C:\Users\tslater\Desktop\FullTuT.swf
Build 3 successfully completed
Created at: Fri May 07 16:20:14 2010
Flash player required: v6.0 or above
Size: 14027 KB
Total frames in main movie: 29700
Playback frame rate: 20
Approximate playback time: 1485 seconds

Annotated text transcript:

Welcome to my first tutorial on AndroidOS Reversing. Before we can begin on the 'fun' stuff we need to learn how to work with our devices from our computer. 

If you haven't seen the readme on installing the SDK, please do so before continuing. (May take a while)

After the SDK is set up and we have a Virtual AndroidOS, we can learn how to install applications and uninstall.
AndroidOS runs on a Linux kernel so it will help if you have a general knowledge of some Linux commands such as 'rm' to delete a file.
Let's first open up a command prompt, in order to 'talk' to our virtual device (and real ones) we use the ADB (Android Debug Bridge) which is a command line application
first we should make sure the ADB can 'see' our device. this is done by issuing the command:
adb devices
Here is a list of all devices that the ADB can 'talk' with
Now that we know the ADB can 'talk' to our virtual device, let's install some software, in particular the one we will be reversing today "SystemPanel"
If SystemPanel.apk is in another directory you will need to enter the full file path
The application is now installed on the device! Let's check to make sure
There it is!
Next I'm going to show how to pull an application OFF of the device and onto your computer (this works for real devices too)
this will start a Linux command shell to the device!
ls -> Directory Listing
/data/app is where most applications will be installed. some end up in /system/app
there is the file name for the SystemPanel program:
nextapp.systempanel.apk

Let's exit out of the command shell
Now, to get the file from the device to our system we need to 'pull' it from the device. 

Syntax is:
adb pull <path on device> <path on PC>
As you can see, it pull'd the file from the device and placed it here :D. You will also notice that PULLing does NOT remove it from the device, for this we need to use the linux 'rm' command
This will remove the application from the device (uninstall). Note that adb does have an uninstall command but it will often fail for unknown reasons.
And over here we see that the SystemPanel application is gone!
Next we will look at how to reverse engineer an Android APK file
Like any other reversing job, we first should find the limitations (if any) of the file we are going to reverse
Ignore the 2099 here, it's originally says 2010. 
So we've found that the application will expire on May 14th of 2010, and from then on will act like the "Lite" version and have some features disabled :(
So what is an APK file exactly? one way to find out would be to open it in a hex editor and see if we recognize the Header of the file...
PK, that means that this .APK file is really just a misnamed ZIP file. Let's change the extension back to ZIP and explore the contents :D
The layout of the files reminds me of a JAR file. And in fact that's what this is, with some certain differences.
ALL AndroidOS programs run through the DalvikVM, which is much like the Java VM we're familiar with on PC's. 
The reason they chose to use Dalvik instead is because it is optimized to run on phones where resources are precious.
Unlike standard JAR files, you will not find any .class files in here. Instead they're all been packaged together into this 'classes.dex' file.

Dalvik VM uses it's own Bytecode, so Java Decompilers will NOT work on these files.

NOTE: It is not currently possible to decompile Android Programs back to source.
We've now extracted the classes.dex file from the archive. Now we need to run it through a decompiler!

The decompiler we'll use is called baksmali (Icelandic for Decompile). Why Icelandic? because that's where Dalvik VM got it's name.
baksmali is a console based jar file, and the syntax to run it is:
java -jar baksmali.jar <path to DEX file> -o <output Directory>
baksmali has created the folder we specified and it contains all the decompiled class files
Remember the full name of the application was:
nextapp.systempanel

So navigate to those folders.
Generaly speaking, one can dismiss all the R classes in this folder, R is a class generated at compile time and is only used for the AndroidOS internals, has no use to us
Settings and SystemPanel however may be worth looking into :D
OK, welcome to the decompiled look of AndroidOS applications. While it's not exactly source code, it's pretty close.

