It’s been a busy week at work. Lots of unique malware. As you may or may not know, malware uses non-conventional things to stay hidden and throw off heuristic analysis.
I see weird stuff. Instructions that make no sense in context like the ‘out’ instruction, blocks of code which perform floating point arithmetic for no reason other than to do it.
I see this on a daily basis. Weird opcodes, memory packing, wacky logic, etc. This week I was unpacking a program that did the usual ‘store everything in the data section then virtualquery / run’ trick. But it was wacky confusing. After unpacking, the binary was different – different md5 / larger, but it looked the same in IDA and immunity. I unpacked it again several more times only to realize the program was making a copy of itself and storing it in the same location I unpacked it from, except it was setting a breakpoint before calling itself. I determined this had something to do with the OpenProcess call which was skipped at the program’s startup, then I lost interest.
How do they do it? They have more time on their hands.
So what did I learn today? I learned how to get the same weird opcodes into my programs even if my compiler throws a shit-fit.
Compile your program, inline a nop sled or something easy to identify, then find / replace.
In this case, I am doing several int3 interrupts RDTSC instructions in a row (0xCC & 0x0F,0x31).
And now we look in the hex editor for the op codes CC 0f 31.
Now what we do is replace the op codes with the ones the compiler didn’t allow us to add and nop out the rest.
I did this to force insert the icebp (int01) break point into my program. Its an undocumented op code which does a breakpoint without setting the trap flag.
Save and we’re good.
There are plenty of instructions out there to mess with. Using this crude method, I can force my instructions into my programs without the compiler giving me shit.