Related
[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...
FOR ALL K2 VARIANTS (K2_CL, K2_UL, K2_U, K2_PLC_CL)
Advantages
- No more hassle with htcdev, tokens, or unlock codes
- No more submitting your phones personal info to htc
- The ability to get back to 100% stock without any visual traces or records of having been S-Off or unlocking your bootloader.
PLEASE PAY CLOSE ATTENTION TO THIS TUTORIAL AS I WILL SHOW YOU HOW TO CHANGE THE FLAG FOR LOCK, RELOCK, UNLOCK, AND TAMPERED!!
I INSIST THAT YOU READ ALL OF THIS BEFORE YOU TAKE FURTHER ACTION - IF YOU FAIL TO FOLLOW INSTRUCTIONS THE ONLY ONE TO BLAME IS YOURSELF. AFTER YOU HAVE READ THIS TUTORIAL AND COME TO UNDERSTAND THIS PROCEDURE THEN BY ALL MEANS GO AHEAD AND CARRY OUT THE NECESSARY STEPS TO ACCOMPLISH WHATEVER GOALS YOU MAY CURRENTLY HAVE AT THIS TIME.
- This tutorial may be easier on the eyes if viewed by the actual web browser vice an app or phone device.
Many thanks to @old.splatterhand for being generous and providing me some files which allowed me to confirm this tutorial for all K2 variants.
Confirmed Working - Credits
Myself - K2_CL
@russellvone - K2_CL
Lordvincent 90 - K2_CL
@DrBassman - K2_CL
REQUIREMENTS FOR THIS TUTORIAL FOR THE PURPOSE OF LEARNING AND APPLYING IT
- This tutorial will be based on an already UNLOCKED Bootloader with TAMPERED flag
- Must be S-OFF
- Must be rooted
- Proper ADB and Fastboot files
- Hex editor (HxD)
- Knowledge of Hex and DD (aka - Data Destroyer)
If you do not know what DD is then please read the following which I extracted from WIKI for the simplicity of this tutorial - Otherwise, skip this and move along.
dd is a command on Unix and Unix-like operating systems whose primary purpose is to convert and copy a file.
On Unix, device drivers for hardware (such as hard disks) and special device files (such as /dev/zero and /dev/random) appear in the file system just like normal files; dd can also read and/or write from/to these files, provided that function is implemented in their respective driver. As a result, dd can be used for tasks such as backing up the boot sector of a hard drive, and obtaining fixed amount of random data. The dd program can also perform conversions on the data as it is copied, including byte order swapping and conversion to and from the ASCII and EBCDIC text encodings.
The name dd may be an allusion to the DD statement found in IBM's Job Control Language (JCL), where the initialism stands for "Data Description." The command's syntax resembles the JCL statement more than it does other Unix commands, so the syntax may have been a joke. Another explanation for the command's name is that "cc" (for "convert and copy", as in the command's description) was already taken by the C compiler.
The dd command is specified by IEEE Std 1003.1-2008, which is part of the Single UNIX Specification.
The command line syntax of dd differs from many other Unix programs, in that it uses the syntax option=value for its command line options, rather than the more-standard --option value or -option=value formats. By default, dd reads from STDIN and writes to STDOUT, but these can be changed by using the if (input file) and of (output file) options.
Usage varies across different operating systems. Also, certain features of dd will depend on the computer system capabilities, such as dd's ability to implement an option for direct memory access. Sending a SIGINFO signal (or a USR1 signal on Linux) to a running dd process makes it print I/O statistics to standard error once and then continue copying (note that signals may terminate the process on OS*X). dd can read standard input from the keyboard. When end-of-file (EOF) is reached, dd will exit. Signals and EOF are determined by the software. For example, Unix tools ported to Windows vary as to the EOF: Cygwin uses (the usual Unix EOF) and MKS Toolkit uses (the usual Windows EOF).
In spirit with the Unix philosophy, dd does one thing (and may be considered to do it "well" ). Unlike a sophisticated and highly abstracted utility, dd has no algorithm other than in the low-level decisions of the user concerning how to vary the run options. Often, the options are changed for each run of dd in a multi-step process to solve a computer problem.
The GNU variant of dd as supplied with coreutils on Linux does not describe the format of the messages displayed on standard output on completion. However, these are described by other implementations, e.g. that with BSD.
Each of the "Records in" and "Records out" lines shows the number of complete blocks transferred + the number of partial blocks, e.g. because the physical medium ended before a complete block was read, or a physical error prevented reading the complete block.
A block is a unit measuring the number of bytes that are read, written, or converted at one time. Command line options can specify a different block size for input/reading (ibs) compared to output/writing (obs), though the block size (bs) option will override both ibs and obs. The default value for both input and output block sizes is 512 bytes (the traditional block size of disks, and POSIX-mandated size of "a block"). The count option for copying is measured in blocks, as are both the skip count for reading and seek count for writing. Conversion operations are also affected by the "conversion block size" (cbs).
For some uses of the dd command, block size may have an effect on performance. For example, when recovering data from a hard disk, a small block size will generally cause the most bytes to be recovered. Issuing many small reads is an overhead and may be non-beneficial to execution performance. For greater speed during copy operations, a larger block size may be used. However, because the amount of bytes to copy is given by bs×count, it is impossible to copy a prime number of bytes in one go without going with one of two bad choices, bs=N count=1 (memory use) or bs=1 count=N (read request overhead). Alternative programs (see below) permit specifying bytes rather than blocks.
Click to expand...
Click to collapse
Let's get started shall we - the following commands highlighted in RED are your commands to execute:
- Go ahead and plug your device in to your PC with a USB cable.
- Open up CMD and change its directory to the location of your proper ADB and Fastboot files
- Establish a proper connection with your device. It should look something like this:
Code:
C:\Users\*******\Desktop\Android_tweak_software\HTC_fastboot_files>[COLOR="Red"][B]adb devices[/B][/COLOR]
List of devices attached
HT3********* device
C:\Users\*******\Desktop\Android_tweak_software\HTC_fastboot_files>
- If connection is established then direct to your devices' adb shell:
Code:
C:\Users\*******\Desktop\Android_tweak_software\HTC_fastboot_files>[COLOR="Red"][B]adb shell[/B][/COLOR]
[email protected]:/ #
- Go ahead and gain superuser rights to your devices' adb shell:
Code:
C:\Users\*******\Desktop\Android_tweak_software\HTC_fastboot_files>adb shell
[email protected]:/ # [COLOR="Red"][B]su[/B][/COLOR]
su
[email protected]:/ #
- Now we need to copy a partition (mmcblk0p7) to your sdcard using DD. Insure you do not make a typo:
Code:
C:\Users\*******\Desktop\Android_tweak_software\HTC_fastboot_files>adb shell
[email protected]:/ # su
su
[email protected]:/ # [COLOR="Red"][B]dd if=/dev/block/mmcblk0p7 of=/sdcard/mmcblk0p7.img[/B][/COLOR]
dd if=/dev/block/mmcblk0p7 of=/sdcard/mmcblk0p7.img
31155+0 records in
31155+0 records out
15951360 bytes transferred in 2.259 secs (7061248 bytes/sec)
[email protected]:/ #
- Now we need to pull this image (mmcblk0p7) to our pc:
Code:
C:\Users\*******\Desktop\Android_tweak_software\HTC_fastboot_files>adb shell
[email protected]:/ # su
su
[email protected]:/ # dd if=/dev/block/mmcblk0p7 of=/sdcard/mmcblk0p7.img
dd if=/dev/block/mmcblk0p7 of=/sdcard/mmcblk0p7.img
31155+0 records in
31155+0 records out
15951360 bytes transferred in 2.259 secs (7061248 bytes/sec)
[email protected]:/ # [COLOR="Red"][B]exit[/B][/COLOR]
exit
[email protected]:/ # [COLOR="Red"][B]exit[/B][/COLOR]
exit
C:\Users\*******\Desktop\Android_tweak_software\HTC_fastboot_files>[COLOR="Red"][B]adb pull /sdc
ard/mmcblk0p7.img[/B][/COLOR]
2523 KB/s (15951360 bytes in 6.172s)
C:\Users\*******\Desktop\Android_tweak_software\HTC_fastboot_files>
- Go ahead and repeat these steps for (mmcblk0p3).
- At this time go ahead and open up your hex editor (HxD) and at the top right change from hex in the drop down bar to dec - you will do this (if necessary) for all images pertaining to this tutorial.
- Drag\drop (mmcblk0p3.img) in to the hex editor (HxD).
- Now hit ctrl+F or go to the Search tab, then click on Find.
- Search for HTCU. You will see the following:
Code:
Offset(d) 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15
000033728 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000033744 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000033760 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000033776 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[COLOR="Red"][B]000033792[/B] 00 00 00 00 [B]48 54 43 55[/B] 01 00 00 00 00 00 00 00 ....[B]HTCU[/B]........[/COLOR]
000033808 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000033824 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000033840 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000033856 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
- Drag\drop (mmcblk0p7.img) in to the hex editor (HxD).
- Now hit ctrl+G or go to the Search tab, then click on Goto....
- Search for DEC OFFSET 4265984.
- You will see something like this:
Code:
Offset(d) 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15
04265920 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
04265936 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
04265952 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
04265968 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[COLOR="Red"][B]04265984[/B] [B]68 25 32 C6 02[/B] 00 00 00 00 00 00 00 00 00 00 00 [B]h%2Æ.[/B]...........[/COLOR]
04266000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
04266016 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
04266032 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
04266048 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
- Now that we have what we needed loaded and prepped we want to see what needs adjustment regarding lock, unlock, relock, and tampered.
- These two partitions are already stamped with the bootloader being unlocked as well as being tampered so finding what we are looking for makes it easy as seen above.
- mmcblk0p3 is the partition which determines if our device is locked, unlocked, or relocked.
- mmcblk0p7 is the partition which determines if our device is tampered with or not.
- Let's look at mmcblk0p3. We see in red, HTCU, which we already know means Unlocked, because as I mentioned in the beginning, this tutorial is based on an already unlocked bootloader and tampered device.
Code:
[COLOR="Red"][B]000033792[/B] 00 00 00 00 [B]48 54 43 55[/B] 01 00 00 00 00 00 00 00 ....[B]HTCU[/B]........[/COLOR]
- We want to lock or relock our device. To relock is, "HTCL". To Lock is, "00 00 00 00".
- Our goal is creating a dd command which will implement these changes for us to our partition already on our device.
- To lock:
Code:
echo -ne '\x00\x00\x00\x00' | dd of=/dev/block/mmcblk0p3 bs=1 seek=33796
- To relock:
Code:
echo -ne "HTCL" | dd of=/dev/block/mmcblk0p3 bs=1 seek=33796
- To unlock:
Code:
echo -ne "HTCU" | dd of=/dev/block/mmcblk0p3 bs=1 seek=33796
- The command for seek is what determines the decimal search of that partition when implementing the echo command from start to finish, from left to right as it writes it out. This is why earlier I told you to change it from hex to dec in your hex editor. If you look at seek=33796 and go back to your hex editor you will notice the dec offset says 33792 then underneath that it says 33808.
Code:
Offset(d) 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15
000033792 00 00 00 00 48 54 43 55 01 00 00 00 00 00 00 00 ....HTCU........
000033808 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
- To determine the exact decimal location where the dd command will start writing to you must first look at the top of your hex editor where it shows '00 01 02 03 04 05, etc'. You will take the offset for 33792 and look at where HTCU begins then scroll to the top which in this case it aligns to '04', so we add 04 to the offset of 33792 which gives us a total of 33796. This becomes our seek (our starting point).
- Now that we have established this concept with mmcblk0p3.img, lets go and take a look at mmcblk0p7.img.
- We already know our device has been tampered with. If you search for tamper or tampered you will find results and these results eventually bring you to where we already are as mentioned above and if following along then what you are currently looking at on your pc.
- This one is really simple. Either your device is tampered or it is not. In this case we notice '02' which signifies the setup for being tampered.
Code:
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00411800 68 25 32 C6 02 00 00 00 00 00 00 00 00 00 00 00 h%2Æ............
- Let's go ahead and change it to '00' with the following dd command:
Code:
echo -ne '\x00' | dd of=/dev/block/mmcblk0p7 bs=1 seek=4265988
- To restore back to tampered you will just replace 00 with 02.
(FOR K2_PLC_CL USERS, REPLACE 00 WITH 04, INSTEAD OF 02 - Credit goes to @DOrtego for notifying me of this)
- Now to show you how to execute these commands. I will only use one command for this example since it will be the same for all of them. The following in RED will be your commands to execute. A lot of these will be due to insuring you are set up prior to executing the dd command itself, so if you are already good to go then just seek for the dd command and follow along:
Code:
C:\Users\*******\Desktop\Android_tweak_software\HTC_fastboot_files>[COLOR="Red"][B]adb devices[/B][/COLOR]
List of devices attached
HT********** device
C:\Users\*******\Desktop\Android_tweak_software\HTC_fastboot_files>[COLOR="Red"][B]adb shell[/B][/COLOR]
[email protected]:/ # [COLOR="Red"][B]su[/B][/COLOR]
su
[email protected]:/ # [COLOR="Red"][B]echo -ne '\x00' | dd of=/dev/block/mmcblk0p7 bs=1 seek=4265988[/B][/COLOR]
ock/mmcblk0p7 bs=1 seek=4265988 <
1+0 records in
1+0 records out
1 bytes transferred in 0.012 secs (83 bytes/sec)
[email protected]:/ # [COLOR="Red"][B]exit[/B][/COLOR]
exit
[email protected]:/ # [COLOR="Red"][B]exit[/B][/COLOR]
exit
C:\Users\*******\Desktop\Android_tweak_software\HTC_fastboot_files>
I will also show you how to go back to S-ON, but you BETTER make sure you have your stock HBoot.img flashed, Stock Boot.img flashed, etc OR YOU WILL BRICK YOUR DEVICE INDEFINITELY!!!
YOU MUST FIRST BE IN FASTBOOT - THERE WILL BE NO USING ADB NOR A TERMINAL EMULATOR FOR THIS STEP
To go from radio S-OFF to radio S-ON enter the following :
Code:
[B]fastboot oem writesecureflag 3[/B]
To go from HBoot S-Off to HBoot S-On just flash a stock HBoot to remove the modified version.
Code:
[B]adb reboot bootloader[/B]
// booting in to bootloader
[B]fastboot devices[/B]
// establishing connection between device and PC
[B]fastboot oem rebootRUU[/B]
// booting in to RUU
[B]fastboot flash zip filename.zip[/B]
// .zip with stock HBoot image
[B]fastboot reboot-bootloader[/B]
// confirm mod S-Off HBoot now reads new S-On from stock HBoot
[B]fastboot reboot[/B]
// boot OS
So, there you have it everyone! Enjoy, and profit!
--- Happy Hunting!
Other users, what I did to confirm this was by pulling mmcblk0p3 and mmcblk0p7 for both versions and compared the results with a hex editor to determine these steps are valid for the K2_CL variant. Enjoy.
EDIT: Confirmed for ALL K2 variants
Sent from my C525c using XDA Premium 4 mobile app
And yes, I used my device as a guinea pig so of course it works
Sent from my C525c using XDA Premium 4 mobile app
Modding.MyMind said:
And yes, I used my device as a guinea pig so of course it works
Sent from my C525c using XDA Premium 4 mobile app
Click to expand...
Click to collapse
What if we wish to put *tampered* back?
Lol
Hmmm, I would have to look at that as I did not consider that as an option. However, having 'tampered' being displayed leaves traces so why would you want to lol.
Sent from my C525c using XDA Premium 4 mobile app
Complete joke, very well done sir.
Awesome find!
Yea, I knew it was ha! And thanks. Would like to see if this works for the other variants as well but I do not have what I need from them so either they will need to figure it out or become very brave with trying my steps lol.
Sent from my C525c using XDA Premium 4 mobile app
+sorry for the off topic+
but I decided to do a complete factory restore of my phone and accept an ota update to see if I could get to that clockworkmod like screen in stock recovery.
and it let me
first attempt it just installed the update without letting me into the clockworkmod like..........
so I simply deleted a system app accepted the next update, allowed to boot into recovery,
then once it got to the hated /!\ Red triangle, I just held volume+ then pressed power and it let me see the reason for the fail.
thought you would like to play with it
Awesome! Thanks.
Sent from my C525c using XDA Premium 4 mobile app
Maybe @old.splatterhand could look in to this with the K2_U and K2_UL variants .
And possibly add this finding to his index *cough**cough* haha
Sent from my C525c using XDA Premium 4 mobile app
Modding.MyMind said:
Awesome! Thanks.
Sent from my C525c using XDA Premium 4 mobile app
Click to expand...
Click to collapse
alrighty, just got into it again, used an app called quick boot and booted into recovery, again it would not let me in to CWM-like until it showed red triangle then had to hold volume+ then power, tried to apply a different zip (crossbreeder)
aborted,
I'm gonna do some playing myself!
I have added it to my Index, but i have to add much more, when its time.
@Modding.MyMind
confirmed working......
thanks again sir, very proud of your hard work!
Yea, will be uploading pictures soon enough so people can see it on my phone. Unfortunately, I won't be able to get a pic where it shows *tampered* because I already removed it lol (but hey, if it isn't there that is evidence in itself). But I can atleast provide pics where it shows locked (not relocked) and unlocked with S-Off.
I got other projects I am looking into as well. Hopefully, they too will be just as satisfying as this.
Sent from my C525c using XDA Premium 4 mobile app
Modding.MyMind said:
I got other projects I am looking into as well. Hopefully, they too will be just as satisfying as this.
Sent from my C525c using XDA Premium 4 mobile app
Click to expand...
Click to collapse
Just helped a fellow with the handle
Lordvincent 90
over on AndroidForums
sent him this way so he could use your find so he could his phone in for hardware repair.......
with out any traces of s-off!!!!
#already_awesome
oh yeah.... I'm on edge waiting for more!
very impressed with what you've brought so early in the game.
I'm rooting for ya \ /*_*\ /
russellvone said:
Just helped a fellow with the handle
Lordvincent 90
over on AndroidForums
sent him this way so he could use your find so he could his phone in for hardware repair.......
with out any traces of s-off!!!!
#already_awesome
oh yeah.... I'm on edge waiting for more!
very impressed with what you've brought so early in the game.
I'm rooting for ya \ /*_*\ /
Click to expand...
Click to collapse
I have added him to the OP under credits
Glad this served him well and soon others when it calls for it
Sent from my C525c using XDA Premium 4 mobile app
Reserved....
Sent from my C525c using XDA Premium 4 mobile app
russellvone said:
very impressed with what you've brought so early in the game.
Click to expand...
Click to collapse
Newbie on XDA forums, but as for androids... Especially K2_CL... Pretty much got the experience needed to get by and to grow. I focus most on mods, hence my name. Something about modding gets me pumped haha.
That's my Bio and I'm sticking to it.
Sent from my C525c using XDA Premium 4 mobile app
Modding.MyMind said:
Newbie on XDA forums, but as for androids... Especially K2_CL... Pretty much got the experience needed to get by and to grow. I focus most on mods, hence my name. Something about modding gets me pumped haha.
That's my Bio and I'm sticking to it.
Sent from my C525c using XDA Premium 4 mobile app
Click to expand...
Click to collapse
THAT'S WHAT I'M SCREAMING!
:beer: «--one for you
:beer: «--one for me
cheers!
#EDIT#
for some reason my beers look like smiley faces on tapatalk?¿
Pictures uploaded in OP. Take additional note that in both pictures you do not see *tampered* nor do you see *relocked*. Enjoy.
Sent from my C525c using XDA Premium 4 mobile app
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
WARNING: This package is never meant for non-experienced members!
Chinese translation of this guide is on the way. (本教程的中文版仍在编写中)
Code:
#include <std_disclaimer.h>
/*
* Your warranty is now void. *
* I am not responsible for bricked devices, dead SD cards,
* thermonuclear war, or you getting fired because the alarm app failed.
Please do some research if you have any concerns about features included in this ROM before flashing it! YOU are choosing to make these modifications, and if you point the finger at me for messing up your device, I will laugh at you.
*/
We changed the flashing procedure this time, so it will:
- Prevent noobs without any experiences
- Avoid installing many dumb security updates
Target: PDA-311A-0-00WW-B02
Now it's available for public.
Please download and install this to your phone via ADB sideload of 874 command: https://android.googleapis.com/pack.../ace851ea59294177f677018648d6c0614317510e.zip
To Chinese Nokia X5 owners: Please convert your phone to Global Nokia 5.1 Plus before flashing, and don't forget to change SKUID to 600WW.
What's the requirement for flashing?
- Nokia 5.1 Plus X5 with Global Android one firmware installed (any version)
- Rooted phone (either MTK-SU or regular root method are OK)
Or:
- The Bootloader is Unlocked
Here's how (if rooted):
Due to the spelling error of the script, the correct one is attached below.
Please replace it to the one inside package, if you want to use "Click_Me_To_Flash.cmd"..
Click to expand...
Click to collapse
- Download the package and extract it. You'll get 17 img files, and 6 other files.
- Create one directory called "pda-3110" on your phone's internal storage. THIS IS CASE SENSITIVE, so don't use uppercase "PDA".
- Copy all the img files to the pda-3110 directory.
- Execute this under command prompt:
Code:
adb shell
- Check what's your current slot:
Code:
getprop ro.boot.slot_suffix
Take a note whether the slot is "_a" or "_b".
- Grant root permission:
Code:
su
If necessary, grant root permission on the phone. If grant successful, you'll see the dollar ($) symbol will become into hash (#) symbol.
If your phone is rooted with MTK-SU, you must do this:
- Open Magisk Manager and install Magisk on another slot.
After installation complete, stay at installation complete screen and don't reboot.
- Now execute following commands.
If current slot is "_a", then execute these:
Code:
dd if=/storage/emulated/0/pda-3110/boot.img of=/dev/block/bootdevice/by-name/boot_b
dd if=/storage/emulated/0/pda-3110/cam_vpu1.img of=/dev/block/bootdevice/by-name/cam_vpu1_b
dd if=/storage/emulated/0/pda-3110/cam_vpu2.img of=/dev/block/bootdevice/by-name/cam_vpu2_b
dd if=/storage/emulated/0/pda-3110/cam_vpu3.img of=/dev/block/bootdevice/by-name/cam_vpu3_b
dd if=/storage/emulated/0/pda-3110/cda.img of=/dev/block/bootdevice/by-name/cda_b
dd if=/storage/emulated/0/pda-3110/lk.img of=/dev/block/bootdevice/by-name/lk_b
dd if=/storage/emulated/0/pda-3110/logo.img of=/dev/block/bootdevice/by-name/logo_b
dd if=/storage/emulated/0/pda-3110/md1img.img of=/dev/block/bootdevice/by-name/md1img_b
dd if=/storage/emulated/0/pda-3110/odmdtbo.img of=/dev/block/bootdevice/by-name/odmdtbo_b
dd if=/storage/emulated/0/pda-3110/preloader.img of=/dev/block/bootdevice/by-name/preloader_b
dd if=/storage/emulated/0/pda-3110/scp.img of=/dev/block/bootdevice/by-name/scp_b
dd if=/storage/emulated/0/pda-3110/spmfw.img of=/dev/block/bootdevice/by-name/spmfw_b
dd if=/storage/emulated/0/pda-3110/sspm.img of=/dev/block/bootdevice/by-name/sspm_b
dd if=/storage/emulated/0/pda-3110/system.img of=/dev/block/bootdevice/by-name/system_b
dd if=/storage/emulated/0/pda-3110/systeminfo.img of=/dev/block/bootdevice/by-name/systeminfo_b
dd if=/storage/emulated/0/pda-3110/tee.img of=/dev/block/bootdevice/by-name/tee_b
dd if=/storage/emulated/0/pda-3110/vendor.img of=/dev/block/bootdevice/by-name/vendor_b
If current slot is "_b":
Code:
dd if=/storage/emulated/0/pda-3110/boot.img of=/dev/block/bootdevice/by-name/boot_a
dd if=/storage/emulated/0/pda-3110/cam_vpu1.img of=/dev/block/bootdevice/by-name/cam_vpu1_a
dd if=/storage/emulated/0/pda-3110/cam_vpu2.img of=/dev/block/bootdevice/by-name/cam_vpu2_a
dd if=/storage/emulated/0/pda-3110/cam_vpu3.img of=/dev/block/bootdevice/by-name/cam_vpu3_a
dd if=/storage/emulated/0/pda-3110/cda.img of=/dev/block/bootdevice/by-name/cda_a
dd if=/storage/emulated/0/pda-3110/lk.img of=/dev/block/bootdevice/by-name/lk_a
dd if=/storage/emulated/0/pda-3110/logo.img of=/dev/block/bootdevice/by-name/logo_a
dd if=/storage/emulated/0/pda-3110/md1img.img of=/dev/block/bootdevice/by-name/md1img_a
dd if=/storage/emulated/0/pda-3110/odmdtbo.img of=/dev/block/bootdevice/by-name/odmdtbo_a
dd if=/storage/emulated/0/pda-3110/preloader.img of=/dev/block/bootdevice/by-name/preloader_a
dd if=/storage/emulated/0/pda-3110/scp.img of=/dev/block/bootdevice/by-name/scp_a
dd if=/storage/emulated/0/pda-3110/spmfw.img of=/dev/block/bootdevice/by-name/spmfw_a
dd if=/storage/emulated/0/pda-3110/sspm.img of=/dev/block/bootdevice/by-name/sspm_a
dd if=/storage/emulated/0/pda-3110/system.img of=/dev/block/bootdevice/by-name/system_a
dd if=/storage/emulated/0/pda-3110/systeminfo.img of=/dev/block/bootdevice/by-name/systeminfo_a
dd if=/storage/emulated/0/pda-3110/tee.img of=/dev/block/bootdevice/by-name/tee_a
dd if=/storage/emulated/0/pda-3110/vendor.img of=/dev/block/bootdevice/by-name/vendor_a
- Now back to Magisk Manager.
If your phone is rooted with MTK-SU:
Tap Reboot on installation complete screen now, and enjoy Android 10.
If your phone is rooted with regular method (which is, latest Magisk installed properly):
- Open Magisk Manager and install Magisk on another slot.
After installation complete, reboot immediately. Then you should be able to enjoy Android 10 with rooted state.
And here's how (if bootloader unlocked and prefer flashing via fastboot):
- Download the package and extract it. You'll get 17 img files, and 6 other files.
- Use some hex editor (e.g. HxD) to open preloader.img file, and remove the content from 0x0-0x7FF, save it.
Because fastboot will flash preloader.img file you inputted to the offset 0x7FF of actual fastboot partitions, so we must remove header from preloader.img dump, otherwise it will kill the phone.
- After removing header, file size should be 284,672 bytes (278 KiB).
Content range for reference:
Code:
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00000000 45 4D 4D 43 5F 42 4F 4F 54 00 00 00 01 00 00 00 EMMC_BOOT.......
00000010 00 02 00 00 FF FF FF FF FF FF FF FF FF FF FF FF ....ÿÿÿÿÿÿÿÿÿÿÿÿ
00000020 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
Code:
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
000007E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000007F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000800 4D 4D 4D 01 38 00 00 00 46 49 4C 45 5F 49 4E 46 MMM.8...FILE_INF
00000810 4F 00 00 00 01 00 00 00 01 00 05 05 10 0F 20 00 O............. .
And here's after removed:
Code:
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00000000 4D 4D 4D 01 38 00 00 00 46 49 4C 45 5F 49 4E 46 MMM.8...FILE_INF
00000010 4F 00 00 00 01 00 00 00 01 00 05 05 10 0F 20 00 O............. .
00000020 44 4E 04 00 00 00 08 00 F0 00 00 00 6C 06 00 00 DN......ð...l...
00000030 F0 00 00 00 01 00 60 C2 4D 4D 4D 01 0C 00 01 00 ð.....`ÂMMM.....
00000040 01 00 00 00 4D 4D 4D 01 64 00 07 00 90 00 00 00 ....MMM.d.......
00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
- Use img2simg to convert system.img and vendor.img into sparse images.
If you're Windows user, please find img2simg binaries yourself.
This is known available by default on Ubuntu and Debian (sudo apt install img2simg).
Code:
img2simg system.img system.simg
img2simg vendor.img vendor.simg
- Check current slot:
Code:
fastboot getvar current-slot
In this case, the current slot is a.
- Flash these partitions (including modified preloader) to the slot you currently have (slot a in this case):
Code:
fastboot flash boot_a /path/to/HCTSW_PDA-3110-0-00WW-B01_600WW_10_20200405.fdump.lzma2/boot.img
fastboot flash cam_vpu1_a /path/to/HCTSW_PDA-3110-0-00WW-B01_600WW_10_20200405.fdump.lzma2/cam_vpu1.img
fastboot flash cam_vpu2_a /path/to/HCTSW_PDA-3110-0-00WW-B01_600WW_10_20200405.fdump.lzma2/cam_vpu2.img
fastboot flash cam_vpu3_a /path/to/HCTSW_PDA-3110-0-00WW-B01_600WW_10_20200405.fdump.lzma2/cam_vpu3.img
fastboot flash cda_a /path/to/HCTSW_PDA-3110-0-00WW-B01_600WW_10_20200405.fdump.lzma2/cda.img
fastboot flash lk_a /path/to/HCTSW_PDA-3110-0-00WW-B01_600WW_10_20200405.fdump.lzma2/lk.img
fastboot flash logo_a /path/to/HCTSW_PDA-3110-0-00WW-B01_600WW_10_20200405.fdump.lzma2/logo.img
fastboot flash md1img_a /path/to/HCTSW_PDA-3110-0-00WW-B01_600WW_10_20200405.fdump.lzma2/md1img.img
fastboot flash odmdtbo_a /path/to/HCTSW_PDA-3110-0-00WW-B01_600WW_10_20200405.fdump.lzma2/odmdtbo.img
fastboot flash preloader_a /path/to/HCTSW_PDA-3110-0-00WW-B01_600WW_10_20200405.fdump.lzma2/preloader_header_removed.img
fastboot flash scp_a /path/to/HCTSW_PDA-3110-0-00WW-B01_600WW_10_20200405.fdump.lzma2/scp.img
fastboot flash spmfw_a /path/to/HCTSW_PDA-3110-0-00WW-B01_600WW_10_20200405.fdump.lzma2/spmfw.img
fastboot flash sspm_a /path/to/HCTSW_PDA-3110-0-00WW-B01_600WW_10_20200405.fdump.lzma2/sspm.img
fastboot flash system_a /path/to/HCTSW_PDA-3110-0-00WW-B01_600WW_10_20200405.fdump.lzma2/system.simg
fastboot flash systeminfo_a /path/to/HCTSW_PDA-3110-0-00WW-B01_600WW_10_20200405.fdump.lzma2/systeminfo.img
fastboot flash tee_a /path/to/HCTSW_PDA-3110-0-00WW-B01_600WW_10_20200405.fdump.lzma2/tee.img
fastboot flash vendor_a /path/to/HCTSW_PDA-3110-0-00WW-B01_600WW_10_20200405.fdump.lzma2/vendor.simg
fastboot -w reboot
- After reboot, enjoy Android 10.
Download link:
AFH: https://www.androidfilehost.com/?fid=4349826312261767469
SHA256 Checksum: f000263c677ff7f0963a34ece67ecaa2ceb16089e3aa1887dddbbe20d46d590c
FAQ
Q1: Why you don't just leak OTA packages like before?
A1: This time I don't want to make my life harder in the future.
Q2: When Android 10 will be pushed to my country?
A2: I don't know. I even don't know when HMD Chinese localization team will be back. So no hope for localized Android 10 for Nokia X5 now.
Q3: How can I rollback to Android 9 if not satisfied?
A3: If not bootloader unlocked, switch the slot back to A under fastboot mode, then flash the phone with SP Flash Tool (Download only). Always backup the whole emmc to for the worst case.
If unlocked, use NFT featured on Nokia 7.2 forum: https://forum.xda-developers.com/nokia-7-2/development/tool-nft-1-0-1-nokia-flash-tool-to-t4003267
Q4: How can I unlock the bootloader?
A4: It's paid method and how to request cannot be disclosed here, or it will violate the rules of XDA.
Q5: My phone is bricked!
A5: I'm not responsible at all. We tested it on Nokia X5 sold in China already.
Q6: Can I use GCam?
A6: No. Nokia 5.1 Plus X5 doesn't support Camera2API at all, so no GCam.
Q7: What does HCTSW stand for?
A7: Hikari Calyx Tech SoftWare.
Reserved #2
Can I roll back to android 9 if I change my active partition to a if installed android 10 on b ??
bx2_nero said:
Can I roll back to android 9 if I change my active partition to a if installed android 10 on b ??
Click to expand...
Click to collapse
Probably yes, but you need to perform factory reset under stock recovery before switching slot.
Any reported bug by your tester?
bx2_nero said:
Any reported bug by your tester?
Click to expand...
Click to collapse
CTS probably cannot be passed which expected.
After that, didn't see any bug so far.
One known issue:
- This Android 10 build seems cannot be rooted with regular procedure of Magisk Manager.
hikari_calyx said:
One known issue:
- This Android 10 build seems cannot be rooted with regular procedure of Magisk Manager.
Click to expand...
Click to collapse
That means no payment app will work because of SafetyNet and no magisk so no bypassing that.
hikari_calyx said:
One known issue:
- This Android 10 build seems cannot be rooted with regular procedure of Magisk Manager.
Click to expand...
Click to collapse
In MTK-SU thread it says that any update after March 20 will block temp root , so I think April security patch fixed the MTK-SU method and it is included in the Android 10 build.
Tips to users who want to downgrade the phone:
- You must perform a regular factory reset on settings (Don't do factory reset on recovery or you will get stuck at FRP lock that requires you to install further updates)
After reset done, don't connect the phone to Internet and just reboot to fastboot mode.
- Switch the slot to A under fastboot mode right after factory reset.
Code:
fastboot --set-active=a
- Use SP Flash Tool to flash any Android 9 firmware on following website:
https://fih-firmware.hikaricalyx.com/hmd_en.html#pda
Any PDA-2***-0-00WW-B** (excluding PDA-209B-0-00WW-B06) are OK. I recommend PDA-214A-0-00WW-B01.
- Skip wifi connection at first boot, or you'll be asked to install latest updates and MTK-SU will be blocked.
- root the phone and follow the guide on topic.
I strongly recommend you, don't login Google account until everything is done.
Three Bugs noticed So far in Android™ 10 beta
1◆ Swiping left (The back button should appear on left) toggles back button on Right side
2◆Accent color: Color changes for text and not. bar but not in settings
3◆A white bar appearing above when using apps
To subscribers of this topic:
PDA-311A-0-00WW-B01 minor patch released!
What's new? I don't know - I don't have access to their changelog at all.
But, to install it, you must have PDA-3110-0-00WW-B01 installed and install the package via external SD card. ADB Sideload is unavailable.
https://www.androidfilehost.com/?fid=4349826312261794057
Cannot run su in adb
i have acquired root in phone with mtksu and suboot with magisk , but getting permission denied output when trying to run su in cmd. Shouldi I run mtksu through cmd? I tried doing that but I was getting cannot find su command.
xdriv3r said:
i have acquired root in phone with mtksu and suboot with magisk , but getting permission denied output when trying to run su in cmd. Shouldi I run mtksu through cmd? I tried doing that but I was getting cannot find su command.
Click to expand...
Click to collapse
Make sure that you have acquired root access buy using any root checker , then change the installation to inactive slot in magisk and wait on the same screen after it is successful, it will prompt to reboot..don't reboot open cmd and flash A10 beta , 'su' command should give a prompt on your phone to allow root access in adb , allow that then only you will be able to use the dd commands.
Dm me if you need further assistance.
bx2_nero said:
Make sure that you have acquired root access buy using any root checker , then change the installation to inactive slot in magisk and wait on the same screen after it is successful, it will prompt to reboot..don't reboot open cmd and flash A10 beta , 'su' command should give a prompt on your phone to allow root access in adb , allow that then only you will be able to use the dd commands.
Dm me if you need further assistance.
Click to expand...
Click to collapse
Successfully flashed Android 10 Beta. Thank you all so much.
Is it possible to factory reset the device?
xdriv3r said:
Is it possible to factory reset the device?
Click to expand...
Click to collapse
After the installation of A10 beta ... absolutely....and it will make it more stable.
bx2_nero said:
After the installation of A10 beta ... absolutely....and it will make it more stable.
Click to expand...
Click to collapse
I'll factory reset from the Android settings?
xdriv3r said:
I'll factory reset from the Android settings?
Click to expand...
Click to collapse
Yes you can.
Disclaimer:
Super image tools was made for testing and educational purposes, ME is not responsible for what you do on/with your device using our tools, you must agree that you using our tools on your own risk, I am not responsible for anything else!
How to use superunpack:
- First step, unpack super.sin using my tool or use @IgorEisberg unsin tool
- Step two, Superunpack. On windows just drag and drop unpacked super image onto our exe to start extraction. Also you can use it from command line, from script or from etc. On Linux use it from command line. No need to set slot like it was a case on lpunpack, our tool will auto extract all slot images for you, enjoy!
- If you need to unpack partition images in RW mode add parameter 1 at the end of command line e.g. "superunpack super.img 1", than resize partition using resize2fs, repair and unshare blocks using e2fsck. Or if you unpack without rw you no need to resize or repair it, just mount it ro.
How to manualy patch super partition in under Linux:
https://forum.xda-developers.com/t/...s-rw-in-super-partition.4120963/post-87112415
Note that, superunpack is a tool for extract all logical partitions from super image or directly from super partition.
How to use superrepack:
adb push superrepack.arm64_pie /data/local/tmp
adb shell
su
cd /data/local/tmp
mv superrepack.arm64_pie superrepack
chmod 755 superrepack
stop
./superrepack /dev/block/bootdevice/by-name/super system_a
sync
reboot
Note that, superrepack is a tool to convert logical RO partitions iside your phone super partition to RW mode without extracting anything, all things is done on the fly directly inside super partition/image! In this example system_a partiton is converted to the rw mode, if you need other partitions to rw just change system_a argument. Or if you need all partitions to rw mode do it without partition rw argumet e.g: "./superrepack /dev/block/bootdevice/by-name/super". YOU MUST RUN TOOL 4-5 TIMES UNTIL ALL ERRORS DISAPEARS!!! One of the well known errors is: "Couldn't clone file: Could not allocate block in ext2 filesystem". Look at /data/local/tmp/script.log each time and make sure it not contain any error otherwise you are not done things right and partition is not repaired yet!!! More info -> https://forum.xda-developers.com/t/...s-rw-in-super-partition.4120963/post-84966715
Platform:
- Superunpack is working on Windows, Linux, Android, Darwin11, just chose right binary.
- Superrepack is working only under android
Changelog:
- version 1 (21.Jun.2020), initial version
- version 1.1 (22.Jun.2020), dump file format detection, partition size correction in case ext4, partition group detection, have extraction progress bar, improvements
- version 2 (03.04.2021) implemented possibility to extract partition images to rw mode using Superunpack & I have made new tool called Superrepack
- version 2 (04.04.2021) implemented arguments so you would do conversion on single partition instead of doing it on all partitions
- version 3 (04.04.2021) implemented return codes and implemented output logs to be more scripting friendly
- version 4 - not released
- version 5 (08.04.2021) implemented resize and repair partitions after switching to rw mode. Implemented build script for building resize2fs, e2fsck, simg2ims, img2simg, lptools
- version 6 (08.04.2021) better loop device detection and setup
- version 7 (08.04.2021) fix selinux status detection
- version 8 (15.04.2021) fix loop device setup in superrepack
- version 9 (16.04.2021) make losetup android compatible
- version 10 - not released
- version 11 (01.05.2021) simplified, removed needs for parameter rw, implemented dm-verity disabler
- version 12 (05.05.2021) make old logs always deleted before fresh log is created, this prevent concentation with old logs
- version 13 (06.05.2021) make linux version so you should do the things on your super partition dump in linux machine
- version 14 (07.05.2021) fix compilation mess between linux and android
- version 15 (08.05.2021) use libselinux to determine and set selinux to permissive mode instead of popening getenforce-setenforce tools
Credits:
- me and me
Source code:
- source code -> https://github.com/munjeni/super_image_dumper
munjeni said:
hardcoded, no external libs, no android libs.
- my source code, later
Click to expand...
Click to collapse
Yet Another great tool!! :highfive:
Thanks!
New version is out, v11, it now detect file format, partition size correction in case ext4, partition group detection, have extraction progress bar, and it looks like:
Code:
---------------------------------------------------------
Super image dumper v_11 (by expert :) munjeni @ xda 2020)
---------------------------------------------------------
LpMetadataGeometry magic = 0x616c4467
LpMetadataGeometry struct size = 0x34
LpMetadataGeometry sha256 = 12FF55F0ABA7B506F25CB5DA5DCA09344234E8DF1D9C93AE82A499D98019467E
LpMetadataGeometry metadata_max_size = 0x10000
LpMetadataGeometry metadata_slot_count = 0x3
LpMetadataGeometry logical_block_size = 0x1000
LpMetadataHeader magic = 0x414c5030
LpMetadataHeader major_version = 10
LpMetadataHeader minor_version = 0
LpMetadataHeader header_size = 0x80
LpMetadataHeader header sha256 = CCF4F5D07842AAAE7C1B87F0E025512CF7AEA426D477B1E5175DA3D74F9B1C8C
LpMetadataHeader tables_size = 0x2e8
LpMetadataHeader tables sha256 = 52578668F89D8BCDA1BD1F748F2F69ED874C10A7062C85EF9970EE05D90161B1
LpMetadataHeader partitions offset = 0x0
LpMetadataHeader partitions num_entries = 0x8
LpMetadataHeader partitions entry_size = 0x34
LpMetadataHeader extents offset = 0x1a0
LpMetadataHeader extents num_entries = 0x5
LpMetadataHeader extents entry_size = 0x18
LpMetadataHeader groups offset = 0x218
LpMetadataHeader groups num_entries = 0x3
LpMetadataHeader groups entry_size = 0x30
LpMetadataHeader block_devices offset = 0x2a8
LpMetadataHeader block_devices num_entries = 0x1
LpMetadataHeader block_devices entry_size = 0x40
Partitions = 5 used, 3 not used, total 8
partition_1_name = system_a
attributes = 0x1
first_extent_index = 0x0
num_extents = 0x1
group_index = 0x1
partition_group = somc_dynamic_partitions_a
extent num_sectors = 0x336390 (0x66c72000 bytes total)
extent target_type = 0x0
extent target_data = 0x800 (dumping offset = 0x100000)
extent target_source = 0x0
Filetype EXT4. EXT4 size = 0x6526c000
Dumping system_a.ext4 ...
....................................................
....................................................
....................................................
..............................................
partition_2_name = system_b
attributes = 0x1
first_extent_index = 0x1
num_extents = 0x1
group_index = 0x2
partition_group = somc_dynamic_partitions_b
extent num_sectors = 0xab178 (0x1562f000 bytes total)
extent target_type = 0x0
extent target_data = 0x337000 (dumping offset = 0x66e00000)
extent target_source = 0x0
Filetype EXT4. EXT4 size = 0x150b3000
Dumping system_b.ext4 ...
..........................................
partition_3_name = product_a
attributes = 0x1
first_extent_index = 0x2
num_extents = 0x1
group_index = 0x1
partition_group = somc_dynamic_partitions_a
extent num_sectors = 0x2b62b8 (0x56c57000 bytes total)
extent target_type = 0x0
extent target_data = 0x3e2800 (dumping offset = 0x7c500000)
extent target_source = 0x0
Filetype EXT4. EXT4 size = 0x5565b000
Dumping product_a.ext4 ...
....................................................
....................................................
....................................................
..............
partition_4_name = product_b (not unused)
attributes = 0x1
first_extent_index = 0x3
num_extents = 0x0
group_index = 0x2
partition_group = somc_dynamic_partitions_b
extent num_sectors = NULL
extent target_type = NULL
extent target_data = NULL
extent target_source = NULL
Skipping dump.
partition_5_name = vendor_a
attributes = 0x1
first_extent_index = 0x3
num_extents = 0x1
group_index = 0x1
partition_group = somc_dynamic_partitions_a
extent num_sectors = 0x186d58 (0x30dab000 bytes total)
extent target_type = 0x0
extent target_data = 0x699000 (dumping offset = 0xd3200000)
extent target_source = 0x0
Filetype EXT4. EXT4 size = 0x30141000
Dumping vendor_a.ext4 ...
....................................................
............................................
partition_6_name = vendor_b (not unused)
attributes = 0x1
first_extent_index = 0x4
num_extents = 0x0
group_index = 0x2
partition_group = somc_dynamic_partitions_b
extent num_sectors = NULL
extent target_type = NULL
extent target_data = NULL
extent target_source = NULL
Skipping dump.
partition_7_name = odm_a
attributes = 0x1
first_extent_index = 0x4
num_extents = 0x1
group_index = 0x1
partition_group = somc_dynamic_partitions_a
extent num_sectors = 0xa60 (0x14c000 bytes total)
extent target_type = 0x0
extent target_data = 0x820000 (dumping offset = 0x104000000)
extent target_source = 0x0
Filetype EXT4. EXT4 size = 0x132000
Dumping odm_a.ext4 ...
partition_8_name = odm_b (not unused)
attributes = 0x1
first_extent_index = 0x5
num_extents = 0x0
group_index = 0x2
partition_group = somc_dynamic_partitions_b
extent num_sectors = NULL
extent target_type = NULL
extent target_data = NULL
extent target_source = NULL
Skipping dump.
Press any key to continue . . .
If you need to mount ext4 partition on Linux you need to mount partition RO or it will not mount!
I'm not one of those who make paid software and promote on xda, my work is always free. Even I'm always providing source code for free, source code of this tool is here -> https://github.com/munjeni/super_image_dumper , enjoy!
munjeni said:
I'm not one of those who make paid software and promote on xda, my work is always free. Even I'm always providing source code for free, source code of this tool is here -> https://github.com/munjeni/super_image_dumper , enjoy!
Click to expand...
Click to collapse
You are the best and I and many others thank you for make life so easy for us. :highfive:
PS: I will send you a PM with something you may find interesting and useful. :fingers-crossed:
Can I make this tool for remake oem.sin?
I have fw Xperia docomo bundling,and many bloatware,so I wont to remake oem.sin and deleted any bloatware, can I?
??sorry my English por????
paijoe88 said:
Can I make this tool for remake oem.sin?
I have fw Xperia docomo bundling,and many bloatware,so I wont to remake oem.sin and deleted any bloatware, can I?
?sorry my English por??
Click to expand...
Click to collapse
No you can't. Tool is unpacker only, it extracts oem from super image but doesn't reconstruct it back to super image. Even there is no known tool to make valid sin back because of signature.
Seems readonly partitions like oem, system, vendor...etc can be set to read-write mode via LP_PARTITION_ATTR overiding LpMetadataPartition.attributes 1 with 0. Anybody tried android version of this tool? E.g. dump block device e.g. /dev/block/bootdevice/super
RO flags (0x1), when it is set to 0x0 its RW mode, but header sha256 checksums of the LpMetadataGeometry and LpMetadataHeader also need to be modified in case we overvrite flags with RW mode!
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
000003080 73 79 73 74 65 6D 5F 61 00 00 00 00 00 00 00 00 system_a........
000003090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0000030A0 00 00 00 00 01 00 00 00 00 00 00 00 01 00 00 00 ................
0000030B0 01 00 00 00 73 79 73 74 65 6D 5F 62 00 00 00 00 ....system_b....
0000030C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0000030D0 00 00 00 00 00 00 00 00 01 00 00 00 01 00 00 00 ................
0000030E0 01 00 00 00 02 00 00 00 70 72 6F 64 75 63 74 5F ........product_
0000030F0 61 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a...............
000003100 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 ................
000003110 02 00 00 00 01 00 00 00 01 00 00 00 70 72 6F 64 ............prod
000003120 75 63 74 5F 62 00 00 00 00 00 00 00 00 00 00 00 uct_b...........
000003130 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000003140 01 00 00 00 03 00 00 00 00 00 00 00 02 00 00 00 ................
Click to expand...
Click to collapse
Removed fake pie binary and made new true pie 64 bit binary for android. With it you can dump your super partition on your own phone e.g.
Code:
adb push superunpack.arm64_pie /data/local/tmp
adb shell
su
cd /data/local/tmp
chmod 755 superunpack.arm64_pie
./superunpack.arm64_pie /dev/block/bootdevice/by-name/super
and whola all ext4 partitonins from your super partition is extracted to the /data/local/tmp folder.
bump. Any news regarding forcing system to be read/write in Android 10 ?
Thanks for your hard work @munjeni
See post 8.
In most case if you change those byte vbmeta protection will do a bootloop, so I think no way to set it to force rw except if you unlock bootloader and disable vbmeta protection trought fastboot (more info -> https://forum.xda-developers.com/t/tool-newflasher-xperia-command-line-flasher.3619426/post-84509179)
munjeni said:
Seems readonly partitions like oem, system, vendor...etc can be set to read-write mode via LP_PARTITION_ATTR overiding LpMetadataPartition.attributes 1 with 0. Anybody tried android version of this tool? E.g. dump block device e.g. /dev/block/bootdevice/super
RO flags (0x1), when it is set to 0x0 its RW mode, but header sha256 checksums of the LpMetadataGeometry and LpMetadataHeader also need to be modified in case we overvrite flags with RW mode!
Click to expand...
Click to collapse
I replaced all 4 occurences of these three bytes in my super.img like you suggested and flashed it to my phone.
It didn't boot probably due to the invalid sha256 checksums as you predicted.
Which bytes I must hex edit in the extracted system.ext4 in order to make it rw? I was thinking maybe the shared_blocks feature?
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
You should read this to get idea -> https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout
TO be honest I never modified RO partitions. it can be probably done using parted, fsck and similar tools so you no need to do it by hexediting, try google a bit for idea I realy don't know
TO be honest I never modified RO partitions. it can be probably done using parted, fsck and similar tools so you no need to do it by hexediting, try google a bit for idea I realy don't know
Click to expand...
Click to collapse
@munjeni thank you so much for writing this amazing superunpack tool!
Thanks to your program and thanks to another tutorial I was able to create an automated bash script that transforms all read only partitions inside super.img (system, vendor , product, etc...) into read write-able partitions again and then flash to device as a brand new super.img.
HERE is the link to new universal version
munjeni said:
Disclaimer:
Superunpack tool was made for testing and educational purposes, ME is not responsible for what you do on/with your device using superunpack, you must agree that you using superunpack on your own risk, I am not responsible for anything else!
How to use:
- First step, unpack super.sin using my tool or use @IgorEisberg unsin tool
- Step two, on windows just drag and drop unpacked super image onto our exe to start extraction. Also you can use it from command line, from script or from etc. On Linux use it from command line. No need to set slot like it was a case on lpunpack, our tool will auto extract all slot images for you, enjoy!
Platform:
- Superunpack is working on Windows, Linux, Android, Darwin11, just chose right superunpack binary.
Changelog:
- version 10 (21.Jun.2020), initial version
- version 11 (22.Jun.2020), dump file format detection, partition size correction in case ext4, partition group detection, have extraction progress bar, improvements
Credits:
- not right now
Source code:
- tool is based on just this header, the rest of things is myself implemented - hardcoded, no external libs, no android libs.
- my source code -> https://github.com/munjeni/super_image_dumper
Click to expand...
Click to collapse
Wow, this is pretty impressive my friend. Big props!! Just curious, what's the difference with "this" utility(superunpack) and the standard android lpunpack?
bynarie said:
Wow, this is pretty impressive my friend. Big props!! Just curious, what's the difference with "this" utility(superunpack) and the standard android lpunpack?
Click to expand...
Click to collapse
Diferencie is that my tool not use any external dependencies so can be build easily as a static binary. Seccond diferencie is its easy to use, just drag and drop file to extract. I'm not tried lpunpack so I can't tell the exact diferencie, you tell me
munjeni said:
Diferencie is that my tool not use any external dependencies so can be build easily as a static binary. Seccond diferencie is its easy to use, just drag and drop file to extract. I'm not tried lpunpack so I can't tell the exact diferencie, you tell me
Click to expand...
Click to collapse
lpunpack:
works with sparse files
creates .img files
gives zero text output so you don't know what's happening under the hood
extracts all partitions even the empty ones
Superunpack:
works with raw files
creates .ext4 files
gives lots of text info so you know exactly what's going on
only extracts the partitions that are not empty
These are the main differences that I noticed.
Hey friend I get this error can you help me out?
[Novice alert]
lebigmac said:
lpunpack:
works with sparse files
creates .img files
gives zero text output so you don't know what's happening under the hood
extracts all partitions even the empty ones
Superunpack:
works with raw files
creates .ext4 files
gives lots of text info so you know exactly what's going on
only extracts the partitions that are not empty
These are the main differences that I noticed.
Click to expand...
Click to collapse
Nice !
munjeni said:
Diferencie is that my tool not use any external dependencies so can be build easily as a static binary. Seccond diferencie is its easy to use, just drag and drop file to extract. I'm not tried lpunpack so I can't tell the exact diferencie, you tell me
Click to expand...
Click to collapse
Good stuff, thank you!