Examining data stored in the memory of the program may be interesting to understand low-level mechanism of variable management and type conversions. Let's dump content of an integer bytewise:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
#include <stdio.h> int main(){ /* Integer to be printed as hex */ int a = 0x89AB07CD; /* Pointer to integer "a" */ int *aptr; aptr = &a; /* Pointer to a character */ char *cptr; /* Casting a pointer to an integer to a pointer to a character */ cptr = (char *) aptr; /* Print as hexadecimal */ printf( "%02X, %02X, %02X, %02X\n", *cptr, *(cptr + 1), *(cptr + 2), *(cptr + 3) ); return 0; } |
Pointer to an integer is casted to pointer to a character, which means that when we dereference it, we expect to obtain a single byte. Printing 4 bytes of integer "a" as a hexadecimal number one byte at a time can be done by incrementing "cptr". Compiling with embedding debug information and executing the program yields:
|
1 2 3 |
[johndoe@ArchLinux]% gcc -g Print_Int_as_Hex_via_char.c -o Print_Int_as_Hex_via_char [johndoe@ArchLinux]% ./Print_Int_as_Hex_via_char FFFFFFCD, 07, FFFFFFAB, FFFFFF89 |
Oops, it is not what we expected. Bytes starting with "1" at the most significant bit (MSB) position now have "FFFFFF" appended in front of them. It turns out "char" data type is signed on Linux amd64 platform and behaves as a signed 8-bit integer. When "cptr" is dereferenced, the content is extended to a size of an integer. Compiler assumes that it is a negative number (it starts with "1" at MSB) and hence appends "FFFFFF" to preserve the sign information.
Let's look at the assembly code in radare2:
|
1 |
[johndoe@ArchLinux]% radare2 Print_Int_as_Hex_via_char |
Running "analyzing all an autonaming functions" command ("aaa") increases readability of the code and renaming local variables on the stack helps tracking them down:
The most interesting instruction is at 0x00400501 (similary at 0x0040050f, 0x0040051d, 0x00400527):
|
1 |
movsx esi, al |
It moves content of a one-byte register "AL" to a double-word register "ESI" with extending the sign. Here is the place where "FFFFFF" is appended.
Fixing this issue may be done by using "uint8_t" data types defined in "stdint.h":
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
#include <stdio.h> #include <stdint.h> int main(){ /* Integer to be printed as hex */ int a = 0x89AB07CD; /* Pointer to integer "a" */ int *aptr; aptr = &a; /* Pointer to an 8-bit unsigned integer */ uint8_t *bptr; /* Casting a pointer to an integer to a pointer to an 8-bit unsigned integer */ bptr = (uint8_t *) aptr; /* Print as hexadecimal */ printf( "%02X, %02X, %02X, %02X\n", *bptr, *(bptr + 1), *(bptr + 2), *(bptr + 3) ); return 0; } |
Compiling with embedding debug information and executing the program yields:
|
1 2 3 |
[johndoe@ArchLinux]% gcc -g Print_Int_as_Hex_via_uint8.c -o Print_Int_as_Hex_via_uint8 [johndoe@ArchLinux]% ./Print_Int_as_Hex_via_uint8 CD, 07, AB, 89 |
The code works as we expected. Analyzing it in radare2 reveals one important detail:
The instruction at 0x00400501 (similary at 0x0040050f, 0x0040051d, 0x00400527) is replaced with a move instruction with zero-extension:
|
1 |
movzx esi, al |
So maybe it is logical to use fixed data types which are not dependent on the platform to avoid such unexpected behavior.