Database Info

[Hack] Root Phones ("exploit needless" method)

[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...

TF700T complete flash layout

I spent some time in analyzing of flash layout. The comprehensive description below attempts to map each byte of the flash and describes way to extract it.
I would be glad if somebody could provide more detailed info about bootloader, signatures, DRM etc.
Patches are welcome.
Code:
mmcblk0 layout
All dumps were done on Asus Eee Pad Transformer Infinity TF700T, 64GB version, firmware 9.4.5.26, locked
mmcblk0 off-partition section
Offset: 0 (0x0)
Size: 38273024 (0x2480000)
Read command: busybox dd if=/dev/block/mmcblk0 of=/mnt/sdcard/mmcblk0pre1.img bs=524288 count=73
Offset: 0 (0x0)
Size: 3670016 (0x380000)
Contains: Zeroes
Purpose: Unknown
Extract command: dd if=mmcblk0pre1.img of=mmcblk0pre1s1.img bs=3670016 count=1
Process command: tr -d '\0' <mmcblk0pre1s1.img >mmcblk0pre1s1nz.img # mmcblk0pre1s1nz.img must be empty file
Offset: 3670016 (0x380000)
Contains: Recovery kernel image followed by zeroes
Size: 8388608 (0x800000)
Extract command: dd if=mmcblk0pre1.img of=mmcblk0pre1s2.img bs=524288 skip=7 count=16
Process commands:
perl split_bootimg.pl mmcblk0pre1s2.img
mkdir mmcblk0pre1s2.img-ramdisk
cd mmcblk0pre1s2.img-ramdisk
zcat ../mmcblk0pre1s2.img-ramdisk.gz | cpio -i
cd ..
# end Process commands
Offset: 12058624 (0xb80000)
Contains: Regular boot kernel image followed by zeroes
Size: 8388608 (0x800000)
Extract command: dd if=mmcblk0pre1.img of=mmcblk0pre1s3.img bs=524288 skip=23 count=16
Process commands:
perl split_bootimg.pl mmcblk0pre1s3.img
mkdir mmcblk0pre1s3.img-ramdisk
cd mmcblk0pre1s3.img-ramdisk
zcat ../mmcblk0pre1s3.img-ramdisk.gz | cpio -i
cd ..
# end Process commands
Offset: 20447232 (0x1380000)
Contains: Block of 16 bytes followed by 0x2de0 hexadecimal numbers followed by FF
Size: 12288 (0x3000)
Extract command: dd if=mmcblk0pre1.img of=mmcblk0pre1s4.img bs=524288 skip=39
Vital data:
Extract command: dd if=mmcblk0pre1s4.img of=mmcblk0pre1s4ss2.img bs=4096 skip=3
Binary part of vital data:
Extract command: dd if=mmcblk0pre1s4ss1.img of=mmcblk0pre1s4ss1ch1.img bs=16 count=1
Hexadecimal part of vital data:
Extract command: dd if=mmcblk0pre1s4ss1.img of=mmcblk0pre1s4ss1ch2.img bs=16 count=734 skip=1
Process command: unhex <mmcblk0pre1s4ss1ch2.img >mmcblk0pre1s4ss1ch2bin.img
FF part of vital data:
Extract command: dd if=mmcblk0pre1s4ss1.img of=mmcblk0pre1s4ss1ch3.img bs=16 skip=735
Process command: tr -d '\377' <mmcblk0pre1s4ss1ch3.img >mmcblk0pre1s4ss1ch3nff.img # mmcblk0pre1s4ss1ch3nff.img must be empty file
Zeroes:
Extract command: dd if=mmcblk0pre1s4.img of=mmcblk0pre1s4ss1.img bs=4096 count=3
Process command: tr -d '\0' <mmcblk0pre1s4ss2.img >mmcblk0pre1s4ss2nz.img # mmcblk0pre1s4ss2nz.img must be empty file
Purpose: Probably encrypted bootloader
mmcblk0p1
Offset: 38273024 (0x2480000)
Size: 805306368 (0x30000000)
File system size: 196608 * 4096 = 805306368 (fully occupies partition)
Format: Linux ext4 filesystem
Mounted at: /system
Mount options: read only, extended attributes, ACL
Permissions: only root can manipulate
Contains: Base system and embedded applications
Purpose: Base system
mmcblk0p2
Offset: 843579392 (0x32480000)
Size: 448790528 (0x1ac00000)
File system size: 109568 * 4096 = 448790528 (fully occupies partition)
Format: Linux ext4 filesystem
Mounted at: /cache
Mount options: read/write, no SUID, no device nodes, no atime
Permissions: only root can manipulate, UID system and GID cache can read and write
Contains: Cache
Purpose: Application cache
Note: The volume has the same UUID as mmcblk0p1
mmcblk0p3
Offset: 1292369920 (0x4d080000)
Size: 2097152 (0x200000)
File system size: 512 * 4096 = 2097152 (fully occupies partition)
Linux rev 1.0 ext3 filesystem
Not mounted
Permissions: GID system can manipulate
Contains: Empty file system
Purpose: Recovery /misc
Referenced by: /system/lib/libandroid_runtime.so recovery ramdisk: /etc/recovery.fstab
Note: File system is referenced in recovery as emmc, not ext3!
mmcblk0p4
Offset: 1294467072 (0x4d280000)
Size: 855638016 (0x33000000)
File system size: 208896 * 4096 = 855638016
Linux rev 1.0 ext3 filesystem
Not mounted
Permissions: GID system can manipulate
Contains: Empty file system
Purpose: Recovery /staging
Referenced by: recovery ramdisk: init.rc /etc/recovery.fstab
mmcblk0p5
Offset: 2150105088 (0x80280000)
Size: 5242880 (0x500000)
File system size: 5092 * 1024 = 5147488
Format: FAT32 file system, no partition table, MS-DOS "Non-system disk" boot block
Not mounted
Permissions: only root can manipulate
Contains: File system with files:
Serial numbers (ISN, PPID, SSN, UUID)
Calibration data (AL3010 light sensor, AMI304 magnetic sensor, KXTF9 motion sensor)
Purpose: Device specific unique system data, mounted as /btmac during Android boot
Referenced by: /system/bin/wifimacwriter /system/bin/brcm_patchram_plus /system/bin/sensors-config /system/bin/sixpair ramdisk: /init recovery ramdisk: /etc/recovery.fstab /init
mmcblk0p5 off file-system area
Offset in section: 5147488 (0x4e8b60)
Size: 28672 (0x7000)
Read command: busybox dd if=/dev/block/mmcblk0p5 of=/mnt/sdcard/mmcblk0p5s2.img bs=1024 skip=5092
Process command: tr -d '\0' <mmcblk0p5s2.img >mmcblk0p5s2nz.img # mmcblk0p5s2nz.img must be empty file
mmcblk0p6
Offset: 2155347968 (0x80780000)
Size: 524288 (0x80000)
Format: binary data
Permissions: UID drm can manipulate
Contains: 208 bytes of binary data, the rest are zeroes
Purpose: DRM, probably contains encrypted DRM key
Referenced by: /system/bin/wvdrmserver /system/vendor/lib/drm/libdrmwvmplugin.so
mmcblk0p7
Offset: 2155872256 (0x80800000)
Size: 5242880 (0x500000)
Format: empty
Contains: Zeroes
Purpose: Unknown
mmcblk0p8
Offset: 2161115136 (0x80d00000)
Size: 61415620608 (0xe4ca80000)
File system size: 14994040 * 4096 = 61415587840
Format: Linux ext4 filesystem
Mounted at: /data
Mount options: read/write, no SUID, no device nodes, no atime
Permissions: only root can manipulate, read and write are directory specific
Contains: User applications, user data, and virtual internal SD card
Note: /data/media is mounted via UID/GID stripping FUSE as /mnt/sdcard
mmcblk0p8 off file-system area
Offset in section: 61415587840 (0xe4ca78000)
Size: 32768 (0x8000)
Read command: busybox dd if=/dev/block/mmcblk0p8 of=/mnt/sdcard/mmcblk0p8s2.img bs=4096 skip=14994040
mmcblk0 off-partition section
Offset: 63576735744 (0xecd780000)
Size: 524288 (0x80000)
Read command: busybox dd if=/dev/block/mmcblk0 of=/mnt/sdcard/mmcblk0post8.img bs=524288 skip=121263
Process command: tr -d '\0' <mmcblk0p8s2.img >mmcblk0p8s2nz.img # mmcblk0p8s2nz.img must be empty file
Offset: 63576735744 (0xecd780000)
Offset in section: 0 (0x0)
Size: 507392 (0x7be00)
Contains: Zeroes
Purpose: Unknown
Extract command: dd if=mmcblk0post8.img of=mmcblk0post8s1.img bs=507392 count=1
Process command: tr -d '\0' <mmcblk0post8s1.img >mmcblk0post8s1nz.img # mmcblk0post8s1nz.img must be empty file
Offset: 63577243136 (0xecd7fbe00)
Offset in section: 507392 (0x7be00)
Size: 16896 (0x4200)
Contains: EFI Partition table (partition names: APP, CAC, MSC, USP, PER, YTU, CRA, UDA)
Extract command: dd if=mmcblk0post8.img of=mmcblk0post8s2.img bs=512 skip=991
Purpose: Partition table
Total size of mmcblk0: 63577260032 (0xecd800000)
Notes:
can manipulate = can read, write partition vital data, only root can mount
can read, write = can read, write partition file system contents
Read commands are ran on the Transformer
Extract and process commands are run anywhere, with pre-read image file in the current directory.
You need dd with large files support. Vanilla dd on TF700T does not support large files. Busybox dd does.
Dropbox link to Asus_Transformer_Infinity_TF700T/flash_layout.txt

Wow, thanks for this detailed analysis - much more detailed than mine.
So what can I add to your research?
Tegra-based systems have another partition table, which has a proprietary layout and an unknown purpose (maybe just important for NVFlash and for flashing blobs?). Looking at the flash.cfg in the NVFlash package from AndroidRoot.mobi, we can get the Tegra partition layout and partition names:
Partition number 1 is missing in the list, maybe it contains the extremely well-hidden APX mode recovery code or even the answer to life, the universe and everything.
The following 3 partitions are located at the beginning of mmcblk0 and their contents are apparently encrypted with a device-specific key. For some reason, with ICS-based ROMs it reads as all zeros; in JB-based ROMs additional mmcblk0boot0 and mmcblk0boot1 partitions appear which together cover this area. The "bricksafe.img" in the nvflash guide covers these 3 partitions.
2 BCT: Tegra Boot Configuration Table - 3145728 bytes
3 PT: Tegra Partition Table - 524288 bytes
4 EBT: Bootloader - 8388608 bytes
You already know the following 2:
5 SOS: Recovery kernel - 8388608 bytes
6 LNX: Linux kernel - 8388608 bytes
Then some more funny ones:
7 CER: I think this stands for "Certificate" and contains the bootloader unlock token. - 8388608 bytes. If I calculated correctly, this is at 0x1380000 into mmcblk0. Saved as "unlock-token.img" in the nvflash guide.
8 IMG: no idea what this is for - 8388608 bytes
9 GP1: space for a GPT partition table, maybe unused - 1048576 bytes
Now the regular partitions follow (p1 to p8):
10 APP: p1 = /system (Android OS)
11 CAC: p2 = /cache (for communication between Android and recovery)
12 MSC: p3 ="misc", whatever that is. On the TF101 it was used for bootloader commands.
13 USP: p4 = The update staging partition. Update blobs are copied here and flashed to the correct partition by the bootloader.
14 PER: p5 = device-specific config in a FAT filesystem
15 YTU: p6 = Apparently the DRM key. Confirmed to be overwritten with 0 by the unlocking process.
16 CRA: p7 = unknown (reserved for crash dumps?)
17 UDA: p8 = /data (Android user data)
And finally:
18 GPT: the EFI partition table that is actually used by the kernel

Well, it seems, that something (ICS stock kernel, hardware) hides contents of the first (at most) 0x380000 bytes of flash.
I am locked, and I have some token at 0x1380000 as well.
I am still thinking about a way to unlock, keep access to nvflash, and upgrade to JB keeping DRM working, even at cost of using stock system. That is why I wanted to backup and analyze everything and find all keys and signatures.
It would be also nice to know, whether there are areas of flash with hardware or kernel write lock.

utx said:
Well, it seems, that something (ICS stock kernel, hardware) hides contents of the first (at most) 0x380000 bytes of flash.
I am locked, and I have some token at 0x1380000 as well.
Click to expand...
Click to collapse
Yes, before unlocking I had something very similar to you there - a 16 byte header followed by some hexdump. I don't know what it was. It was overwritten by the unlock process with a 4 byte data block prefixed with a "-SIGNED-BY-SIGNBLOB-" header and followed by 256 bytes of what looks like a digital signature, very similar to the signed update blobs.
utx said:
I am still thinking about a way to unlock, keep access to nvflash, and upgrade to JB keeping DRM working, even at cost of using stock system. That is why I wanted to backup and analyze everything and find all keys and signatures.
Click to expand...
Click to collapse
Definitely back up the YTU partition before unlocking (p6) and then make the nvflash backups - but maybe the key must match something that is broken by the unlocking process, or it is renewed periodically, etc., so it might not help. Maybe try using DRM before unlocking and watch if the content of the partition changes over time.
utx said:
It would be also nice to know, whether there are areas of flash with hardware or kernel write lock.
Click to expand...
Click to collapse
Never tried to write directly to the block device - too scared to break something.
---------- Post added at 09:32 PM ---------- Previous post was at 09:28 PM ----------
Another small addition:
Note: /data/media is mounted via UID/GID stripping FUSE as /mnt/sdcard
Click to expand...
Click to collapse
This FUSE trick also makes /mnt/sdcard case-insensitive.

I just thought of something. What if you launched a data recovery process and recovered the DRM keys for the device?

ostar2 said:
I just thought of something. What if you launched a data recovery process and recovered the DRM keys for the device?
Click to expand...
Click to collapse
How do you define "data recovery process"? You cannot recover data that has been overwritten.

_that said:
How do you define "data recovery process"? You cannot recover data that has been overwritten.
Click to expand...
Click to collapse
Well, if the DRM partition is write enabled, it may be possible to restore its contents, if you backed it up before unlock (it is probably per-device unique). But it could be insufficient. Locked bootloader can be different than unlocked bootloader, and may drop cipher needed for DRM decihering. It is just a theory. Somebody could proof it or falsify, if:
1) Backed all accessible data before unlock.
2) Unlocked (and to be safe, also made brickproof image).
3) Recovered the data creates in step 1.
Will DRM work then? Or did we need the contents of (currently inaccessible) locked stock data of the first megabytes?
But I see no way, how to back-up first megabytes of locked device (on ICS; JB is not as interesting for us, once you upgrade to JB, you cannot create brickproof image for nvflash).
I even don't know, which part of the subsystem causes these megabytes being reported as zeroes. Is it stock Asus ICS kernel? Is it bootloader? Is it a hardware lock on the flash device?

