Normalize without losing provenance
Record where a byte range came from: file offset, packet layer, connection direction and capture timestamp. Remove spaces, separators and 0x prefixes while preserving the original dump. Reject odd digit counts and non-hex input. Normalization can remove presentation noise, but it cannot restore omitted bytes or merge unrelated layers safely.
Verify normalized byte count against the selected capture length. Use synthetic or redacted data and keep identifiers fixed-width. If text is present, record its character encoding separately; a hex cleaner cannot decide whether bytes represent UTF-8, ASCII, BCD or a binary integer.
Derive offsets from structure
Byte offsets are zero-based positions after normalization. Derive them from parsed headers and declared lengths rather than counting hexadecimal characters. Optional flags, variable-length fields and nested records can move every later field, so a fixed offset should be tied to an explicit layout condition.
Compare one field across at least two known samples and use a deliberately asymmetric value. Values such as 0x00000000 or repeated bytes can look correct under several wrong offsets and byte-order assumptions. Preserve the extracted slice, width and parent boundary in diagnostics.
Treat byte order as field metadata
Endianness belongs to the field definition, not the workstation. State unsigned or signed interpretation, byte width, scale and sentinel values. Fixed-width identifiers can use the same byte operations as integers while remaining semantically different; do not remove leading zero bytes merely because decimal display does not need them.
For values larger than JavaScript safe integers, use BigInt or preserve hex. A plausible decimal output is not proof of correct byte order. Compare with an independent implementation or a documented test vector before applying the interpretation to production evidence.
Name complete checksum parameters
A checksum diagnosis needs the algorithm variant, polynomial, initial value, reflection behavior, final XOR, byte range and transmitted byte order. CRC-16/MODBUS, CRC-16/CCITT-FALSE and an XOR BCC are different algorithms. Matching only the word CRC or a two-byte result is insufficient.
Validate the implementation with a known check vector before debugging a frame. Exclude or include delimiters, length fields and received check bytes exactly as the protocol defines. Report mathematical value and wire bytes separately because their displayed order can differ.
Build semantic comparisons after structural alignment
A raw hex diff reports positions, but one inserted optional field shifts every later byte. Parse structure first, align corresponding fields and exclude expected serial, timestamp and checksum changes. Preserve unknown data rather than forcing a label. The result should state what is observed, what is inferred and which document defines the interpretation.
- Keep original and normalized bytes together.
- State boundary, offset, width, byte order and scale.
- Validate checksums with complete named parameters.