Wednesday, May 08, 2019

"Oh, the places you'll go!": A look back at reverse engineering on Mobile/Embedded Systems

A bunch of years ago(circa 2003), after a little while in the Antivirus industry, I'd been consulting on web development but still had an itch for reverse engineering and malware.

The day job was mostly maintenance and upgrade on a VBScript(not .Net) site. With an MS Access database backend. Eventually this was converted to the WAMP stack and things got a bit more stable. Unfortunately stable became boring.

So I picked up perl in the evenings. My interest was in picking up a new language and playing with newer platforms. I'd always wanted to get a Psion Series 5 or a Revo palmtop computer but could never justify the $400-$600 price. I got lucky, Tiger Direct ended up with a lot of Diamond Mako(re-branded Psion Revo) palmtops and were selling for the impulse buy price of $100. Epoc32(renamed Symbian) was the OS running on the Series 5(and later many Smartphones). 

Picture of A Diamond Mako palmtop computer. It is a re-branded Psion Revo device.
A Diamond Mako(Psion Revo)
Credit: Miha Ulanov Licensed under 
CC BY-SA 3.0



“The little [computers] have .exe’s too? How cute?”


I'd picked up a few habits in the Antivirus industry that served me well :
  1. Run executables only as a last resort.
  2. Make sure you have analysis tools, even if you have to build them yourself.
Tools that dump information on executables are a primary tool for malware analysts. If you ask 100 Windows malware analysts, likely all 100 of them have written their own PE dumper. For the same reason. The research to build these tools requires learning the file format in depth.

On Symbian I wanted to know what info I could pull from its various file formats(e.g. .exe, .sis). For the .exe and .dll dumper I found a lot of information(e.g. internal structures, values, etc.) necessary to build the executable dumper from a header file posted to a Usenet group.(Today the post is gone, but the header file is available as Open Source.)


“Stop opening things. They packed them for a reason.”


The .exe dumper was done. .sis files(Symbian's installation file format) are useful. Unpack them and you get more files, especially the .exe/.app/.dll files. If you wanted to analyze a potentially malicious sample, you'd need an unpacking tool.

This is where the reversing fun happened. The first version of .sis files, used on earlier EPOC devices(release 5), was documented publicly. They got updated for EPOC Release 6(Symbian).

Public specifications, even slightly outdated, help reversing immensely. You also need samples of good files. A hex editor in which to view them. And some way to take notes.

As Perl had a Symbian port I was able to run the same code on both my laptop and the Mako(Revo). I could verify it was working and displaying the right information on the device.

Having a spec is a good start. I started hunting for sample SIS files. Success came from a number of places(e.g. old Symbian SDK CDs, sites on the Internet). Having an actual Symbian device gave me access to additional valid files.

Staring at hex dumps isn't the exciting part, it's the figuring out what's in a spec, comparing it to reality. I've had colleagues who can tell you what specific system call is encoded in those hex bytes. They can you tell where a particular virus opens an .exe, where it copies its virus code to the end. It seems like magic at first, then you see it's just pattern recognition. More fun is climbing inside the head of the creator; with file formats, seeing what they did right and occasionally where they went wrong.

Viewing .sis file with Symbian worm SymbOs/Cabir.A in a hex editor.
Viewing .sis file with Symbian worm SymbOs/Cabir.A in a hex editor.

I spent a few months building DumpSis(creative naming, no? Programmers tend to be lazy about naming, Symbian named their later tool the same). Running tests, fixing bugs and taking notes. Finally DumpSis worked. So it went on the shelf/in the toolbox. Because this was still 2003-2004 and here was no Symbian malware. Yet.

Unicode Build
Uid1: 0x38b1a3d Uid2: 0x10003a12 Uid3: 0x10000419 Uid4: 0xab80e0c4 
SIS CRC: 0xe840 
Number of Languages: 1 
Number of Files: 3 
Number of Dependencies: 1 
Installed Language: 
Last Installed File: 0 
Installed Drive: ! 
Installer Version: 200 (0xc8) 

Type: App Version: 1.0.0 
Install Name: caribe 


Files ---------|
             1 |-!:\system\apps\caribe\caribe.rsc 
             2 |-!:\system\apps\caribe\flo.mdl 
             3 |-!:\system\apps\caribe\caribe.app

DumpSIS output for SymbOs/Cabir.A.
Things changed in mid-2004. I got contacted by Antivirus colleagues asking for help getting DumpSis running on Windows. I asked what they were using it on. The virus writing group 29A had released SymbOS/Cabir in their latest zine(29A #8).

Soon after Symbian malware became a thing. I exchanged samples with other researchers and provided analysis.(still more fun than the day job)

About six months after that I got asked if I wanted to get back into Antivirus Research. It was the right place at the right time with the right tools.

Symbian malware led to other mobile phone malware, then to other embedded system threats. Times change, yet somehow to this day I'm still explaining that new platforms are vulnerable.

No comments:

Auto "Kill Switch", solving the wrong problem?

Consumer Watchdog, a consumer advocacy group, put out a report on the dangers of Internet connected cars. They received coverage on the nigh...