An SHB with a magic of 0x1A2B3C4D isn't necessarily little-endian.
If it's 0x1A2B3C4D, that means it has the same byte order as the instruction set for which Wireshark was built[*]; if it's 0x4D3C2B1A, it means it has the opposite byte order. (We assume no "middle-endian" machines here; it's extremely unlikely that any of this code will ever work on a PDP-11.) Wireshark *does* work on big-endian machines (if there are any places where it doesn't, those are bugs that must be fixed), so we can't assume that "same byte order as our instruction set" means "little-endian". [*]If, for example, you run a PowerPC binary under Rosetta, it'll act as if big-endian is the native byte order, even though it's running on a little-endian machine. Change-Id: Ic438bd85c034f1fba276408ba30214d7078121d1 Reviewed-on: https://code.wireshark.org/review/14133 Reviewed-by: Guy Harris <guy@alum.mit.edu>
This commit is contained in:
parent
84ac392e9f
commit
24aaddcf43
|
@ -543,7 +543,7 @@ pcapng_read_section_header_block(FILE_T fh, pcapng_block_header_t *bh,
|
|||
version_major = shb.version_major;
|
||||
version_minor = shb.version_minor;
|
||||
|
||||
pcapng_debug("pcapng_read_section_header_block: SHB (little endian) V%u.%u, len %u",
|
||||
pcapng_debug("pcapng_read_section_header_block: SHB (our byte order) V%u.%u, len %u",
|
||||
version_major, version_minor, bh->block_total_length);
|
||||
break;
|
||||
case(0x4D3C2B1A):
|
||||
|
@ -555,7 +555,7 @@ pcapng_read_section_header_block(FILE_T fh, pcapng_block_header_t *bh,
|
|||
/* tweak the block length to meet current swapping that we know now */
|
||||
bh->block_total_length = GUINT32_SWAP_LE_BE(bh->block_total_length);
|
||||
|
||||
pcapng_debug("pcapng_read_section_header_block: SHB (big endian) V%u.%u, len %u",
|
||||
pcapng_debug("pcapng_read_section_header_block: SHB (byte-swapped) V%u.%u, len %u",
|
||||
version_major, version_minor, bh->block_total_length);
|
||||
break;
|
||||
default:
|
||||
|
|
Loading…
Reference in New Issue