I was having a look at today’s ecard.exe spam campaign (detected as Troj/Agent-HRI) and saw an anti-emulation trick I hadn’t seen before.
Quite a lot of the samples we analyse at the moment use multiple stages of maths to calculate values, to avoid you being able to see what they’re doing quite so easily, and this is no exception. It starts off by calculating a dword value,
0xF02464FF, and pushing it to the stack:
That number doesn’t raise any immediate alarms (to me anyway), so we’ll move on.
A little while later it calculates another value,
0x58585858, and again pushes it to the stack:
Now that’s a little more obviously interesting, though it’s not immediately apparent how it’s going to be relevant. But then all is made clear shortly afterwards when it executes a call to the stack:
At this point, it’s clear that the first two pushes have been carefully setting up some code on the stack, so let’s see where we’ve landed:
Those two dword values we pushed earlier have become four pops and a jump – so what do they do exactly?
When executed the call to the stack, we implicitly pushed our return address to the stack as well – the first pop picks that up. Then the second pop picks up the
0x58585858 value (never mind that we’re half-way through executing the code that the
0x58585858 represents), and the third pop picks up the
But now we’ve run out of things that we’ve pushed to the stack, so what does the fourth pop get? It picks up the value that was on the top of the stack when we started to execute the file – and for a Windows executable, that’s a pointer into kernel32.dll to code which calls ExitThread.
Next we jump to [esp-10h], which is the same as saying we jump to the value that was on the stack before we started popping from it … in other words we jump to our return address back in the main code.
So now we’ve returned from the stack, and for our pains we’ve picked up a pointer to some code in kernel32. What next?
The code picks up a dword
0xE bytes before that ExitThread code, then starts adding numbers to it, and those additions determine whether or not we then take a conditional jump. In fact if you tally up the numbers that get added, they come to –
0x6A096A50 … which exactly matches the code you’d find
0xE bytes before that ExitThread code. So adding those values together gives you zero, and the conditional jump isn’t taken.
However if you were running this in an emulator or sandbox that didn’t exactly map out what this was expecting to find in kernel32.dll, you’d end up taking that conditional jump into the middle of nowhere.
After all that reasonably complex code, it then continues with some quite disappointingly straight-forward decryption – clearly all the development time had been spent on the earlier anti-emulation technique.
Let’s see if tomorrow’s ecard.exe outbreak brings anything else interesting.