Shifting yourself to space

May 31, 2011

The case of the spying eyes: blizzard stubs

Filed under: Uncategorized — shift32 @ 11:17 pm
Tags: , , , , ,

So I finally managed to unpack SpyEye this Saturday, and only today (Thursday) had the time to start actually exploring what it does,
I’ve heard and read from friends and the net that SpyEye got some several interesting modules
also it’s module load – use – unload technique seemed interesting. I’ve also heard that it steals money and performs different kind of phising attacks, all of this seemed quite interesting to research.

I’ve hooked up olly and opened the unpacked version of spyeye, opened the names bar and looked for interesting function to set breakpoints on, I’ve also searched for all intermodular calls and found some (even more) interesting functions

As it seems, SpyEye doesn’t import all the function it’s using in it’s IAT, as when inspecting it with PEiD or anything else you see not many functions

To my humble guess it’s using a simple (yet, known), “trick” of dynamic libary loading, I have first seen it in uninformed and the technique is quite nice (originally by lsd-pl folks)

As olly shown in the “show all intermodular calls” window, it seems

However, be mistaken not – the calls repeat themselves, what really caught my eye was the unresolved call here, I’ve set bp on every possible call outside and started my static analysis journey

I started stepping the code, not running it, to see if there are any interesting things and it seems that the start of the code had some nice spots

