2

So I'm looking for some guidance on this topic.

If I open up my exe in a Hexeditor and go to the location where the address of the string is pushed as argument I have the following:

68 7C 9D F1 01 - push 01F19D7C

The string in the exe however is at 01ADC808.

I do have the same exe but for a different language.

68 78 DE F0 01 - push 01F0DE78

and the string is at 01B94B0C.

Looking at it in Ghidra for example, the address from the push instruction matches the location of the string. So currently my best guess is, that Ghidra aligns the data properly with info from the PE Header.

I'm writing a tool that modifies that string. Patterns could be created for each version, however I'd like a rather "universal" way to solve this.

Additionally, here's the overview for the Section Headers for the first example: enter image description here

Feel free to let me know if my question was not clear enough or more information is required!

Thanks in advance for any advice! :)

EDIT: Forgot to mention the tool I'm writing is written in C#.

2 Answers 2

2

push 402010 is broken down like

402010 - base_address - virtual_address_of_section + file_ptr_to_rawdata

your data has some inconsistencies it must be a counted string or pascal string etc there is a 4 byte mismatch between the addresses 0xc/0x8

disassembly of a string push

0:000> u . l4
msgbox!WinMain:
002c1000 55              push    ebp
002c1001 8bec            mov     ebp,esp
002c1003 6a00            push    0
002c1005 6810202c00      push    offset msgbox!⌂USER32_NULL_THUNK_DATA+0x4 (002c2010)

0:000> db 2c2010 l20
002c2010  57 69 6e 64 20 54 65 73-74 00 00 00 54 65 73 74  Wind Test...Test
002c2020  20 54 68 65 20 57 69 6e-64 00 00 00 00 00 00 00   The Wind.......

0:000> ? msgbox
Evaluate expression: 2883584 = 002c0000

0:000> ? 2c2010 -msgbox
Evaluate expression: 8208 = 00002010

0:000> .shell -ci "!dh -s msgbox" grep -A 5 #2
SECTION HEADER #2
  .rdata name
     206 virtual size
    2000 virtual address
     400 size of raw data
     600 file pointer to raw data


0:000> ? 0x2010 - 0x2000 + 0x600
Evaluate expression: 1552 = 00000610

0:000> q
quit:

dispaly on hexeditor

:\>xxd -g 1 -s 0x610 -l0x20 msgbox.exe
0000610: 57 69 6e 64 20 54 65 73 74 00 00 00 54 65 73 74  Wind Test...Test
0000620: 20 54 68 65 20 57 69 6e 64 00 00 00 00 00 00 00   The Wind.......
1

You are right, this is because of alignment. There are 2 types of section alignment. Alignment on disk, and alignment in memory. They usually equal 0x400 and 0x1000 respectively. When you open exe in hexeditor, you should notice that your .text section starts at 0x400, but Ghidra shows you exe as it would be in memory, so .text now starts at 401000 (imagebase + virtual address). The best way to solve this problem is to use:

CreateFileMapping, MapViewOfFile, ViewMapOfFile

1
  • Thank you for your answer :) So if I understand this correctly, the address used by the push instruction is basically the one being used with the "in memory alignment" you mentioned. If that's the case, I assume I can just parse the PE Header, read the involved sizes and calculate the correct address in the file from there? I forgot to mention that the tool is written in C#. I apologize.
    – c0dy
    Commented Apr 3, 2019 at 12:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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