Posts Tagged with reverse engineering
Loose Documentation Leads to Easy Disassembler Breakages

As people have seen in the past, I tend to have a fun time finding edge-cases which break tools. Often you can find these types of edge-cases while reading documentation and cross referencing the implementation of that in the systems your validating. A pretty good example of this is highlighted in my BlackHat 2012 talk, where I was looking at the header section, which is described as always have the value of 0x70. When looking at the open source tools, some checked to make sure this was true – others ignored it. The actual code in the Dex Verifier is as follows;

From this we can see the actual implementation doesn’t care what the size of, as long as it is larger than the current structure size, which is 0x70. This allows for the verifier to be forward compatible, though if anyone was creating a tool and only read the documentation – this might not be fully understood or assumed.

This leads me to two extremely easy breakages which I never mentioned in my talk, but noticed IDA Pro 6.4 and Radare would fail against. The issue that IDA Pro and Radare broke against, was a bad file magic. According to the documentation the magic bytes are the following;

embedded in header_itemThe constant array/string DEX_FILE_MAGIC is the list of bytes that must appear at the beginning of a .dex file in order for it to be recognized as such. The value intentionally contains a newline (“\n” or 0x0a) and a null byte (“\0” or 0x00) in order to help in the detection of certain forms of corruption. The value also encodes a format version number as three decimal digits, which is expected to increase monotonically over time as the format evolves.

ubyte[8] DEX_FILE_MAGIC = { 0x64 0x65 0x78 0x0a 0x30 0x33 0x35 0x00 }
= “dex\n035\0”

Note: At least a couple earlier versions of the format have been used in widely-available public software releases. For example, version 009 was used for the M3 releases of the Android platform (November–December 2007), and version 013 was used for the M5 releases of the Android platform (February–March 2008). In several respects, these earlier versions of the format differ significantly from the version described in this document.

So one might assume that the currently accepted magic bytes will be exactly “dex\n035\00” – though, they would be wrong in assuming this. If we take a look at the code in DexFile.h;

We can see that there are constant magic bytes of “dex\n”, but the versioning afterwards – which is loosely explained in the documentation, has multiple options. Since API level 14 on, the verifier has accepted both “036\00” and “035\00” as valid versioning parts of the magic bytes. Since the magic bytes are not part of the checksum or the signature of the dex file, one can simply bump the version number without any specialized tools, just doing it with a hex editor would be fine. This lead to Radare failing to load the file and IDA Pro to thinking the file was corrupt with the following dialog and log output;

Corrupt File Dialog

I originally reported this issue to January 22nd, 2013 and received a thank you and a fix back from them only two days later on the 24th. I’m unsure if they sent this out to all their customers or have it totally bundled into their latest packages, but you should easily be able to request it if not. For Radare I submitted a patch for this issue which was quickly merge upstream by the extremely proactive author of the tool.

The second breakage, which only directly effected IDA Pro, was revolving around the file size as dictated by the dex_header vs the actual file size. IDA Pro was comparing the two, and if they where not actually equal – assumes the file is corrupt. The documentation states, “size of the entire file (including the header), in bytes”, though the implementation of the code doesn’t actually care – as seen from the DexSwapVerify.cpp file;

As we can see from above, if the actual length must be at least as large as the expected length, most likely to avoid any truncated files. Though it can easily be larger, which will just produce a warning – though processing of the dex file will continue. However, the same corrupt file dialog with this logging message comes up when loaded in IDA Pro;

Corrupt File Dialog

This was also fixed on the same timeline as the other issue I reported to Hex-Rays, so if you run across any files like this you will be prompted with this dialog;

Extra data

Just two small little issues that came about when looking at the implementation of the file format. These edge-cases always seem to exist in ever system, especially when creating reversing/disassembling/analyzing tools.

Android Zitmo Analysis: Now you see me, now you don’t