I'll explain some things as we go along
Static Constructor, this is the constructor called when the application starts. Or rather when this class is created (at startup).
Let's look into what it's doing
This line says to create a new instance of java.util.GregorianCalendar and place a reference to it in v0

Let's pull up the java documentation for this class.
Take a look at the constructors. In order to create one, a constructor has to be used. So getting an idea of the possible constructors will help
This is the most likely one to be used if we're looking for a calendar showing a date other than the current one.
As we can see in this invoke-direct call, they're calling the init() routine (constructor) and passing 3 variables (v1,v2,v3). Let's look at the values for these variables
v1 == 0x7da (2010 decimal)
v2 == 0x4 (May) 
v3 == 0xf (15th)

So they're creating a calendar for the day 15th May, 2010 (the expiration day)
They're then calling a routine call getTimeInMillis() let's look at what the documentation has to say about it.
Get a Long (64 bit number) representation of the date.
They are then taking this value (the date as a long) and storing it in v0
Then they assign that value to the FULL_VERSION_EXPIRATION field of this class.
So now that we have a feel for what's being done here, it seems the easiest fix to this is to set the year to some crazy amount like 2099 ;)
ok, now that it's fixed, lets take a look at the rest of this class for places we may need to patch up.
This seems like a good routine to force to always return true.

Let's see what's going on here
Seems they are calling a function from the Settings class. Let's scroll down and get a look at the whole routine, and then i'll explain whats going on!
Move result into v0 and compare to 0 (false)

If True (not equal to zero) goto cond_9
If it doesn't branch move v4 into v0 (v4 is set to 0x00) and then return v0 (false)
If true, get the current time in Milliseconds
Move result to v0.

Move value of FULL_VERSION_EXPIRATION to v2
Compare the 2 values, putting the result of the compare in v0
If greater than or equal (expired) goto     cond_15
cond_15 again returns false
Otherwise set v0 == 0x01 and return via goto_8
We could patch the file here, but I think it would be safer to patch the 'problem' at the source, in the Settings file :D
Here's the routine that was being called!
Seems this routine is calling another function (this time the function is a built-in android one)

Let's look up the documentation for this routine, to help understand the parameters being passed in!
Seems that you pass in a key String (name of the value) and the value to return if the key doesn't exist. 
Here's the Key String being created and assigned to v1
And the default value being assigned to v2
They then call the routine passing v1 and v2 and move the result into v0
They then return the value that was gotten. While we could just change the string so that it would never find it and just spit out default value, I feel it's safer to change the variable they return!
There, now it will always return 0x01 (v2) !
Nothing else of interest, let's save changes and recompile!
Delete old one
smali.jar is another console based JAR file, the paramters for this one are the exact opposite of baksmali
No longer need this folder, go ahead and delete it!
Need to rename this to classes.dex to match the original one
Now let's replace it!
Now we should be done right?

No, All applications downloaded from the Market are digitally signed. By altering the contents of the file we've messed up the verification of this file. So it must be resigned.
If this is the first time you are using the resigner provided in the tools folder, you should run options 1 and 2 first. Otherwise just run option 4
Need to change the extension back to .apk (may not be necessary at this point, but will be later, so might as well do it now)
No apparent errors, file was signed properly!
Now it's time to reinstall and make sure everything still works!
Make sure to click this. It will 'uninstall' any programs you've installed on the virtual device.

If you forget this, you will have to uninstall the application via the ADB command line before it'll let you reinstall it.

On a real device it's best to uninstal using the Settings application of the device.
Make sure the device is 'visible' to the adb application
The application has been installed :D now let's test it out.
Take note of the date (before expiration)
2099 hehe ;)
Now let's restart the device with the date set ahead of the expiration day :D
Past expiration day
Seems Full Version is still enabled :D
Well that does it, that's reversing AndroidOS Applications 101. Expect more to come as more interesting targets are found!

Next will be how to visually modify an application!

Hope you enjoyed this tutorial!

-- Nieylana
