This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

HEX Interpretation

0

Excuse me if this sounds like a stupid question or maybe i need a revision lesson. I have a HEX printout in Wireshark 0C27 Am i right that this is reversed to interpret as 270C or have i got this wrong. I ask because when converting using HEX calculator my result is 3111 Yet i am expecting the result 9996

Thanks in Advance Sven

asked 29 Sep '11, 22:47

Sven's gravatar image

Sven
1112
accept rate: 0%


2 Answers:

2

Welcome to Gulliver’s Travels, the confusing world of endianess. When you have a sequence of symbols it's always required to know in which order to interpret them.

Least significant bit vs. most significant, the bit order in an octet (8 bit sequence).

Least significant byte vs. most significant byte, the byte order in a word, long word, quad word, etc.

In your case it's the endianess of a 2 byte number that confuses you. You interpret it as big endian, which results in 0c27(hex) = 3111(dec). But since you know it's 9996(dec) = 270c(hex) you now know to interpret it little endian.

answered 30 Sep '11, 00:12

Jaap's gravatar image

Jaap ♦
11.7k16101
accept rate: 14%

Thanks for the advice the tips

(30 Sep '11, 00:52) Sven

2

Whether some part of the hex data is interpreted as big-endian or little-endian all depends on the protocol and sometimes even on the application or OS.

If you look at the sequence numbers in icmp echo packets. Although each ping program will count 1,2,3,4,etc, on the network it looks like 0x0001, 0x0002, 0x0003, 0x0004 for some systems and 0x0100, 0x0200, 0x0300, 0x0400 for others.

For well defined protocols, the protocol description should tell you how the values are put on the network. So in your case, it all depends on the definition of the protocol at hand.

answered 30 Sep '11, 00:13

SYN-bit's gravatar image

SYN-bit ♦♦
17.1k957245
accept rate: 20%

Thanks what confuses me is that in the same message i get 52F020 which translates as 5435424 which is correct. Think i will have to do some reading this weekend.

(30 Sep '11, 00:51) Sven
1

Many protocol make a blanket statement about endianess, like "the packets will be transmitted in network order". This means big endian, by the way, see RFC1700.

The host could be big or little endian in it's memory access. Hence any portable software must, before sending / receiving packets, be aware of this and convert multibyte fields between the two using htonl|s / ntohs|l respectively. These macro's are empty on big endian architectures, and swap on little endian architectures.

This is where the ICMP count issue comes from.

In your example it seems there's a mix in endianess.

(30 Sep '11, 07:25) Jaap ♦