The first thing which caught my eye was that SpyEye looks for kernel32.dll by first getting it’s address from the PEB, by walking through it’s linked list, this method is quite known as i mentioned earlier by uninformed ,however, spyeye doesn’t use a loop to look for kernel32.dll it
goes through two values and hopes for the best – if someone put kernel32.dll in a different place in the linked list – SpyEye is a bit doomed (;

The other thing which caught my eye was that SpyEye accesses its .rsrsrc section (resource), it gets a handle to them, changes their permissions and continues onward – this is something which might be pretty interesting

the find.resource calls are to find the specified resource with GetModuleFilenameA function
and the rsrsrc.alter.perm are to alternate the permissions the resource has probably to FFFFF, or something like it, it is still unknown what their purpose is, so I don’t know what to look for

One of the resources starts with a string “!EYE” which hints for some propriatery struct for SpyEye (or perhaps something different ? we don’t know yet)

There’re basically three resource section I got my eye on – C1 C2 and C3, but I didn’t find any usage with/of them for now, so we’ll leave them for now.

Also I found several strings which got my eye glitchy

Remember “algonic” from the previous posts ? this is the name of the child process that our malware creates, as for config.bin – well the name answers for everything, it seems to be some sort of configuration SpyEye has, perhaps it contains C&C IPs and passwords to communicate with our big brother

After stepping more code I’ve found some small jackpot, I remember when I was unpacking SpyEye I got really frustrated when I didn’t know which functions SpyEye was using in order to allocate space for itself, and once I’ve found them – everything went alot easier,
So after stepping some code I found that SpyEye calls NtAllocateVirtualMemory to allocate space for something…something big, as of writing now I have a few clues of what it might be, but I still can’t be sure,
however my guesses go from
1. a huge decryption stub to decrypt the configuration and other resource section
2. a huge decompression/compression stub to de/compress something else
3. something else I have no clue yet (always leave room for the unexpected, hehe)

Why am I not thinking about hooking processes ? because as it seems SpyEye is only going through the tasklist at later stages of the code, I’ve seen a few calls to GetCurrentProcessId, and you are right if you said that it doesn’t prove anything, this is only a guess…I’m writing this while still disassembling everything..
However in order to prove more that I’m right I’ve scrolled down with olly a bit more and found this little interesting (yet, exciting) block :

See the comments olly adds on the side ? see smss.exe, csrss.exe, services.exe, etc ? does this look to you like something that would’ve done after we hook things up ? This looks like a prologue to something…something interesting (:

I kept stepping the code until I reached the copy of a resource section, however, the rest seems to be like a topic for another post,
To be continued(:

May 28, 2011

The case of the spying eyes: The third eye

Filed under: Uncategorized — shift32 @ 4:52 pm
Tags: , , , , , , ,

About an hour ago I managed to fully unpack SpyEye, my work was stopped due to other commitments but this morning I promised myself that I’ll try finishing the initial analysis.

The sample I have of SpyEye is triple packed with three layers of known packers, the configuration stub crypto and probably anything else is totally different topic

UPX is quite easy to unpack, basically when you hook up olly you begin at the regular “pusha” instruction

The first thing you gotta do is just scroll down until you meet lots of “db 00”
and set a breakpoint at

sub esp,-80
jmp entryPoint

This would be the last jump before you hit the entry point of the executable, in our case – we’ll hit the ep of ASPack, since my sample is triple packed

In order to get the decryptor stub, we’ll be setting a breakpoint at VirtualAlloc, as this is the function which is used to allocate the space for the function,

Once we hit VirtualAlloc, we’ll step over and return to the caller, we could see where the decryption stub will be written to by the return value of eax

So we set a memory bp on the address eax points to and run –
we hit one rep stos instrcution which copies the decrypted stub into the location and hit step over to complete the copy process

Right now we have the function which decrypt the real (packed with UPX) exectuable code, I’ll try to analyze it once I’ll finish the global analysis, in order to get to the real entrypoint, we have two possibilities:
1. Step the code and look for interesting writes and reads
2. Set a bp at the function which allocates space for the EP

The first option would work if we didn’t know which function is used to allocate the EP, however it would be tedious work.
The second option is quite easier, as assuming we don’t know which function actually writes the EP code, we set a bp on every interesting allocation function, this includes – (amongst others) – VirtualAlloc, VirtualAllocEx, NtAllocateVirtualMemory, GlobalAlloc, HeapAlloc, etc
I’ve had a few hints from friends and managed to figured that the function is ZwAllocateVirtualMemory

I’ve set a bp on ZwAllocateVirtualMemory and hit F9 in olly, the first occurrence was the routine which copies the decrypted PE.

Once the PE was written to it’s original place just hit twice “execute till return” and you’ll hit a ret that get you into ZwFreeVirtualMemory, return there and you’ll hit the EP
You’re now in the EP of the UPX packed code, as this is – once again – quite easy to unpack –
just jump to the real EP and have fun

To be continued.

Edit: the post is a bit messy, I’ll rewrite it later on

May 25, 2011

The case of the spying eyes

Filed under: Uncategorized — shift32 @ 10:48 pm
Tags: , , , , , ,

I found this sample of an interesting spyeye malware packed with UPX and ASPack,
and decided to reverse it on my own.
As I’ve never unpacked ASPack I decided to look around and found two interesting anchors,
both are interesting win32-api memory allocation functions which are called VirtualAlloc and ZwAllocateVirtualMemory

But before reversing the malware itself I wanted to see what goes “on the hood”, as Mark Russinovich documents in his blog
In other words – before dwelling into an unpacking nightmare I want to see what sort of files it adds to the system, what registry keys it modifies, what sort of hooks it adds etc

So onward my small journey I’ve hooked up several processes (sysinternals + rku, rootkitRevealer)
I’ve set a snapshot on the vm to return to my initial status after executing and executed the binary

And there I’ve had it, after just executing it everything remained the same, I’ve looked at procmon and regmon to see what sort changes in their process tree and started investigating.

Before running the malware I’ve used shellrunas to first run the malware in a Guest user restricted mode, just to see how it handles things, and I saw that the malware forks itself to a new process called “algonic.exe”,

I’ve set the process in suspended mode and started looking at the log of procmon to see which values it tried modifying

Considering that the malware doesn’t have any zerodays it couldn’t leave Guest user, and execute code in ring0, this helps a bit as I know I’m dealing with any kernelmode malware

Now onto the interesting part, I’ve looked at procmon and saw that the process fork itself and looks for certain specific registry values such as ComputerName,
“HKU\S-1-5-21-1547161642-152049171-839522115-501\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders” ,
“HKU\S-1-5-21-1547161642-152049171-839522115-501\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Cache” , “HKLM\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers\Paths\{dda3f824-d8cb-441b-834d-be2efd2c1a33}” etc,

it tries to lower down the security attributes ie has, open different know dlls (ntdll, wininet, usp01 (??), windows Shell manifest etc),

At this time of writing I do not know the purpose of all those, I can only think it wants to hide itself (with hooks, though), and add different malicious things
I can also ponder that it tries to collect information about the system, if the malware is smart enough it will detect that it’s running inside VirtualBox ( as vbox has two main processes with *vbox* initials inside them, though there are other ways to detect you’re inside a vm like timing-attacks etc )

One interesting thing my eyes caught was that the malware tries to read the

E:\Documents and Settings\Guest\Application Data\Microsoft\SystemCertificates\My\CRLs

This path is quite important as it includes the local system certificates the user has, adding the virus’s certificate to the trusted path will probably break any av or scanner that tries to look for malicious things automagically

Aight, enough for that now –
Let’s move onto the real binary – the algonic.exe which seems to do all the dirty job
[btw, as this time of writing, since no dynamic/static analysis of the binary is done, it is quite unknown what the malware is looking for, I can only assume that I’m missing alot of under the hood stuff, but that’s only an assumption which must be analyzed and faced ]

The algonic.exe is located in the same root drive the malware was originally located, in my own situation it’s located in


The folder is secret and probably well protected if ran with administrator privileges.
The folder contains to files – algonic.exe and config.bin

I’ve hit PEiD on algonic.exe and I wasn’t surprised to see that it is indeed also packed with UPX and
probably also with ASPack,
at this point I’ve unpacked the UPX packing protection by simply putting a bp at 497F3 which is probably the most classical way to unpack most UPX versions

I’ve set also two hardware breakpoints – one for each unique function I was hint’ed, one for VirtualAlloc and one for ZwAllocateVirtualMemory,

Once I’ve hit both bp’s I’ve managed to get the decryption stub, and also the function which calls the EP, I’ve seen the real PE header (at 0x4000000) and currently I’m reversing the last part of the loop before reaching the last popad + ret part.
(I do want to apologize for not writing too much about this phase, but since it’s incomplete I’m still unsure what I am missing and what’s not)
Wish me luck.

To be continued

May 23, 2011

Nanomites – First thoughts

Filed under: Uncategorized — shift32 @ 4:19 pm

After reading about nanomites I got quite excited and thought about implementing it on Linux
I thought it would quite easy, however it didn’t seem as the development started.

My work was basically based upon signals, whenever an application hits a signal
it goes to a signal handler, either registered by the parent process (debugger, etc)
or that the executable itself has it’s own signal handler

Signals are not a vague topic in Linux and there’s full documentation, I read a few papers about them and started working

1. SINGLESTEPPING with int $3

The basic idea was this –
1. Executable executes it's instructions one by one.
2. A signal handler is registered to handle interrupt traps
3. When the executable hits int $3 - Interrupt Trap the signal handler is executed
3.1 The signal handler check its tables against the current EIP to see whether or not it's a nanomite
3.1.1 Assuming it is a nanomite - the handler replaces the instructions of int $3 with the real instructions
3.1.2 The handler transfers execution to the executable to continue its journey

Problems –
1. When an int $3 is occured the program stops :/ so you can’t do anything
2. It’s not that easy to replace instructions due to sizes, int $3 only takes two bytes, while the real instructions might take more…

The solutions I tried going with were basically these:
1. Use PTRACE (shrug, I know) interface in order to single-step the executable and look for “cc” opcodes (int $3) using PEEKUSER parameter in the ptrace(…) function
2. The instructions after the int $3 will be padded with nops/garbage so we could replace them upon runtime

2. Using a different signal than int $3

I chose a random signal than int $3 and hoped for good, the idea was basically the same except this time I wasn’t using ptrace() at all
The problems which occured were that I was unable to write code to the running process and thus had to continue execution in my own huge char tables[c0de] = { “\xcd\x80”} array

3. Section permissions

This is a theoretical idea which I read that was implemented in the Shrinker packer (win32)
We set our section permissions to non-readable/executable and once a signal is raised we check our tables

Every packed section is encrypted and has no read/execution permissions
Each time there’s a jmp a section without read/execution permissions a signal is raised
We intercept the signal and on the fly decrypt one instruction at a time (and not the whole section, to avoid cold memory attacks) and execute it on the fly
The section remains encrypted and once its execution is done we set back the permissions to non-readable/execution

I haven’t started implementing it yet but it seems quite interesting work.

Stay tuned (:

May 21, 2011

Push `n call

Filed under: Uncategorized — shift32 @ 8:43 pm
Tags: , , ,

I’m no glorious reverser, however I’m always glad to learn some cool new technique to
detect interesting behaviour
As my journey reversing for fun and non-profit I got into different methods to call a function
in an “obfuscated” way

Such way that in most cases you won’t be able to know where the call would actually go to
The actual value of the call is decided upon runtime and is based on the value of a few things
The actualy value of the call is decided upon runtime and is based on usually one of things below:

1.The value of the register
For example – let’s take a look at this simple method

mov eax,[ebp-22]
shl eax,3
call eax

in this example below the value of ebp-22 can be calculated upon runtime
but if we’d try to statically analyse the function it will be quite hard to follow the stack changes and call
as this example is quite abstract, most malware add different kind of obduscation methods
such as different calls to useless function and register manipulation

2. push `n ret

push 5
push &exit
call obfuscation_method

In this example it gets a bit trickier, obfuscation_method doesn’t really interest us
since once we’ll comeback from obfuscation_method, we’ll be back to the previous stack frame
and since we’ve pushed the address of printf beforehand – we’ll return to it immidiately after calling obfuscation_method

3. nopsled, bruteforce

In this specific method we don’t really know at all (nor does the program itself) where are we going
The method is based on a simple “brute-force” loop which tries calling addresses by simple arithmetic manipluation

mov eax,&base_offset
call [eax+ecx]

in this specific method we’ll have to allocate an array of MAX_BASE_OFFSET
pad it with nops or garbage instructions and add our real code in specific location for example

[ ... real code goes here ... ]
[ ... more real code goes here ... ]

it is quite hard (and frustrating) to know where the real code is especially if don’t have nops and real garbage code the disadvantage in this specific method is that you must align you code perfectly else you’ll get an exception of an invalid instruction

this method is quite equivalent to a malware which doesn’t know it’s decryption key (same concept) and so it just bruteforce’s itself until it finds the key the disadvantage here is that you’ll need large computation power in order to get they decryption key when not dealing with the classical xor/XTEA/etc crypto

4. nanomites

I’ve read about this method in peter ferrie’s article and decided to try to implement it on my own
From Peter Ferrie’s article :

Nanomites are a more advanced method of anti-dumping.
They were introduced in Armadillo. They work by replacing
branch instructions with an “int 3” instruction, and using
tables in the unpacking code to determine the details. The
details in this case are whether or not the “int 3” is a
nanomite or a debug break; whether or not the branch
should be taken, if it is a nanomite; the address of the
destination, if the branch is taken; and how large the
instruction is, if the branch is not taken.
A process that is protected by nanomites requires selfdebugging
(known as “Debug Blocker” in Armadillo, see Anti-Debugging:Self-Debugging
section below), which uses a copy of the same process.
This allows the debugger to intercept the exceptions that are
generated by the debuggee when the nanomite is hit.
When the exception occurs in the debuggee, the debugger recovers
the exception address and searches for it in an address table. If a match is found, then
the nanomite type is retrieved from a type table. If the CPU
flags match the type, then the branch will be taken. When
that happens, the destination address is retrieved from a
destination table, and execution resumes from that address.
Otherwise, the size of the branch is retrieved from the size
table, in order to skip the instruction.

This method however adds much more complication to the code you’re writing
and divides it into separate projects:

One is your original project which has all the code you’ve written originally

The other is a “stub” ( those who ever wrote a packer would know this acronym better than I do) that keeps track of the nanomites and knows when a real nanomite is hit and not a regular int 3 instruction caused by the debugger / compiler.

The third is a project that injects the stub ( PE/ELF file manipulation, adding a new section if necessary ) and replaces the calls/jmps
with nanomites (int 3 instructions)

This is a whole new level of complication and it really frustrates the reversing process, not talking about that it is really hard to statically reverse such binary
without having all the instructions in your hand….

Blog at