Early last week, Denis from Kaspersky had blogged about a new Zitmo (Zeus in the Mobile) variant which was affecting both Android and Blackberry. After some digging I was finally able to turn up a sample for analysis. Originally I figured it would be the same old sample as before, wouldn’t do much and not be very sophisticated at all. Turns out I was half right, most of it was identical to previous samples – though I did learn new little trick from the malware this time around.

After I did a tear down I submitted a sample to Mila over at the Contagio Mobile Dump, so if you’d like to follow along the sample I was dissecting you can find it here.

Firing up our trusty keytool, we can see what the certificate is – try to get an estimated date when this file was created;

So, assuming that the malware author hasn’t been messing around with timestamps, we can assume that the malware was created before or on July 24 of this year – and signed on that day as well. As a sanity check, the Android debug certificate validates this, since it was created before this date. This is in no way concrete that it was actually build/signed on that day – but it does give us a decent idea of the timeframe.

The next piece of interest lays within the AndroidManifest.xml – let’s see how the author intends this application to be started;

According the AndroidManifest above we can see the application has four main entry points;

  • MainActivity – launched as the main activity, which should be visible by the launcher/tray
  • ActionReceiver – launched when the HOME, BOOT_COMPLETED or USER_PRESENT intent is fired by the system
  • SmsReceiver – launched when the SMS_RECEIVED intent is fired, with a priority of Integer.MAX_VALUE
  • RebootReceiver – launched when the REBOOT or ACTION_SHUTDOWN intent is fired

This seemed like a bit to many receivers right off the bat, it seems odd that there is a reboot receiver – though maybe the author was trying to more than just intercept SMS messages? Let’s first dig into the code and see how the malware is looking to get started. Loading up IDA Pro and a terminal with baksmali, there is something we can notice right off away, the authors where using the latest Android SDK – there is a ton of support code in the android/support directory used for backwards compatibility. It’s actually a bit funny as there is more code in those files than the malware itself!

Looking at the MainActivity default create method, we can see the only code which a user might actually see when the malware is launched;


MainActivity.onCreate, cleaned up a bit

Essentially the bulk of the of the code is just checking a PersistenceManager object, which is just a wrapper for the normal Android SharedPreference object. This checks to see if the application has been run or not before. If the application has not been run, it will mark the first run as having occurred – followed by running the SmsReceiver.sendInintSms() function. This function, pictured below, gets the default admin number (+46769436094) and sends it the message “INOK”.


The next receiver to look at is the ActionReceiver. This is also very simple – essentially if the intent is either BOOT_COMPLETED or USER_PRESENT then it will attempt to kick of the MainActivity, which would cause the code above to be launched. This is also gated by the same isFirstLaunch function from the PersistenceManager class. The cleaned up code for this receiver is below, pretty self explanatory as well;


