Framework for Writing Flexible Bruteforcers

When writing a bruteforcer, it’s easiest to think of it as mapping some kind of output to a monotonically-increasing number.

Like for one of the solved PlaidCTF question, the answer string was composed from the eight letters “plaidctf”, which conveniently is a power of 2, meaning each output character can be represented with 3 bits. To write a bruteforcer for a string composed of these characters, you might imagine generating a 3-bit number (i.e. from 0 to 7) then mapping it to the character set for one output character, or a 30-bit number if the output string was 10 characters. Unsurprisingly, this was exactly what I did for my solver script. The output string was generated from a BitVector of 171 * 3 bits.

But what if the output was composed of several different pieces that cannot be represented uniformly as a set of bits?

One solution might be to emulate such a behaviour using an array of integers, like how I modified my solver script in version 2 to handle a character set of arbitrary length.

In this post, I will walk-through writing a basic, but flexible, bruteforcer with accompanying code snippets in Go.

Keeping State

Continuing on the CTF puzzle, the BitVector was replaced with an array of Ints. Each Int will represent one character of the output string. We can thus represent the state like so (for simplicity, let’s limit the output string to 2 characters):

type state struct {
    digit [2]int
}

In order to increment each digit, we can write a function that increments state.digit until a certain number, then resets it to zero.

To make it generic, we will write a function that returns another function that manipulates a digit position, so we don’t have to copy & paste the code for each digit position:

// returns a function that manipulates the digit at given pos
func digitManipulator(pos int) func(*state) bool {
    return func(s *state) bool {
        s.digit[pos]++
        if s.digit[pos] == MAX_NUMBER {
            s.digit[pos] = 0
            return true
        }
        return false
    }
}

We will talk more about the boolean return value later.

Continue reading

Advertisements

Cracking iTunes Backup Passwords with hashcat

Following the recent announcement of LUKS support in hashcat, I noticed that there have been some commits to support iTunes Backup passwords as well.

This is only useful if the backup was encrypted by setting a backup password on the iOS device. If the backup is not encrypted then all the files are in clear and there is nothing to bruteforce.

The keys used to encrypt the backup are stored in the BackupKeyBag, which can be found in the Manifest.plist file. This keybag is a binary blob, the format of which has already been documented by researchers from Sogeti ESEC Lab.

I have written a simplified script which dumps the BackupKeyBag.
You will need the Python bindings from libplist for the script to work. If you cannot get it to work, you can try the Perl script from philsmd instead.

Speeding up iOS Backups

iOS device backups usually take a while, depending on how much storage has been used on your device.

The iOS backup process is driven by the device itself, through the BackupAgent process. This process treats the host PC like a dumb disk store, by sending it commands like DLMessageCreateDirectory, DLMessageUploadFiles, DLMessageRemoveFiles, DLMessageGetFreeDiskSpace, etc. so that it can determine what has been backed up previously and what to send/update for incremental backups.

For password cracking, we don’t need the entire 64 GB (or God forbid, 128 GB) of data on the iOS device. We just need the Manifest.plist, which is typically less than 50 KB. But because the backup process is controlled by the device and not the PC, we can’t simply ask it to send over that single file. Sometimes when we setup a VM with libimobiledevice, we might also not have allocated such a large virtual disk. Of course when I say “we”, I really mean “I”.

Continue reading

Paper Shredder Repair

Now is probably a good time to mention that I have a paper shredder. When I was shopping for a shredder, the basic requirement is that it must be relatively “secure”. Straight cut shredders (that produce long straight strips) are definitely not secure.

Ultimately I settled on the CARL DS-3000 personal paper shredder. The DS-3000 is a cross-cut shredder which produces “particles” no larger than 2mm x 4.5mm and this meets DIN security level 4. These days, the NSA mandates 1mm x 5mm “particles” for classified documents.

At this point, it’s probably helpful to show you what my shredder bin looks like:

shredder confetti

From the particles, you can make out various truncated words such as “A/C”, “exp” and the number “5”, but it’s almost impossible to reconstruct any bank balances or personal information from it.

This particular model was the right balance between my budget and the level of security. Plus, the shredder is compact enough to sit on your desk. I bought it in 2009 and I use it every couple of months when I have accumulated enough material that needs to be destroyed.

I was in the middle of shredding papers when it suddenly stopped working. Now the shredder does not respond when I stick paper into its slot. The LED indicator looks dimmer than usual when it is turned on.

But I’m not ready to give up on it just yet…

Continue reading

Interesting 31C3 Talks

31C3 logo "a new dawn"

The 31st Chaos Communication Congress (31C3) ended just 3 days ago, and there were several interesting talks.

They have got live streaming of the event over the web, as well as encourage you to use an external player with RTMP or HLS support. The video streams were very reliable and best of all, it’s available in HD. In comparison, I tried the Apple live event once and it was really crappy. For one, the HLS1 URL is not publicly available , so someone had to dig that out and post it. Even after that, the audio stream was (I believe, unintentionally) a mix of both English and Chinese simultaneously.

The 31C3 video recordings were also uploaded very quickly after the event. This is much quicker than other events such as Black Hat (although as an attendee, you do get a copy of the stuff on a DVD). A really big kudos to the organizers and the video production team!

If you don’t have time to listen to each and every talk, here are a few selected talks that were interesting to me, as well as a short summary to see if it’s worth 30 or 60 minutes of your time.

A full list of talks can be found here: http://media.ccc.de/browse/congress/2014/index.html

Continue reading

Android Internals: Package Verifiers

Inspired by Nikolay Elenkov’s detailed technical posts on Android Explorations, I decided to dig into the Android source code myself and document the package verification mechanism in Android.

Package verification was introduced in Android 4.2 to allow for apps to be verified or checked before they are installed. If you have tried to install a malicious app on a production Android device, you might have seen the following screen, displayed by the verifier:

screenshot of malicious app install warning

Android was built in such a way that it tries to be generic for third-parties to implement stuff. Package verification is a feature that is currently only used and implemented by Google, but it is abstracted in such a way that any manufacturer can implement their own. Documentation and examples on how to do this is almost non-existent, although anyone determined enough can read the Android source code and figure it out for themselves.

Continue reading