OpenRCE

About Articles Book Store Distributed RCE Downloads Event Calendar Forums Live Discussion Reference Library RSS Feeds Search Users What's New

Customize Theme

Flag: Tornado! Hurricane!

Created: Thursday, January 3 2008 09:58.27 CST

Modified: Thursday, January 3 2008 15:39.28 CST

Printer Friendly ...

CommWarrior.B Thorough IDB (ARM/C++)

Author: RolfRolles

# Views: 8386

It's with pleasure that I am allowed to release this IDB.  I want to say "thank you" to you-know-who.  The truth is stranger than fiction sometimes.

This is a nasty little SymbianOS worm that I reverse engineered in February of 2006.  The project was more difficult than most in several respects.  I'd only ever done one ARM project before this, and so I found myself referencing the ARM documentation.  I had no familiarity with the SymbianOS API, which turns out to be object-oriented from start to finish.  Apart from that, the author made extensive use of the object-oriented features of C++ in his non-API-related code; the project was the most intensely object-oriented one that I had done up until that time.  Plus, this excellent document on SymbianOS reversing had not been released yet.  I also did not have access to hardware upon which to run the worm, and so the project had to be conducted purely statically.  Finally, I had never used a mobile phone before and was unfamiliar with all of this fancy SMS and BlueTooth stuff -- yeah, I'm a luddite.

I also did a decompilation for this, but I think that releasing it would do more harm than good.  Mobile phone worms are lame, and the world does not need more of them.

Make sure to check out the database notepad.  Enjoy!

Blog Comments

aeppert	Posted: Thursday, January 3 2008 10:05.54 CST
Fantastic work and thank "you-know-who" again for us all.

neoxfx	Posted: Thursday, January 3 2008 20:48.13 CST
great work! you're cool.

Orr	Posted: Sunday, January 6 2008 07:12.02 CST
Awesome work my friend.

RolfRolles

Posted: Sunday, January 6 2008 10:28.15 CST

Two notes about this project.

About half-way through doing this disassembly, I encountered a bug in IDA 4.9, described in the SP1 update literature as:

"Very long comments (>1KB) were not correctly displayed"

When they say "were not correctly displayed", what they really mean is "causes IDA to crash". In a rare moment of foresight I made a copy of the .ID0, .ID1, .TIL and .NAM files before trying to re-open the database. It's a good thing I did, because IDA failed to repair the database and then deleted all of those files. I could've re-done the work (it's always much faster the second time around), but I refused to accept that. The only option was VICTORY. I managed to resurrect the database with a hex editor by finding the offending comment in the .ID0 file and writing a NULL byte towards the beginning of it. I then got a new IDA.WLL from Ilfak.

Secondly, I mentioned in the original post that CommWarrior has a highly object-oriented design. Most of the malware that I'd analyzed up until then was written in plain C, was not very sophisticated, and was usually quite buggy. On the other hand, most of the commercial software that I've analyzed is written in C++ and is usually at least marginally better than malware in terms of design. CommWarrior's design is actually an excellent little sculpture. It's far superior to most of the commecial software that I've analyzed even to this day. The person who wrote CommWarrior is a better programmer than I am.

aeppert

Posted: Monday, January 7 2008 08:28.47 CST

Rolf,

A bit tangential to your blog entry - but I can say based on a recent analysis of some malware that the authors are getting inordinately better.  What I have found interesting in my last few malware analysis cases was the fact that there seems to be a movement away from packers and instead relying more and more on "trickery" during the actual execution to hide what is happening.

Examples, while not new, but still interesting include remote thread creation.  The most recent analysis entailed a piece of malware spawning no less than four remote threads and slowly and brutally carefully copying itself over bit by bit and using a "proprietary" function lookup facility.  The malware did assume certain addresses for the starting offset of the libraries though (kernel32.dll, user32.dll, etc.)  But overall what caught me was the quality of the code, it did NOT leak memory nor file handles and was brutally efficient in cleaning up after itself.

Thus, I have to say it was a magnitude better than what we consider your average commercial grade code.  We need to recruit these folks into the commercial world :)

RolfRolles

Posted: Tuesday, January 8 2008 03:17.56 CST

Hey Aaron,

You make a good point. I've done some analysis of similar trojans and they are increasingly sophisticated. One of the ones that I looked at injects six threads into the tray that all make use of a shared 2800h-something byte structure. I was disappointed to see that the "encryption" for the HTTP-based cmd.exe shell and the filesystem browser was an xor loop, but apart from that it was well-written and obviously created by a low-level-minded person. That particular sample was being distributed via an 0day exploit that was the most professional quality that I've seen; I could have done no better.

While we're talking about malware analysis, remote-thread-injecting malware used to be particularly difficult to analyze. Since the API calls are done via function pointers, versions of IDA prior to 5.1 (with its simplex solver scheme) had a very hard time keeping track of the stack pointer. Thus you'd have to go through very tediously manually correcting the stack pointer after each library call.

Thanks for your interesting comments :-)

c1de0x	Posted: Tuesday, January 8 2008 03:18.57 CST
amen aeppert. Rolf: I can't wait to take an in depth look into the idb. Thanks for sharing!

There are 31,311 total registered users.

Recently Created Topics
[help] Unpacking VMP...	Mar/12
Reverse Engineering ...	Jul/06
hi!	Jul/01
let 'IDAPython' impo...	Sep/24
set 'IDAPython' as t...	Sep/24
GuessType return une...	Sep/20
About retrieving the...	Sep/07
How to find specific...	Aug/15
How to get data depe...	Jul/07
Identify RVA data in...	May/06

Recent Forum Posts
Finding the procedur...	rolEYder
Question about debbu...	rolEYder
Identify RVA data in...	sohlow
let 'IDAPython' impo...	sohlow
How to find specific...	hackgreti
Problem with ollydbg	sh3dow
How can I write olly...	sh3dow
New LoadMAP plugin v...	mefisto...
Intel pin in loaded ...	djnemo
OOP_RE tool available?	Bl4ckm4n

Recent Blog Entries
	halsten	Mar/14
Breaking IonCUBE VM
	oleavr	Oct/24
Anatomy of a code tracer
	hasherezade	Sep/24
IAT Patcher - new tool for ...
	oleavr	Aug/27
CryptoShark: code tracer ba...
	oleavr	Jun/25
Build a debugger in 5 minutes
More ...

Recent Blog Comments
	nieo on:	Mar/22
IAT Patcher - new tool for ...
	djnemo on:	Nov/17
Kernel debugger vs user mod...
	acel on:	Nov/14
Kernel debugger vs user mod...
	pedram on:	Dec/21
frida.github.io: scriptable...
	capadleman on:	Jun/19
Using NtCreateThreadEx for ...
More ...

Imagery

SoySauce Blueprint
Jun 6, 2008

[+] expand

View Gallery (11) / Submit