Author Topic: help with byte order in memory  (Read 16195 times)

nobody

  • Guest
help with byte order in memory
« on: May 27, 2008, 08:33:15 AM »
so far i thought that if you decide to store a word in memory, say 0x1234, it will look like this in memory: 3412
and, if you want to store a dword (0x12345678), it will then be stored that way: 78563412
NOW, if you want to pick up a word or dword, the same process will happen, to get back to the things you were manipulating in the first place, 0x1234 or 0x12345678.

my problem is, i want to extract a number from a JPEG file. I know that this number is in a word, and that its value is 0x0010 (16)
i extract it: mov cx, word [buffer+4]
now i use a function that shows the decimal number i picked up
(see my previous post here http://sourceforge.net/forum/forum.php?thread_id=1897133&forum_id=167170)
   xor eax, eax
   mov ax, cx
   call showeaxd
i get 4096, meaning the number i picked was 1000h, not 0010h :-((((((((((

for more info i print the output i get with 'hexedit':
00000000   FF D8 FF E0  00 10 4A 46  49 46 00 01  01 01 00 48
00000010   00 48 00 00  FF E1 10 D7  45 78 69 66  00 00 49 49
00000020   2A 00 08 00  00 00 09 00  0F 01 02 00  06 00 00 00
(the word i'm struggling with is at 00000004)

here is the output of 'hexdump'
0000000    d8ff    e0ff    1000    464a    4649    0100    0101    4800
0000010    4800    0000    e1ff    d710    7845    6669    0000    4949
0000020    002a    0008    0000    0009    010f    0002    0006    0000
i never use this one because it seems all data is reversed word by word before it's displayed (??), you can see it at offset 00000022, where i know the value stored is a dword, 0x00000008

Note, JPEG files can be stored in either the Intel or Motorola way, would that be the reason? (this file is Intel)

AC

nobody

  • Guest
Re: help with byte order in memory
« Reply #1 on: May 27, 2008, 11:33:59 AM »
I'm not familiar with the internals of the jpeg format(s). It's not unheard-of for cross-platform stuff to be in "standard byte order", that is, big-endian(!). (the internet, for example, is big-endian) "This file is Intel" doesn't sound like it. The dword 8 at 00000022 appears little-endian. But if you "know" the "word" at offset 4 is 16... that's big-endian. Either the damn thing's random-endian (unlikely, but ya never know) or one of the things you "know" ain't so.

Possible there's a "header" in "standard byte order", and one of those 01s is telling it "following data is little-endian"? ("this file is Intel"?)... Looks like "jfif" following your 10/1000... I dunno, AC!

Best,
Frank

nobody

  • Guest
Re: help with byte order in memory
« Reply #2 on: May 27, 2008, 01:03:11 PM »
>Possible there's a "header" in "standard byte order", and one of those 01s is telling it "following
>data is little-endian"? ("this file is Intel"?)... Looks like "jfif" following your 10/1000... I dunno, AC!

exactly. '4949' at offset 1E tells that the following is Intel. indeed after this indication is a word of control, 0x002A.
I just found out that JPEG files are big-endian !! that explains the big-endianness of the header :)

nobody

  • Guest
Re: help with byte order in memory
« Reply #3 on: June 13, 2008, 12:40:24 AM »
> I just found out that JPEG files are big-endian

COOL.

JPEG: BIG
PNG:  BIG
OGG:  LITTLE
ZIP:  LITTLE