IF you are a malware writer, or just curious, or landed on this page accidently, this post will show how you could fool all those smart disassemblers, quiet easily!
Output:
Woops! We can't see any "call <some_address>" instruction. Why?
Here, I used the "_emit" instruction to emit a byte (0x0F) in the assembly. Now, when the disassembling engine encounters our first conditional jump, it goes there, starts decoding it, assuming it as an instruction and hence, screwing everything ahead!
This trick is enough to fool debuggers like IDA Pro, Immunity Debugger, OllyDBG, etc.
This isn't a flaw in any of the disassembling engine, it's just how they are designed to work. We basically exploited the limitation. Nothing great and guess what.. one could still easily get the original "hidden" instruction from the above. Figure that out yourself now.
Well, that's about it. Have fun playing around.
How they work?
Apparently, there are two methods : linear sweep and recursive traversal.
Linear sweep is simply.. read data, decode it, and get the actual code step-by-step.
Recursive traversal is a little bit "smarter" method than linear sweep, based on control-flow analysis.
But.. both approaches are limited and could be exploited by a malware writer.
Here's how it's done.
Output:
 |
| "main" method disassembled |
Woops! We can't see any "call <some_address>" instruction. Why?
Here, I used the "_emit" instruction to emit a byte (0x0F) in the assembly. Now, when the disassembling engine encounters our first conditional jump, it goes there, starts decoding it, assuming it as an instruction and hence, screwing everything ahead!
This trick is enough to fool debuggers like IDA Pro, Immunity Debugger, OllyDBG, etc.
This isn't a flaw in any of the disassembling engine, it's just how they are designed to work. We basically exploited the limitation. Nothing great and guess what.. one could still easily get the original "hidden" instruction from the above. Figure that out yourself now.
Well, that's about it. Have fun playing around.
I checked it with IDA Pro, WinDBG, and Visual Studio Debugger (Debug and Release build, both). Though this trick results in incorrect assembly listing, bypassing it and finiding actual stuff is damn easy!!!
ReplyDeleteSorry to say, this trick is not effective.
... and that's exactly what is mentioned in the last para.
DeleteWell, it's just one more obstacle for the analyst.
It's a trick to discourage analysis, you can find that inside every packer. Sorry to say, your statement is shit.
DeleteThis comment has been removed by the author.
ReplyDeleteModify the text section as RWE and modify 1 byte of the next instruction, you will see IDA threatening the next opcodes as data. Pastebin is offline so enjoy a raw code:
ReplyDelete//=========================================================================================
// Result: http://i.imgur.com/8aA7qex.png
//=========================================================================================
__declspec ( naked ) void gay_marriage_ ( void )
{
__asm
{
MOV BYTE PTR [ NextInstr1 ], 0x90
NextInstr1:
__emit 0x00
pause
nop
pause
nop
pause
nop
pause
nop
// add your shit here and stay cool, gay marriage will not be legalized again.
// of course if you add a retn Ida will come back blaming you to be a nigger
// so if you still care to retn and dont want to jmp ( if so you are an idiot )
// to your code routine, just put that at the end of this gayasm block:
// MOV BYTE PTR [ GayInstr ], 0xC3
// GayInstr:
// __emit 0x00
}
}
//=========================================================================================