My infected computer

This is a sort of continuation of the previous post, the one about malware able to infect right-handed only.
It’s a Msn malware, one of the recent one (as far as I remember I got it from Malware Domain List). I think there’s often something interesting inside a malware, no matter what it does and this is a perfect example!

The malware is not really interesting per se, but it has something I’ve never noticed before. It’s not a cool and dangerous new technique, but a coding behaviour. Look at the graph overview:

The image represents the content of a malware procedure. Nothing strange per se, except the fact that it contains 657 instructions in it, too many for a simple malware. It’s a big routine and I was surprised at first because you can do a lot of things with so many instructions. I started analysing the code, nothing is passed to the routine and nothing is returned back to the original caller. I tought it should be an important part of the malware, but I was disappointed by the real content of the routine. After few seconds I realized what’s really going on: 657 lines of code for doing something that normally would require around 50 lines…
The function contains a block of 17 instructions repeated 38 times. When I’m facing things like that I always have a little discussion with my brain. The questions are:
- why do you need to repeat each block 38 times?
- can’t you just use a while statement?
- is this a sort of anti-disassembling trick?
- can you produce such a procedure setting up some specific compiler’s options?

The repeated block contains the instruction below:

00402175    push 9                       ; Length of the string to decrypt
00402177    push offset ntdll_dll        ; String to decrypt
0040217C    push offset aM4l0x123456789  ; key: "M4L0X123456789"
00402181    call sub_401050              ; decrypt "ntdll.dll"
00402186    add  esp, 0Ch
00402189    mov  edi, eax
0040218B    mov  edx, offset ntdll_dll
00402190    or   ecx, 0FFFFFFFFh
00402193    xor  eax, eax
00402195    repne scasb
00402197    not  ecx
00402199    sub  edi, ecx
0040219B    mov  esi, edi
0040219D    mov  eax, ecx
0040219F    mov  edi, edx     
004021A1    shr  ecx, 2
004021A4    rep movsd
004021A6    mov  ecx, eax
004021A8    and  ecx, 3
004021AB    rep movsb

It’s only a decryption routine, nothing more. The string is decrypted by the “call 401050″, the rest of the code simply moves the string in the right buffer.
Ok, let’s try answering the initial questions.

According to some PE scanners the exe file was produced by Microsoft Visual C++ 6.0 SPx.
It’s possible to code the big procedure just using a loop (while, for, do-while) containing the snippet above. I don’t think the author used one of these statements because as far as I know it’s not possible to tell the compiler to explode a cycle into a sequence of blocks. At this point I have to options:
- he wrote the same block for 38 times
- he defined a macro with the block’s instructions repeating the macro for 38 times
I won’t code something like that, but the macro option seems to be the most probable choice.
Is it an anti-disassembling trick? My answer is no because it’s really easy to read such a code. You don’t have to deal with variables used inside a for/while; to understand what’s going on you only have to compare three or four blocks.
I don’t have a valid answer to the doubt I had at first….

Trying to find out some more info I studied the rest of the code. I was quite surprised to see another funny diagram.

This time the image represents the content of the procedure used to retrieve the address of the API functions. Again, no while/for/do-while statement. The rectangle on the upper part of the image it’s a sequence of calls to GetProcAddress, and the code below it’s just a sequence of checks on the addresses obtained by GetProcAddress.
It’s a series of:

address = GetProcAddress(hDLL, "function_name");

followed by a series of:

if (!address) goto _error;

Apart the non-use of a loop there’s something more this time, something that I think reveals an unusual coding style; tha author checks errors at the end of the procedure. I always prefer to check return values as soon as I can, it’s not a rule but it’s something that help you to avoid oversight and potential errors… The procedure has a little bug/oversight at the end, the author forgot to close an opened handle. Just a coincidence?

Anyway, two procedures without a single loop. Seems like the author didn’t use any kind of loop for choice. In case you still have some doubts here’s another cool pictures for you:

The routine inside the picture contains the code used to check if the API(s) are patched or not. The check is done comparing the first byte with 0xE8 and 0xE9 (call and jump). If the functions are not patched the malware goes on, otherwise it ends. As you can see no loops are used.

In summary: it’s not jungle code, it’s not an anti-disasm code and it’s not a specific compiler setting. I think it’s only a personal choice, but I would really like to know why the author used this particular style.
Do you have any suggestions?

Beyond the coding style, the malware has some more strange things. As pointed out by *asaperlo*, the code contains a bugged RC4 implementation (Look at the comments of the previous blog post).
It also has a virtual machine check. The idea is pretty simple, the malware checks the nick of the current user. If the nick is “sandbox” or “vmware” you are under a virtual machine…
This malware spawns another one (it’s encrypted inside the file), it might be material for another post.

That’s a funny coded malware for sure!

I’m not kidding, the title is right.

Among all the windows settings there’s one made for left handed people. The option I’m referring to is located under the Mouse control panel, labelled “Switch primary and secondary buttons”. It lets you exchange the functions performed by the right and left mouse button. Don’t know if this setting is usefull or not, most of the left handed friends I have are still using the mouse like a right handed. Maybe they don’t even know the existence of such an option. Anyway, look at this code:

It’s a simple query on a registry key named SwapMouseButtons.
result_value is sent back to the caller, and the caller checks the value. If the value is equal to 0×30 (right handed) the malware goes on running the rest of the code, but if the value is 0×31 (left handed) the malware ends immediately. All the nasty things performed by the malware are executed after this check, it means that a left handed won’t get infected!

I’ve seen some malwares using SwapMouseButton function in the past, but never something like that. I bet the author is left handed and he wrote the check just to be sure to avoid a possible infection… I can’t think of anything else. Quite funny!!!

QTPlayerSession.xml (located under %USERPROFILE\Application Data\Apple Computer\QuickTime\) is used to store various user settings. Among all, it’s used to save a list of favorite movies, and a list of the recent opened files. These lists are called FavoritesListName and MRUListNameWithURLs, here is a possible definition:



There’s a *key* definition followed by an *array* keyword. Inside the *array* tags QuickTime saves some values.
A single item is composed by two lines, the first one (“test 1″) represents the name showed by QuickTime while the other (“C:\Programs\QuickTime\Sample.mov”) is the path of the file. No matter what you write inside the string tag, QuickTime doesn’t check if the text is valid or not.
When QuickTime is fully loaded you can see the items from the *favorites* and *open recent* menu items (I don’t know the right english item’s names because I have an italian version of the software).

When QuickTime starts, it retrieves all the possible information parsing the xml file. It scans MRUListNameWithURLs values, and after that it checks FavoritesListName list. Like every parser, it scans the file tag by tag saving the content of each line inside the memory. When it has all the necessary structures stored inside the memory, the program proceeds retrieving the stored information in order to put them in the right places: *recent opened files* and *favorites files*.

QuickTime takes the values to put inside the two menu items running this piece of code:
1: movzx eax, word ptr [esi]
2: lea eax, [esi+eax*4+4]
3: lea eax, [eax+edi*4]

After instruction at line 2 EAX register points to a series of DWORD values, each DWORD value contains a pointer to a single information to retrieve; EDI represents the index because the dwords are taken one at a time. When MRUListNameWithURLS is checked I have something like:
EAX -> 68 D2 34 01 08 D3 34 01 D8 D3 34 01 50 D4 34 01 0D F0 AD BA AB AB AB AB
0134D268 points to a structure containing "Another test"
0134D308 points to a structure containing "C:\abc.mov"
0134D3D8 points to a structure containing "The last one"
0134D450 points to a structure containing "path"

The bytes above are stored inside a piece of memory allocated at runtime using RtlAllocateHeap function. Every time the snippet above will be executed the program will take a single string, depending on the index value. The items retrieved from the xml file are showed under the right menus when QuickTime is fully loaded. As I said before, there are two defined items for a single file so QuickTime always execute the code two times. The last 8 bytes pointed by EAX are not related with any string, they are just old bytes.

