Cатсн²² (in)sесuяitу / ChrisJohnRiley

Because we're damned if we do, and we're damned if we don't!

SANS FOR610: Reverse Engineering Malware – Course Review


What follows is a review of the SANS FOR610: reverse engineering malware class taken at the SANS Prague 2013 event. What follows are rough notes, feelings and impressions from the class as it was taking place… Take it as you will, and I hope it proves useful for you in evaluating the class.

Note: Prior to the class I’d never done reverse engineering of malware… however I have done limited exploit dev and other tasks that dovetail well with some of the concepts.


Day 1 started off slowly walking through some simple malware using some behavioral and code analysis, before moving into the setup of our lab environments. Although the first half of the day was a little slow (and instructor led, so no hands-on), it brought everybody up to speed on what we’d be doing in the coming days and helped to lay the foundation for some of the more fun topics I’m sure are headed our way in the later part of the class. After a quick bite to eat we moved into the first hands-on section of the class.

The afternoon was spent slowly walking through the step by step process of performing a behavioral analysis of brbbot in our labs. The pace for the hands-on was a little slower than I’d have liked, but the step by step methodology helped really push home the process required. It was also nice to see procDOT (from the Austrian CERT team) mentioned as well, as an easy way to perform some of the steps.

The day finished off by walking through debugging brbbot in OllyDBG to perform code analysis and dive into some of the malware’s inner workings. Again that walk-through with the class was slow-paced with a few students struggling. With a class like this it’s hard to find a suitable pace to ensure everyone can follow along. That said, even though I’ve never done malware reversing before day 1 seemed slower than it really needed to be in a lot of places.

Day 2

As is standard with most SANS classes, we kicked-off day 2 with a quick recap of the topics covered in day 1 of the class, finishing off the day 1 material with a brief discussion of what should be included in a malware analysis report.

Diving into the real day 2 content we starting looking at commonly seen packers and how to deal with them. Aside from the simple UPX cases (which are apparently more common than I thought in malware) we looked at dumping the unpacked code from memory using a number of tools. Unfortunately we didn’t dive more into the process and how to do it without the tool. I know this isn’t a simple process, but I’ve always been more of the “do it the hard way and learn, before you use the point and click tool” guy. Still you can’t have everything, and the walk-through on doing the same kind of dump using OllyDbg and the OllyDump plugin was an interesting diversion.

After a quick bite to eat we ventured into some patching of executables using OllyDbg (in particular patching to avoid debugger checks). Moving away from Windows executables, we began looking at analyzing browser-based malware.

After going through the standard JavaScript de-obfuscation techniques (as well as some debugging of JavaScript with Firebug) we moved on to a brief (possibly too brief) look at Java based malware. To finish up the final hour we dove into SWF decompilation and static analysis of some older Flash malware. The tools and techniques covered were not that different from what we’d already covered. Seems that the debugging of SWF files is still trickier than it should be (at least without the aid of costly and specialist Flash debuggers). There’s just too many ways to trick the tools into misunderstanding the code, and an area that needs a lot more research.

Day 3

No reversing class would be complete without some serious time spent crawling around in assembly. The morning was filled with the usual fare, compilers, linkers, commonly seen assembly codes and the like. Nothing that most wouldn’t have already seen and read if they were interested in this area of security. Where I think the topics really made things clear was breaking down recursion and jumps and looking at the raw C and compiled assembly versions (or one possible assembly version). It really helped to show that you can tell if the original code was a loop or an If Else. Probably nothing earth shattering for most, but I found it interesting to go down to the level. We also covered jump logic extensively looking at the way the registers are used to store the results used for common jumps. Good stuff to know if you’re reversing unknown code.

The afternoon covered some anti-disassembling examples that malware authors use to cause headaches for people reversing their work, before moving into the final real topic of the day, user-mode rootkits. The afternoon session seemed to be a little rushed, maybe due to some delays earlier on in the day. Day 3 certainly tries to cram in more than previous days have and it showed at the end with a few sections covered in a little less detail than I’d have liked. Pity really, as I’d rather a few day 1 or 2 topics were given short shrift and replaced with more time to really dig in and look at sniffers, keyloggers and the like in Olly/IDA. Overall though, the best day so far… very good stuff!

Day 4

