Then,you can change the instructions in the address contains "oep" to "jmp itself"(that is patching the first 2 bytes to EB FE).In the above example it's "jmp 0x121000".After calling "WriteProcessMemory" and "SetThreadContext",you will see codes run in a loop at the "oep" of target process because the instructions are changed to "jmp oep",in the above example it's "jmp 0x401000".the target process "stops". You can easily calculate the offset between "oep" and "lpBaseAddress",then, if the offset>0 as well as the offset< parameter "nSize",add the offset to "lpBuffer",you will get the address contains "oep" codes in the buffer.įor example, the "oep" of target process is 0x401000, the parameter "lpBaseAddress" is 0x400000,the parameter "lpBuffer" is 0x120000,so the address contains "oep" codes in the buffer is 0x401000-0x400000+0x120000=0x121000. Ollydbg saved changes delete itself how to#Most of the time when a malware has injected itself into another process,it will call "SetThreadContext" to set the CONTEXT structure.You can easily get the "oep" of the target process through the "eax" member in the CONTEXT structure.The "oep" stands for the original address when target process resumes,you can make a loop at the "oep" so that the target process will always run in the loop.But how to make a loop in the"oep"?Ī malware often call "WriteProcessMemory" to write codes into target process.The second parameter of "WriteProcessMemory" is "lpBaseAddress",it means where this codes begin in the target process.And the third parameter is "lpBuffer",it stands for the buffer contains this codes. Ollydbg saved changes delete itself code#Instead of changing the target process you can do as C0rK1 suggested in his answer, and modify the first two bytes to jmp self (x86/64 bytes are EB FE), and then let the malicous code execute in that loop, suspend the process, place a breakpoint on the jump self loop and replace it with the original code manually. You'll need to kill it and then reopen it from within ollydbg. You can also debug iexplore.exe if you're interested. It is probably reasonable to create a dummy process (I often use calc.exe) you created debugged, let the malware inject into that process instead of original target, then BP the injected code and let it run. Redirecting it to the same process might work, but it may also cause issues. Make sure you redirect both the memory writes/injections and the code execution. Therefore, you can easily breakpoint on the injection procedure and redirect it to another process. Most of the times when a malware does something like that it's simply to make debugging it harder.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |