Flag: Tornado! Hurricane!

Blogs >> RolfRolles's Blog

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: 8022

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

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!

Add New Comment

There are 31,246 total registered users.

Recently Created Topics
let 'IDAPython' impo...
set 'IDAPython' as t...
GuessType return une...
About retrieving the...
How to find specific...
How to get data depe...
Identify RVA data in...
Question about memor...
How can i find conne...
How can I write olly...

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

Recent Blog Entries
Breaking IonCUBE VM

Anatomy of a code tracer

IAT Patcher - new tool for ...

CryptoShark: code tracer ba...

Build a debugger in 5 minutes

More ...

Recent Blog Comments
nieo on:
IAT Patcher - new tool for ...

djnemo on:
Kernel debugger vs user mod...

acel on:
Kernel debugger vs user mod...

pedram on:
frida.github.io: scriptable...

capadleman on:
Using NtCreateThreadEx for ...

More ...

SoySauce Blueprint
Jun 6, 2008

[+] expand

View Gallery (11) / Submit