In my experience, it is best to get the stock ROM (that is the original ROM or firmware). This is to prevent some unexpected outcomes. With the stock ROM, at least we can recover to the (true) factory setting.
In order to flash the ROM, rooting is not required. But with an un-rooted Android, the backup will only works on the SD card (internal or external) and backup feature from the apps themselves, such as WhatsApp conversation backup and Wechat conversation backup. That means, all the games data and other apps data cannot be backup.
Therefore, if possible, root the phone then backup the data with Titanium Backup, then we no need to save the data to the cloud.
Flash a ROM or root only?
In my opinion, flashing a ROM is simpler than just rooting a phone. In order to root the phone, the method is varied between the phones. But to flash the ROM, the method is similar (in my case, Samsung device only). (As I never successfully root the phone directly, even using the one-click rooting tool.)
Flashing a custom ROM, normally provides a lot of features especially superuser (root) and busybox. Both are my favourites, as I can adb shell to do a lot of things. However, if root only, then we need to install busybox ourselves. This may be time consuming. Furthermore, with root only, we may have difficulty to upgrade the Android version, such as from Froyo to Jelly Bean. Yet, if flashing the ROM, we can choose the version of Android that we prefer (normally the latest stable).
Originality and genuineness is nice. Root an Android phone or flash in a custom ROM will void the warranty. If the warranty is expired, and the phone is “dying”, maybe flashing a new ROM is good solution to “renew” the phone. After flashing a custom ROM, you can enjoy the features provided by the ROM, especially root. So that you can install more powerful apps to your phone, including advertisement blocking apps.
Other than that, some new apps (such as games) require higher version of Android. The official firmware may only support to Ice Cream Sandwich. But, now already KitKat, you at least try to get Jelly Bean. But your Android is still Froyo or Gingerbread. Where is Honeycomb? You have missed a lot of things.
The best thing I like is busybox. With busybox, I can enjoy command-line in Terminal Emulator and also the adb shell to hack the device.
After flashing the CyanogenMod, then I had a message about the invalid IMEI. This is seriously exhaustive when I want to restore it. Finally, I give up the IMEI.
In order to restore IMEI, I had done several things. Firstly, I re-flashed the stock ROM. Then the IMEI is restored. However, in order to preserve IMEI for the custom ROM, I have to backup the /efs folder. Yet, this folder cannot be accessed without the root permission. That is why, root is needed. I failed to root the phone. As a result, I used the psneuter method to gain the root access then used the busybox to “tar” the /efs folder.
According to the forums, if we have backup efs, then we can restore the IMEI. But, after I re-flashed the CyanogenMod, then I restored the efs folder, there is a message related to “not enough disk space”. Rebooted the phone, the phone then had a valid IMEI, but it could not call and no signal. This was worse than invalid IMEI. That is why I give up the IMEI.
Heimdall and Odin
In order to flash ROMs to Samsung devices, we need to use either Heimdall or Odin. I personally use Heimdall since I am using Linux. The stock ROM I obtained are the files end with tar.md5 extension. These files are compatible to Odin. However, they can be still flashed by using Heimdall. I used “tar xf” command to extract the tar.md5 files. As a result, I got some files like recovery.img, modem.bin, factoryfs.rfs, etc. These are the files that can be flashed with Heimdall.
Therefore, to flash with Heimdall, I can use a command like
For the parameters, such as --KERNEL, these are depending on the device. In order to know what parameters are available, we can use
By these information, we can relate the parameters with the corresponding files.
During flashing, I caused my phone always boot into the Recovery Mode. The phone cannot boot into the Bootloader. I think that was because the files I flashed were incompatible and they damaged the bootloader. Thus, I downloaded another stock ROM that contains the boot.bin. Flashed it, then only that the phone can boot normally.
So, now I can enjoy my phone with custom ROM or stock ROM. Great Android phone!
Recently, my phone (3 years old) is slower and slower. This causes me frustrated, especially if I want to use it to call urgently. Interface changed slowly, the contacts listed slowly, and my urgency becomes meaningless. So, the phone is either to be replaced with a new phone, or hack it!
My old phone, namely Samsung Galaxy S (i9000), to make it reborn, I decided to install CyanogenMod. CyanogenMod is well-known of its performance and reliability. The installation steps can be found in the wiki page.
Whatever it is, data is always the most precious. So, I backup’ed all the data in the /sdcard, which is the only partition that can be accessed in a non-rooted Android. I also used Super Backup to backup the installed apps, SMS, contacts, and others. However, the backup of the apps does not include the apps setting. Sorry to say that, all the saved states of the games will be no more. Unless I root the Android first.
Since the apps data can not be backup’ed, but only the data stored in the /sdcard can be backup’ed, thus I used other ways to backup some important data. For instance, WeChat and WhatsApp. Because the conversations are precious to me, so, I used the built-in backup function of these apps.
Before start flashing the ROM to the phone, I downloaded all the necessary files: CyanogenMod stable version for Samsung Galaxy S, Google Apps, Heimdall suite, and ClockworkMod Recovery. Because I am using Linux, I installed android-sdk-platform-tools which contains the adb command.
Once prepared everything, and read the whole wiki several times, so that I know what are the possible problems and issues. Then I just followed the steps from the wiki. (However, anyone who is doing this must take the risk that, you may need to throw your phone away.)
I faced many problems. Firstly, there was no “disclaimer message” for me to accept as written in the wiki. Besides that, there was no screenshot available from the wiki. Thus, when first time I entered the download mode, I am waiting for the disclaimer message.
I ignored it, so I continued to follow the steps. The next problem was the message in the console after I flash the zImage downloaded from the wiki.
ERROR: Partition “kernel” does not exist in the specified PIT.
Immediately I searched for the information, then a user from a forum mentioned to use uppercase of --KERNEL parameter. Actually it was written in the wiki, yet the wiki didn’t mention the error message as above.
After flashed the “zImage” which was downloaded from the wiki, I came to a serious problem. My phone was stuck at the pre-boot screen. There was a Samsung logo, but the phone could not boot. The “zImage” came from the Semaphore.tar in the wiki. I immediately visited to ClockworkMod webpage to search for the “recovery image“. Yet I found none of them looks like “zImage” (they are .zip files which contain some scripts and programs). Thus, I searched “Semaphore.tar” then I came to the official page. I tried other files from the official site, yet none of them works.
Then, I found some forums mentioned they have the same problem that stuck at the pre-boot screen. Finally, I read the Discussion of the wiki. It is very useful. Other users had the same problem, and they provided some information in the discussion. Consequently, I downloaded another recovery image from the discussion page of the wiki.
Then I flashed it, and the other things worked fine (some issues were mentioned in the discussion page).
After installation, booted it, and I saw something totally different: new theme, Android 4.3, superuser, etc. Yeah!!!
So, the next thing I did was installing the Super Backup, so that I can restore all the other apps. Then restored SMS and contacts. WeChat and WhatsApp conversations were also restored. Luckily, the flashing of a ROM does not destroy the data in the /sdcard, else I need to copy the things to the phone again.
Next, I setup the Google Account and also the emails.
Then I tried to install Facebook app. Seriously, the app was slow as usual. So, I removed it immediately.
Now, I am still trying it and hopefully it has much better performance then the original ROM.
[Added 2012-10-16] Read this first: Quite a lot of readers asked me how to hack this game or hack that game. Sorry to say, I am not that expert in hacking those games, and I don’t have much time to play and hack the games. And what I shared here is only how to hack the games in general way, without permanent root the Android. So, if you are asking about a specific game, please find it on other channel. Thank you.
Frustrated with some Android games? Want to hack? Want to kill the monsters with one slice?
Okay, this is the main purpose I learn about Android rooting. After we gain the “#” from “adb shell” (refers to my previous post), now we can see all the files in /data folder. This folder contains the game save data and also some libraries.
Simple problem and solution
My hacking method is not memory editing, but save file editing. So, to edit the save file, we must have the knowledge and experience on hexadecimal editing. Now, since we can access those data files in /data/data folder, meaning that we can pull them, edit them, push them back.
So, pull the save file you want, the name such as Save0.dat or similar name. Use a hex editor, such as bless, ghex, hexedit, etc. Edit the value, then push the file back.
I personally wrote a small command-line tool, so that I can do hex editing in adb shell. (It is available here). I push it to /data/local/tmp folder, so that I can use it without pulling and pushing the file.
For some games, the save file is plain binary file. We can understand the file with the hex editing, such as the value of the coins, the level of the weapons, the status of the hero such as strength, vital, hp, and so on. These can be easily edited. (Please always make a backup before editing).
Advanced problem and solution
For other games, the save file is really a pain. They are encrypted/encoded save file. We cannot understand anything about the file. Modifying the file does not help. So, my only solution is to edit the library file, i.e. shared object (.so).
For example, if there is a library called libdhunter.so, we need to use objdump (ARM target, not x86 or x86-64 target) to disassemble the shared object. The objdump can be obtained from Android NDK package.
/path-to/objdump -dC libdhunter.so > asm.txt #pull the library file first, not doing this in adb shell
This will create “asm.txt” which contains the disassembled data. Now, what we can do is just study the functions. We might find some functions such as “encode”, “encrypt”, “decode”, “decrypt”, “save”, “load”. And also, need to look for open file, read or write file, and close file. This is because normally, they will call encrypt or encode before write the file (save). Study what the functions they are calling.
For example, in the “save” function, it might contain a call of “encode” function, then only “write” the buffer. In this case, it will be quite easy to solve the problem. Use a hex editor to open the shared object. Edit the hexadecimal value of the opcode that calls the “encode” function within “save” to “00 00 00 00”, this will produce NOP operation. That means, we disable calling “encode” function in “save” function.
Then, we can objdump again to check whether we have disabled the function call.
Push the edited library to the device. Make sure backup the original library and also the save file.
Run the game, load the save file, save the game, then exit.
Now, do not restart the game yet. Now, check the newly saved file with hex editor. If it is a plain binary file, then we success! If not, try until you want to give up.
Do not restart the game yet, because the game will load the encoded save file, not the plain binary save file. So, to make the game load the plain binary save file, we need to disable calling “decode” function in the “load” function as the method discussed above.
Push the newly edited library, then start the game.
Now, we can hex edit the save file freely as we like.
Other problem and solution (added 2012-03-19)
There are even easier problems, such as the game Aqua Pet. There is no shared object (lib*.so). And the save file is also a plain text file. Meaning, we need no hex editor to edit it. However, editing the file might not change anything. In this type of case, we must “force stop” the app first, then edit the file.
In the previous post, I mentioned about rooting the Android emulator. Now, rooting the real Android phone is another thing, quite different from rooting Android emulator.
What is the main difference? In the Android emulator, once we “adb shell”, it is “#” as root. That is why we can remount the filesystem, and do whatever as root. In the real Android phone, once we “adb shell”, it is “$” instead of “#”. That is the main difference. That is why we cannot remount the filesystem or do whatever.
Then, how should we do? According to this article, it mentions a very general way to have a temporary root. To simplify it, what we need to do is to get “psneuter“. We can get the source code of “psneuter” also. In my case, I compile the source myself with Android NDK.
Before connect the phone with the computer, make sure the setting of USB Debugging is enabled. Once we obtain this psneuter (compile by our own or get pre-compiled binary), we can
adb push psneuter /data/local/tmp
/data/local/tmp is the only folder that has read/write/execute access. So, “adb shell”, then in “adb shell”,
As a result, we will kick out from “adb shell”. Now, “adb kill-server”, then wait a while, then “adb devices”, then “adb shell” again. Now, we can see the “#” instead of “$”. Yes, this is a temporary root. If we reboot the phone, everything will be restored, then we need to run psneuter from “adb shell” again.
So, we can put the busybox or any other command-line tools in the /data/local/tmp/ as well.
PS: Next, I am going to post about game hacking. Actually, this is the original purpose that I want to root Android, because I am frustrated with some stupid games.
What is rooting actually? How does it work? I tried to figure this out these days. Now, I know how to at least root an Android emulator including creating ROM image. Since I am using emulator only, the following explanation is only applied on emulator. I have not tested on real mobile phone.
Before I begin, the followings are my working environment:
OS: Arch Linux
android-2.2 r03-2 – required for the Android platform
android-sdk r16-1 – required for emulator
android-sdk-platform-tools r10-2 – required for adb command
I was trying on Android Froyo (2.2) only.
So, to root the Android, first we need to obtain “su” binary for Android. We can get it easily from the internet. Besides that, busybox binary for Android is very useful, this can also be obtained from the internet.
Then, we need to start the emulator by providing extra partition size to /system. This can be done only through command-line, eg
Make sure the AVD “MyAndroid” is already created. The “-no-snapshot-load” option is used if we enabled the snapshot. As a result, we will start the emulator with extra disk space for /system. By this, we can adding extra files to /system later.
Then, we need to use “adb shell” to remount the /system so that we have write access to the /system.
adb shell mount -o rw,remount -t yaffs2 /dev/block/mtdblock0 /system
Then, we can push the su and busybox to the /system/xbin.
adb push su /system/xbin/
adb push busybox /system/xbin/
Now, to actually make the su work properly, we need to chmod it,
Now, we need to install Superuser.apk (which you can get together with “su”). We can install it with “adb install” command. It is required when the other apps request for “su”.
We can try our “su” with Root Checker Basic or Stericson Busybox. We should see the following image.
Now, that is rooting. You might feel happy with it. However, if we restart the emulator, without snapshot, all the “su” does not work any more. So, we are going to customise the ROM image. But before this I just want to go through about Android Market first.
To make the emulator work with Android Market, we need two APKs, Google Services Framework and Market. They are available in internet. The Market package name is com.android.vending and Google Services Framework is com.google.process.gapps
After obtaining the files, then we can push them into /system/app.
Wait a while, then you can see Market app in the emulator.
Besides that, according to this page, we need to remove the /system/app/SdkSetup.apk.
adb shell rm /system/app/SdkSetup.apk
Then, the emulator can run the Android Market, we can sign in with Google Account.
Customise ROM image for emulator
Now, if we restart the emulator, everything will return to default. No more “su” and Android Market. Why? The reason is because whatever we done to the /system, it will not save to the ROM image.
The /system is actually from the system.img, installed with android-2.2 in my case. This file is mounted in emulator as yaffs2 file system format. In order to customise this ROM image, I have tried several ways.
Using unyaffs, it can only extract the image, but I cannot continue. I can simply pull the /system using adb command without it.
Using yaffs2utils, unyaffs2 produced nothing. And the image built by mkyaffs2 does not allow the emulator to boot.
Some resources mentioned that, we can get the mkyaffs2image utility when building the Android source. But the problem is, to get the source, it requires a lot of disk space and need a long time to download.
So, what is the best way to modify the system.img? I even tried the low level way using dd to extract the /dev/block/mtdblock0, but failed.
Finally, I tried to solve it with userdata-qemu.img. This is the /data folder that will always modified when we install apps in the emulator. Restarting the emulator does not reset /data. Therefore, we can simply create the ROM image from /data. We can done it simply clean all the /data.
adb shell busybox rm -R /data/*
This will remove everything is /data, except “lost+found” folder.
adb shell busybox ls /data
Check with ls command, make sure only “lost+found” left.
Now, since the /system contains the “su”, “busybox”, Market and Google Services Framework we have done earlier, we need to copy the whole /system to the /data.
adb shell busybox cp -a /system/* /data/
adb shell busybox ls /data
As a result, the /data is identical to the /system.
Now, we have the userdata-qemu.img file in the AVD folder, which is modified. Close the emulator. Then, we can use the userdata-qemu.img file as the system image. We can rename it to system.img, or calling it as the system with “-system” option from the emulator command-line.
Start the emulator with this customised system.img, now, we have busybox by default, and also Android Market.
Missing Market apps problem (added 2012-03-14)
But if we look into the Android Market, we will discover that, a lot of apps are not available, only a few apps are available. To show most of the apps (not all the apps), we need to customise the boot image, namely ramdisk.img. We can get this file from android-2.2 package. It is together with default system.img.
Unlike system.img, ramdisk.img is actually a cpio gzip file. So, we can extract it with,
mkdir temp #make a folder
cd temp #change to the folder "temp"
gunzip -c ../ramdisk.img | cpio -i #extract the ramdisk.img,
# where it is located at the parent directory of temp
This will extract all the files to the temp/ folder.
Now, edit the default.prop, modify lines as following,
Optionally, we can also modify ro.build.fingerprint key in /system/build.prop, to bypass regional restriction. But I am not sure what are the value should be used.
After customisation, we need to re-compile the ramdisk.img. In the temp/,
This will make a new-ramdisk.img. We can rename it as “ramdisk.img” and put it in AVD folder, so that the emulator will use it be default.
Now, if we find out the apps are still missing after customisation, then we need to stop and clear both cache and data for Google Services Framework and Market. Then restart the emulator (several times), then it can work.