After a sleepless night (gotta love hotels) we dove into self defending malware and started to look at some of the more commonly seen anti-debugging techniques used by modern malware. Kicking things off we manually walked through a malware sample using SEH to fool analysts, and a simple packer to prevent easy analysis of the real malware. The same was interesting in the way it used multiple techniques to fool people trying to understand the executable, but was pretty simple to bypass the protections given a few minutes and a few hints on how it works. The SEH trick was an interesting one and not one that I’d thought of before (I’m not a malware analyst after all).

The afternoon continued on from the morning session dealing with more anti-debugging tricks used commonly by packers and malware writers (including timing based RDTSC and TLS Callback techniques, amongst others). Some of these techniques are probably well-known and documented amongst analysts, but as I’ve said before, as a non-malware analyst the techniques were new to me and made for an interesting afternoon in OllyDbg and shellcode.

finishing off the theme of malware that fights back, we moved into some web-based malware and JavaScript obfuscation techniques.

Day 5

Despite only 1.5 hours sleep (don’t ask…) day 5 started quickly diving into malicious Office and PDF documents. After covering the basics, we moved into some quick analysis of malicious samples using a range of tools and scripts. As expected, the PDF section of the class was a relative what’s what of Didier Stevens research. Some of it is things I’ve already read or seen based on Didier’s wonderful training and workshops. Still, there were some interesting extensions to this using tools like shellcode2exe to create a debuggable PE in order to walk through injected shellcode in a more controllable way. I particularly liked the technique of using libemu’s sctest to create an overview of what the shellcode is doing. Something that will definitely come in handy…

Moving away from malicious files we focused on the uses of memory forensics and how malware analysis can be performed on forensic images. As expected, volatility played a big part of the afternoon, using it to check connections, find hidden processes and dump out the unpacked malware from memory into a PE file to be analysed in the normal way. Using some of the more run modules in volatility we looked at detection of kernel and user-level rootkits and how to extract information from memory dumps that help us as malware analysts understand what malware is doing on a system.

Day 6

CTF style challenges to reinforce the material covered in days 1-5… I won’t go further into this, but the experience was a good one for sure! I managed to hover around 10th position before having to head off early to catch a train. Not stellar, but for a first time malware analyst, I guess it could have been worse ;)


The pace of the class was a common theme for me throughout the first half of the week, but quickly picked up pace midway through day 3. There’s a number of reasons for this, and it was hard to tell if the class was just paced for a more beginner crowd (disclaimer: I’ve never done malware reversing, but I’ve used a majority of the tools before for various other tasks/purposes), or if the pace was effected by a few people in the class that seemed to get lost pretty easily. I won’t launch into a tirade here about people doing technical classes and not having the chops for it, so consider the issue of pace discussed ;)

The tips/tricks and general processes for working with malware were very clearly discussed and worked very well during the course. How they work in real life with modern malware that wanted to stop you at every turn is to be seen. Although we covered some of the more common methods used by malware to cause problems for analysts, there’s no way you can cover them all. Things like that can only be learnt from experience and expose to different techniques and methods after all. The processes helped me quite a lot with a few debugger questions I had. Not just when it comes to malware, but also for more offense-based reversing (thick clients etc…)

The class is very tools based. This isn’t necessarily a bad thing, as most of what we do on a day-to-day basis is tools based… but the first half in particular lacked a certain amount of “rolling up your sleeves and getting into the dirt” that I personally like to see from classes like this. Although it’s a hard way to learn, I find that learning the hard way before you just load a tool makes you respect and understand the issue and the solution. This was dealt with better in the final days with much more hands on stuff. Also, as much as people like to say the day 6 CTF style challenge is a wasted day, I found that some parts of it helped bring back points I’d forgotten from the earlier parts of the class. This really helped reinforce things for me.

Overall the class was good for a beginner just looking to get a grounding in the topic. That said however the pace made it feel like the class could have achieved so much more in the first 2 days in particular. Missing were more automated and scriptable debugging of malware. Things like pydbg, vdb/vivisect and a number of other script based debuggers would have been nice to cover, even if only in passing. A number of the examples really fell into the category of easily scriptable, and it would have been nice to get some hands on with that stuff.

I think the class really came into its own in the later days… much more focused, technical and designed to really stimulate your thinking.

A sneak peek into Android “Secure” Containers

It’s been a bit quiet here on the blog, so I thought I’d take a few minutes to write up an issue I raised with the fine folks over at LastPass .

