Log in

View Full Version : Another trojan I couldn't identify the packer


Cthulhu
April 2nd, 2007, 16:11
I could not identify the packer of this one either.

http://rapidshare.com/files/23236233/sys1.rar.html

Warning this is a trojan!!!!!!!!!

quetzalcoatl
April 8th, 2007, 16:53
wow, big one

edit: oh.. its delphi

quetzalcoatl
April 9th, 2007, 04:16
there's at least 2-stage unpacking. I lack the knowledge for naming the packer/encryptor (edit: PEiD doesnt recognize neither original file, nor pre-2ndstage dumped from memory to PEfile by CFExplorer suite), but I think I'm able to unpack it. First, there's small decrypting/correcting routine that fixes the code to be executed next and jumps there. there's something looking like small decryptor again, and it gets to ebp-proc 401A55 where's something that large I didnt get through yet. However, it was surely written in highlevel language, like delphi suggested in manifest - everything ebpbased, lots of nicely structured and clear code. at beggining it reloads some parts from the original exe, globalallocs large block, reads from a file into it, performs decryptin per-byte (adds and xors), and virtualallocs 2 blocks. then theres call to 0x401000, one virtualfree, return to original proc from 401a55 and significant

00401A8B mov eax,[stackvariable]
00401A8E jmp eax -- address is probably from that globalalloc

unfortunatelly, I didnt get through 401000 yet, the procedure is 100% high-level code, clear, unobscured, almost 100% maths and memmoving - some large decryptor, the second stage one, so probbaly it would be safe just to execute it and wait till jmp eax is hit, but, well, until I setup a VM I won't risk. It may very well overwrite itself on the runtime and happen to be the right badcode -- remember the firststage loader which fixed itself right on the start.

oh.. and if someone could enlighten me.. there's a lot of:
call 0x401064
jump trash
..

and at 401064:
inc byteptr [esp+0]
retn

obviously it skips the 'jump' opcode and executes proceeding bytes as code, so for myself i renamed call 401064 to jmp1bytefwd.. its easy for me but not for my disassembler, actually it completely breaks it flow analysis and I have to manually correct functions start-ends and such.. is it some post-build obscuring method od rather it compiler-generated?

Kayaker
April 9th, 2007, 04:58
Hiya,

I can't really help with any details yet, but I looked at this target briefly earlier and the custom packer looks rather interesting. As you mention, not really difficult to follow the generalities without having to trace forever and anon, but I didn't have time to get into it deeply.

If you let it run, which you don't want to do outside of a VM since it tries to install a service to be run every time your computer starts, it unpacks an exe file to the windows system32 directory. The file is upx packed. If you unpack that it also has a PEPACK packing.

I did a quick dump of the PEPACK but imprec doesn't resolve the imports and suggests manual rebuilding would be necessary. I've never played with PEPACK so maybe there's a few trickz involved...


I *think* if you let it run you could safely get the UPX packed file, as long as you've got a firewall such as ZoneAlarm which will alert you that a service ("Servicos" is wanting to be installed, which you can of course deny. I wouldn't want to say go ahead and do this outside of a VM because I don't know if any registry entries are created or any other files are unpacked. but it *looks* like only the 1 service file (system.exe I believe) is created.

If you deny the service to be installed it think it would be fairly impotent. Mcafee at least doesn't register the PEPACKed file as a threat by itself.

fr33ke
April 9th, 2007, 06:16
The first packer is THInstall I believe. Already thought so when I heard about the jmp1bytefwd trick. After tracing it in Olly I'm 99% sure.

If your disassembler is IDA, you can undefine the "jmp trash" with "u", and then redefine the byte after e9 with "c".

The real OEP of the main exe is easily found after the "jmp eax". Search for the text "entry" and you will find this:
Code:
7FF52890 68 6866F97F PUSH 7FF96668 ; ASCII "APISPY: Calling EXE Entry Point %x\n"
Then the call after the "pop ecx" is the call to OEP.

fr33ke
April 9th, 2007, 09:17
Okay I unpacked the main exe, and got something that looks like Kayakers file: UPX + PE Pack 0.99. It's the same file that is dropped in C:\Windows\system32\Drivers\system.exe

With upx unpacked it's 6 MB. That is really ridiculous.

Here's the UPX-ed MALWARE file:
http://rapidshare.com/files/25097479/system.vxe

EDIT: Unpacking PE Pack was pretty easy too, just had to find the import table manually. The final unpacked file is a Delphi exe of a whopping 7 MB.

MALWARE download: http://rapidshare.com/files/25107747/dumped_.7z

Cthulhu
April 9th, 2007, 13:23
Long time without logging here.....
Brilliant job friends!

quetzalcoatl
April 9th, 2007, 14:18
great job fr33ke! that 'u'-'c' I do know, I just thought that there's some way of automating it :| nice to know the packer name, thx

edit: um.. fr33ke - could you point me to some article/info how to rebuild PE in such case? I know the basic-basics and the fact that was globalalloted at 7Fxxxxx prevented me from dumping.. are there any tools, or need to do it 100% manual?