The main functionality of the malware is located where it has been for the last few Zitmo samples, inside the SmsReceiver. The onReceive method essentially houses a large switch statement which will allow the following commands to be parsed;

  • “on” – replies “ONOK” if sent from admin #, then sets the sms interceptor on
  • “off” – replies “OFOK” if sent from admin #, then sets the sms interceptor off
  • “set admin ${#}” – replies “SAOK” if sent from admin #, then sets a new admin # to user

All of the commands above will have their broadcast aborted, so no other application should receive the SMS message. If any other SMS is received other than the commands above the code follows a simple path. It will abort the broadcast aborted and the message sent to the admin number in the format of: “message ${SMS_BODY}, F: ${SMS_SENDER}”. These basic commands, combined with the a PC infected with Zeus, is enough for the authors to programmatically intercept mTans for what would appear to be German bank users.

So what, right? I said there was something interesting about this malware – yet everything described has been old stuff. Well the interesting part for me happened when I looked at the last receiver, which didn’t seem like it would be necessary. The malware already has all the code it needs to function as normal, right? Well – it actually is going to attempt to hide itself from the user on a reboot. If we look back at the AndroidManifest.xml we can see the activity tag which lets the application appear in the launcher/tray of the device;

Previously, we’ve seen malware that avoids putting this into the manifest, trying to hide from the user. In this case, the malware does want to be found and hopefully executed by the user. The trick is, they only want this to be visible to the user for one boot. If we take a look at the RebootReceiver.onReceive function, we can see a simple code path that checks for the REBOOT or ACTION_SHUTDOWN intents. If either is caught by their receiver, it will call the MainActivity.hideIcon() function. The pseudo code for this function is as follows;

This code will dynamically remove the receiver component, even though it is still set within the AndroidManifest.xml. This means on reboot, the icon will no longer be present inside the launch/tray of the device, but the other receivers should still remain active. While this isn’t rocket science – mainly just understand the Android APIs, it’s something I’ve never seen any malware do. Performing a few Google searches, it doesn’t seem to be something widely used or deployed in practice. I did perform a few searches though for applications that did this and found a few that used this to be “less annoying” to a user and hide when they where not wanted. This is also recommended for something like an option BOOT_COMPLETE intent, such as an option service that a user might not want from an application.

TL;DR – You can dynamically disable you competent in your Android application, effectively “hiding” yourself from a users launcher/tray.

A Lesson in Safe Dex
Presenting at Blackhat 2012

Presenting at Blackhat 2012

It’s been almost a full week since my talk, Dex Education: Practicing Safe Dex, though I think I’m only now beginning to recover. The past few months have truly been a whirlwind of both working on dissecting malware at Lookout and working on putting together a solid presentation for BlackHat. So far I’ve been unable to draw a crowd like Charlie, though maybe someday I’ll have people sitting in the aisles fighting for a seat during a presentation. Until then the people who went will just have to deal with the extra legroom. Over all the presentation seemed to go over pretty well, some interesting chats afterwards with some smart people. A few people where interested in the slides and proof of concept code, so I told them I would tweet it and also make a blog post about it.

My slides are available here with the proof of concept code being hosted on my github page here. The proof of concept crackme code on the same github page as well shortly.

I’ve got some extra content that I wasn’t able to fit into the slide-deck, heck it was 96 slides as is after trimming some things out. While I didn’t intend to try and cover everything possible to break most analysis tools, I wanted to attempt to cover as much as possible. Over the course of a few days or weeks, I’ll try to roll out details in my blog about how certain things worked, mainly for people who where unable to attend the presentation, hear my explanations or ask me things at the conference. Feel free to reach out to me if there is anything I’ve missed or you would live a better explanation about.

A few people asked me about Blackhat and Defcon – wondering if it’s worth attending. So to step on a soap box just for a minute, I’ll give the mini speech that I normally tell people. Conferences are only worth what you put into them, go to talks that seem interesting and are outside of your direct field of work. Why attend talks outside the direct field of work? I’ve found it’s a great way to try and find different perspectives, which often can be related back into your own work and field. It is also quiet hard to appreciate a talk on something that you deal with daily, definitely very important to try and keep this in mind if you do see those types of talks. As a presenter myself, I found it exceptionally hard to not go too low level while still feeling like I can add value to everyone in the audience. After attending the talks you chose, meet the presenters and pick their brains, this is honestly where you can learn the most. As I have said, it’s really hard to make a presentation accessible for a whole audience, talking directly with these people will give you so much more information than the slides often do. The people you meet at the bars (for Blackhat @ Caesars goto the Galleria bar) are often people you talk to online already. Make friends, go outside that comfort zone and buy some people drinks. Most everyone is friendly, if they aren’t – don’t drink with them. Almost all conferences are worth going to, Blackhat and Defcon included, mainly due to the talent it attacks that you can find hanging out at the bars.

Probably the greatest thing about Blackhat for me was to meet some really great people I’ve only had the pleasure of talking to online. Talking with Mila, the mind behind Contagio Dump, was really great – able to pay her back a little for all the hard work she does with a beer or two. Got to talk with some of the original DroidSecurity (now AVG) guys, Elad and Oren, it’s never a dull moment talking to an Israeli reverse engineer – just look at Zuk. Another interesting person who I got to hang out with was along side me in the malware talk track, @snare. He did some crazy things with EFI rootkits for OSX, pretty scary and interesting stuff all in the same talk.

People often say it isn’t what you know, but who you know. I’d argue the security space is a ying and yang of both; to be a valuable (reverser) engineer you need to know your stuff and the people to help you succeed.

Enough on this soapbox, hopefully you enjoy the slides and code. If you ever run into me at a conference – let’s have a beer or two and chat.

Mobile Security Meetup, DexTemplate and smali-mode!

Tonight there was a great meet up at the Lookout HQ, Mobile Security and Privacy – got to meet a bunch of really smart mobile developers. The topic at hand was one close to me, reverse engineering Android applications. The concept was to show developers how easy it is to do and to help them understand how an attacker might see their code. Along with showcasing the normal tools people use in their day to day lives one of my coworkers, Emil, gave a great little presentation on the overview of how reversing is done for Android. After the demonstration, Emil had some prepared crackmes for people to try, most of the engineers did surprisingly well for not having reversed anything before!

After talking with a few people who where asking about reversing, I completely forgot that I’ve never really mentioned 010 Editor. This is by far one of the best hex editors I’ve ever used, with an excellent ability to use templates. One of the best parts is, a little over half a year ago, they came out with a fully native OSX client. On top of that Jon Larimer has created a DEX template for it available on his github. This is definitely a great way to visualize a dex file and help look for anomalies in them.

Recently I’ve actually submitted some pull requests which Jon has accepted to better parse the dex files. They should be able to parse the latest dex files generated by the jellybean toolkit and even handle some “oddities” that I’ll be releasing at my BlackHat 2012 talk.

Along my route for completing my BlackHat talk, Dex Education: Practicing Safe Dex, I finally updated the small mode for emacs. It’s available on my github page. It should have color parsing for just about all the elements available inside a smali file – along with the newer jumbo opcodes.

Around the same time as my presentation at BlackHat, I’ll be posting the slides and proof of concepts to my github. So check back soon for some interesting way to break (and fix) disassembly/decompilation tools for Android.

Static decryption for Android LeNa.[b/c] using IDA Pro

Recently at Lookout we blogged about a newer flavor of Legacy Native (LeNa). This variant is extremely similar to the other ones we’ve found in the past and blogged about in October of 2011, the full tear down I wrote can be found in pdf form here. The samples for both LeNa.b and LeNa.c have been added to the Contagio Mini Dump

While going through some samples I decided to throw together a quick IDC script for IDA Pro to help decrypt the commands and variables without executing the code. The decryption isn’t hard, in fact it actually ends up just being an XOR with 0xFF. Though if anyone hasn’t ever dealt with IDA Pro or ARM, it might look a bit confusing at first. Below is the decryption function commented from one of specific samples of LeNa;

Simple XOR

Simple XOR with 0xFF

The IDC script is really simple, the current version can be found on github with the current version featured below;

The script should be really easy to follow, I tried to comment it well enough. Essentially when you load the script it will bind the function for decrypting to the “/” key. Find the pointer to the encrypted data like below;

Highlighted pointer to the encrypted data

Next just follow the pointer to it’s selection in the text section. Once the encrypted pointer is highlighted, simply hit the assigned hot-key “/” and let the script do it’s job. The script will dump the decrypted message to the output window and also add a comment next to the pointer as seen below;

The script also traverses back to all the cross references (xrefs) and will add a comment to all those spots where this variable is used.

The original usage in the decryption function

The main use of the decrypted data in another function

The main use of the decrypted data in another function

Nothing too fancy or complicated, though it was a nice way to get into IDC scripts for IDA Pro. Also it’s a good way to start segwaying people who may only have used baksmali or dex2jar into using IDA Pro for ARM reversing.

InsomniDroid – crackme solution

It’s a bit amusing that this solution for the InsomniHack CTF challenge named “InsomniDroid” was written up past midnight because I couldn’t sleep. Regardless, this was typed up as a play-by-play analysis taken from my crib notes when I actually was solving the crackme, so try to bare with me as this may read a bit odd. While some of the steps might seem odd – I find it is often just easier to tackle each APK in the same manner. This sets up a nice way to quickly find the call-stack and how things get executed and where. When tackling this challenge, I attempted to only use baksmali, opposed to any other tools for simplicity and since not everyone has IDA Pro. Anyway, if you haven’t downloaded the challenge yet you can get it from or from this local mirror (MD5: c2f94fd52c8f270e66d8b16e07fe93e4). If you haven’t solved the challenge yet, I’d recommend to stop reading here and give it a good try.

Starting off, we shoudl take a quick look at the AndroidManifest.xml through AXMLPrinter shows which is the main activity;

Now we see what where to start our search without opening the app yet, toss that crackme into baksmali and get ready for the output. No baksmali tricks in place, so we can just take a look right at the main activity, InsomniActivity. The only interesting bits for us is the call to compute method on keyBytes and setting an onClick listener for the validate button;

Seems weird that we’re computing something, though never doing anything with the returned result. Let’s just take note of that and come back later. If we look into the onClick listener (InsomniActivity$1) we can see what is going on deeper in the app;

Here we can see the bulk of this onClick listener just grabs the text from the EditText widget and uses it as a parameter for the checkSecret function. Now onward to the checkSecret function;

Ok, this doesn’t help us much. As we can see from the inlined comments I put above, all it’s doing is a SHA-256 hash for our input and comparing it to secretHash – which obviously must also be a SHA-256 digest. Let’s see if we can find this being set anywhere;

Only one hit – this is good. Let’s go back into Compute.smali and check out whats actually going on. Once we get in here we can see what appears to be, some left over code, along with an array-fill for the secretHash which is trigger the sput-object search we just performed. Let’s get the hash;


And toss that into a hashcat… Maybe it’s an easy one to get and I won’t have to do any other work… Probably not – that would seem like a brute force challenge and not a crackme one, definitely not something simple like that for someone named “crypto girl”. So lets keep looking!

Looking back at Compute.smali lets looks back into that function, compute([B) we noticed being called earlier in the APK – but never had the return value used. This one looks interesting because (1) it’s seems left over, is called once but not using the return value and (2) it’s the only place certain left over variables are being touched like c1_null, c2 and is also expecting the parameter keyBytes which we also have a variable for.

This seems interesting… It’s taking in the keyBytes as a parameter, using them to create a SecretKeySpec then using the ivBytes to initialize an IvParameterSpec. Then it attempts to decrypt the c1_null variable, though it does nothing with this return value. After that, we decrypt something that is much larger and again, don’t do anything with the value. Essentially this maps out to the following java code;

At this point I’m assuming I just solved this — run the app, look at the output… Garbage — it’s just not UTF-8 (or UTF-16) characters. That can’t be it — I don’t think the challenge would be to include non-ascii characters!

After staring at this a bit longer I decided to look at the lengths of what is being output. result has a length that will always going to be 16. p2 will end up having a length that is always being divisible by 16… Well – lets try some operations between the two resulting arrays that aren’t being used. First one I tried was XOR’ing them together (everyone loves XOR, malware writers, crackme writers, etc, etc) — and this ended up being exactly what needed to be done.

After running this we get the output;

Ah – Crypto girl left us a nice crypto related message. Essentially explaining what went on here. Fun stuff and definitely glad I didn’t wait for hashcat to try and spit out that password.

InsomniDroid – great presentation on Android Reversing Tools

Recently, Axelle from Fortinet aka Crypto Girl, presented a well done paper at InsomniHack 2012 – which she just posted on her twitter account. It does a very good job at outlining the basics of how to get into Android reversing and the Android reverse engineer tools. Since she works in the AV industry, it’s based on that view – a defensive analyst looking at malware. She does a great job describing the contents of an APK, how to read specific files (AndroidManifest.xml, etc) – giving multiple ways too. It’s nice to see how different people tackle these types of issues.

It’s also a nice thing to see someone outline all the different applicable tools. I haven’t seen anyone outside of a few Google people mention dexdump in a long time – definitely an underrated tool! It was interesting to see the list of tools she listed for decompiling the apk, specifically ded. I mention ded specifically since I’ve never actually seen anyone use it or mention it outside of the academic work done around it. Dex2jar was obviously mentioned, it’s quiet possibly the most (over)used tool out there. Personally I’m not that big of a fan of the project, though it definitely has some great use cases and people seem to love it.

Axelle did a great job providing a tutorial with a clean step by step of what to look for when tackling malware. Great steps provided about which tool to use, how to identify interesting points and then a nice little “ops! the tool broke, lets switch to the next one!” which can often happen due to the early stages of development for most of these tools. She also provides a slide on how synthetic access is created when inner classes access private members of their enclosing classes. It’s an interesting concept that seems to be lost on many beginner reversers in the Android world.

There are even a few slides on anti-emulator code, which has always been an interesting thing to me. She mentions how the Honeynet challenge implemented a few tricks and how one could either (1) modify the application or (2) modify the emulator. I’ve seen a few other people mention “hiding the emulator”, which has sent me into an interesting little tangent of research. Hopefully I’ll have time to add that into an expect Blackhat/Defcon presentation I’m working on. Personally I’m not a fan of the simplistic approach of just changing the application or the emulator imei – there have to be a ton of easier ways for an attacker to find the emulator and the defender to hide it.

Another awesome aspect of this presentation is how Axelle really did try to provide information about every tool. I’ve seen many people mention the use of Androguard, but not what features they use. I’ve personally messed around with it a bit, but haven’t found the urge to use it more often in my day to day work. I keep coming back to thinking, awesome features and implementation, though it’s just so much information I haven’t found it useful. One of Axelle’s slides I think sums it up pretty well;

Uhmm -- maybe?

Enough about the presentation – you should read it yourself. The PDF is available from Fortinets’s site (local mirror)

As a last side note — it’s extremely refreshing to see an Android presentation that does not include this “presentation filler” known as the “Android Architecture” picture 🙂

Edit: I forgot to link the crackme challenge which Axelle also provided at InsomniHack – which is also called InsomniDroid. It’s published over at if anyway wants to take the challenge. It was a fun quick little challenge, available here.

Making smali a bit easier to read in Emacs

Oh that? Just some pretty colors while reversing...

Oh that? Just some pretty colors while reversing...

Spending a large amount of time using baksmali and reading through small files can be rather dull without the right tools. A while back I noticed a few people making color scheme files for vim, Notepad+ and other tools I didn’t use. So after reading up on a quick few tutorials I created a smali-mode for Emacs.

The code is up on my github, I haven’t actually touched it in a while until last night. I noticed a few other people actually pulled clones of it and made a few minor fixes! Some good fixes too, making the loading much faster and fixing some things I wasn’t too sure about myself for making an Emacs mode.

Anyway – hopefully other people find this useful and maybe more people will contribute to the project.

For people looking for the other color schemes here are some of those resources;

Jon Larimer’s vim scheme;

Lohan+’s Notepad+ color scheme; (Directions here)

Conquering the mysterious userId (Fixing Android Market downloading)

Originally I found the easiest way to download applications was just spoofing the final request. This worked – and worked well for the entire time I had been using it. Though it bugged me that I couldn’t find out where the actual userId was coming from. So I keep digging and digging and finally came up with the solution which is posted below. I never really shared this though, since as I said – other people just used the hack and didn’t seem to care much. The main concern people had was “how do I get it faster” – which to that I always replied “learn whats going on”. Plenty of people figured it out, though now, according to the the emails I’ve been getting recently and the ones on the Android-Market-Api Google Group, this stopped old hack has working. So, I guess it’s about time to spill the rest of the mysery.

The requests originally looked like this when being sniffed over the wire;

Though recently they started looking like this;

Well – this didn’t matter much to me since I don’t use that project, but I’ve helped enough people through side channels that I figured the information is as good as public. So I’ve decided to write up a little “what is actually going on”.

Just a little while ago I committed an updated market.proto with the necessary fields to request downloads from the Android Market. Essentially I’ve added the GetAssetRequest and the GetAssetRequest which was previously missing. I also fixed the unknown field which is known as the isSecure field. This boolean field lets the market know what type of request is coming in and which token will be used.

In the order versions of the vending apk, not everything was send over HTTPS. When most normal requests (get application info, queries, etc) where over unsecured HTTP, the GetAssetsRequest was considered “secure” and only went over HTTPS. This meant the isSecure field had to be set and a new authtoken would be used. Instead of the android service authtoken being sent, the androidsecure token would be sent. This is probably done so that if someone was sniffing requests, they couldn’t just reuse your android token and get away with it, though it may have been done for other reasons.

So what was the mystery of the userId? Well – it was never found on the device, because it was never actually stored on the device. It was only stored sometimes inside of URLS which had been cached or saved to databases. If properly using the protobuf, this relieves the person from needing to find these values, since the market themselves provide them! It was a bit annoying to figure this out finally, but also a huge relief since I wasn’t going crazy not finding the userId anymore.

So let’s sum this all up;

1. Get the android secure token for your account, use this as the authtoken for your next request
2. Build proper request protobuf; Use authtoken from above, set isSecure to true and add the assetId to a GetAssetRequest
3. Receive the GetAssetResponse and build an HTTP request from it using the; blobUrl as the URL and set a cookie using the downloadAuthCookieName/downloadAuthCookieValue pair.

Lastly, I’d like the apologize for the delay in this information. I feel a bit bad since I’ve known this for a while, but most people who ask me questions where just using the hack, which — until very recently worked fine. Also, it has always been possible to just reverse the apk yourself and figure out what was going on 😉

Quickly setting up an Android emulator for fuzzing/hacking

Normally I like spending time fuzzing/causing segfaults with real devices, not sure why – maybe it’s just because it just feels more gratifying. Though recently for a small project at work, I need to be able to do multiple devices for longer periods of time and swap out different modules relatively fast. This would be a huge problem – but I wanted to automate it and do the least amount of work possible. A challenge that comes up sometimes with the somewhat stock phones I use for testing, is that some compiled modules/elf binaries never worked that well. Sometimes due to carrier modifications, sometimes due to Cyanogen modifications other times just due to me being stupid and compiling things horribly wrong. Since I just got my desktop machine all set up, it seemed like the perfect time to try and automate this on a box I could just SSH into and let run all the time!

After a quick bit of Googling, I didn’t see many instructions on how to modify emulator images fast. Lots of people said, generate an emulator, then change the system.img by mounting it, then restart the emulator and make sure it doesn’t overwrite changes. That’s a pain though, I don’t want to mount anything! Though this did remind me of building the AOSP which can product the system.img — perfect!

After making all my changes, some Dalvik changes and some Webkit changes, kicked off a full build via the normal commands;

While waiting for the compilation to finish – I prepped a “target platform” to build an emulator image for. To quickly do this I just copied the android-15 directory under the platforms directory of the sdk. This will give us the proper structure and files required while keeping the normal platform for android-15 intact.

Awesome, we copied over the system.img too the nessicary directory, lets just edit a few files so I don’t forget what this when I build my emulators. Open up the file and edit the version number to something you can remember, I just changed mine to say 4.0.3-hacked;

Now I can just create an emulator like normal and fire it up;

Now it just time to attach your fuzzing and other automated tools to the emulator.