NASM - The Netwide Assembler
NASM Forum => Using NASM => Topic started by: nobody 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) (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
-
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
-
>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 :)
-
> I just found out that JPEG files are big-endian
COOL.
JPEG: BIG
PNG: BIG
OGG: LITTLE
ZIP: LITTLE