Alongside the HTTP Response Code stuff, I’ve been playing around more and more with Android applications. One of the things I presented on in Vegas at the BSidesLV Underground track was breaking into Android Secure Containers. The name of the talk was cryptic for sure, mostly because said “secure” containers were anything but secure, and because I hadn’t had time to report the issues to the effected vendors. The issues I discussed weren’t tied to a single application, and effect numerous apps within the Play Store…
So, here we are a month later, and LastPass has rolled out a “fix” for the issue I reported to them. This means I can give you the down and dirty details now that you’ve all updated your Android devices to the latest LastPass version (currently 2.5.1). FYI: the CVE  numbers for these issues although not referenced in the LastPass changelogs as yet are CVE-2013-5113 and CVE-2013-5114.

This research needs a little back story to explain it, so bear with me for a minute while I set the stage.

Back Story / Testing Scenario

I started down this research track when I was looking at how Android applications provide additional security through PIN and/or password protection of specific applications. This additional layer of security offered by applications like LastPass is there to stop people who have physical access to your Android device from getting into the more secure areas of your data (e.g. Passwords). With this in mind I expected the implementation of these protections to be designed to stand up to an attacker with physical access to the device (aka. somebody who’s stolen/borrowed/found your Android device).

Some Facts

Without root access to the android device, it’s not directly possible to view or alter the data of specific applications. Even if USB Debugging is enabled (by the owner, or later by an attacker with device access) it’s only possible to view specific data on the Android device, not all the juicy stuff. Everything I’m about to discuss is possible based on a non-rooted device, however USB debugging needs to be enabled to allow us to interact with the device using adb. Remember, the scenario we’re talking about here is physical device access, so this shouldn’t be a big hurdle.

Note: It goes without saying that everything that can be achieved here with ADB /USB Debugging can also be achieved through exploitation of the device… although, there are much more fun things to do if you’re popping shell on a device ;)

The LastPass Case


LastPass allows a user to save their password within the Android application so that you don’t need to type it every time you open the app. This isn’t abnormal for applications, and like any good security minded application they give you options to secure the access using something other than your long long password (aka… the PIN).

Given my experience, users of such applications have too much faith in the security of their devices and have no desire to type in their 32 character random LastPass password whenever they open the application (have you tried that on a handheld device? Yhea, not fun…). Much better to store the password in the secure container settings and assign a PIN to protect the app (because that’s secure!).

So with the back story and the explanation out the way, here’s the meat of the issue

The Meat

When I first started testing LastPass on the Android (version 2.0.4 at the time) I noticed something interesting about the AndroidManifest. In particular the android:allBackup was set to True, meaning that even though I couldn’t read or edit the configuration/settings of LastPass directly on the device (remember, non-rooted device) or via ADB (remember, USB debugging enabled, but even then no direct access), I could perform backup and restore operations via ADB.

This led me down the trail of learning more about the “adb backup” command (introduced in Android ICS). What makes adb backup and restore so useful in this context, is the ability to not only backup a device entirely over USB, but also to specifically backup individual application data (with or without the APK file). This makes the backup and restore much more flexible for what we’re looking at doing. After all, backing up an entire 16GB device every time gets tiring (I’m looking at you iOS).

