2

enter image description here

In the sourcecode i can clearly see that the Array called "buf" is 32 byte long since 1 char = 1 byte I assume that the array starts at the address [rbp-0x30] and the argv[ ] is stored in the register rsi and moved onto the stack in line 22. Here are the questions:

  • First of all, why is it a QWORD PTR? A Qword is 8 Byte, how does that make sense when a char is only 1 byte
  • Where can i recognize the 32-byte length of the buf-array in the assembler code?
1
  • Could you replace the screenshot by text? You can use code formatting so it’s displayed nicely. – Igor Skochinsky Jan 26 at 8:06
0
  1. The array doesn't start @ -30. That's where the argv pointer is stored, i.e. notice contains of rsi are moved on stack @ 22. Also notice instruction 26 where 8 is being added to that pointer, so that you can access argv[1] in strcpy.
  2. Array is stored @ -20. The array must be stored from -32 to 1 (i.e. from -20h). But there's no way to know this (assuming you don't have symbols or you don't know the source code) without analyzing complete stack and predicting size and locations of other variables (this is a very small program thus you can somehow predict by looking at the code). And with more optimizations, it will be very difficult to predict the existence of that array.
  3. The type information of buff is lost after compilation. This is a very common problem in type recovery.
  4. Workaround - if you have the source code then compiler this code with gcc -g flag. Then examine the symbol table using something like readelf.
  5. Workaround - A naïve decompiler will detect the type as a scalar of size char or int, while a professional decompiler like ida pro will be able to guess correct type information.
0

I think it's possible to estimate the length of the local variable(s) using the instruction at main+0x04 which is sub rsp, 0x30, that's the space the function allocates on the stack for local variables. In your case it's (0x30) 48 bytes, so we now know that the local variables are all 48 bytes or less. argc was provided to the main() function through the edi register as we can see on main+0x08, which is moved into the allocated stack space at offset -0x24.

We know that argc is 4 bytes in length due to the mov instruction at main+0x08, so I imagine the stack is now aligned as follows:

  • From -0x30 to -0x28 = **argv pointer, 8 bytes.
  • From -0x24 to -0x20 = argc, 4 bytes.
  • From -0x20 down to the stored RBP qword = buf, 32 bytes.


enter image description here

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.