'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789 /' 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz' > s = 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789 /' This modified unpacking routine is not only changing the value "5" to "4" but is also accessing the string at location 0x51B8 ( "ABCD.890 /") and XOR's the first 52 characters with 0x20 so that it becomes as follows (the XOR operation actually swaps characters): rdata: 004051 B8 aAbcdefghijklmn db 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789 /', 0. The program stopped at 0x4060B where we can see the value 0x34 ( "4") written to our memory location: To confirm that assumption, I set a access harwdare breakpoint at memory location 0x40524C and ran the executable. The only possible explanation is that the packed executable has a modified unpacking routine (actually the UPX utility is using its own unpacking routine when unpacking the executable and hence will never proceed with the code modifications embedded in the initial executable's unpacking routine). If we analyze the packed version directly in memory, we can see that the value at memory location 0x40524C is not "5" but "4": text: 0040147 F jnz short loc_4014EE Will never jump since ESI = 5 text: 00401452 mov eax, ds : std::basic_ostream> std::cout. PE32 executable (console) Intel 80386, for MS Windows UPX 3.91w Markus Oberhumer, Laszlo Molnar
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |