Posts Tagged with java

Oh no, papihack!

Oh no, papihack!

So haven’t been around for a while, due to the flu. So it gave me plenty of time to play PapiJump and PapiRiver. Though I kind of got interested in the method of high scores so I took a more indepth look at it. I’ll posted all the code to emulator a papi* score submit. I took out the little tidbit that actually sends the request, so this just prints to the screen. I’ve also removed the “secret keys” which wouldn’t be too hard to find if your really wanted to use this.

Ah, also – kudos to anyone who figures out what I replaced the keys with. It’s sort of a little joke…

On a little after thought, maybe it should be called papipwn? Eh – oh well, either way it will be easily bannable/removable by the administrators. It’s not hard as they are linked to your specific android id so I wouldn’t recommend using this or if you do, going over board with it.

Dexdump alternatives…

Thanks to my friend Gabor, over at has created a really well done dex file dissembler. The direct link for the post is here and the source code is all free and located at

It’s nice as it outputs the format in jasmin like the following;

Opposed to the normal;

Great work Gabor, and keep up the good work!

Vending.apk reversing and getting live market data…

Mmmmm... Market Data...

Mmmmm... Market Data...

So I’m not sure why I didn’t think to try to get live market data? For some reason I just *figured* it would be done with SSL or something so I just didn’t try it. Long story short, after building a market-cache parser – I realized, DOH! You can just get the market data live using certain requests! Luckily the parser I made worked fine with the data that I was getting sent back.

It took a little reversing of Vending.apk to see exactly what type of encoding was being used – I sort of guessed right just by looking at what the phone was sending via a Cain&Abel and Wireshark dump. Though google just happened to have some data in there that would through errors if you tried decoding the data directly or certain ways.

I’ll post come up some of the reversing I did on Vending.apk – more specifically the .buildPostParameters routine which is where everything was created for post. It’s actually pretty interesting stuff, and it helped find some routines online that google has publicly available through apache… Though I didn’t find them in the Android libraries 🙂 (nice of them, no? haha)

Anyway, tournament tomorrow followed by a snowboarding trip tomorrow – so I’ll probably post that data on monday!

DroidASM: The Concept

Ok – so lately I’ve been tooling around with a few different ideas. As a practical use to my injection ideas and to incorporate my love of asm, well – combine the two! This would result in essentially a dex byte-code translator that could then run on the AndroidOS. The main idea behind it would be to code up a basic structured java file that contains all the higher level functions you would need. Toast, web stuff, etc could all be considered “higher level” functions. Then the main part of the code would be asm that is translated into dex bytecode by DroidASM and injected into the premade dex file.

Ok, so no I don’t think a huge number of people would use it, but heck – it’d be a nice little tool and a good practice at coding. Just dumping this idea into the blog as of right now, since I only have bits and pieces of code that don’t make a whole lot of sense, so it would be useless to post them right now. More to come though, for sure.

Uniquely Identifying Android Devices with special permissions

Previously I wrote about how to uniquely identify Android devices without special permissions. However, maybe you want to get into the nitty-gritty and get an even more unique identifier for the device. This can be done, but you need special permissions. Essentially what I mean by “special permissions” is that the user will be prompted when installing that “this application tries to do this”. “This” referring to (in this specific case) Reading Phone State. This doesn’t mean it’s doing anything bad, however users might be turned off if your calculator wants to read the phones state etc. This is just how Google has set up the installation of applications, so that a user is properly notified of what an application is given permission to do.

What are the kind of identifiers we can get with this special permission? We can grade the “Device ID” which is the IMEI number, the phone number, Software Version (not sure if it’s currently being used?), Sim Serial Number and Subscriber ID.

That should be enough unique identifiers for anyone to come up with some hash! Heck, phone number alone should be enough since it would be readily known by a customer and easy to use.

To get these values add the following somewhere in your program;

Note that you MUST add permission access to android.permission.READ_PHONE_STATE otherwise your program will force close. This is added in the AndroidManifest.xml like the following;

On the emulator it will output things like the following;

DeviceId(IMEI) = 000000000000000
DeviceSoftwareVersion = null
Line1Number = 15555218135
SimSerialNumber = 89014103211118510720
SubscriberId(IMSI) = 310995000000000

One should also note that a real device currently returns “00” for Device Software Version, so it’s possible that this is something reserved for future use. These could all easily be used in some type of registration algorithm that you want to tie to a certain device. Also if you choose your identifiers properly you could allow your registration code to be complaint across all versions of your product. Using a phone number for example could allow a user to use your application on any phone they put their SIM card into. If you want to prevent this you could tie it to both the device ID and the phone number.

Uniquely Identifying Android Devices without special permissions.

Something that you always come across in writing algorithms for devices that you want to lock down is getting a grasp of the actual device it is intended to be on. Sometimes programmers want to lock a registration code not only to a name for registration, but also to a device. This can cut down on “sharing” of serial numbers etc. I was doing some research and looking for device specific information when I stumbled upon a few things. They are right out there in the open, but here they are just in case you have not seen them yet.

In Android.Provider.Settings.System we have some interesting values that could be of use, one specifically is “Android_ID”. From the documentation it is the following;

String ANDROID_ID The Android ID (a unique 64-bit value) as a hex string. “android_id”

Though while this is considered a “unique key”, please keep in mind that if a program has write access to the Settings, which is possible, this could be changed easily. Though it could be a safe assuming that it should not be changed, and upon normal program usage it wouldn’t be changed. Anyway, to retrieve this ID you just use the following snip-it of code;

Also, note that in an emulator this will return “null”, though a real device will return an actual value. The nice thing about this tid-bit of code is that you are not required any special permissions to call it, since it’s essentially a passive call to get information. No write access is (obviously) required.

Dex File Header Dump

I’ve been working on the header a little more – so I figured I’d post some code I just finished throwing together quickly. It’s not all the code, since most of it is experimental and I’m not finished doing it, but this will provide people with the information on how to dump the dex file header information.

This now dumps all the header information from the original file, and will recalculate the signature and checksum in case something has changed. A version should be available shortly to check for differences in all the values, hopefully soon being able to calculate the correct values if something is wrong.

Maybe this will be useful for someone? Otherwise, oh well it’s just here in case I delete my files. Working on functions to find the new values after patching and to allow patching/injection of code. I’ll have to write up more later as I don’t have an overwhelming amount of time right now, busy day and I’m exhausted. Saw Sara play some volleyball, finished up solo campaign in COD5, spent a few hours reading and researching some dex related things and trying to get some more injection to work. Tomorrow I probably won’t have time to post – but trust me, this stuff will be up sooner or later. It’s a big puzzle I’m chipping away at, and it’s bugging the heck out of me not having the answers.

DEX File signature and checksums

DEX files, which are the compiled bytecode files that run on the Android OS. Essentially they are like the java bytecode, except they use a modified VM which is called “Dalvik” that was developed for the Android OS.

So long story short – I want to know the structure of these files, and how to edit or patch them. Why? I enjoy reverse engineering things! Anyway there is a wealth of information that I could find on the following sites;

Shane Isbell’s Weblog :
RetroCode, Dex File Formate :

These site both have great information, thoughmore so on the second link. What intrigued me was that they must have a ‘checksum’ and a ‘SHA-1’ signature. The best information I could find though only eluded to this (Retrocode);

[quote]Notes: All non-string fields are stored in little-endian format. It would appear that the checksum and signature fields are assumed to be zero when calculating the checksum and signature.[/quote]

Well that doesn’t really help me if I’d like to patch a DEX file and then redo the signature and checksum. Especially since we don’t know what exactly is being used to calculate either or what checksum is being used to well, calculate the checksum!

Good thing we can extract .jar files and decompile class files, even more so thank goodness google hasn’t used obstufication on any of the classes. An except from “dx\com\android\dx\dex\file\DexFile.class” after being decompiled into DexFile.jar.

Ah hah! Now we know how to calculate the signature and the checksum. Essentially is reads in all the bytes of the program, and it disreguards the first 32 bytes and calculates the signature using SHA-1. Then it calculates the checksum disreguarding the first 12 bytes (so it includes the signature). Excellent, lets drop this code into our own program so we can recalculate those values;

Excellent, now I can easily recalculate the signature and the checksum of the dex files. Note that the checksum is actually in little-endian so you need to reverse it when entering it in a hex editor.

So, now the Android OS will allow you to install this dex file, after signing it in the correct package (apk). Though as of right now the program still crashes upon launching the file… Hhhmmmmm we’ll have to look into this more I guess.