Good idea, but what I meant by "Data Recovey". Is restoring the deleted data from that filesystem/partition.

ostar2 said:
Good idea, but what I meant by "Data Recovey". Is restoring the deleted data from that filesystem/partition.
Click to expand...
Click to collapse
I see, so I assume you assume you had a backup before.
Somebody (maybe you?) could try roughly the following sequence:
- get new TF700
- update to 9.4.5.26. if it's already newer, forget nvflash, but the rest could still work.
- root it using debugfs
- make a backup of /dev/block/mmcblk0p6
- do some DRM-dependent stuff and check that it works
- after some days, make another backup of /dev/block/mmcblk0p6 and compare if anything has changed. If the key is static, maybe restoring after unlocking could work. If not, chances are high that it doesn't work.
- unlock (this erases mmcblk06 and voids warranty)
- optional, but very useful: install AndroidRoot hacked bootloader to make blobs for nvflash, then use nvflash to backup all partitions
- restore backup of /dev/block/mmcblk0p6
- try if DRM still works

_that said:
I see, so I assume you assume you had a backup before.
Somebody (maybe you?) could try roughly the following sequence:
- get new TF700
- update to 9.4.5.26. if it's already newer, forget nvflash, but the rest could still work.
- root it using debugfs
- make a backup of /dev/block/mmcblk0p6
- optional, but very useful: install AndroidRoot hacked bootloader to make blobs for nvflash, then use nvflash to backup all partitions
- do some DRM-dependent stuff and check that it works
- after some days, make another backup of /dev/block/mmcblk0p6 and compare if anything has changed. If the key is static, maybe restoring after unlocking could work. If not, chances are high that it doesn't work.
- unlock (this erases mmcblk06 and voids warranty)
- restore backup of /dev/block/mmcblk0p6
- try if DRM still works
Click to expand...
Click to collapse
To install AndroidRoot bootloader and by that getting nvflash blobs, you have to unlock first... The order of your steps is therefore wrong.

