[Hack] Root Phones ("exploit needless" method)
How I root any ROM on (almost?) any Android Phone
My Phone simply needs to fullfill one requirement:
I MUST be able to flash the recovery.img standalone!
Chapter One: unpack, edit and repack recovery.img
I will use these Linux programs:
split bootimg (Thanks to William Enck)
mkbootimg (compiled from AOSP source)
...the former splits the recovery.img into kernel and ramdisk...
...the latter repack all togheteher...
...For example I'll try these commands on a clockworkmod recovery from an HTC desire (I download 5.0.2.0-bravo from ClockWorkMod)...
Linux Side:
Code:
[email protected] $ split_bootimg.pl recovery-clockwork-5.0.2.0-bravo.img
Page size: 2048 (0x00000800)
Kernel size: 1831224 (0x001bf138)
Ramdisk size: 1291948 (0x0013b6ac)
Second size: 0 (0x00000000)
Board name:
Command line: no_console_suspend=1 msmsdcc_sdioirq=1 wire.search_count=5
Writing recovery-clockwork-5.0.2.0-bravo.img-kernel ... complete.
Writing recovery-clockwork-5.0.2.0-bravo.img-ramdisk.gz ... complete.
[email protected] $
I write down parameters needed later on:
Page Size = 2048
Command line = 'no_console_suspend=1 msmsdcc_sdioirq=1 wire.search_count=5'
HexEditing Lookout of recovery.img header:
Code:
[email protected] $ hexedit recovery-clockwork-5.0.2.0-bravo.img
00000000 41 4E 44 52 4F 49 44 21 38 F1 1B 00 00 80 00 20 ANDROID!8......
00000010 AC B6 13 00 00 00 00 21 00 00 00 00 00 00 F0 20 .......!.......
00000020 00 01 [COLOR=#0000ff][B]00[/B][/COLOR] [COLOR=red][B]20[/B][/COLOR] 00 08 00 00 00 00 00 00 00 00 00 00 ... ............
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000040 6E 6F 5F 63 6F 6E 73 6F 6C 65 5F 73 75 73 70 65 no_console_suspe
00000050 6E 64 3D 31 20 6D 73 6D 73 64 63 63 5F 73 64 69 nd=1 msmsdcc_sdi
00000060 6F 69 72 71 3D 31 20 77 69 72 65 2E 73 65 61 72 oirq=1 wire.sear
00000070 63 68 5F 63 6F 75 6E 74 3D 35 00 00 00 00 00 00 ch_count=5......
I use the highlighted address ordered as follows:
base = 0x20000000
Now I simply repack alltoghether.. just to check new file vs old one:
Code:
[email protected] $ mkbootimg --kernel recovery-clockwork-5.0.2.0-bravo.img-kernel --ramdisk recovery-clockwork-5.0.2.0-bravo.img-ramdisk.gz --base 0x20000000 --pagesize 2048 --cmdline 'no_console_suspend=1 msmsdcc_sdioirq=1 wire.search_count=5' -o recovery_new.img
[email protected] $
[email protected] $ diff recovery-clockwork-5.0.2.0-bravo.img recovery_new.img
[email protected] $
No warnings, binary files don't differ...
Editing ramdisk:
Code:
[email protected] $ mkdir ramdisk
[email protected]ndalf $ cd ramdisk/
[email protected] $ gunzip -c ../recovery-clockwork-5.0.2.0-bravo.img-ramdisk.gz | cpio -i
4294 blocks
[email protected] $ ls -l
totale 144
drwxrwx--x 2 doc doc 4096 23 nov 23.56 data
-rw-r--r-- 1 doc doc 2615 23 nov 23.56 [B]default.prop[/B]
drwxr-xr-x 2 doc doc 4096 23 nov 23.56 dev
drwxr-xr-x 2 doc doc 4096 23 nov 23.56 etc
-rwxr-x--- 1 doc doc 94372 23 nov 23.56 init
-rwxr-x--- 1 doc doc 691 23 nov 23.56 init.rc
drwxr-xr-x 2 doc doc 4096 23 nov 23.56 proc
drwxr-xr-x 3 doc doc 4096 23 nov 23.56 res
drwxr-x--- 2 doc doc 4096 23 nov 23.56 sbin
drwxr-xr-x 2 doc doc 4096 23 nov 23.56 sys
drwxr-xr-x 3 doc doc 4096 23 nov 23.56 system
drwxr-xr-x 2 doc doc 4096 23 nov 23.56 tmp
-rw-r--r-- 1 doc doc 0 23 nov 23.56 ueventd.goldfish.rc
-rw-r--r-- 1 doc doc 4027 23 nov 23.56 ueventd.rc
[email protected] $
I'm going to modify one line of default.prop from
Code:
...
ro.secure=[B]1[/B]
...
to
Code:
...
ro.secure=[B]0[/B]
...
WARNING: clockworkmod recoveries could already have ro.secure set to 0
Repack ramdisk:
Code:
[email protected] $ find . | cpio -o -H newc | gzip > ../recovery-clockwork-5.0.2.0-bravo.img-ramdisk.gz
4295 blocks
[email protected] $ cd ..
[email protected] $
Repack recovery.img (as showed before):
Code:
[email protected] $ mkbootimg --kernel recovery-clockwork-5.0.2.0-bravo.img-kernel --ramdisk recovery-clockwork-5.0.2.0-bravo.img-ramdisk.gz --base 0x20000000 --pagesize 2048 --cmdline 'no_console_suspend=1 msmsdcc_sdioirq=1 wire.search_count=5' -o recovery_new.img
[email protected] $
Chapter Two: flash recovery.img to phone
I own a Samsung Galaxy Next, so I need to create an Odin Ready Archive and so on...
Different phone brands need different flash methods, I bet...
Chapter Three: Rooting
I need android sdk and I try android debug bridge...
...on a not rooted phone:
Code:
(i686) [email protected] $ adb shell
[B]$[/B] su
Permission denied
[B]$[/B]
...and on a rooted one:
Code:
(i686) [email protected] $ adb shell
[B]$[/B] su
[B]#[/B]
Now, starting the phone in recovewry mode with ro.secure=0, connecting with "adb shell" I find:
Code:
[email protected] $ adb shell
#
Already a root shell! No exploit needed!
Take a look to /system:
Code:
# mount
...
/dev/block/mmcblk0p3 /system ext4 [B]rw[/B],relatime,barrier=1,data=ordered 0 0
...
WOW! already "read-write" mounted... (if not mounted I can easily remount it "rw"... I'm root!)
Now, having su binary, Superuser.apk and busybox in the linux working directory:
Linux side:
Code:
[email protected] $ adb push su /system/xbin
417 KB/s (22228 bytes in 0.051s)
[email protected] $ adb push su /system/bin
529 KB/s (22228 bytes in 0.041s)
[email protected] $ adb push busybox /system/xbin
5061 KB/s (1674712 bytes in 0.323s)
[email protected] $
Anyway it should be better to make a backup of old su binary before overwriting it (adb pull /system/bin/su su-old)
"adb shell":
Code:
# chown root.shell /system/bin/su
# chmod 06755 /system/bin/su
# chown root.shell /system/xbin/su
# chmod 06755 /system/xbin/su
# chmod 04755 /system/xbin/busybox
#
WARNINNG: ordered commands
Linux:
Code:
[email protected] $ adb push com.noshufou.android.su-1.apk /system/app/Superuser.apk
5198 KB/s (843503 bytes in 0.158s)
[email protected] $
"adb shell":
Code:
# chmod 644 /system/app/Superuser.apk
#
THAT'S ALL FOLKS!
reboot system now!
...
Code:
[email protected] $ adb shell
$ su
#
Enjoy!
...no exploit needed...
...
...Simply Linux Way of Hacking!...
Doc,
I dont get any command line: ...
in stock recovery/boot image.
can i just edit the default.prop of stock recovery img and flash it as PDA? or one package?
also does this not work when done to the boot.img?
roofrider said:
...I dont get any command line: ...
in stock recovery/boot image.
Click to expand...
Click to collapse
Command Line is optional, and usually - for example - you don't get anyone on Samsung Galxy Phone... for the HTC used in the example, instead, there was one, needed to tune the boot parameters on runtime...
can i just edit the default.prop of stock recovery img and flash it as PDA? or one package?
Click to expand...
Click to collapse
Surely you can! This Thread is exactly what you said: "change one file in stock recovery image"... all the rest is explanation on how I did it...
also does this not work when done to the boot.img?
Click to expand...
Click to collapse
Loud and Clear! Boot works in the same way but I prefer not to unsecure the system too much... cause any app could gain root privileges without asking for whenever she wants...
...whilst I'm the only one who decide to enter Recovery Mode...
Hi.
Even I can read on /tmp/recovery.log:
Code:
[property list]
ro.secure=0
ro.allow.mock.location=0
I get a normal user prompt on adb shell when phone is recovery boot.
So I guess I need some more tunning for make this work on a Samsung Galaxy Mini.
Thanks anyway. I've learnt how to build images with this post :good:
Galaxi Mini too!
XiR_ said:
Hi.
Even I can read on /tmp/recovery.log:
Code:
[property list]
ro.secure=0
ro.allow.mock.location=0
I get a normal user prompt on adb shell when phone is recovery boot.
So I guess I need some more tunning for make this work on a Samsung Galaxy Mini.
Thanks anyway. I've learnt how to build images with this post :good:
Click to expand...
Click to collapse
I own a Galaxy Mini too and I just get the same issue while testing Gingerbread 2.3.6 S5570XWKTN; my previous release was S5570XIKQC (2.3.4) where I got easy superuser rights on connection...
Maybe there is something more to check for...
Actually I have two simple workarounds to root, anyway, the working system as explained above:
I flash an old Recovery (2.3.4)! no real need to bump to 2.3.6 other then "on working system" (here there is my one: CODE_S5570XIKQC_recovery.tar.md5)
I flash (my current option) a CWM based recovery (here there is my one, freshly compiled from Mebitek Cyanogen 7.2 Unofficial Source: CODE_S5570CYANO_recovery.tar.md5 - CWM 5.0.2.8)
2.3.6 XWKTN
Testing Gb 2.3.6 XWKTN I got another unusual issue (unconfirmed on the network...):
After root, when I power on the phone I get the binaries
/system/xbin/su
/system/xbin/busybox
always deleted...
I workarounded it modifying the boot image:
I changed permissions of
/sbin
folder
Code:
# ls -l /
...
drwxr-x[B][COLOR="Red"]r[/COLOR][/B]-[B][COLOR="Red"]x[/COLOR][/B] 2 root root 0 Jan 1 1970 sbin
...
to give every user "exec rights" on it, then I put there both binaries!
Eh eh... I know that the system PATH first look there for commands:
Code:
# set | grep ^PATH
PATH=[B][COLOR="Red"]/sbin[/COLOR][/B]:/vendor/bin:/system/sbin:/system/bin:/system/xbin
#
Last:
I also put in 2.3.6 recovery /sbin folder the last "su" binary (source from GitHub)...
On execution I get "SegFault", but Root privileges Anyway:
Code:
$ su
Segmentation Fault
#
...amazing...
after doing a little research on the web why it's asking for sim network unlock pin, found out it's because my device it locked with a certain carrier/provider. i made sure it was already unlocked when i got, i was even able to use for about a week. however, for some reason it got locked again and got that message. i'm sure i didn't make any changes because this is my first time to have a samsung tab, that's when i tried to do more research about it and i know there's a way to do it but i guess i need a more detailed guide, please help... thanks!
This program finds the SIM unlock code for your Samsung Galaxy p6200 device. It requires root / superuser.
Simply install the application, hit the "SIM unlock code" button, wait a few minutes, and it should come up with the code. It can indeed take a while, so plug your phone in the charger before running, and go make yourself a cup of coffee.
Write down the code, turn off your device, insert a SIM that doesn't match your SIM lock, turn the device on again, and enter the code when the device asks for it.
If the code does not work, do NOT try it again. You might end up with a freeze. The app can also find the unfreeze code, but if the SIM unlock code was wrong in the first place, maybe so is the unfreeze code.download free sim unlock for galaxy p6200 here:http://www.mobyware.net/get-software-65666.html
........Another method :Step 1. - Retrieve nv_data.bin file
use "adb shell" or a terminal emulator to get a terminal prompt and run the following commands
Code:
su
cat /efs/nv_data.bin >> /sdcard/nv_data.bin
cat /efs/.nv_state >> /sdcard/.nv_state
busybox cp -r /efs /sdcard/
Step 2. - Edit nv_data.bin file
mount the internal SD Card on your computer
make a backup copy of the nv_data.bin file on your computer
using your favorite HEX editor open the nv_data.bin on the sdcard
jump to address 0x181468
you should see a string like this
ff 01 00 00 00 00
there are 5 different types of locks in 5 different bytes
the FF byte should be left alone
the first byte after the FF is the network lock
the next byte is the network subset lock
the next byte is the sp lock
the next byte is the cp lock
the last byte appears to be a data lock.
the 46 46 should be left alone
Change any 0x01 to 0x00 (or 0x00 to 0x01 to lock for warranty)
It should read ff 00 00 00 00 00 46 46 for unlocked
save and close file
unmount SD Card
Step 3. - Replace nv_data.bin file
I want to say it again so no one misses it MAKE SURE YOU HAVE A BACKUP OF YOUR /efs/ FOLDER BEFORE YOU CONTINUE!!!!!
use "adb shell" or a terminal emulator to get a terminal prompt and run the following commands
Code:
su
rm /efs/nv_*
rm /efs/.nv_*
cat /sdcard/nv_data.bin >> /efs/nv_data.bin
cat /sdcard/.nv_state >> /efs/.nv_state
chmod 755 /efs/nv_data.bin
chown radio.radio /efs/nv_data.bin || chown 1001.1001 /efs/nv_data.bin
chmod 755 /efs/.nv_state
chown radio.radio /efs/.nv_state || chown 1001.1001 /efs/.nv_state
reboot
your tab is now unlocked... enjoy
Just make sure you back up your entire /efs folder (save it on your computer and your tablet) before making any change.I believe you can refer to this one on the 10.1 tab forum :http://forum.xda-developers.com/showthread.php?t=1336659&highlight=t-mobile+unlock....
Can anyone confirm that this solution works? I'm reluctant to try without a guarantee
Sent from my HTC Desire S using xda app-developers app
@devid801
Ok, so I've opened the nv_data.bin file in hex edtor and found the following at address 00181468 : ff 01 00 00 00 00 44 4b . As you can see, the 46 46 is not there, instead there is 44 4b . Is this significant? Do I have to replace with 46 46 or should I leave it alone? Could this mean that this solution does not apply in my case and I risk breaking my device if I use it? Please advise.
Edit: I ignored the 44 4b bytes there and just changed the 01 to 00 and it worked, I am now network unlocked. Thanks for posting the solution
Folks,
I was trying to SIM unlock my Galaxy S I9000 using this thread: http://forum.xda-developers.com/showthread.php?t=761045 and noticed the following:
Filesystems Mounted Read only: / and /system are mounted ro
Patching nv_data.bin doesn't work: the result once that's done is the phne still being SIM locked
So here's my amended procedure, that worked on my Galaxy S I9000, locked to T-mobile UK:
If your phone is not rooted, then follow any of the methods listed in this link to root your phone first, before going any further. I will post a full rooting procedure and integrate it with this post shortly, for convenience and completeness.
Once rooted, enable USB debugging on your phone from the settings menu. Various releases of Brokendroid will have subtle differences on how this is done, but I'm sure you'll find your way. Again, I intend to update this procedure once I finish the rooting article, so the instructions are more complete. Also enable SD Card USB access.
Connect your phone to a USB port on a computer
Assuming you have downloaded, extracted and installed Brokendroid SDK from (Google, then there will be a directory under where you extracted the tools that looks something like: sdk/platform-tools. Change to that directory, and issue the following commands:
Code:
$ ./adb shell
[email protected]$ su -
[email protected]# cat /efs/nv_data.bin >> /sdcard/nv_data.bin
Once done, copy the nv_data.bin file from your SD card to your machine and make a working copy (e.g. nv_data-working.bin)
Using your favourite hex editor, go to address 0x00180066 and look for the following sequence of bytes:
Code:
00 [HL] [HL] [HL] [HL] [HL] 23
Where the [HL] sequence represents your present network's PLMN code.
Replace all the sequence above with 00; In n my case, the PLMN for T-mobile is 23410, so the byte sequence was changed as follows:
Code:
From
00 32 33 34 31 30 23
To
00 00 00 00 00 00 00
Go to address 0x181468
This is a sequence of 8 bytes that starts with FF and ends with 46 46. In my case, this was:
Code:
FF 01 00 00 00 00 46 46
The significance of these bytes are as follows:
FF Sart of string - LEAVE ALONE
Network Lock
Network Subset Lock
SP Lock
CP Lock
Data Lock.
46 46 End of string - LEAVE ALONE
You need to change this sequence so that all bytes between the FF and 46 46 are set to 00. I.e.;
Code:
FF 00 00 00 00 00 46 46
Save the resulting file.
Transfer the resulting file to your SD card - I am assuming your new file name is nv_data-working.bin
Issue the following commands, with your phone connected to the computer:
Code:
[email protected]# mount -o rw,remount /
[email protected]# mount -o rw,remount /sys
[email protected]# mount -o rw,remount /system
[email protected]# rm /efs/nv_data.bin
[email protected]# rm /efs/nv_data.bin.md5
[email protected]# cat /sdcard/nv_data-working.bin > /efs/nv_data.bin
[email protected]# chmod 755 /efs/nv_data.bin
[email protected]# chown radio.radio /efs/nv_data.bin || chown 1001.1001 /efs/nv_data.bin
reboot
[/LIST]
And you are done .. your phone is SIM unlocked :)
Hello friends, I'm back again with something I wish to share with you all. I have compiled three files to work flawlessly for ARM devices which will allow users to unpack, edit, and repack their boot.img without the use of a PC and all straight from their device.
---unmkbootimg, mkbootfs, mkbootimg---
Click here for the source on my Github.
Hey guys, since I have made this thread a while back there has been a LOT of changes made to the resource. For starters, it is now a multi call binary. In addition, I have updated mkbootfs for better support, mkbootimg.c has dt support, unmkbootimg.c has dt support, bootimg.h has dt support, as well as adding dtbtool, and dtc. Lets not also forget about lz4 for those whos ramdisks are not gz compressed. I am continuously making changes to the source and the op attachment will not be kept up to date. To stay up to date you will need to build the multi call binary from the source provided by the link above. Just simply run: make multi.
Note:
-- The mkbootimg binary is based upon the AOSP with some added modifications to work in conjunction with unmkbootimg.
-- The unmkbootimg binary is based on the original mkbootimg source but with reverse engineering to compliment its helpful use in extraction and thus providing the needed command to rebuild properly.
-- The mkbootfs binary is based on the source provided within the dsixda kitchen to insure the proper structural repacking of the ramdisk, etc.
Requirements:
-- BusyBox (cpio, gunzip and gzip is mandatory)
-- /System Write Permissions (Does not need to be a modified kernel)
-- Terminal Emulator
-- ES File Explorer (or similar)
-- Hex Editor (or use of DD)
-- Unzip boot_manipulation.zip on your device and copy the three files over to /system/bin. Those three files inside the .zip will be named unmkbootimg, mkbootfs and mkbootimg.
-- EDIT: I have included a flashable zip for these files.
-- Set permissions to rwxr-xr-x (755) on each binary. Note: The flash zip does this already.
-- Open up your android terminal emulator.
-- Now go ahead and pull your boot.img from your device (or use another one if you wish). Here is an example:
Code:
[email protected]:/ # [COLOR="Red"]dd if=/dev/block/mmcblk0p20 of=/data/local/tmp/boot.img[/COLOR]
dd if=/dev/block/mmcblk0p20 of=/data/local/tmp/boot.img
32768+0 records in
32768+0 records out
16777216 bytes transferred in 1.496 secs (11214716 bytes/sec)
[email protected]:/ #
-- Open up your boot.img with the Hex Editor and look for: ANDROID!. Remove everything before it so that the ANDROID! header is the first to be read then save it over top of the boot.img. NOTE: This is only required if you are using a stock boot.img. Here is an example:
Code:
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00000000 [COLOR="red"]A5 F0 BA B7 B0 43 E3 F8 3C E1 63 55 AE 75 C6 69 ¥ðº·°Cãø<ácU®uÆi[/COLOR]
00000010 [COLOR="red"]11 27 16 2F 51 48 E5 41 6F ED E1 7D C9 61 FB 3B .'./QHåAoíá}Éaû;[/COLOR]
00000020 [COLOR="red"]5F 45 49 EE 48 79 6E 4E FB DE 18 FC A0 F4 9A C3 _EIîHynNûÞ.ü*ôšÃ[/COLOR]
00000030 [COLOR="red"]43 11 35 67 AD 7E 2F D8 F6 E8 B1 4D 7D E0 45 B6 C.5g.~/Øöè±M}àE¶[/COLOR]
00000040 [COLOR="red"]E2 08 5F 0B 56 7F 45 71 3D 38 E2 C4 76 3E 53 EE â._.V.Eq=8âÄv>Sî[/COLOR]
00000050 [COLOR="red"]A4 3D 83 9F A2 BE D5 F4 75 5D B5 08 4E CC 9B BC ¤=ƒŸ¢¾Õôu]µ.NÌ›¼[/COLOR]
00000060 [COLOR="red"]7F 7A 9E 3D 4B 19 1B 91 6D FB 82 A0 B5 A8 38 88 .zž=K..‘mû‚*µ¨8ˆ[/COLOR]
00000070 [COLOR="red"]25 07 B5 1B 74 A2 03 62 BE 78 FA 33 96 A0 32 70 %.µ.t¢.b¾xú3–*2p[/COLOR]
00000080 [COLOR="red"]05 56 50 EF 88 C1 F3 73 E4 C5 73 6A 4E F8 CA 0A .VPïˆÁósäÅsjNøÊ.[/COLOR]
00000090 [COLOR="red"]D7 EF 2A 7F 09 30 21 BF 63 61 35 9A 9B 8A 62 42 ×ï*..0!¿ca5š›ŠbB[/COLOR]
000000A0 [COLOR="red"]28 C2 78 08 B0 CD 94 5F 7E EC F6 BA AD E6 AE 23 (Âx.°Í”_~ìöº.æ®#[/COLOR]
000000B0 [COLOR="red"]3E FD D8 A0 F1 F6 6D E2 D9 1E 2C E5 9F 91 84 92 >ýØ*ñömâÙ.,埑„’[/COLOR]
000000C0 [COLOR="red"]2E F0 6E 3C 1D 2B 1A D5 61 18 B2 F4 E0 66 B5 2F .ðn<.+.Õa.²ôàfµ/[/COLOR]
000000D0 [COLOR="red"]AE 97 9F F8 53 65 CE ED 68 43 4B 2B D5 A1 B6 D9 ®—ŸøSeÎíhCK+Õ¡¶Ù[/COLOR]
000000E0 [COLOR="red"]7D 36 CE A9 CC EC F4 5A 07 D8 99 5A 91 CC 8F 71 }6ΩÌìôZ.Ø™Z‘Ì.q[/COLOR]
000000F0 [COLOR="red"]A1 8D D7 82 C3 20 AB 7A 07 68 10 2D CC F6 A8 F9 ¡.ׂà «z.h.-Ìö¨ù[/COLOR]
00000100 41 4E 44 52 4F 49 44 21 08 D6 56 00 00 80 40 80 ANDROID!.ÖV..€@€
00000110 0E F0 07 00 00 80 80 81 00 00 00 00 00 00 30 81 .ð...€€.......0.
00000120 00 01 40 80 00 08 00 00 00 00 00 00 00 00 00 00 [email protected]€............
00000130 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
-- Please note, HTC uses a 256 bit signature prior to the ANDROID! magic found in the boot.img. This may vary with other devices so keep that in mind. To remove the 256 bit junk so the boot.img is read properly you can use a hex editor and delete it or you can use DD. The following dd command I will be using is based on K2_CL in regards to the partition for our boot.img. Please make necessary adjustments to this command by insuring you know the location and where abouts of your own boot.img; Example:
Code:
dd bs=256 skip=1 if=/dev/block/mmcblk0p20 of=/data/local/tmp/boot.img
-- Alright, so we have the unmkbootimg, mkbootfs and mkbootimg located in /system/bin. We have pulled our boot.img and removed the junk before the magic android value: ANDROID!. Let's continue.
-- Go back to your android terminal emulator and change directories to /data/local/tmp. Here is an example:
Code:
[email protected]:/ # [COLOR="red"]cd /data/local/tmp[/COLOR]
cd /data/local/tmp
[email protected]:/data/local/tmp #
-- Now run unmkbootimg. Here is an example:
Code:
[email protected]:/data/local/tmp # [COLOR="red"]unmkbootimg -i boot.img[/COLOR]
unmkbootimg -i boot.img
kernel written to 'kernel' (5690888 bytes)
ramdisk written to 'ramdisk.cpio.gz' (521735 bytes)
To rebuild this boot image, you can use the command:
mkbootimg --base 0 --pagesize 2048 --kernel_offset 0x80408000 --ramdisk_offset 0x81808000 --second_offset 0x81300000 --tags_offset 0x80400100 --cmdline 'console=ttyHSL0,115200,n8 user_debug=31' --kernel kernel --ramdisk ramdisk.cpio.gz -o boot.img
[email protected]:/data/local/tmp #
-- Before you go any futher, copy all text within your android terminal emulator and paste it in to a text document. I personally use 920 Text Editor from the play store. You will do this so when the time comes you can open it back up and copy/paste the command to rebuild your boot.img as listed (This will save you some time).
-- Congratulations, you have done well so far. By typing and entering the command 'ls', you can see what all is in your directory. Here is an example:
Code:
[email protected]:/data/local/tmp # [COLOR="red"]ls[/COLOR]
ls
boot.img
init.rc
kernel
ramdisk.cpio.gz
[email protected]:/data/local/tmp #
-- Now lets create a folder and lets call it ramdisk. Here is an example:
Code:
[email protected]:/data/local/tmp # [COLOR="red"]mkdir ramdisk[/COLOR]
mkdir ramdisk
[email protected]:/data/local/tmp #
-- Now lets change directories to that ramdisk folder. Here is an example:
Code:
[email protected]:/data/local/tmp # [COLOR="red"]cd ramdisk[/COLOR]
cd ramdisk
[email protected]:/data/local/tmp/ramdisk #
-- Go ahead and extract ramdisk.cpio.gz. Here is an example:
Code:
[email protected]:/data/local/tmp/ramdisk # [COLOR="red"]gunzip -c ../ramdisk.cpio.gz | cpio -i[/COLOR]
isk.cpio.gz | cpio -i <
1851 blocks
[email protected]:/data/local/tmp/ramdisk #
-- Congratulations, you have done well so far. By typing and entering the command 'ls', you can see what all is in your directory. Here is an example:
Code:
[email protected]:/data/local/tmp/ramdisk # [COLOR="red"]ls[/COLOR]
ls
cwkeys
data
default.prop
dev
fstab.k2_cl
init
init.goldfish.rc
init.qcom.rc
init.qcom.sh
init.rc
init.target.rc
init.target.recovery.rc
init.trace.rc
init.usb.rc
proc
sbin
sys
system
ueventd.goldfish.rc
ueventd.rc
ueventd.target.rc
[email protected]:/data/local/tmp/ramdisk #
-- Now feel free at this point to make your edits within the ramdisk folder. When complete then come back and we shall finish the job.
-- Go ahead and move back out of the ramdisk folder by the following command:
Code:
[email protected]:/data/local/tmp/ramdisk # [COLOR="Red"]cd ..[/COLOR]
cd ..
[email protected]:/data/local/tmp #
-- You should now be in /data/local/tmp/.
-- Lets go ahead and repack the contents found in the ramdisk folder. Here, we will make use of the mkbootfs binary. Please take note that your original is named 'ramdisk.cpio.gz'. Here we will be repacking and renaming it to 'myramdisk.gz'. Here is an example:
Code:
[email protected]:/data/local/tmp # [COLOR="red"]mkbootfs ./ramdisk | gzip > myramdisk.gz[/COLOR]
mkbootfs ./ramdisk | gzip > myramdisk.gz
[email protected]:/data/local/tmp #
-- Open up your saved text file as instructed earlier and scroll to where you see this:
Code:
To rebuild this boot image, you can use the command:
mkbootimg --base 0 --pagesize 2048 --kernel_offset 0x80408000 --ramdisk_offset
0x81808000 --second_offset 0x81300000 --tags_offset 0x80400100 --cmdline 'conso
le=ttyHSL0,115200,n8 user_debug=31' --kernel kernel --ramdisk ramdisk.cpio.gz -o
boot.img
-- Look for --ramdisk ramdisk.cpio.gz and INSURE you change it to --ramdisk myramdisk.gz. Also go ahead and change boot.img to modboot.img. Now copy the mkbootimg command and paste it in to your android terminal emulator. Press enter.
-- There are multiple ways you can apply the new boot.img. The smartest way would be to use fastboot so that you may boot the image vice flashing it in case you screwed something up on your own accord. However, I personally will write the boot.img straight to the boot partition using dd, then I reboot the device. If you wish to do the same then that is fine.
-- Now you have your new Modded Boot Image. Enjoy, and as always... CLICK THANKS if this was helpful to you and....
--- Happy Hunting!!!
MKBOOTIMG-TOOLS
GITHUB SOURCE:
https://github.com/ModdingMyMind/mkbootimg_tools
Original Author: xiaolu (GITHUB SOURCE: https://github.com/xiaolu/mkbootimg_tools)
Heavily Modified By: @Modding.MyMind
This project is originally based from xiaolu. To make this compatible for ARM I modified the script, compiled some binaries such as file, bash, grep, gzip, lzma, xz, mkbootimg, etc.
-- This project uses busybox but due to how stripped and limited busybox is ultimately led to me having to compile a few binaries from source. These binaries must be part of the project in order for the project to be succesfull. For example, busybox grep will not always give accurate offsets for the android header. One of MANY bugs found with busybox.
This project supports device tree binaries found inside the Boot.img and Recovery.img.
This project supports multiple Ramdisk compressions.
-- This project will check the ramdisk compression and if it determines that the tool does not support that particular compression then it will display a hazard warning letting the user know that the compression is not supported and that the ramdisk currently cannot be decompressed or compressed until support has been officially added.
-- If the compression is supported it will display what type of compression the Ramdisk is and how many blocks it has when unpacked.
This project will determine your kernel size, ramdisk size, and TRUE OFFSETS (not just the standard mkbootimg.c offsets).
-- With respect to the offsets; You will learn that many available tools found available specifically handle images where the ANDROID! header is located at 0x0. Not all images are built like this from stock. This project will find the header, base, kernel offset, ramdisk offset, second offset, and tags offset. It will rebuild the image using DD to insure the android header is located at 0x0. The found offsets inside the image will be cross referenced to see if the OEM of that image built it using the standard mkbootimg.c. If it detects any offsets which are built using NON-standard offsets then it will display a warning as well as show you what the image TRUE offsets actually are. Those same offsets are then applied to properly rebuild your image to insure that it boots like it was intended to do.
-- The warning will let you know that you may modify mkbootimg.c with the NON-standard values if you wish to have a binary specific to your device. The offsets displayed are not the address. Because the offsets are determined and not the address this makes it possible for this project to not have to rebuild mkbootimg.c. When the project is used to rebuild your image using the mkbootimg args such as --ramdisk_offset, --kernel_offsets, etc, etc, this then tells mkbootimg.c to ignore the hardcoded offsets and only use the ones it has been instructed to use. This is even more successful by insuring the BASE is accurate and applying the base as one of the mkbootimg args (--base 0 <-- this is lazy and stupid).
The mkboot script requires two args whether unpacking the image or repacking the image.
-- mkboot boot.img bootfolder (This will unpack the image)
1. mkboot is the script.
2. boot.img is the actual image.
3. bootfolder will be created and become the project folder.
-- mkboot bootfolder newboot.img (This will repack the image)
1. mkboot is the script.
2. bootfolder is the project folder which has the needed files and information to repack.
3. This will be the name of the finished build.
UNPACK STANDARD IMAGE
This image uses standard mkbootimg.c:
[email protected]:/data/local/tmp/mkbootimg_tools-master # ./mkboot boot.img work
Unpack & decompress boot.img to work
kernel : zImage
ramdisk : ramdisk
page size : 2048
kernel size : 2529072
ramdisk size : 230255
base : 0x12200000
kernel offset : 0x00008000
ramdisk offset : 0x01000000
second_offset : 0x00f00000
tags offset : 0x00000100
cmd line : mem=471M console=ttyMSM2,115200n8 androidboot.hardware=thunderc lge.rev=10
Ramdisk is lzma format.
1436 blocks
Unpack completed.
[email protected]:/data/local/tmp/mkbootimg_tools-master #
Click to expand...
Click to collapse
REPACK STANDARD IMAGE
Image repacked with standard mkbootimg.c:
[email protected]:/data/local/tmp/mkbootimg_tools-master # ./mkboot work boot.img
mkbootimg from work/img_info.
kernel : zImage
ramdisk : new_ramdisk.lzma
page size : 2048
kernel size : 2529072
ramdisk size : 230029
base : 0x12200000
kernel offset : 0x00008000
ramdisk offset : 0x01000000
tags offset : 0x00000100
cmd line : mem=471M console=ttyMSM2,115200n8 androidboot.hardware=thunderc lge.rev=10
Kernel size: 2529072, new ramdisk size: 230029, boot.img: 2762752.
boot.img has been created.
[email protected]:/data/local/tmp/mkbootimg_tools-master #
Click to expand...
Click to collapse
UNPACK NON-STANDARD IMAGE
This image uses non-standard mkbootimg.c:
[email protected]:/data/local/tmp/mkbootimg_tools-master # ./mkboot recovery.img work
Unpack & decompress recovery.img to work
****** WARNING ******* WARNING ******* WARNING ******
This image is built using NON-standard mkbootimg!
RAMDISK_OFFSET is 0x01608000
You can modify mkbootimg.c with the above value(s)
****** WARNING ******* WARNING ******* WARNING ******
kernel : zImage
ramdisk : ramdisk
page size : 2048
kernel size : 5834192
ramdisk size : 4351685
base : 0x80600000
kernel offset : 0x00008000
ramdisk offset : 0x01608000
second_offset : 0x00f00000
tags offset : 0x00000100
cmd line : console=ttyHSL0,115200,n8 user_debug=31
Ramdisk is gzip format.
14837 blocks
Unpack completed.
[email protected]:/data/local/tmp/mkbootimg_tools-master #
Click to expand...
Click to collapse
REPACK NON-STANDARD IMAGE
Image repacked with non-standard mkbootimg.c:
[email protected]:/data/local/tmp/mkbootimg_tools-master # ./mkboot work recovery.img
mkbootimg from work/img_info.
kernel : zImage
ramdisk : new_ramdisk.gzip
page size : 2048
kernel size : 5834192
ramdisk size : 4358038
base : 0x80600000
kernel offset : 0x00008000
ramdisk offset : 0x01608000
tags offset : 0x00000100
cmd line : console=ttyHSL0,115200,n8 user_debug=31
Kernel size: 5834192, new ramdisk size: 4358038, recovery.img: 10194944.
recovery.img has been created.
[email protected]:/data/local/tmp/mkbootimg_tools-master #
Click to expand...
Click to collapse
UNPACK IMAGE WITH INCOMPATIBLE RAMDISK
[email protected]:/data/local/tmp/mkbootimg_tools-master # ./mkboot boot-1.img work
Unpack & decompress boot-1.img to work
kernel : zImage
ramdisk : ramdisk
page size : 2048
kernel size : 3580032
ramdisk size : 594701
base : 0x10000000
kernel offset : 0x00008000
ramdisk offset : 0x01000000
second_offset : 0x00f00000
tags offset : 0x00000100
cmd line :
****** HAZARD ******* HAZARD ******* HAZARD ******
Ramdisk is data format. Can't unpack ramdisk.
This tool currently does not support data.
****** HAZARD ******* HAZARD ******* HAZARD ******
[email protected]:/data/local/tmp/mkbootimg_tools-master #
Click to expand...
Click to collapse
REPACK IMAGE WITH INCOMPATIBLE RAMDISK
[email protected]:/data/local/tmp/mkbootimg_tools-master # ./mkboot work boot-1.img
mkbootimg from work/img_info.
****** HAZARD ******* HAZARD ******* HAZARD ******
Ramdisk is data format. Can't repack ramdisk.
This tool currently does not support data.
****** HAZARD ******* HAZARD ******* HAZARD ******
[email protected]:/data/local/tmp/mkbootimg_tools-master #
Click to expand...
Click to collapse
mkbootimg updated in .zip file. Enjoy
I went through some mess to get it to work correctly lol.
Works like a champ now.
Sent from my K2_CL using Tapatalk
Modding.MyMind said:
mkbootimg updated in .zip file. Enjoy
I went through some mess to get it to work correctly lol.
Works like a champ now.
Sent from my K2_CL using Tapatalk
Click to expand...
Click to collapse
Did you compiled mkbootimg?
Please can you say me in detail the not-booting problem? It rebooted continuously between bootloader and bootanimation?
xpirt
xpirt said:
Did you compiled mkbootimg?
Please can you say me in detail the not-booting problem? It rebooted continuously between bootloader and bootanimation?
xpirt
Click to expand...
Click to collapse
Yea, I compiled it. The last one I compiled wasnt done correctly. The sha and rsa was corrupted. But I fixed it.
Sent from my K2_CL using Tapatalk
Modding.MyMind said:
Yea, I compiled it. The last one I compiled wasnt done correctly. The sha and rsa was corrupted. But I fixed it.
Sent from my K2_CL using Tapatalk
Click to expand...
Click to collapse
I understand. And the bootloop I said is exactly what happened when packed with old mkbootimg?
xpirt
@xpirt
No bootloop. It would boot once and show the splash screen. Then reboot straight in to the custom recovery. Basically what happen in the old mkbootimg was the source code having too many white spaces and some other syntax issues. I had to go through every single command line in every single file to fix it. Spent almost 15+ hours reworking the codes. Then I compiled it, placed it on my device in /data/local/tmp. Pulled my boot img from my partition using dd over to /data/local/tmp. Ran the steps to unpacking, editing, and then used the new mkbootimg to repack it. After completion I wrote the new boot.img over to the partition using dd. Then rebooted, worked flawlessly without any bugs, errors, or hiccups.
Sent from my K2_CL using Tapatalk
Modding.MyMind said:
@xpirt
No bootloop. It would boot once and show the splash screen. Then reboot straight in to the custom recovery. Basically what happen in the old mkbootimg was the source code having too many white spaces and some other syntax issues. I had to go through every single command line in every single file to fix it. Spent almost 15+ hours reworking the codes. Then I compiled it, placed it on my device in /data/local/tmp. Pulled my boot img from my partition using dd over to /data/local/tmp. Ran the steps to unpacking, editing, and then used the new mkbootimg to repack it. After completion I wrote the new boot.img over to the partition using dd. Then rebooted, worked flawlessly without any bugs, errors, or hiccups.
Sent from my K2_CL using Tapatalk
Click to expand...
Click to collapse
Ok. Good, I'll try it out
xpirt
xpirt said:
Ok. Good, I'll try it out
xpirt
Click to expand...
Click to collapse
Sounds good. If it is a stock boot.img then you will need to remove everything before the android magic value (ANDROID!). After that, have at it lol. I will be adding additional code later on that will automatically look for the android magic value and make the necessary changes to it so it reads properly. This will keep others from having to do it themselves. Until then, has to be done by the user since I have hard-coded the magic android value.
Sent from my K2_CL using Tapatalk
Also plan to edit the unpackbootimg file so it will automatically extract the ramdisk archive automatically with out the need of the user having to use the ramdisk.sh file or by manually inputing the commands to do so. Got other plans as well. So a lot of improvements and bonuses are to come. Gonna try and make this thing a beast for arm devices.
Sent from my K2_CL using Tapatalk
OP updated with more in depth instructions/examples. Also, I have taken out the ramdisk.sh file and have also removed the unpackbootimg file. I have implemented unmkbootimg and a remake of the mkbootimg file(s). Works like a boss and gives you all the information you need to rebuild your boot.img. Will work on ALL arm devices. Enjoy.
Added download link to open source. See OP.
Sent from my K2_CL using Tapatalk
OP has been updated. I have included an additional binary called mkbootfs to work in conjuction with the other two given the necessary structural building properties of the boot.img. I have tested this on A LOT of boot.img's and all have been successful. I have also updated the instructions for using these binaries on your android device. Enjoy.
sweet sweet victory!
russellvone said:
sweet sweet victory!
Click to expand...
Click to collapse
This project was a pain bro. I almost gave up on it. Was dancing on thin ice until I had a break through which pushed me to complete the task. Works beautifully now .
Sent from my K2_CL using Tapatalk
Modding.MyMind said:
This project was a pain bro. I almost gave up on it. Was dancing on thin ice until I had a break through which pushed me to complete the task. Works beautifully now .
Sent from my K2_CL using Tapatalk
Click to expand...
Click to collapse
This is awesome.
Can you share the source code for this?
Sent from my GT-I8730 using Tapatalk
PM Sent
Sent from my K2_CL using Tapatalk
Modding.MyMind said:
PM Sent
Sent from my K2_CL using Tapatalk
Click to expand...
Click to collapse
Thank you!
Sent from my GT-I8730 using Tapatalk
OP updated with four photo attachments.
Sent from my K2_CL using Tapatalk
(Probably n00bish) Question:
How do I compile the binaries from the source? By gcc or make?
Beamed from my Galaxy Express using Tapatalk
Hi - I tried doing a backup of my SM-S908E EFS / IMEI partition today using the following command:
dd if=/dev/block/mmcblk0p3 of=/storage/sdcard/efs.img bs=4096
It failed, giving me a dd: /dev/block/mmcblk0p3: No such file or directory error.
Can I backup my EFS / IMEI partition on my SM-S908E using the command terminal?
you should find your efs location first by enter command below
ls -la /dev/block/by-name
Click to expand...
Click to collapse
Remarks rooted require
Thanks, @cyclonemon - I found this entry in the cornucopia of blocks listed:
lrwxrwxrwx 1 root root 15 1970-04-03 17:56 efs -> /dev/block/sda6
Would I use the same 'dd' command I posted above, and just replace the mmcblk0p3 with sda6 (keeping the same block size value of 4096)?
¿GotJazz? said:
Thanks, @cyclonemon - I found this entry in the cornucopia of blocks listed:
lrwxrwxrwx 1 root root 15 1970-04-03 17:56 efs -> /dev/block/sda6
Would I use the same 'dd' command I posted above, and just replace the mmcblk0p3 with sda6 (keeping the same block size value of 4096)?
Click to expand...
Click to collapse
¿GotJazz? said:
Thanks, @cyclonemon - I found this entry in the cornucopia of blocks listed:
lrwxrwxrwx 1 root root 15 1970-04-03 17:56 efs -> /dev/block/sda6
Would I use the same 'dd' command I posted above, and just replace the mmcblk0p3 with sda6 (keeping the same block size value of 4096)?
Click to expand...
Click to collapse
Yes, but location of storage should change as below
dd if=/dev/block/sda6 of=/sdcard/efs.img bs=4096
Thanks!
cyclonemon said:
you should find your efs location first by enter command below
Remarks rooted require
Click to expand...
Click to collapse
Code:
ls -la /dev/block/by-name | grep efs
Gives a simpler answer