By performing an adb backup (command: adb backup com.lastpass.lpandroid -apk) and accepting the prompt on the device, you end up with a backup.ab file containing the LastPass application (APK) and the data/configuration/settings from the application. There have been numerous discussions on the format used by Android Backup files, but I wasn’t happy with any of the solutions offered to decrypt the AB files into something usable. So I decided to automate the lengthy process in Python (see http://blog.c22.cc/2013/08/01/bsideslv-android-backup-unpacker-release/) and add in some features to ease things a little.

The final result is a directory output of the LastPass application (with or without the APK – your choice – screenshot is without APK). lastpass_tree

Taking a look at the files the sp/LPandroid.xml quickly stood out as worth further analysis. As expected the configuration file contained the username and password in encoded format (if saved within the LastPass app). Alongside this the XML also contains an encoded version of the PIN and various other application settings. Putting aside the possibility to decode the password and PIN, a few settings caught my eye for easy wins:

  • reprompt_tries

This is a simple integar that increases as incorrect PINs are entered

  • passwordrepromptonactive
  • pincodeforreprompt (holds encoded PIN)
  • requirepin

These control the password reprompt on startup and the PIN protection (yeah, you can see where this is going already)

The Story So Far

We have access to the LastPass configuration of a non-rooted device via adb backup… and we can fiddle with the resulting configuration file. However we’re still playing about with the XML inside a backup and not with the device itself. We need to get the changes back into the device

Next Step

Using more Python trickery goodness (see http://blog.c22.cc/2013/08/01/bsideslv-android-backup-unpacker-release/) we can take the directory structure created and rebuild the Android Backup file (with the changes that we’ve made to the files of course). Then we can restore the backup to the device (if you still have access to it) or to your own device/emulator (make sure you have the APK in the backup file or the app already installed if you want to restore to another device).


lastpass_home_screenAs expected, playing with the reprompt_tries by setting it to a minus number (-9999 for example) allows you to bypass the 5 PIN attempts before wipe feature of LastPass. This essentially gives you 10,000 retries. If you can’t guess a 4 digit PIN in 10,000 retries, then nothing can help you :P

However, the easier and more fun option is the pincodeforreprompt / passwordrepromptonactive and requirepin alteration which results in the LastPass application not requiring a PIN for entry anymore.

  1. Backup configuration and unpack
  2. Alter XML settings as required
  3. Pack configuration and restore
  4. <<< Profit >>>


Some of the more eagle eyed amongst you may have already noticed another interesting attack vector here. The ability to backup LastPass from a device (within 30 seconds if you’re handy ;) and return the device to the owner, coupled with the freedom to restore said backup to an attacker controlled device, makes the attack much more interesting. Not only can you do this, bypass the PIN in your own time, and then read and extract the stored passwords as desired. You can also maintain access to the users LastPass account until such time as they change their LastPass password itself.

If the original owner alters their any of the passwords their store in the LastPass service, the attacker can simply close and restart the cloned Android container to update the information from LastPass’ servers.

Note: Version 2.5.1 mentions an alteration in the way LastPass creates UUIDs. This may effect this cloning attack – as yet unconfirmed

Round 2 – It’s not over yet

You may have noticed the use of quotes around “fix” at the beginning of this post… After LastPass got back to me to say they’d fixed the issue (actually they responded to say they’d fixed it the day before I reported it as they’d disabled allowBackup and not pushed it to the Play Store yet), I started looking at the proposed fix and possible bypasses based on the same physical access scenario. After a few false starts I have a working bypass for their fix that once again allows the attack (with an additional step). Once they’ve fixed the fix, I’ll let you guys know how that one went down ;)

Until then, make sure you upgrade your Lastpass to the latest Play Store version (2.5.1 at this time) and keep an eye out for further fixes!


#DEFCON Defense by numbers: Making Problems for Script Kiddies and Scanner Monkeys

dc-21-logo-smWell, I finally popped my DEF CON cherry and did a presentation at the largest hacker conference in the world… and no I’m not talking about RSA!

Despite my fears of freezing on stage and beginning to drool like a moron, I think the presentation went well. Excluding of course the point where Powerpoint decided it would die in a fire rather than show my next slide. Still, in typical DEF CON fashion there were goons on hand to deliver shots _just_ at the right time to cover the problem. This will forever be known to me now as JITAD (Just In Time Alcohol Delivery).

Hopefully the attendees took something from the presentation that they can use to make their systems a little more secure, or at least the lives of script kiddies a little harder (this is a dream for us right?).

The slides for the presentation are now online (see below), and the video will be uploaded as soon as DEF CON make the release possible.

As always, feedback on the talk, the idea and anything else is gratefully received…


  • Slideshare –> HERE

BSidesLV: Android Backup [un]packer release

bsideslvlogoAs part of my “Mobile Fail: Cracking open “secure” android containers” talk at BSidesLV I’ve released a couple of scripts I wrote to automate some of the legwork involved in backing up Android applications and automatically unpacking their data and settings. The accompanying script takes the data and settings structure and re-packs it into a working Android Backup file for restoration.

These scripts were used as part of my research to view settings used by applications and in some cases alter the configuration to deactivate secure features or allow access. In some cases it’s also possible to alter configuration files to gain elevated functionality (unpaid… but nobody would ever do that… right!).

The process isn’t new and can be done manually, however automated solutions are always easier…

packer unpacker


  • openssl with zlib support
  • star (apt-get install star)

Simple Python scripts to perform:

  • an adb backup of a specific application and uncompress it to a directory structure
  • recompress a directory structure back into a valid adb restore file

Example usage:

./ab_unpacker.py -p com.app.android -b app.ab

  • Creates an adb backup of com.app.android called app.ab and uncompresses it into ./com.app.android

./ab_packer.py -d ./com.app.android -b app_edit.ab -o app.ab -r

  • Repacks the contents of ./com.app.android into app_new.ab and attempts to restore it via adb




Get every new post delivered to your Inbox.

Join 129 other followers