firetech said:
To install AndroidRoot bootloader and by that getting nvflash blobs, you have to unlock first... The order of your steps is therefore wrong.
Click to expand...
Click to collapse
Oops, thanks for noticing. I edited my post.

what if we were to read from the NAND externally (RAW)....xbox 360 style...wouldn't that be the same as nvflash....
except that the three partitions in question are encrypted with a key that is probably unique per Tegra...
2 BCT: Tegra Boot Configuration Table - 3145728 bytes
3 PT: Tegra Partition Table - 524288 bytes
4 EBT: Bootloader - 8388608 bytes
but I would suppose it wouldn't be a problem since a raw flash would restore everything back to normal...even if we can't read it..the CPU can..and that's all that matters.
---------- Post added at 11:21 AM ---------- Previous post was at 11:13 AM ----------
never mind...its a BGA

_that said:
I see, so I assume you assume you had a backup before.
Somebody (maybe you?) could try roughly the following sequence:
- get new TF700
- update to 9.4.5.26. if it's already newer, forget nvflash, but the rest could still work.
- root it using debugfs
- make a backup of /dev/block/mmcblk0p6
- do some DRM-dependent stuff and check that it works
- after some days, make another backup of /dev/block/mmcblk0p6 and compare if anything has changed. If the key is static, maybe restoring after unlocking could work. If not, chances are high that it doesn't work.
- unlock (this erases mmcblk06 and voids warranty)
- optional, but very useful: install AndroidRoot hacked bootloader to make blobs for nvflash, then use nvflash to backup all partitions
- restore backup of /dev/block/mmcblk0p6
- try if DRM still works
Click to expand...
Click to collapse
Correct order maybe.
- get new TF700
- update to 9.4.5.26.
- root it using debugfs
- make a backup of /dev/block/*.*
- unlock (this erases mmcblk06 and voids warranty)
- install AndroidRoot hacked bootloader to make blobs for nvflash
- restore backup of /dev/block/mmcblk0p6
- try if DRM still works
Q1:If i backed up 9.4.5.26 all block image.After i updated 9.4.5.30 can i get the nvflash blob from backed up images?No way to dig out the blob key from the backup?

W3ber said:
Q1:If i backed up 9.4.5.26 all block image.After i updated 9.4.5.30 can i get the nvflash blob from backed up images?No way to dig out the blob key from the backup?
Click to expand...
Click to collapse
No way - the BCT, bootloader, etc. is not visible to the kernel at all (so it's not included in your images), and I don't know which kind of magic the blob creation tool uses, but I assume it's more than reading stuff from the nand.

[Tool][python] LG Compressed KDZ Extractor

Hello everybody!
This will be my first XDA-wide release of my new utility for all LG phones.
What is this?
This is a utility to extract the new format KDZ files that LG distributes, specifically the 'compressed' ones.
LG frequently distributes firmware for phones as KDZ files, which are essentially a firmware image of the eMMC and a DLL file that is used by the downloader utility to communicate with the phone.
In the past, there were utilities to extract KDZ files to a DLL file and a DZ file, but no further (at least to my knowledge).
This utility lets you break the KDZ file into it's respective partitions (aboot, rpm, tz, and so on)​
What good does this do me?
If you're an phone modder, haxxor, or just an enthusiast that has access to their phone's KDZ file and would like to have a copy of the actual partitions stored within, this will let you.
As an example, firmware for the new LG G2 on many device models is distributed as a KDZ file only.
Other phones use a TOT file, which is essentially a disk image of the eMMC with no compression.
If someone with a KDZ firmware-only phone wiped a partition (for example, modem) and wanted to get it back without flashing the whole phone all over again, they would be stuck.
TOT files are easily extractable, as there is software available currently for that but until today there was none (to my knowledge) for these new KDZ files.​
How do I use this?
Glad you asked.
Inside the ZIP file you'll see two Python scripts, KDZFileTools.py and DZFileTools.py.
There's also a README.txt file for more in-depth information if you're curious.
Both scripts respond to --help or -h, so if you're even more curious, try that too!
KDZ files contain DZ files and DLL files, so the first step will be to split those into their respective parts:
LAS_V08d_pre3_00.kdz is the name of the KDZ file that I've copied to the working directory for this example.
Code:
# python KDZFileTools.py -l -f LAS_V08d_pre3_00.kdz
[+] KDZ Partition List
=========================================
0 : LAS_V08d_pre3_00.dz (1428092632 bytes)
1 : LGUP_8974.dll (1477632 bytes)
This shows me that there are two files inside the KDZ file: LAS_V08d_pre3_00.dz and LGUP_8974.dll
You can now extract them by ID by using the -s option, or by using -x to extract all of the files.
Code:
# python KDZFileTools.py -f LAS_V08d_pre3_00.kdz -x
[+] Extracting all partitions!
[+] Extracting LAS_V08d_pre3_00.dz to kdzextracted\LAS_V08d_pre3_00.dz
[+] Extracting LGUP_8974.dll to kdzextracted\LGUP_8974.dll
Now you'll see a folder called "kdzextracted" in your current working directory, which will contain the extracted files.
The next step would be to extract the DZ file to get the partitions it contains:
Code:
# python DZFileTools.py -f kdzextracted/LAS_V08d_pre3_00.dz -l
[+] DZ Partition List
=========================================
0 : PrimaryGPT_0.bin (4299 bytes)
1 : modem_32768.bin (25719664 bytes)
2 : sbl1_163840.bin (179443 bytes)
3 : dbi_165888.bin (10505 bytes)
4 : aboot_229376.bin (288082 bytes)
5 : rpm_231424.bin (93084 bytes)
6 : boot_262144.bin (8959565 bytes)
7 : tz_294912.bin (149388 bytes)
8 : persist_393216.bin (23621 bytes)
9 : recovery_458752.bin (10454494 bytes)
10 : laf_622592.bin (14244284 bytes)
11 : system_7176192.bin (66791740 bytes)
12 : system_7438336.bin (2651 bytes)
13 : system_7440008.bin (2313 bytes)
14 : system_7444120.bin (103727934 bytes)
15 : system_7704592.bin (114239263 bytes)
16 : system_7964296.bin (2313 bytes)
17 : system_7968408.bin (103349001 bytes)
18 : system_8228880.bin (121921125 bytes)
19 : system_8488584.bin (2313 bytes)
20 : system_8492696.bin (101078725 bytes)
21 : system_8753168.bin (125454806 bytes)
22 : system_9012872.bin (2313 bytes)
23 : system_9016984.bin (105806605 bytes)
24 : system_9277456.bin (115830981 bytes)
25 : system_9537160.bin (2313 bytes)
26 : system_9541272.bin (108458465 bytes)
27 : system_9801744.bin (83280847 bytes)
28 : system_10063888.bin (67940827 bytes)
29 : system_10326032.bin (91997923 bytes)
30 : system_10588176.bin (58015487 bytes)
31 : system_10846208.bin (2314 bytes)
32 : system_11108352.bin (2314 bytes)
33 : system_11370496.bin (2314 bytes)
34 : system_11632640.bin (2314 bytes)
35 : system_11894784.bin (2314 bytes)
36 : system_12156928.bin (2314 bytes)
37 : system_12419072.bin (2314 bytes)
38 : system_12681216.bin (2314 bytes)
39 : system_12943360.bin (2314 bytes)
40 : system_13205504.bin (2314 bytes)
41 : system_13467648.bin (2314 bytes)
42 : system_13729792.bin (2652 bytes)
43 : system_13731464.bin (2314 bytes)
44 : BackupGPT_61070336.bin (4286 bytes)
Excellent! All the files are there!
Large images are split up by LG, and can be combined with "cat" or something like that.
The filename actually is in the form "partname_offset.bin" where "offset" is the actual location that the file should be written to on the phone's eMMC (handy!)
You can substitute -l in the options for -x again to extract all the partitions to the folder "dzextracted" in the current working directory as well.
The option --out or -o will change the output directory, so it doesn't have to output to {kdz|dz}extracted​
Where can I download this?
Code:
[URL="http://downloads.codefi.re/thecubed/androidtools/Compressed_KDZUtils.zip"]http://downloads.codefi.re/thecubed/androidtools/Compressed_KDZUtils.zip[/URL]
Please don't mirror this file, as having it in one location makes it easy for me to keep it up to date, or pull it if there are problems with this script​
It doesn't work? Can you help me?!
Sure, join #lg-g2 on Freenode and ask for IOMonster and I'll try to help out as best I can.
I will not answer questions in PM or via email, please don't PM me about this script!
As usual, if this script eats your dog/cat/uncle please don't blame me either. I didn't mean to do it, I swear!​
Whoo! Thanks! It works! How can I say thanks?
"Thanking" this thread is great!
If you feel that I absolutely saved you many hours of time, feel free to click on the "Donate to Me" button next to my username in this post.
This project was funded by a boring day at work and lots of caffiene ​
Alright guys, let me know if you've got any questions and I'll see what I can do!

Ha! Just what I was looking for but now to get it to work in Windows...
Thanks!
Edit
So I installed Python for Windows and this was the output...
C:\Python33>KDZFileTools.py -l -f F320K11D_00.kdz
File "C:\Python33\KDZFileTools.py", line 159
print "[!] Error: Unsupported KDZ file format."
^
SyntaxError: invalid syntax
C:\Python33>python.exe DZFileTools.py -l -f D80210C_00.kdz
File "DZFileTools.py", line 96
print "[!] Bad DZ sub header!"
^
SyntaxError: invalid syntax
C:\Python33>python.exe KDZFileTools.py -l -f D80210C_00.kdz
File "KDZFileTools.py", line 159
print "[!] Error: Unsupported KDZ file format."
^
SyntaxError: invalid syntax

AndroidUser00110001 said:
Ha! Just what I was looking for but now to get it to work in Windows...
Thanks!
Edit
So I installed Python for Windows and this was the output...
C:\Python33>KDZFileTools.py -l -f F320K11D_00.kdz
File "C:\Python33\KDZFileTools.py", line 159
print "[!] Error: Unsupported KDZ file format."
^
SyntaxError: invalid syntax
C:\Python33>python.exe DZFileTools.py -l -f D80210C_00.kdz
File "DZFileTools.py", line 96
print "[!] Bad DZ sub header!"
^
SyntaxError: invalid syntax
C:\Python33>python.exe KDZFileTools.py -l -f D80210C_00.kdz
File "KDZFileTools.py", line 159
print "[!] Error: Unsupported KDZ file format."
^
SyntaxError: invalid syntax
Click to expand...
Click to collapse
Not sure what's happening here, but I wrote this in Windows, so it works for me...
Try using Python 2.7 ? I haven't tested it with Py3k...
If it still gives you invalid headers after you get rid of the SyntaxError messages, let me know and I'll take a look. I've only verified that this works on a handful of KDZ files.

Thanks for such a awesome tool. After extracting D80210E_00.kdz, I found that system_xxxxxxx.bin files is not contiguous. Merge into one file, you can not mount it.
would you like to develop a tool more for system partitions merge?

honentan said:
Thanks for such a awesome tool. After extracting D80210E_00.kdz, I found that system_xxxxxxx.bin files is not contiguous. Merge into one file, you can not mount it.
would you like to develop a tool more for system partitions merge?
Click to expand...
Click to collapse
Excellent timing I'm actually working on that right now.
It would appear that the KDZ file contains only the 'sparse' data from large partitions.
Basically, it's the same as if you fed the utility "hexdump" a large file with multiple sections will have the empty sections 'collapsed' and shown as a "*".
My utility needs to take the beginning position of the first system_xxxx.bin file into account, and the end system_xxxx.bin 's position and size.
From there, it knows how big the image file needs to be, then it can simply seek to the position in the new file as defined by each .bin file and write it's contents there.
Ultimately, I'd like to have in-place extraction from the KDZ files, without the need to extract the DZ file itself (since it really is just copying the bytes from the right position to a new file on the hdd), and a utility to merge split partitions, like system.
Until then, if you need to create this image yourself, you can do so with a hex editor or dd
1. Take the first system_xxxxx.bin file and write down the value of xxxxx somewhere. We're going to use this as an offset.
2. Take the last system_xxxxx.bin file and write down it's xxxxx as well. Subtract the two. You should now get the size of the system.img file
3. Use "dd" to create a file of proper length: dd if=/dev/zero of=system.img bs=1 count=SIZE_FROM_EARLIER
4. Now, let's put our files into the right places. The first file can just be merged into it with dd if=system_xxxxx.bin of=system.img conv=notrunc
5. For every file after the first one, you'll have to take the xxxxx value from the file, and subtract the offset you found from step 1. use dd if=system_xxxxx.bin of=system.img seek=VALUE_YOU_JUST_FOUND
6. The end file is no different. Subtract it's xxxxx value again and run the above DD command.
If I'm right, this should leave you with a working partition image.
I haven't verified yet, but it seems logical and should work

thanks for your reply. I am going to try the method as you mentioned just now to merge the system.img using winhex, but I have not verified yet too. I will try it tomorrow.
as a advice, new tool should be able to extract and repack new kdz file.

honentan said:
Thanks for such a awesome tool. After extracting D80210E_00.kdz, I found that system_xxxxxxx.bin files is not contiguous. Merge into one file, you can not mount it.
would you like to develop a tool more for system partitions merge?
Click to expand...
Click to collapse
thecubed said:
Excellent timing I'm actually working on that right now.
It would appear that the KDZ file contains only the 'sparse' data from large partitions.
Basically, it's the same as if you fed the utility "hexdump" a large file with multiple sections will have the empty sections 'collapsed' and shown as a "*".
My utility needs to take the beginning position of the first system_xxxx.bin file into account, and the end system_xxxx.bin 's position and size.
From there, it knows how big the image file needs to be, then it can simply seek to the position in the new file as defined by each .bin file and write it's contents there.
Ultimately, I'd like to have in-place extraction from the KDZ files, without the need to extract the DZ file itself (since it really is just copying the bytes from the right position to a new file on the hdd), and a utility to merge split partitions, like system.
Until then, if you need to create this image yourself, you can do so with a hex editor or dd
1. Take the first system_xxxxx.bin file and write down the value of xxxxx somewhere. We're going to use this as an offset.
2. Take the last system_xxxxx.bin file and write down it's xxxxx as well. Subtract the two. You should now get the size of the system.img file
3. Use "dd" to create a file of proper length: dd if=/dev/zero of=system.img bs=1 count=SIZE_FROM_EARLIER
4. Now, let's put our files into the right places. The first file can just be merged into it with dd if=system_xxxxx.bin of=system.img conv=notrunc
5. For every file after the first one, you'll have to take the xxxxx value from the file, and subtract the offset you found from step 1. use dd if=system_xxxxx.bin of=system.img seek=VALUE_YOU_JUST_FOUND
6. The end file is no different. Subtract it's xxxxx value again and run the above DD command.
If I'm right, this should leave you with a working partition image.
I haven't verified yet, but it seems logical and should work
Click to expand...
Click to collapse
I merged system.img using script as you mentioned, but it couldn't be mounted also.
Progress was obtained, I got all files in system.img using ext2explore(version2.1).
Code:
dd if=/dev/zero of=system.img bs=1 count=5505024
dd if=system_819200.bin of=system.img conv=notrunc seek=0
dd if=system_1081344.bin of=system.img conv=notrunc seek=262144
dd if=system_1082760.bin of=system.img conv=notrunc seek=263560
dd if=system_1086808.bin of=system.img conv=notrunc seek=267608
dd if=system_1347536.bin of=system.img conv=notrunc seek=528336
dd if=system_1607048.bin of=system.img conv=notrunc seek=787848
dd if=system_1611096.bin of=system.img conv=notrunc seek=791896
dd if=system_1871824.bin of=system.img conv=notrunc seek=1052624
dd if=system_2131336.bin of=system.img conv=notrunc seek=1312136
dd if=system_2135384.bin of=system.img conv=notrunc seek=1316184
dd if=system_2396112.bin of=system.img conv=notrunc seek=1576912
dd if=system_2655624.bin of=system.img conv=notrunc seek=1836424
dd if=system_2659672.bin of=system.img conv=notrunc seek=1840472
dd if=system_2920400.bin of=system.img conv=notrunc seek=2101200
dd if=system_3179912.bin of=system.img conv=notrunc seek=2360712
dd if=system_3183960.bin of=system.img conv=notrunc seek=2364760
dd if=system_3444688.bin of=system.img conv=notrunc seek=2625488
dd if=system_3706832.bin of=system.img conv=notrunc seek=2887632
dd if=system_3968976.bin of=system.img conv=notrunc seek=3149776
dd if=system_4231120.bin of=system.img conv=notrunc seek=3411920
dd if=system_4493264.bin of=system.img conv=notrunc seek=3674064
dd if=system_4755408.bin of=system.img conv=notrunc seek=3936208
dd if=system_5017552.bin of=system.img conv=notrunc seek=4198352
dd if=system_5275648.bin of=system.img conv=notrunc seek=4456448
dd if=system_5537792.bin of=system.img conv=notrunc seek=4718592
dd if=system_5799936.bin of=system.img conv=notrunc seek=4980736
dd if=system_6062080.bin of=system.img conv=notrunc seek=5242880
dd if=system_6324224.bin of=system.img conv=notrunc seek=5505024
ext2explore log:
Partition Table Error on D:/Android-ROM/980VS/system.img
Invalid End of sector markerBlock size 4096, inp 8064, inodesize 256
Linux Partition found on disk 1 partition 0
Inode 727 with file size 0

thecubed said:
Not sure what's happening here, but I wrote this in Windows, so it works for me...
Try using Python 2.7 ? I haven't tested it with Py3k...
If it still gives you invalid headers after you get rid of the SyntaxError messages, let me know and I'll take a look. I've only verified that this works on a handful of KDZ files.
Click to expand...
Click to collapse
Thanks, I got it working using 2.7 I have everything extracted and now I need to learn how to merge all the system files.
Thanks!

AndroidUser00110001 said:
Thanks, I got it working using 2.7 I have everything extracted and now I need to learn how to merge all the system files.
Thanks!
Click to expand...
Click to collapse
I'm working on a modified version of the DZFileUtils.py script, since the DZ file actually contains the proper information to regenerate the full system.img easier than using DD or a hex editor.
Work has been a little crazy for the past few days, so I may not get a chance to work on the script until next week, but it won't be that hard to have this script put the system.img files back together.
I could modify the whole toolsets to do in-place extraction from a KDZ file (skipping the intermediate DZ file) but for now this is the easiest and accomplishes my goal the fastest (which is to allow extraction of bootloader stacks from KDZ files found on the interwebs)
I have no plans on creating a utility to generate KDZ files, since myself and @Shelnutt2 are in the process of writing a utility to flash images without needing any LG software on your PC.

I used dd for windows and was able to merge all the files with the script that someone posted. Sorry on XDA App and can't see full thread but thanks for the script.
If you guys need help with testing let me know.
Sent from my LG-D800 using XDA Premium 4 mobile app

thecubed said:
Hello everybody!
This will be my first XDA-wide release of my new utility for all LG phones.
What is this?
This is a utility to extract the new format KDZ files that LG distributes, specifically the 'compressed' ones.
LG frequently distributes firmware for phones as KDZ files, which are essentially a firmware image of the eMMC and a DLL file that is used by the downloader utility to communicate with the phone.
In the past, there were utilities to extract KDZ files to a DLL file and a DZ file, but no further (at least to my knowledge).
This utility lets you break the KDZ file into it's respective partitions (aboot, rpm, tz, and so on)​
What good does this do me?
If you're an phone modder, haxxor, or just an enthusiast that has access to their phone's KDZ file and would like to have a copy of the actual partitions stored within, this will let you.
As an example, firmware for the new LG G2 on many device models is distributed as a KDZ file only.
Other phones use a TOT file, which is essentially a disk image of the eMMC with no compression.
If someone with a KDZ firmware-only phone wiped a partition (for example, modem) and wanted to get it back without flashing the whole phone all over again, they would be stuck.
TOT files are easily extractable, as there is software available currently for that but until today there was none (to my knowledge) for these new KDZ files.​
How do I use this?
Glad you asked.
Inside the ZIP file you'll see two Python scripts, KDZFileTools.py and DZFileTools.py.
There's also a README.txt file for more in-depth information if you're curious.
Both scripts respond to --help or -h, so if you're even more curious, try that too!
KDZ files contain DZ files and DLL files, so the first step will be to split those into their respective parts:
LAS_V08d_pre3_00.kdz is the name of the KDZ file that I've copied to the working directory for this example.
Code:
# python KDZFileTools.py -l -f LAS_V08d_pre3_00.kdz
[+] KDZ Partition List
=========================================
0 : LAS_V08d_pre3_00.dz (1428092632 bytes)
1 : LGUP_8974.dll (1477632 bytes)
This shows me that there are two files inside the KDZ file: LAS_V08d_pre3_00.dz and LGUP_8974.dll
You can now extract them by ID by using the -s option, or by using -x to extract all of the files.
Code:
# python KDZFileTools.py -f LAS_V08d_pre3_00.kdz -x
[+] Extracting all partitions!
[+] Extracting LAS_V08d_pre3_00.dz to kdzextracted\LAS_V08d_pre3_00.dz
[+] Extracting LGUP_8974.dll to kdzextracted\LGUP_8974.dll
Now you'll see a folder called "kdzextracted" in your current working directory, which will contain the extracted files.
The next step would be to extract the DZ file to get the partitions it contains:
Code:
# python DZFileTools.py -f kdzextracted/LAS_V08d_pre3_00.dz -l
[+] DZ Partition List
=========================================
0 : PrimaryGPT_0.bin (4299 bytes)
1 : modem_32768.bin (25719664 bytes)
2 : sbl1_163840.bin (179443 bytes)
3 : dbi_165888.bin (10505 bytes)
4 : aboot_229376.bin (288082 bytes)
5 : rpm_231424.bin (93084 bytes)
6 : boot_262144.bin (8959565 bytes)
7 : tz_294912.bin (149388 bytes)
8 : persist_393216.bin (23621 bytes)
9 : recovery_458752.bin (10454494 bytes)
10 : laf_622592.bin (14244284 bytes)
11 : system_7176192.bin (66791740 bytes)
12 : system_7438336.bin (2651 bytes)
13 : system_7440008.bin (2313 bytes)
14 : system_7444120.bin (103727934 bytes)
15 : system_7704592.bin (114239263 bytes)
16 : system_7964296.bin (2313 bytes)
17 : system_7968408.bin (103349001 bytes)
18 : system_8228880.bin (121921125 bytes)
19 : system_8488584.bin (2313 bytes)
20 : system_8492696.bin (101078725 bytes)
21 : system_8753168.bin (125454806 bytes)
22 : system_9012872.bin (2313 bytes)
23 : system_9016984.bin (105806605 bytes)
24 : system_9277456.bin (115830981 bytes)
25 : system_9537160.bin (2313 bytes)
26 : system_9541272.bin (108458465 bytes)
27 : system_9801744.bin (83280847 bytes)
28 : system_10063888.bin (67940827 bytes)
29 : system_10326032.bin (91997923 bytes)
30 : system_10588176.bin (58015487 bytes)
31 : system_10846208.bin (2314 bytes)
32 : system_11108352.bin (2314 bytes)
33 : system_11370496.bin (2314 bytes)
34 : system_11632640.bin (2314 bytes)
35 : system_11894784.bin (2314 bytes)
36 : system_12156928.bin (2314 bytes)
37 : system_12419072.bin (2314 bytes)
38 : system_12681216.bin (2314 bytes)
39 : system_12943360.bin (2314 bytes)
40 : system_13205504.bin (2314 bytes)
41 : system_13467648.bin (2314 bytes)
42 : system_13729792.bin (2652 bytes)
43 : system_13731464.bin (2314 bytes)
44 : BackupGPT_61070336.bin (4286 bytes)
Excellent! All the files are there!
Large images are split up by LG, and can be combined with "cat" or something like that.
The filename actually is in the form "partname_offset.bin" where "offset" is the actual location that the file should be written to on the phone's eMMC (handy!)
You can substitute -l in the options for -x again to extract all the partitions to the folder "dzextracted" in the current working directory as well.
The option --out or -o will change the output directory, so it doesn't have to output to {kdz|dz}extracted​
Where can I download this?
Code:
[URL="http://downloads.codefi.re/thecubed/androidtools/Compressed_KDZUtils.zip"]http://downloads.codefi.re/thecubed/androidtools/Compressed_KDZUtils.zip[/URL]
Please don't mirror this file, as having it in one location makes it easy for me to keep it up to date, or pull it if there are problems with this script​
It doesn't work? Can you help me?!
Sure, join #lg-g2 on Freenode and ask for IOMonster and I'll try to help out as best I can.
I will not answer questions in PM or via email, please don't PM me about this script!
As usual, if this script eats your dog/cat/uncle please don't blame me either. I didn't mean to do it, I swear!​
Whoo! Thanks! It works! How can I say thanks?
"Thanking" this thread is great!
If you feel that I absolutely saved you many hours of time, feel free to click on the "Donate to Me" button next to my username in this post.
This project was funded by a boring day at work and lots of caffiene ​
Alright guys, let me know if you've got any questions and I'll see what I can do!
Click to expand...
Click to collapse
Hi, i make my phone soft bricked. no other method works. i need bin file to flash my phone.i have the orignal kdz file.how can i make a single bin file to flash it using LGNPST? If you want to read my whole phone bricking story, please follow this
http://forum.xda-developers.com/showthread.php?t=2492105

AAAAwesome!!!
Thank you very much!
Able to customize LG's ROM easier than ever!

thecubed said:
I'm working on a modified version of the DZFileUtils.py script, since the DZ file actually contains the proper information to regenerate the full system.img easier than using DD or a hex editor.
Work has been a little crazy for the past few days, so I may not get a chance to work on the script until next week, but it won't be that hard to have this script put the system.img files back together.
I could modify the whole toolsets to do in-place extraction from a KDZ file (skipping the intermediate DZ file) but for now this is the easiest and accomplishes my goal the fastest (which is to allow extraction of bootloader stacks from KDZ files found on the interwebs)
I have no plans on creating a utility to generate KDZ files, since myself and @Shelnutt2 are in the process of writing a utility to flash images without needing any LG software on your PC.
Click to expand...
Click to collapse
Any word on the DZfileUtils.py script? I am trying to convert the dz to the system img and all I get is errors when trying to use dd. If there is a better way than dd for windows could someone let me know.
Well I think I have found where my error was at with what I was trying to do.
Thank you for all your hard work on this

honentan said:
I merged system.img using script as you mentioned, but it couldn't be mounted also.
Progress was obtained, I got all files in system.img using ext2explore(version2.1).
ext2explore log:
Partition Table Error on D:/Android-ROM/980VS/system.img
Invalid End of sector markerBlock size 4096, inp 8064, inodesize 256
Linux Partition found on disk 1 partition 0
Inode 727 with file size 0
Click to expand...
Click to collapse
I can confirm I could not mount or use normal methods I have used in the past for getting the system image extracted but I also used ext2explore on windows and it worked like a charm. Thank you

Thanks for tools:good:
but I got this error when I tried with KDZ file.
C:\Users\VM\Desktop\Compressed_KDZUtils>KDZFileTools.py -f L01E20A_00.kdz -x
[!] Error: Unsupported KDZ file format.
[ ] Expected: 0x28 0x5 0x0 0x0 0x34 0x31 0x25 0x80 ,
but received 0x31 0x23 0x53 0x7f 0x89 0x1e 0xe6 0x9b .
Click to expand...
Click to collapse
and when I got DZ file from other KDZ extracter and tried DZ file I got this
C:\Users\VM\Desktop\Compressed_KDZUtils>DZFileTools.py -f L01E20A_00.dz -l
[!] Error: Unsupported DZ file format.
[ ] Expected: 0x32 0x96 0x18 0x74 ,
but received 0x22 0x12 0x84 0x19 .
Traceback (most recent call last):
File "C:\Users\VM\Desktop\Compressed_KDZUtils\DZFileTools.py", line 212, in
<module>
dztools.main()
File "C:\Users\VM\Desktop\Compressed_KDZUtils\DZFileTools.py", line 196, in
main
self.openFile(args.dzfile)
File "C:\Users\VM\Desktop\Compressed_KDZUtils\DZFileTools.py", line 173, in
openFile
sys.exit(0)
NameError: global name 'sys' is not defined
Click to expand...
Click to collapse
I never run python script but I think I did it right.
I'm installed python 2.7. and KDZ file is for Optimus G

rquiett said:
I can confirm I could not mount or use normal methods I have used in the past for getting the system image extracted but I also used ext2explore on windows and it worked like a charm. Thank you
Click to expand...
Click to collapse
honentan said:
I merged system.img using script as you mentioned, but it couldn't be mounted also.
Progress was obtained, I got all files in system.img using ext2explore(version2.1).
Click to expand...
Click to collapse
in linux
Code:
mkdir -p /mnt/dsk
mount -o loop system.img /mnt/dsk
this will return an error
mount: wrong fs type, bad option, bad superblock on /dev/loop0,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so
Click to expand...
Click to collapse
run dmesg
Code:
dmesg | tail
there will be a line like this:
EXT4-fs (loop0): bad geometry: block count 851968 exceeds size of device (819537 blocks)
Click to expand...
Click to collapse
now truncate the file with the value of the first number
Code:
truncate -o -s 851968
remount, and hey presto.
thank you @Flinny for this
edit: not needed anymore, just ignore it. keeping it here for reference though

merging the bins on linux
ok, so there have been a few issues with getting this done on any platform. I was asked to try to get into a kdz for someone, so I did it
included below is a python script that takes advantage of dd. I've set it up for the system partition (as that's the only one that is split)
I have left all my comments and tweaks in so you can see how it was formed
to run:
Code:
python SystemMerger.py
It should run with python3 (untested). can someone please report any errors and I'll see if I can fix them up.
after running the script, just mount the image, and you're away
Happy Hacking
ps, don't forget to change the extension to .py

ok final version here, should support windows now
https://github.com/cybojenix/random-scripts/blob/master/SystemMerger.py
it should also support python3 still, but someone please check, same with windows (though I'm sceptical about the way I write zeros. might not work on winblows...)
anyway, happy hacking again

cybojenix said:
ok final version here, should support windows now
https://github.com/cybojenix/random-scripts/blob/master/SystemMerger.py
it should also support python3 still, but someone please check, same with windows (though I'm sceptical about the way I write zeros. might not work on winblows...)
anyway, happy hacking again
Click to expand...
Click to collapse
good job! awesome! thanks.

AndroidUser00110001 said:
Ha! Just what I was looking for but now to get it to work in Windows...
Thanks!
Edit
So I installed Python for Windows and this was the output...
C:\Python33>KDZFileTools.py -l -f F320K11D_00.kdz
File "C:\Python33\KDZFileTools.py", line 159
print "[!] Error: Unsupported KDZ file format."
^
SyntaxError: invalid syntax
C:\Python33>python.exe DZFileTools.py -l -f D80210C_00.kdz
File "DZFileTools.py", line 96
print "[!] Bad DZ sub header!"
^
SyntaxError: invalid syntax
C:\Python33>python.exe KDZFileTools.py -l -f D80210C_00.kdz
File "KDZFileTools.py", line 159
print "[!] Error: Unsupported KDZ file format."
^
SyntaxError: invalid syntax
Click to expand...
Click to collapse
just put bracket on each print params, then it should work
like this print ("[!] Error: Unsupported KDZ file format.")
also the KDZFileTools not work on LG G2, the header doesnt match with required
here
i debug to find what is the actual value on verify_header
D80210b.kdz header found
>>> verify_header
b'(\x05\x00\x0041%\x80'
kdz_header = '0x28 0x5 0x0 0x0 0x34 0x31 0x25 0x80'
KDZFileTools error log
[!] Error: Unsupported KDZ file format.
Traceback (most recent call last):
File "C:\Downloads\KDZFileTools.py", line 197, in <module>
kdztools.main()
File "C:\Downloads\KDZFileTools.py", line 182, in main
self.openFile(args.kdzfile)
File "C:\Downloads\KDZFileTools.py", line 160, in openFile
print ("[ ] Expected: %s ,\n\tbut received %s ." % (" ".join(hex(ord) for n in self.kdz_header), " ".join(hex(ord) for n in verify_header)))
File "C:\Downloads\KDZFileTools.py", line 160, in <genexpr>
print ("[ ] Expected: %s ,\n\tbut received %s ." % (" ".join(hex(ord) for n in self.kdz_header), " ".join(hex(ord) for n in verify_header)))
TypeError: ord() expected string of length 1, but int found
Click to expand...
Click to collapse

[Without PC] Unpack, Edit, Repack boot.img

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

[Q] Update of ZTE Nubia Z5s Mini nx406e

zte nubia z5s mini nx406e - version android 4.4.4
Greetings, could someone guide me ?
I want to be able to update this device,
to an android version a little more current,
if I have a copy of the system made with twrp recovery,
starting from there, how can I extract everything to be able to develop.
I know that everything that is needed is within the system itself,
I would appreciate any guidance.
Please do not block what I write again, like the one here
I just tried to explain myself in a way that they could understand me better, excuse my bad english.

Procedure performed to extract .img
adb version: Android Debug Bridge version 1.0.32 - > files used: googledrivers
adb>adb devices
List of devices attached
0123456789 device
previously rooted device -> with this version of the super su -> files here SuperSu
adb shell
[email protected]:/ $ su
[email protected]:/ # cat /proc/partitions
major minor #blocks name
179 9 12288 mmcblk0p9 -> boot
179 24 1280000 mmcblk0p24 -> system
[email protected]:/ # cat /dev/block/mmcblk0p9 > /sdcard/boot_pull.img
[email protected]:/ # cat /dev/block/mmcblk0p24 > /sdcard/system_pull.img
[email protected]:/ # exit
[email protected]:/ $ exit
adb>adb pull /sdcard/system_pull.img stock_system.img
2773 KB/s (1310720000 bytes in 461.535s)
img to download from here: stock_system.img
adb>adb pull /sdcard/boot_pull.img stock_boot.img
2792 KB/s (12582912 bytes in 4.400s)
img to download from here: stock_boot.img

Procedure to extract kernel
1.- Download the tool: android bootimg tools
2.- Extract the file using: tar xvzf android_bootimg_tools.tar.gz
It contains two binaries:
unpackbootimg
mkbootimg
3.-Then run: ./unpackbootimg -i boot.img -o unpack
./unpackbootimg -i <filename.img> -o <output_path>
It will contain:
boot.img-base
boot.img-cmdline
boot.img-pagesize
boot.img-ramdisk.gz ----> ramdisk
boot.img-zImage ----> kernel
archive: boot-img-zImage
to extract: boot.img-ramdisk.gz
use command: gunzip -c boot.img-ramdisk.gz | cpio -i
I'm looking at how to extract kernel sources from: boot.img-zImage