Can you understand what I’m trying to say?
The xml file is updated by QuickTime, but you can edit it. The problem occours when you modify FavoritesListName and MRUListNameWithURLs a little, using something like:



You can modify FavoritesListName in the same way. Of course you can define some more items. The point is that QuickTime is not able to handle item definition without the necessary two lines (name to display and path of the file) inside MRUListNameWithURLs and FavoritesListName; writing down 1 or 3 or 5 or 7 (or 9…) lines between *array* tags you’ll get the same result, a crash.
Why? Well, because the program will take the next not initialized 4 bytes and you don’t know what they are.

I could be wrong, but I don’t think it’s possible to exploit it. It’s a bug that can lead to a sort of denial of service because the crash occours in the initialization process. If your copy crashes you can try checking the xml file.

Some time ago I blogged about Vmware snapshots introducing a way to recognize hidden files by simply comparing two snapshots. I wanted to extend my research on the subject a little bit more, but I didn’t. I got the opportunity to put my hands on some snapshots again in these days. I haven’t anything on my mind, but I was surprised by some coincidences. Look at the information below:

80544bc0: 804fc624 00000000 0000011c 804fca98
80544bd0: bf995ba8 00000000 0000029a bf98f5f8
80544be0: 00000000 00000000 00000000 00000000
80544bf0: 00000000 00000000 00000000 00000000

00544BC0: 24C6 4F80 0000 0000 1C01 0000 98CA 4F80 $.O………..O.
00544BD0: A85B 99BF 0000 0000 9A02 0000 F8F5 98BF .[..............
00544BE0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00544BF0: 0000 0000 0000 0000 0000 0000 0000 0000 ................

First 4 lines are taken from Windbg while I was debugging an XP sp1 virtual machine running under Vmware; last 4 lines are taken from a saved Vmware snapshot (same os of course).
Do you see anything useful? These are KeServiceDescriptorTable[0],[1],[2],[3] and they have of course the same bytes, but there’s something else. There’s a connection between the addresses on the first lines and the offsets on the second ones, just remove the first 2 digits from the address. Do you see it? Look here: 80544BC0/544BC0, 80544BD0/544BD0, 80544BE0/544BE0, 80544BF0/544BF0.

Seems like the kernel memory is stored inside the snapshot. It’s not totally true indeed, there’s only a part of the kernel memory stored inside a Vmware’s snapshot. All the KeServiceDescriptorTable entries are present btw.
SSDT is inside the snapshot I have and it’s complete; SSDT Shadow seems to be inside the snapshot too, but there’s no real connection between kernel memory/snapshot addresses and it’s not complete (it needs some more research btw).

Is it only a coincidence? I tried with some XP machines and the result is the same, it’s possible to obtain real information of SSDT. According to Kayaker’s test it should work on win2k (don’t remember the service pack he was using…).

With this new information it’s pretty easy to code a SSDT revealer. I gave it a try and here is a result:

You can use the program to display SSDT entries and to find out modified entries too by simply comparing an original snapshot with another one.

To retrieve information from a snapshot you have to provide the address of KeServiceDescriptorTable[0] (something like 80544BC0, no “0x” prefix), and you have to select the OS of the virtual machine. After that you can:
1. save an untouched SSDT using the button labelled “Create untouched SSDT”
2. retrieve SSDT information from a snapshot by simply pushing the button labelled “Get snapshot SSDT”. Checking “Load untouched SSDT data” you can compare the original table (previously saved) with the one from the snapshot you’ll select. If a service has been changed you’ll read the word “YES” in the last column.

I took the name of the services from this table: http://metasploit.com/users/opcode/syscalls.html
I can’t test all the OS, if you find one or more errors drop me a mail.

Following this method it’s also possible to get the list of the running processes/modules, more about this later.

SSDT from snapshot