running on windows 7, 32bit home pro
I created a very simple few line app in visual studio 2008 , compiled and linked with standard libraries in release mode into executable test.exe.
The code in c is as follows:
char* test = "h";
int main()
{
_asm
{
push 0xFEEDBACC;
}
MessageBoxA(0,test,test,0);
}
which results in the following machine code and corresponding assembly as viewed in VS2008 (addresses rebased below, normal starting virtual address of 0x4001000)
char* test = "h";
int main()
{
_asm
{
push 0xFEEDBACC;
00261000 68 CC BA ED FE push 0FEEDBACCh
}
MessageBoxA(0,test,test,0);
00261005 6A 00 push 0
00261007 68 F4 20 26 00 push offset string "h" (2620F4h)
0026100C 68 F4 20 26 00 push offset string "h" (2620F4h)
00261011 6A 00 push 0
00261013 FF 15 A4 20 26 00 call dword ptr [__imp__MessageBoxA@16 (2620A4h)]
}
Now instead of calling MessageBox I want instead to push another string "h" right after the push 0, so using hexedit I search for the section containing FF15A420... and overwrite it to become
90 68 CC BA ED FE
Now if I open up the executable in IDA free i see the following in my .text section:
.text:00401000 push 0FEEDBACCh
.text:00401005 push 0
.text:00401007 push offset unk_4020F4
.text:0040100C push offset unk_4020F4
.text:00401011 push 0FFFFFF90h
.text:00401013 nop
.text:00401014 push 0FEEDBACCh
.text:00401019 retn
this looks good so far , i see at 0x401014 my new push statement.
Now, if I debug the exe in IDA free suddenly I see my code changes (see below) the push 0FEEDBACC becomes push 0FFA4BACC and I cant see why the first 2 bytes are changed.
.text:00F71000 push 0FEEDBACCh
.text:00F71005 push 0
.text:00F71007 push offset unk_F720F4
.text:00F7100C push offset unk_F720F4
.text:00F71011 push 0FFFFFF90h
.text:00F71013 nop
.text:00F71014 push 0FFA4BACCh // im puzzled!
Can anyone explain what is going on here and why the number I am pushing on is getting modified? I tried changing the starting physical byte of this address (suspecting some sort of alignment issue) but it didnt seem to make a difference.
Thanks,
skimon