Database Info

How to extract contents of *.img (boot/recovery/system/userdata) for adp1 on host

Hi,
After downloading the official image with android-1.5 (also known as
signed-dream_devphone_userdebug-img-150275.zip) for adp1 from the link
(http://www.htc.com/www/support/android/adp.html#s3) provided by HTC
and unzipping the image into someplace you want in the terminal, and
then four files with the same extension of .img will be got, as shown
below.
boot.img
recovery.img
system.img
userdata.img
Here's a discussion mainly focused on how to extract these contents of
the last two images for adp1 on host.
With respect to how to extract these contents of the first two images
for adp1 on host, please refer to the following link. Meanwhile,
thanks for the community efforts as well!!
http://forum.xda-developers.com/showthread.php?t=443994
http://android-dls.com/wiki/index.php?title=HOWTO:_Unpack,_Edit,_....
1> system.img
==> the unyaffs2 tool is used to extract the contents from system.img
on host.
For the tool, you can access its source code with the license of GPLv3
located at the link (http://code.google.com/p/unyaffs/) and download
the source code and its binary.
2> userdata.img
While using the aforementioned tool extracting these contents of
userdata.img, the contents fail to be got on host and just a message
of "end of image" is shown up in the terminal, as follows.
$ chmod a+x unyaffs
$ unyaffs userdata.img
end of image
So, the problem to be asked is about how to extract contents of
userdata.img for adp1 on host!!
Any input will be greatly appreciated!!

for the official rom, userdata should be empty isn't it?

You could flash userdata and then boot into recovery, mount data, and adb pull /data.
I'm also interested in extracting boot and recovery images, so any hints please post here

First off, thanks for your reply, billc.
As regards the issuse that if the image of userdata.img is empty, the two methods are taken, as follows. (so sorry that the below is too long. )
1. checking that with bash command in the terminal
$ ls -lh
total 57M
-rw-r--r-- 1 samuel samuel 1.6M 2009-01-01 00:00 boot.img
-rw-r--r-- 1 samuel samuel 1.8M 2009-01-01 00:00 recovery.img
-rw-r--r-- 1 samuel samuel 54M 2009-01-01 00:00 system.img
-rw------- 1 samuel samuel 2.1K 2009-07-02 08:23 userdata.img
With the first scenario, the size of "userdata.img" is shown as "2.1K", which seems to indicate that the image of "userdata.img" isn't empty, instead of with the size.
2. checing that with programs (unyaffs.c[1]/unyaff.h[2]) for the tool of "unyaffs"
[1]http://unyaffs.googlecode.com/files/unyaffs.c
[2]http://unyaffs.googlecode.com/files/unyaffs.h
(NOTE: the instruction of complicatioin is "gcc -o unyaffs unyaffs.c" with the version 4.2.4 of gcc)
After compiling, the executable tool is got in your directory, also known as "unyaffs". And then, type the instruction with the terminal below.
$ unyaffs userdata.img
end of image
Unfortunately, there is nothing out there after extracting contents of "userdata.img" with the size of "2.1K"(-the length really includes what contents?). Only a message of "end of image" is shown up with the terminal.
To get more information about the message of "end of image, therefore, diving into the C file used to generate the tool of "unyaffs", getting the following connents. Meanwhile, please also pay more attention to the lines with the bold.
int read_chunk()
{
ssize_t s;
int ret = -1;
memset(chunk_data, 0xff, sizeof(chunk_data));
s = read(img_file, data, CHUNK_SIZE + SPARE_SIZE);
if (s == -1) {
perror("read image file\n");
} else if (s == 0) {
printf("end of image\n");
} else if ((s == (CHUNK_SIZE + SPARE_SIZE))) {
ret = 0;
} else {
fprintf(stderr, "broken image file\n");
}
return ret;
}
And then, indexing the function in the Linux Programmer's Mannual with the command of "man read" in the terminal to get more info, as shown below. In the meantime, please pay more attention to the lines with the bold as well.
$man read
...
...
NAME
read - read from a file descriptor
SYNOPSIS
#include <unistd.h>
ssize_t read(int fd, void *buf, size_t count);
DESCRIPTION
read() attempts to read up to count bytes from file descriptor fd into
the buffer starting at buf.
If count is zero, read() returns zero and has no other results. If
count is greater than SSIZE_MAX, the result is unspecified.
RETURN VALUE
On success, the number of bytes read is returned (zero indicates end of
file), and the file position is advanced by this number.
...
...
Just judging from the combination of the snippet of "unyaffs.c" and the mannual of "read" above, the conclusion below can be come to.
The real contents of "userdata.img" with the size of "2.1k" is exactly empty ending up with "end of file".
When compared the two conclusions as mentioned above, it's found that the both are just contrary, the former ISN'T empty while the latter IS empty.
So, there are a set of problems about the above confusion herein.
Q1: What contents exactly does the "userdata.img" with the size of "2.1k" mean?
Q2: What contents and from which position does the function of "read" read in the file? In the case of "userdata.img", what are"what contents" and "from which position" respectively?
Q3: According to the above two scenarios, what steps to take are to judge if the file is really empty?
Looking forward to your replies, thanks!!

to jubeh,
As to extracting the images of boot and recovery from adp1/g1, you can refer to the following links. hope that that's helpful.
http://forum.xda-developers.com/showthread.php?t=443994
http://android-dls.com/wiki/index.php?title=HOWTO:_Unpack,_Edit,_and_Re-Pack_Boot_Images

[TOOL] rkflashtool for Linux and rk2808, rk2818 and rk2918 based tablets

Hi,
Because I don't run Windows nor NetBSD, I rewrote rkflash from scratch with the use of libusb-1.0, so you can now read and write your rk2818-based tablet's flash memory under Linux (also w/o the need to root your tablet). Credit for reverse-engineering the protocol goes to the original author of rkflash (see source).
Small guide
- unzip the file
- compile
Linux (Debian, Ubuntu, ...)
Code:
sudo apt-get install libusb-1.0-0-dev
gcc -o rkflashtool rkflashtool.c -lusb-1.0 -O2 -W -Wall -s
Mac OS X (thanks to surfer63, binary here)
Code:
sudo port install libusb
gcc -I/opt/local/include -I/opt/local/include/libusb-1.0 \
-L/opt/local/lib -o rkflashtool rkflashtool.c -lusb-1.0 -O2 -W -Wall
Preparation
- powerdown your tablet
- disconnect all cables
To get into flash mode differs for many tablets. Google around or use trial and error
- insert the USB cable in computer
- hold vol+ (or put on/off/locked-switch in the locked position)
- insert the other end of your cable in the tablet
- wait a few seconds
- release vol+
Now if you run lsusb, the following line should appear:
Bus 001 Device 044: ID 2207:281a (290a for rk2918 based tablets)
Bus and device number may be different. The screen of your tablet stays black.
The USB device must be readable and writable for the user running rkflashtool. If that's not the case, you'll see an error like this:
Code:
$ ./rkflashtool b
libusb couldn't open USB device /dev/bus/usb/001/048: Permission denied.
libusb requires write access to USB device nodes.
rkflashtool: fatal: cannot open device
This can be fixed in several ways (chmod, run as root, udev rules) but that's beyond the scope of this posting. For now, chmod 666 the device mentioned in the error message.
Usage of rkflashtool
Code:
$ ./rkflashtool
rkflashtool: fatal: usage:
rkflashtool b reboot device
rkflashtool r offset size >file read flash
rkflashtool w offset size <file write flash
offset and size are in units of 512 bytes
On my tablet, the boot partition starts at offset 0x8000 (in blocks of 512 bytes)
Its size is 0x2000 blocks
To backup the partition, issue:
Code:
$ ./rkflashtool r 0x8000 0x2000 >boot.img.backup
rkflashtool: info: interface claimed
rkflashtool: info: reading flash memory at offset 0x00008000
rkflashtool: info: reading flash memory at offset 0x00008020
.......
rkflashtool: info: reading flash memory at offset 0x00009fe0
To write a new boot.img or an old backup back to the device:
Code:
$ ./rkflashtool w 0x8000 0x2000 <boot.img.backup
rkflashtool: info: interface claimed
rkflashtool: info: writing flash memory at offset 0x00008000
rkflashtool: info: writing flash memory at offset 0x00008020
.......
rkflashtool: info: writing flash memory at offset 0x00009fe0
You can find a list of all partitions of your tablet in the HWDEF file, which is inside the update.img for your tablet. If no such file is available, you can also look at /proc/cmdline on a running device (either through adb or a terminal app running on the device itself). Depending on the tablet, you might need root access to view /proc/cmdline. Another option is dumping the first 0x2000 blocks of nand flash by issuing rkflashtool r 0x0000 0x2000 >parm. View the file with hexedit, xxd, or a similar program. The kernel parameters contain a description of several mtd partitions (sizes and offsets).
After reading and writing at will, you can reboot your tablet by issuing
./rkflashtool b
Note that if your tablet has an on/off/locked-switch and it is still in the locked position, rebooting won't work.
If the file you are writing is smaller than the specified size, the rest is padded with zeroes. If it's bigger, it will be truncated. This is different from rkflash, which will overwrite blocks beyond the partition size.
rkflashtool does not support flashing a new bootloader directly.
If you have a different tablet, please try rkflashtool b and r first before flashing (w) something new.
Standard DISCLAIMER with regard to bricking your tablet applies.
Enjoy!
EDIT: better build instructions, clean up text
EDIT2: works on rk2918 tablets too (tested on Arnova 7 G2) if you change the USB product id from 0x281a to 0x290a before compilation
EDIT3: released version 2 of rkflashtool. now supports rk2918 tablets out of the box. if it doesn't find one, it falls back to rk2808/rk2818. also, updated the wording a bit.
EDIT4: new mac osx binary
EDIT5: more ways to find offsets and sizes of partitions on your tablet
EDIT6: small emphasis changes above and...
version 1 is here ONLY for archival purposes or if version 2 does not work on your rk28xx tablet. In all other cases, you need to download rkflashtool-v2.zip

Thanks a lot for this flash tool. I'm on MacOSX and Ubuntu and don't have Windows either. I tried the original rkflash as well but couldn't get it to work. On my Ubuntu boxes your rkflashtool compiles and works fine.
My Archos 7 HT V2 presents itself also as:
Code:
Bus 002 Device 004: ID 2207:281a
Reading partitions works fine and so does writing.
I did a quick modification of a system.img (left some files out) of my custom froyo rom and wrote it to my tablet.
That works fine. As /data is a separate partition I even have all my downloaded apps, data, settings, etc. This makes modifying a new rom much faster then building a complete update.img, flashing it, restore some data and then start testing.
Nice work.

great! finally I can remove one line from my todo list
thank you!
EDIT:
random notes (I don't see your code yet so it may be fixed, then sorry)
* I always specify b(reboot) for rk2818 tablets with my rkflash because it hanged easily if I try to write multiple times without b
* parameter file need to be converted with rkcrc -p. official RKAndroid tools flashed it 5 times with offsets. (read & check 1st 0x0-0x2000 block)
* I logged how to update bootloader, but it's complicated and I could not understand probably bootloader can be updated via misc partition. see update-script in update.img. (but not recommended/no reason to do it)
EDIT2:
there is libusb for Windows and OS X. rkflashtool may work on them.
on Windows, there is RKAndroidTool.exe (not batchupgrade). but "read" function in rkflash/rkflashtool may be useful on some case on Windows

Good to hear it works for others, too! I have not had a hanging tablet after several writes in one session, but this might depend on the tablet.
Thanks for mentioning that it should also work on other platforms supported by libusb. I'd forgotten to do that.
About using update.img to flash a new bootloader, this can be done, but if you brick the tablet by flashing a wrong/faulty bootloader, you can only unbrick it with the Windows tools
Which leads me to the question: could you send me the snooped log of updating the bootloader? Two people see more than one and perhaps we can eventually manage to do this through libusb too.

ivop said:
About using update.img to flash a new bootloader, this can be done, but if you brick the tablet by flashing a wrong/faulty bootloader, you can only unbrick it with the Windows tools
Click to expand...
Click to collapse
probably you also need a needle to short pins of NAND chip
so I don't recommend to flash bootloader
ivop said:
Which leads me to the question: could you send me the snooped log of updating the bootloader? Two people see more than one and perhaps we can eventually manage to do this through libusb too.
Click to expand...
Click to collapse
I made that log several months ago with another windows machine which is not used lately. I'm not sure log is still exist... if I find it, I'll send it to you (but please don't expect)
probably you may also get log on Windows on VM on Linux. it seems VMware has log function (refer http://vusb-analyzer.sourceforge.net/tutorial.html) or there is "usbmon" function in Linux.
actually I didn't try this way myself so it may be wrong, sorry.

I've tryed a couple of firmwares, cooking my own.
Every time after flashing, tablet shows boot animation and after few seconds display becomes dark.
My investigation led me to following:
Log shows:
Code:
ERROR/Lights(865): write_int failed to open /sys/class/backlight/rk28_button_light/brightness
in /sys/class/backlight I found symlink (rk28_bl):
rk28_bl -> ../../devices/platform/rk28_backlight/backlight/rk28_bl
Shouldn't be there another symlink named r28_button_light ?
I'm using MANTA MID001 from Poland.

fun_ said:
EDIT2:
there is libusb for Windows and OS X. rkflashtool may work on them.
Click to expand...
Click to collapse
ivop said:
Good to hear it works for others, too! I have not had a hanging tablet after several writes in one session, but this might depend on the tablet.
Click to expand...
Click to collapse
I did a couple of successive writes as well from ubuntu.
ivop said:
Thanks for mentioning that it should also work on other platforms supported by libusb. I'd forgotten to do that.
Click to expand...
Click to collapse
My main platform is OSX and I immediately added libusb. So far I have not been able to compile rkflashtool despite declaring all kind of CFLAGS, CXXFLAGS and/or LDFLAGS.
Trying a little bit more.

Could you post the compiler warnings/errors here? I might be able to help out.

ivop said:
Could you post the compiler warnings/errors here? I might be able to help out.
Click to expand...
Click to collapse
I managed to compile it. It took a lot of hurdles. I used the build environment I also use for Hugin for which I'm the OSX maintainer.
I now built a single combined 32/64bit (i386/x86_64) rkflashtool that will run on 10.4.x/10.5.x/10.6.x/10.7.x (building multi-architecture, multi-version binaries/libraries in one binary/library is possible on OSX. I'm not going to explain that here but it's a feature of OSX).
The compiled version is attached. You can also attach it to your first post if you like.
It works fine. I did some reading/writing of images without issues.

If you are on OSX and have macports installed, you can do the following to build rkflashtool.
Install libusb from Macports:
Code:
sudo port install libusb
cd into the folder where your rkflashtool.c is is and run the following command:
Code:
gcc -I/opt/local/include -I/opt/local/include/libusb-1.0 \
-L/opt/local/lib -o rkflashtool rkflashtool.c -lusb-1.0 -W -Wall
This will build rkflashtool for your native environment (OSX version, hardware and config).
--- removed the rest of the post as well as the attachments. He/She who is interested in building a complete universal distributable rkflashtool can ask via this thread ---

UPDATE: Works on rk2918 tablet too
Yesterday I have tested the tool on an Arnova 7 G2 tablet, which has an rk2918 CPU. If you change the ProductID before compilation, like this:
... libusb_open_device_with_vid_pid(c, 0x2207, 0x281a) ...
to
... libusb_open_device_with_vid_pid(c, 0x2207, 0x290a) ...
it'll work, except for rebooting the device if the tablet is still locked. To boot the tablet in bootloader mode, turn off the tablet completely, put the on/off-switch in the locked position and connect it to your computer. It should be visible now with lsusb. For further instructions, see first post. I advise dumping the first 0x2000 blocks at offset 0x0000 first as this contains the parameter block in which you can see where each partition starts and how big it is.

ivop said:
UPDATE: Works on rk2918 tablet too
Yesterday I have tested the tool on an Arnova 7 G2 tablet, which has an rk2918 CPU. If you change the ProductID before compilation, like this:
... libusb_open_device_with_vid_pid(c, 0x2207, 0x281a) ...
to
... libusb_open_device_with_vid_pid(c, 0x2207, 0x290a) ...
Click to expand...
Click to collapse
Feature request :
I's nice but could you also make it a startup option, like the b,r,w options, with an if-else option in the source code? Something like (RK)2818 and (RK)2918 and maybe even for the older ones: (RK)2808.
In that case you only need one binary. Users who are going to use the tool will definitely know what CPU they have.

surfer63 said:
Feature request :
I's nice but could you also make it a startup option, like the b,r,w options, with an if-else option in the source code? Something like (RK)2818 and (RK)2918 and maybe even for the older ones: (RK)2808.
In that case you only need one binary. Users who are going to use the tool will definitely know what CPU they have.
Click to expand...
Click to collapse
I released a new version and updated the first post. It now tries to connect to an rk2918 tablet and if it doesn't find one, it falls back to rk2818.

The V2 version works fine too on MacOSX. The compilation is still the same for a "my machine only" version.
I compiled a universal Intel 32bit/64bit 10.4/10.5/10.6/10.7 V2 version as well.
See attached.
Note: I don't have a RK2918 so I can only test for a RK2818 tablet.

Hi,
Thanks for your thread it's very intersting.
I succeed flashing my boot partition with your tool but I don't success in remount,rw my system partition. It's cramFS and in init.rk28board.rc you can see those line :
Code:
# Mount /system rw first to give the filesystem a chance to save a checkpoint
mount cramfs [email protected] /system
mount cramfs [email protected] /system ro remount
I tried everything like replacing ro by rw, deleting the second line but my system stills in ReadOnly, don't understand why. I also tried deleting those lines to test if my flash process works properly and it's worked... So I'm lost. Any idea ?
----
Other thing, if I want to do same as flashing boot partition but with system partition is it possible with the same process ? Unfortunately I don't know the beginning offset of the partition. I don't know where to find HWDEF file. The size of partition is 00038000 (hex) bytes => 229376 (dec) bytes
Here is my /proc/mtd :
Code:
dev: size erasesize name
mtd0: 00002000 00000010 "misc"
mtd1: 00004000 00000010 "kernel"
mtd2: 00002000 00000010 "boot"
mtd3: 00004000 00000010 "recovery"
mtd4: 00038000 00000010 "system"
mtd5: 0003a000 00000010 "backup"
mtd6: 0003a000 00000010 "cache"
mtd7: 00080000 00000010 "userdata"
mtd8: 00534000 00000010 "user"
mtd9: 00020000 00000010 "pagecache"
mtd10: 00020000 00000010 "swap"
Thank you for your great job

My problem is solved. I was searching for a while but ivop gave the answer in a previous post
I advise dumping the first 0x2000 blocks at offset 0x0000 first as this contains the parameter block in which you can see where each partition starts and how big it is.
Click to expand...
Click to collapse
So I did it, after I opened an Hex Editor like GHex on Ubuntu and I can saw this :
Code:
[email protected](misc),
[email protected](kernel),
[email protected](boot),
[email protected](recovery),
[email protected](system),
[email protected](backup),
[email protected](cache),
[email protected](userdata),
[email protected](user)
So system partition starts at E000 and has a length of 38000 (hex) bytes.
Thanks for your help this thread is now in my bookmarks
And really nice job with this flashtool

I pushed latest my rkutils to https://github.com/naobsd/rkutils
rkunpack can unpack RKFW image used in RK2918 ROM, RKAF image (update.img), KRNL/PARM image used in some single partition image. unpack will be done recursively.
rkcrc can make KRNL/PARM images with -k/-p.
rkafpack can make RKAF image. (I need to write docs/howtos...)
little off-topic,
latest RK2918 ROMs which is based on "SDK2.0", new format for boot.img/recovery.img is introduced. it's almost same as common boot.img format for android. unpackbootimg/mkbootimg can be used to unpack/repack it with one exception...
there is SHA1 hash value in header of boot.img (offset 0x240 bytes). Rockchip changes it by some unknown way. normal mkbootimg can't generate same hash value as Rockchip, so we can't make custom boot.img with new format
fortunately, we can split new boot.img, and we can make separate kernel.img and boot.img(ramdisk) like as pre-SDK2.0 RK2918 ROMs, which is loadable with new bootloader in SDK2.0 ROMs.
--
btw I just found interesting one: https://github.com/jhonxie/rk2918_tools

relsyou said:
My problem is solved. I was searching for a while but ivop gave the answer in a previous post
So I did it, after I opened an Hex Editor like GHex on Ubuntu and I can saw this :
Code:
[email protected](misc),
[email protected](kernel),
[email protected](boot),
[email protected](recovery),
[email protected](system),
[email protected](backup),
[email protected](cache),
[email protected](userdata),
[email protected](user)
So system partition starts at E000 and has a length of 38000 (hex) bytes.
Thanks for your help this thread is now in my bookmarks
And really nice job with this flashtool
Click to expand...
Click to collapse
I'll add that to my first post. Also, you can view /proc/cmdline to see a list of partitions. It's part of the kernel command line.
Note that the lengths are not in bytes but in blocks of 512 bytes. This happens to be the same as the requirements of the rkflashtool btw (length in blocks).
As for having a writable system partition, currently the system partition is cramfs which cannot be written to. Ever. If you want a writable system partition, you need to change it to ext3 for example. That means unpacking fun_'s system.img and recreating it as an ext3 partition.
In short:
Unpack cramfs img with cramfsck -x (as root, so you preserve permissions and uid/gid)
Create an empty file the size of your system partition (dd if=/dev/null of=fubar.img bs=512 count=...... et cetera, do the math)
mkfs.ext3 fubar.img
mount -o loop fubar.img /someplacemountable
copy contents of old image to /someplacemountable (use cp -a to preserve ownership etc)
umount
flash fubar.img to system partition
change init.rk28board.rc to reflect the changes
reflash boot.img
reboot device
This is untested, but should work in theory.
Another option is to keep the system partition read-only and use unionfs to overlay a writable partition. I'm not sure if this can be a file on your userdata partition mounted with -o loop, but I suppose it can. This depends on your kernel having unionfs and loopback support though.

fun_ said:
I pushed latest my rkutils to https://github.com/naobsd/rkutils
Click to expand...
Click to collapse
Nice! I was thinking about creating an rkpack(tool ) myself, but I see it's not necessary anymore.

here is an example for rkafpack
Code:
$ rkunpack N3NET-2.3-20110722.img
[COLOR="Red"][B]FIRMWARE_VER:1.0.0[/B][/COLOR]
[COLOR="Red"][B]MACHINE_MODEL:rk2818sdk[/B][/COLOR]
MACHINE_ID:
[COLOR="Red"][B]MANUFACTURER:rock-chips[/B][/COLOR]
unpacking 12 files
-------------------------------------------------------------------------------
00000800-00000fff [COLOR="Red"][B]HWDEF:HWDEF[/B][/COLOR] 797 bytes
00001000-000017ff [COLOR="Red"][B]package-file:package-file[/B][/COLOR] 532 bytes
00001800-00021fff [COLOR="Red"][B]bootloader:RK28xxLoader(L).bin[/B][/COLOR] 131700 bytes
00022000-000227ff [COLOR="Red"][B]parameter:parameter:[email protected][/B][/COLOR] 506 bytes
00022800-0002e7ff [COLOR="Red"][B]misc:Image/misc.img:[email protected][/B][/COLOR] 49152 bytes
0002e800-0066bfff [COLOR="Red"][B]kernel:Image/kernel.img:[email protected][/B][/COLOR] 6541946 bytes
0066c000-006947ff [COLOR="Red"][B]boot:Image/boot.img:[email protected][/B][/COLOR] 163844 bytes
00694800-008e8fff [COLOR="Red"][B]recovery:Image/recovery.img:[email protected][/B][/COLOR] 2441220 bytes
008e9000-085fc7ff [COLOR="Red"][B]system:Image/system.img:[email protected][/B][/COLOR] 131149828 bytes
----------------- [COLOR="Red"][B]backup:SELF:[email protected][/B][/COLOR] (N3NET-2.3-20110722.img) 140498948 bytes
085fc800-085fcfff [COLOR="Red"][COLOR="Red"][B]update-script:update-script[/B][/COLOR][/COLOR] 1294 bytes
085fd000-085fd7ff [COLOR="Red"][B]recover-script:recover-script[/B][/COLOR] 266 bytes
-------------------------------------------------------------------------------
unpacked
$ rkafpack \
[COLOR="Red"][B]FIRMWARE_VER:1.0.0[/B][/COLOR] \
[COLOR="Red"][B]MACHINE_MODEL:rk2818sdk[/B][/COLOR] \
[COLOR="Red"][B]MANUFACTURER:rock-chips[/B][/COLOR] \
[COLOR="Red"][B]HWDEF:HWDEF[/B][/COLOR] \
[COLOR="Red"][B]package-file:package-file[/B][/COLOR] \
'[COLOR="Red"][B]bootloader:RK28xxLoader(L).bin[/B][/COLOR]' \
[COLOR="Red"][B]parameter:parameter:[email protected][/B][/COLOR] \
[COLOR="Red"][B]misc:Image/misc.img:[email protected][/B][/COLOR] \
[COLOR="Red"][B][B]kernel:Image/kernel.img:[email protected][/B][/B][/COLOR] \
[COLOR="Red"][B]boot:Image/boot.img:[email protected][/B][/COLOR] \
[COLOR="Red"][B]recovery:Image/recovery.img:[email protected][/B][/COLOR] \
[COLOR="Red"][B]system:Image/system.img:[email protected][/B][/COLOR] \
[COLOR="Red"][B]backup:SELF:[email protected][/B][/COLOR] \
[COLOR="Red"][B]update-script:update-script[/B][/COLOR] \
[COLOR="Red"][B]recover-script:recover-script[/B][/COLOR] \
> new.img
$ sha1sum N3NET-2.3-20110722.img new.img
e758a6c47dca7f09f0b8a82ad89b0cd7c7c8e826 N3NET-2.3-20110722.img
e758a6c47dca7f09f0b8a82ad89b0cd7c7c8e826 new.img
some values are empty in RK2818 ROM.
--
here is how to make RKFW image
Code:
$ rkunpack N50-2.3-20111103-ZZ-SDK2.0.img
VERSION:2.0.3
unpacking
00000000-00000065 N50-2.3-20111103-ZZ-SDK2.0.img-HEAD 102 bytes
00000066-00022623 N50-2.3-20111103-ZZ-SDK2.0.img-BOOT 140734 bytes
00022624-0c342627 update.img 204603396 bytes
unpacking update.img
================================================================================
FIRMWARE_VER:0.2.3
MACHINE_MODEL:rk29sdk
MACHINE_ID:007
MANUFACTURER:RK29SDK
unpacking 10 files
-------------------------------------------------------------------------------
00000800-00000fff package-file:package-file 540 bytes
00001000-000237ff bootloader:RK29xxLoader(L)_V2.08.bin 140734 bytes
00023800-00023fff parameter:parameter:[email protected] 610 bytes
00024000-0002ffff misc:Image/misc.img:[email protected] 49152 bytes
00030000-006a3fff boot:Image/boot.img:[email protected] 6766592 bytes
006a4000-01167fff recovery:Image/recovery.img:[email protected] 11288576 bytes
01168000-0c31efff system:Image/system.img:[email protected] 186346496 bytes
----------------- backup:SELF:[email protected] (update.img) 204603396 bytes
0c31f000-0c31f7ff update-script:update-script 933 bytes
0c31f800-0c31ffff recover-script:recover-script 266 bytes
-------------------------------------------------------------------------------
================================================================================
00022624-0c342627 N50-2.3-20111103-ZZ-SDK2.0.img-MD5 32 bytes
unpacked
$ cat N50-2.3-20111103-ZZ-SDK2.0.img-HEAD N50-2.3-20111103-ZZ-SDK2.0.img-BOOT update.img > new.img
$ md5sum new.img
[COLOR="Red"][B]5191abc65649eacf8d2476e37d84a046[/B][/COLOR] new.img
$ cat N50-2.3-20111103-ZZ-SDK2.0.img-MD5
5191abc65649eacf8d2476e37d84a046
$ echo -n [COLOR="Red"][B]5191abc65649eacf8d2476e37d84a046[/B][/COLOR] >> new.img
$ sha1sum N50-2.3-20111103-ZZ-SDK2.0.img new.img
3120b13df8886e0ddfae0e35379443c27c925572 N50-2.3-20111103-ZZ-SDK2.0.img
3120b13df8886e0ddfae0e35379443c27c925572 new.img

[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

[Q] Need help to resolve compile error CM-11.0

I am trying to build cm11 for the nabi big tab 20" I have already made a working TWRP for it and have it rooted I am coming across an error at the end of the compile that I have no idea to get around any insight would be much appreciated.
Traceback (most recent call last):
File "./build/tools/releasetools/ota_from_target_files", line 1132, in <module>
main(sys.argv[1:])
File "./build/tools/releasetools/ota_from_target_files", line 1100, in main
WriteFullOTAPackage(input_zip, output_zip)
File "./build/tools/releasetools/ota_from_target_files", line 543, in WriteFullOTAPackage
MakeRecoveryPatch(OPTIONS.input_tmp, output_zip, recovery_img, boot_img)
File "./build/tools/releasetools/ota_from_target_files", line 409, in MakeRecoveryPatch
boot_type, boot_device = common.GetTypeAndDevice("/boot", OPTIONS.info_dict)
TypeError: 'NoneType' object is not iterable
make: *** [/home/lmortal/android/out/target/product/dmtabnv20a/cm_dmtabnv20a-ota-3f1aec2841.zip] Error 1

Was able to get around the above error by adding "TARGET_NO_SEPARATE_RECOVERY := true" to the BoardConfig.mk.
but now I am getting a new error, have seen it mentioned a few times but haven't found any solutions to it as of yet.
Traceback (most recent call last):
File "./build/tools/releasetools/ota_from_target_files", line 1157, in <module>
main(sys.argv[1:])
File "./build/tools/releasetools/ota_from_target_files", line 1125, in main
WriteFullOTAPackage(input_zip, output_zip)
File "./build/tools/releasetools/ota_from_target_files", line 570, in WriteFullOTAPackage
common.CheckSize(boot_img.data, "boot.img", OPTIONS.info_dict)
File "/home/lmortal/android/build/tools/releasetools/common.py", line 511, in CheckSize
if not fs_type or not limit: return
UnboundLocalError: local variable 'fs_type' referenced before assignment
make: *** [/home/lmortal/android/out/target/product/dmtabnv20a/cm_dmtabnv20a-ota-155a6e9ebd.zip] Error 1

It is my understanding that the common.py is looking for a variable for boot.img fs_type but I have no idea where I need to put this variable. If some one could point me in the right direction I would appreciate it.

lmortal said:
Was able to get around the above error by adding "TARGET_NO_SEPARATE_RECOVERY := true" to the BoardConfig.mk.
but now I am getting a new error, have seen it mentioned a few times but haven't found any solutions to it as of yet.
Traceback (most recent call last):
File "./build/tools/releasetools/ota_from_target_files", line 1157, in <module>
main(sys.argv[1:])
File "./build/tools/releasetools/ota_from_target_files", line 1125, in main
WriteFullOTAPackage(input_zip, output_zip)
File "./build/tools/releasetools/ota_from_target_files", line 570, in WriteFullOTAPackage
common.CheckSize(boot_img.data, "boot.img", OPTIONS.info_dict)
File "/home/lmortal/android/build/tools/releasetools/common.py", line 511, in CheckSize
if not fs_type or not limit: return
UnboundLocalError: local variable 'fs_type' referenced before assignment
make: *** [/home/lmortal/android/out/target/product/dmtabnv20a/cm_dmtabnv20a-ota-155a6e9ebd.zip] Error 1
Click to expand...
Click to collapse
Just in case any one else runs accross this error it turns out it was due to incompatible recovery.fstab format.

lmortal said:
Just in case any one else runs accross this error it turns out it was due to incompatible recovery.fstab format.
Click to expand...
Click to collapse
i get the error . what should i do ?
thank you

vulture BIAN said:
i get the error . what should i do ?
thank you
Click to expand...
Click to collapse
If your issue is what his was, read up on the difference between fstab version 1 and 2 formatting differences.

aicjofs said:
If your issue is what his was, read up on the difference between fstab version 1 and 2 formatting differences.
Click to expand...
Click to collapse
i dont know. but i delete target no ****** recvery+ture .it is ok.
But my phone dont open. i think it is kernel source's problem.
i try again and again. but i am loser.
---------- Post added at 02:40 AM ---------- Previous post was at 02:37 AM ----------
vulture BIAN said:
i dont know. but i delete TARGET_NO_SEPARATE_RECOVERY := true it's ok
But my phone dont open. i think it is kernel source's problem.
i try again and again. but i am loser.
Click to expand...
Click to collapse
sorry. Some words wrong

My experience getting my H918 rooted and debloated

I'm a novice enthusiast when it comes to phones. When my wife needed a replacement phone after hers started to fail (I blame repeated gravity-related incidents, but she insists that's not it), I decided to see if I could transform my old V20 into a "new" V20 for her. I didn't know what was to come, but I was going to do it!
This can also serve as a pseudo-guide for other novices, and something to laugh at for those more experienced as I list all the steps I took, and all the mistakes I made through the process. If you are going to use this as a guide, make sure you read it completely before starting! I've made mistakes, and I list them here, but don't repeat them!
Big list of files​
Stuff for Linux live environment:
Etcherv1.7.9 https://github.com/balena-io/etcher/releases
steadfasterX's FWUL/mAid_v4.0-RC3_x86_64.iso https://leech.binbash.rocks:8008/mAid/
Stuff for Windows:
Android SDK Platform Tools (adb and fastboot) https://developer.android.com/studio/releases/platform-tools#downloads
LGMobileDriver_WHQL_Ver_4.8.0.exe http://tool.lime.gdms.lge.com/dn/downloader.dev?fileKey=UW00120120425
LGUP_Store_Frame_Ver_1_14_3.msi http://downloads.codefi.re/autoprime/LG/Flash_Tools/LGUP/
LGUP_Common_DLL_Ver_1_0_40_2.msi https://drive.google.com/uc?id=1MQ7u7ghlNNzjAgVkCpCmswdtZjeB3l6p&export=download&confirm=t
CXZa's utilities https://forum.xda-developers.com/t/lg-tools-lg-kdz-dll-tool-lgup_ui-fixer-lg-kdz-downloader.3916444/
Files you'll want on your external SD card:
H91810p_00_0717.kdz https://forum.xda-developers.com/t/...-and-including-20h-now-n00b-friendly.3773443/
Phoenix591's h918-20g-prerooted.zip https://forum.xda-developers.com/t/...-20g-20h-oreo-flashable.3848854/post-77987795
topjohnwu's Magisk-v23.0.zip (renamed from .apk) https://github.com/topjohnwu/Magisk/releases/tag/v23.0
TeamWin's twrp-3.6.1_9-0-h918.img https://dl.twrp.me/h918/
rootchecker apk https://apkpure.com/p/com.joeykrim.rootcheck
(optional but highly recommended) Darnrain1's Auto_Debloat v7.4 https://forum.xda-developers.com/t/...hones-volte-and-wifi-calling-working.4432865/
(optional) F-droid apk https://f-droid.org
(optional) laf_restore.zip https://forum.xda-developers.com/t/laf-restore-zip-file.4398879/
(optional) Phoenix591's encrypt-v3.zip https://forum.xda-developers.com/t/recovery-unofficial-twrp-3-3-1-1-2019-10-25.3720239/
Credits:
@topjohnwu for Magisk
@Phoenix591 for 20g in zip format and TWRP
@npjohnson for TWRP
@CXZa for their awesome LG utilities
@runningnak3d for the core of the project: lafsploit
@75th for updated method of using lafsploit
@steadfasterX for their amazing FWUL/mAid and SALT
@me2151 for their original root exploit Dirty Santa
@demasta123 for finding and sharing laf_restore.zip
@Darnrain1 for the excellent debloat script
What I did:
Flashed mAid_v4.0-RC3_x86_64.iso to my thumbdrive via Etcher.
Put the thumbdrive into my little Lenovo laptop and booted (had to reboot cause the bootloader menu was super brief), and selected "Search for GRUB2 configuration on external media"
Logged in (password is 'linux')
Connected to WiFi
Started V20 in download mode (VOLUP+USB)
Opened SALT and under Advanced found that none of my partitions were displayed (which I expected because the V20 has Universal Flash Storage).
In SALT there's three buttons on the bottom. The leftmost one allowed me to change all the ummm sources? builds? to 'develop' and then I restarted SALT. Now I can see the partitions!
Clicked the backup option and selected Custom. All the partitions appeared to be selected, but I can't see the whole window because it doesn't allow itself to be resized smaller than a certain point which was too large for my little laptop screen. Since it appeared that all the partitions were checkmarked, I tapped Enter and it prompted me for a location to save the 60GB(!) backup.
I opened the file browser and I found the laptop's internal hard drive listed as '158 GB Volume'. Clicking it prompted for a password so I tried 'linux' and it worked! I created a directory at /home/user/Documents/H918, then copied the very cryptic path from the address bar of the file browser over to SALT and started the backup.
I babysat the laptop so it would not fall asleep or w/e just in case that would ruin the backup.
It hung during the backup (possibly because I was looking for a way to change the mouse senstivity and the screen timeout) so I had to forcibly power off the laptop and reboot into FWUL/mAid. I had to remove the battery from the phone to get it out of download mode. I did everything as before but this time I am only backing up the userdata partition as it is by far the largest, and I am touching NOTHING during the process other than the occasional mouse jiggle. If/When that's done I'll backup everything else. I very much doubt I need the userdata but better safe than sorry. The speed is slow; less than 1GB/minute.
Hung again, and I discovered that my poor little laptop was super hot, so I think that my laptop's cooling has failed, or for some reason it doesn't engage in FWUL/mAid. I'll need to either find a cooling solution, or more likely use my big desktop for this.
I used my desktop to do this, and was able to extract all the partitions as .img files. I also captured my device info and saved it to the PC as well. I was going to do the rest of the steps right from FWUL/mAid but outside of SALT, I couldn't get anything to work. I think it was missing Java because nothing was listed for echo $JAVA_HOME and the ADB tool would not launch. I'll just do the rest from Windows.
Back in Windows I tried compressing the images with 7zip but it was being a resource hog so I'll do it later and let it run overnight since I want this super compressed.
I went through the process of unlocking the bootloader:
Booted up phone to OS.
Skipped/Bypassed as much of the initial setup as possible. For some reason it keeps telling me it will "process my request" when it has connection to the Internet (cell data or wifi). Don't know WTF that is. Hope it is wiped during the process of rooting and installing a new ROM.
PC didn't have drivers, but I ran the LGMobileDriver_WHQL_Ver_4.8.0.exe and it installed them.
Set USB mode to file transfer.
Enabled USB debugging.
Enabled Dev Options.
Enabled OEM unlock.
adb reboot bootloader
fastboot oem unlock
fastboot reboot
Since the userdata was wiped I had to go through the setup again, enabled dev options, usb debugging (oem unlock was enabled and greyed out unsurprisingly).
adb reboot bootloader
fastboot getvar unlocked (reported as yes; so the bootloader is successfully unlocked!)
Now for flashing H91810p_00_0717.kdz, I head back to FWUL/mAid to use SALT.
Or not. SALT doesn't work because LG changed something in regards to being able to flash as of MM, but it appears I can do this in Windows with LGUP.
A (device-specific?) DLL file is required for LGUP and after much searching I learned that it is extracted directly from the KDZ. Fortunately CXZa has some nifty tools available, one of which is a dll extractor which is perfect for this. The readme for the dll extractor said I should install LGUP_Common_DLL_Ver_1_0_40_2.msi in addition to LGUP_Store_Frame_Ver_1_14_3.msi so I did so. I used the dll extractor to get the needed dll file from H91810p_00_0717.kdz. The option to copy to the LGUP folder didn't appear to work so I tried again and told it to not copy the dll. It doesn't say as such but it places the extracted dll in the folder that the kdz was in with the same name as the KDZ +.dll.
Copied and renamed the extracted dll to 'C:\Program Files (x86)\LG Electronics\LGUP\model\Common\LGUP_Common.dll'
Upgraded LGUP with CXZa's tools (not really necessary but neat)
Ran LGUP as admin, selected UPGRADE, for the BIN file I selected the H91810p_00_0717.kdz that I downloaded from the link in the original lafsploit thread by runningnak3d, and clicked start (and held my breath...)
It worked! The phone rebooted as part of the process directly to the OS, and Settings > Phone Info shows "H91810p" so I should be ready for the next part which is following the updated lafsploit instructions by 75th with some minor edits by me for clarity: :
Boot from your FWUL/mAid USB stick.
Put your phone into download mode.
Double click the LG folder that is on the desktop.
Double click on open-lglafsploit.desktop and you will be at a terminal prompt.
Enter the following into that terminal. I'd copypasta the first line at least:
git clone https://gitlab.com/runningnak3d/lglaf -b h918-miscwrte
cd lglaf
./step1.sh
When you are told to, pull the USB cable, and the phone will power off. You now have TWRP on your laf partition.
I then booted to Download mode (VOLUP+USB) again and the phone booted to the TWRP 3.2.1-3 image installed on the laf partition. I did not mount system as rw (keep as read only). Chose Install > Install Image > and browsed to the TWRP image (twrp-3.6.1_9-0-h918.img) on my external SD. For the location to flash it I selected Recovery, and then swiped to flash.
When complete I hit the Back button twice, and changed to Install Zip. Selected Magisk-v23.0.zip, and swiped to confirm flash. When done wiped cache/dalvik, then reboot system. I opted to not install the TWRP app.
Back in the OS I turned on wifi because Magisk had to download the full app. Once Magisk was done I turned off wifi because holy **** why are outbound firewalls not a thing on phones!? Then w/in the Magisk app I selected Install, checkmarked both Preserve AVB 2.0/dm-verity and Preserve force encryption (I learned later this was a big mistake), and then chose the Direct Install method, and rebooted when it completed.
I then installed the root checker apk, and it verified that I was rooted!
Spoiler: THIS IS THE PART WHERE I AM ACTUALLY RETARDED
Read this section if you want to laugh at me, but don't follow any of the steps because it was a massive mistake due to my catastrophic stupidity.
Recovery and download mode issues?
If I am in the OS I can use adb reboot recovery and it will boot to TWRP 3.6.1_9-0 as expected. However if I do the hw key combo of VOLDN+PWR release PWR, hold PWR again, it takes me to what appears to be some stock "recovery" that only gives me the option to factory reset the device. Oddly, you have to tell it to reset your device and it will load TWRP 3.6.1_9-0 instead of doing a factory reset.
Also, if I try to go to download mode (which should have been replaced with a version of TWRP as part of the lafsploit process) it only brings me to a screen that says "Welcome to Fastboot Mode". This would be fine, but if I run fastboot reboot recovery it reboots not into recovery, but into the OS so I wonder if this fastboot mode is broken in some way. The *only* thing I can think of that may have caused fastboot to replace TWRP is installing Magisk as its process of patching the image(s) may have changed the laf partition from TWRP to fastboot. I also end up here if I am in TWRP and select reboot to bootloader, so is "download mode" == "bootloader"? I thought they were different tbh...
Next step is to get onto stock Oreo so I can run the debloater. To get oreo, Darnrain1 says "I have learned from experience that v20h has kernel panic green screen errors. Best to use v20g if you can." https://forum.xda-developers.com/t/...hones-volte-and-wifi-calling-working.4432865/
Ok so I'm wrong about the lafsploit TWRP being gone. When I attempted to flash to an Oreo ROM (H91820g_00_1010.kdz) via LGUP, it rebooted to TWRP 3.2.1-3! So the TWRP used to replace Download mode (the laf partition) is still there, but why do I get a fastboot prompt when I attempt to boot to download mode via the VOLDN+USB?
Summary:
In Android OS, adb reboot bootloader --> fastboot prompt
In Android OS, adb reboot recovery --> TWRP 3.6.1_9-0
In Android OS, adb reboot fastboot --> Android OS
In fastboot prompt, fastboot reboot bootloader --> fastboot prompt
In fastboot prompt, fastboot reboot recovery --> Android OS
In fastboot prompt, fastboot reboot --> Android OS
Within (either) TWRP, reboot bootloader --> fastboot prompt
Within (either) TWRP, reboot recovery --> TWRP 3.6.1_9-0
VOLDN+PWR, release PWR for 1s, hold PWR again --> TWRP 3.6.1_9-0 (after being prompted to factory reset)
VOLDN+USB --> fastboot prompt
Since LGUP won't work w/o the original laf partition for download mode, I had to find a copy of the laf_restore.zip at https://forum.xda-developers.com/t/laf-restore-zip-file.4398879/ since the links for it in the OP were dead. Flashed it via recovery TWRP 3.6.1_9-0, wiped cache/dalvik (probably not needed tbh), then reboot system.
Copied and renamed the dll extracted from H91820g_00_1010.kdz to 'C:\Program Files (x86)\LG Electronics\LGUP\model\Common\LGUP_Common.dll'. I suspect that I can just use the latest version of the dll, but I'm not going to risk anything so I will just use the one extracted from the very KDZ I'm flashing.
Ran LGUP as admin, selected UPGRADE, for the BIN file I selected the H91820g_00_1010.kdz file.
After reboot the phone reported its software version as H91820g. Magisk was still installed, but not surprisingly, root had been lost. This time there wasn't an easy Direct Install option so I'll need to extract the boot image so that Magisk can patch it, then I can flash it.
PROBLEM! Looks like the KDZ isn't just the OS, but also (all?) other partitions including recovery! I no longer have TWRP for my recovery. I really hope I can flash H91810p_00_0717.kdz back and redo lafsploit.
I was able to use LGUP to flash back to H91810p with the only complaint that the phone couldn't be decrypted so it had to be reset, which wasn't a problem and I let it do so.
I think I'm ****ed. Although I was able to reflash H91810p, I cannot run the lafsploit again because I only get "fastboot mode" when I hold VOLDN and plug in the USB. This fastboot mode doesn't work with the lafsploit script. I also do not have a recovery. adb reboot recovery sends me to a screen with a dead android mascot with a red triangle and the text "No command". Neither adb devices[ICODE] nor [ICODE]fastboot devices will list the phone in this mode, and LGUP doesn't see it. My recovery is totally broken.
I attempted fastboot flash recovery twrp-3.6.1_9-0-h918.img but got:
Sending 'recovery' (24948 KB) OKAY [ 3.608s]
Writing 'recovery' FAILED (remote: 'unknown command')
fastboot: error: Command failed
I used LGUP to once again reflash H91810p, and even though that should wipe everything, I also did the VOLDN+PWR, release PWR, press PWR, and told it to factory reset (no TWRP here of course so it actually factory reset). I jumped through initial ****up again and enabled dev options and USB debugging.
Now the phone isn't seen by LGUP. In device manager it shows as "Android Sooner Single ADB Interface". No COM ports. WTF!?
I tried running LGMobileDriver_WHQL_Ver_4.8.0.exe again. It didn't throw errors but nothing changed. Tried uninstalling the "sooner" device and reinstalling the LGMobileDriver. The "sooner" device just reappeared.
Windows Explorer gave me a hint though. It just showed "V20" listed with no access to its storage. On the phone I changed its USB mode to file transfer and now it shows up as a COM port. I'd forgotten that I had set the phone to always do file transfer before wiping it so it always showed up as a COM port in DM. God I'm dumb.
Now for something really ghetto. Since LGUP does send the phone into download mode when I tell it to flash, and I need to be in that mode to run the lafsploit script, I'm going to tell it to flash my phone and yank the USB cable as soon as the phone powers off for a reboot into DL mode.
It seems to have actually worked? Below is the output of my run of step1.sh:
This will install TWRP.
You do NOT need to do ANYTHING!
If it fails, NO damage is done to your phone.
If the hash check fails, it will make five attempts.
If after five attempts, it does not get a hash match, it will abort.
NO damage has been done to your phone.
You can re-run this script as many times as you want, however,
if you are not getting a hash match, you should try a different PC,
or a different cable, or a different USB port.
Press any key to continue...
Flashing... this will take a while.
Flashing TWRP to lafbak. Please wait...
Traceback (most recent call last):
File "/home/android/programs/lglafsploit/lglaf/./partitions.py", line 471, in <module>
main()
File "/home/android/programs/lglafsploit/lglaf/./partitions.py", line 421, in main
lglaf.try_hello(comm)
File "/home/android/programs/lglafsploit/lglaf/lglaf.py", line 401, in try_hello
data = comm.read(0x20, timeout=HELLO_READ_TIMEOUT)
File "/home/android/programs/lglafsploit/lglaf/lglaf.py", line 240, in read
buff = self._read(need, timeout=timeout)
File "/home/android/programs/lglafsploit/lglaf/lglaf.py", line 359, in _read
array = self.usbdev.read(self.ep_in, 2**14, timeout=timeout)
File "/usr/lib/python3.9/site-packages/usb/core.py", line 1029, in read
ret = fn(
File "/usr/lib/python3.9/site-packages/usb/backend/libusb1.py", line 846, in bulk_read
return self.__read(self.lib.libusb_bulk_transfer,
File "/usr/lib/python3.9/site-packages/usb/backend/libusb1.py", line 954, in __read
_check(retval)
File "/usr/lib/python3.9/site-packages/usb/backend/libusb1.py", line 602, in _check
raise USBTimeoutError(_strerror(ret), ret, _libusb_errno[ret])
usb.core.USBTimeoutError: [Errno 110] Operation timed out
Dumping lafbak for hash check...
[ 100 % ] 2022-04-25 20:22:36,237 partitions: INFO: Wrote 50331648 bytes to h918-twrp-tmp.img
Trimming trailing zeros
Checking hash...
TWRP hash: S260cb44d98c67f5ad11fb4512577b6ad4754d9fc8173802ae15d7f5c3aa39e3c
Test dump hash: S97ccbe70f0431f824a0f46c4256f0e7f3c1b6e0e9ac35f69978fbd58fe2b55be
Hash check failed! Retrying for 5 times.
Attempt 1 - Press ctrl C to break
Flashing TWRP to lafbak. Please wait...
[ 100 % ] 2022-04-25 20:23:58,271 partitions: INFO: Done after writing 29798400 bytes from h918-twrp.img
Dumping lafbak for hash check...
[ 100 % ] 2022-04-25 20:24:02,820 partitions: INFO: Wrote 50331648 bytes to h918-twrp-tmp.img
Trimming trailing zeros
Checking hash...
TWRP hash: S260cb44d98c67f5ad11fb4512577b6ad4754d9fc8173802ae15d7f5c3aa39e3c
Test dump hash: S260cb44d98c67f5ad11fb4512577b6ad4754d9fc8173802ae15d7f5c3aa39e3c
Hash check passed. Copying TWRP to laf
Flash sucessful! Unplug your USB cable and your phone will power off.
Once your phone is off, go back into download mode - hold vol up and plug the USB cable back in.
Once TWRP loads, you need to flash TWRP onto recovery.
Attempt 2 - Press ctrl C to break
Flashing TWRP to lafbak. Please wait...
Traceback (most recent call last):
File "/home/android/programs/lglafsploit/lglaf/./partitions.py", line 471, in <module>
main()
File "/home/android/programs/lglafsploit/lglaf/./partitions.py", line 421, in main
lglaf.try_hello(comm)
File "/home/android/programs/lglafsploit/lglaf/lglaf.py", line 401, in try_hello
data = comm.read(0x20, timeout=HELLO_READ_TIMEOUT)
File "/home/android/programs/lglafsploit/lglaf/lglaf.py", line 240, in read
buff = self._read(need, timeout=timeout)
File "/home/android/programs/lglafsploit/lglaf/lglaf.py", line 359, in _read
array = self.usbdev.read(self.ep_in, 2**14, timeout=timeout)
File "/usr/lib/python3.9/site-packages/usb/core.py", line 1029, in read
ret = fn(
File "/usr/lib/python3.9/site-packages/usb/backend/libusb1.py", line 846, in bulk_read
return self.__read(self.lib.libusb_bulk_transfer,
File "/usr/lib/python3.9/site-packages/usb/backend/libusb1.py", line 954, in __read
_check(retval)
File "/usr/lib/python3.9/site-packages/usb/backend/libusb1.py", line 602, in _check
raise USBTimeoutError(_strerror(ret), ret, _libusb_errno[ret])
usb.core.USBTimeoutError: [Errno 110] Operation timed out
Dumping lafbak for hash check...
Traceback (most recent call last):
File "/home/android/programs/lglafsploit/lglaf/./partitions.py", line 471, in <module>
main()
File "/home/android/programs/lglafsploit/lglaf/./partitions.py", line 421, in main
lglaf.try_hello(comm)
File "/home/android/programs/lglafsploit/lglaf/lglaf.py", line 401, in try_hello
data = comm.read(0x20, timeout=HELLO_READ_TIMEOUT)
File "/home/android/programs/lglafsploit/lglaf/lglaf.py", line 240, in read
buff = self._read(need, timeout=timeout)
File "/home/android/programs/lglafsploit/lglaf/lglaf.py", line 359, in _read
array = self.usbdev.read(self.ep_in, 2**14, timeout=timeout)
File "/usr/lib/python3.9/site-packages/usb/core.py", line 1029, in read
ret = fn(
File "/usr/lib/python3.9/site-packages/usb/backend/libusb1.py", line 846, in bulk_read
return self.__read(self.lib.libusb_bulk_transfer,
File "/usr/lib/python3.9/site-packages/usb/backend/libusb1.py", line 954, in __read
_check(retval)
File "/usr/lib/python3.9/site-packages/usb/backend/libusb1.py", line 602, in _check
raise USBTimeoutError(_strerror(ret), ret, _libusb_errno[ret])
usb.core.USBTimeoutError: [Errno 110] Operation timed out
Trimming trailing zeros
sha256sum: test.img: No such file or directory
Checking hash...
TWRP hash: S260cb44d98c67f5ad11fb4512577b6ad4754d9fc8173802ae15d7f5c3aa39e3c
Test dump hash: S
Hash check failed! Retrying for 5 times.
rm: cannot remove 'h918-twrp-tmp.img': No such file or directory
rm: cannot remove 'test.img': No such file or directory
Attempt 3 - Press ctrl C to break
Flashing TWRP to lafbak. Please wait...
Traceback (most recent call last):
File "/home/android/programs/lglafsploit/lglaf/./partitions.py", line 471, in <module>
main()
File "/home/android/programs/lglafsploit/lglaf/./partitions.py", line 421, in main
lglaf.try_hello(comm)
File "/home/android/programs/lglafsploit/lglaf/lglaf.py", line 401, in try_hello
data = comm.read(0x20, timeout=HELLO_READ_TIMEOUT)
File "/home/android/programs/lglafsploit/lglaf/lglaf.py", line 240, in read
buff = self._read(need, timeout=timeout)
File "/home/android/programs/lglafsploit/lglaf/lglaf.py", line 359, in _read
array = self.usbdev.read(self.ep_in, 2**14, timeout=timeout)
File "/usr/lib/python3.9/site-packages/usb/core.py", line 1029, in read
ret = fn(
File "/usr/lib/python3.9/site-packages/usb/backend/libusb1.py", line 846, in bulk_read
return self.__read(self.lib.libusb_bulk_transfer,
File "/usr/lib/python3.9/site-packages/usb/backend/libusb1.py", line 954, in __read
_check(retval)
File "/usr/lib/python3.9/site-packages/usb/backend/libusb1.py", line 602, in _check
raise USBTimeoutError(_strerror(ret), ret, _libusb_errno[ret])
usb.core.USBTimeoutError: [Errno 110] Operation timed out
Dumping lafbak for hash check...
Traceback (most recent call last):
File "/home/android/programs/lglafsploit/lglaf/./partitions.py", line 471, in <module>
main()
File "/home/android/programs/lglafsploit/lglaf/./partitions.py", line 421, in main
lglaf.try_hello(comm)
File "/home/android/programs/lglafsploit/lglaf/lglaf.py", line 401, in try_hello
data = comm.read(0x20, timeout=HELLO_READ_TIMEOUT)
File "/home/android/programs/lglafsploit/lglaf/lglaf.py", line 240, in read
buff = self._read(need, timeout=timeout)
File "/home/android/programs/lglafsploit/lglaf/lglaf.py", line 359, in _read
array = self.usbdev.read(self.ep_in, 2**14, timeout=timeout)
File "/usr/lib/python3.9/site-packages/usb/core.py", line 1029, in read
ret = fn(
File "/usr/lib/python3.9/site-packages/usb/backend/libusb1.py", line 846, in bulk_read
return self.__read(self.lib.libusb_bulk_transfer,
File "/usr/lib/python3.9/site-packages/usb/backend/libusb1.py", line 954, in __read
_check(retval)
File "/usr/lib/python3.9/site-packages/usb/backend/libusb1.py", line 602, in _check
raise USBTimeoutError(_strerror(ret), ret, _libusb_errno[ret])
usb.core.USBTimeoutError: [Errno 110] Operation timed out
Trimming trailing zeros
sha256sum: test.img: No such file or directory
Checking hash...
TWRP hash: S260cb44d98c67f5ad11fb4512577b6ad4754d9fc8173802ae15d7f5c3aa39e3c
Test dump hash: S
Hash check failed! Retrying for 5 times.
rm: cannot remove 'h918-twrp-tmp.img': No such file or directory
rm: cannot remove 'test.img': No such file or directory
Attempt 4 - Press ctrl C to break
Flashing TWRP to lafbak. Please wait...
Traceback (most recent call last):
File "/home/android/programs/lglafsploit/lglaf/./partitions.py", line 471, in <module>
main()
File "/home/android/programs/lglafsploit/lglaf/./partitions.py", line 421, in main
lglaf.try_hello(comm)
File "/home/android/programs/lglafsploit/lglaf/lglaf.py", line 401, in try_hello
data = comm.read(0x20, timeout=HELLO_READ_TIMEOUT)
File "/home/android/programs/lglafsploit/lglaf/lglaf.py", line 240, in read
buff = self._read(need, timeout=timeout)
File "/home/android/programs/lglafsploit/lglaf/lglaf.py", line 359, in _read
array = self.usbdev.read(self.ep_in, 2**14, timeout=timeout)
File "/usr/lib/python3.9/site-packages/usb/core.py", line 1029, in read
ret = fn(
File "/usr/lib/python3.9/site-packages/usb/backend/libusb1.py", line 846, in bulk_read
return self.__read(self.lib.libusb_bulk_transfer,
File "/usr/lib/python3.9/site-packages/usb/backend/libusb1.py", line 954, in __read
_check(retval)
File "/usr/lib/python3.9/site-packages/usb/backend/libusb1.py", line 602, in _check
raise USBTimeoutError(_strerror(ret), ret, _libusb_errno[ret])
usb.core.USBTimeoutError: [Errno 110] Operation timed out
Dumping lafbak for hash check...
Traceback (most recent call last):
File "/home/android/programs/lglafsploit/lglaf/./partitions.py", line 471, in <module>
main()
File "/home/android/programs/lglafsploit/lglaf/./partitions.py", line 421, in main
lglaf.try_hello(comm)
File "/home/android/programs/lglafsploit/lglaf/lglaf.py", line 401, in try_hello
data = comm.read(0x20, timeout=HELLO_READ_TIMEOUT)
File "/home/android/programs/lglafsploit/lglaf/lglaf.py", line 240, in read
buff = self._read(need, timeout=timeout)
File "/home/android/programs/lglafsploit/lglaf/lglaf.py", line 359, in _read
array = self.usbdev.read(self.ep_in, 2**14, timeout=timeout)
File "/usr/lib/python3.9/site-packages/usb/core.py", line 1029, in read
ret = fn(
File "/usr/lib/python3.9/site-packages/usb/backend/libusb1.py", line 846, in bulk_read
return self.__read(self.lib.libusb_bulk_transfer,
File "/usr/lib/python3.9/site-packages/usb/backend/libusb1.py", line 954, in __read
_check(retval)
File "/usr/lib/python3.9/site-packages/usb/backend/libusb1.py", line 602, in _check
raise USBTimeoutError(_strerror(ret), ret, _libusb_errno[ret])
usb.core.USBTimeoutError: [Errno 110] Operation timed out
Trimming trailing zeros
sha256sum: test.img: No such file or directory
Checking hash...
TWRP hash: S260cb44d98c67f5ad11fb4512577b6ad4754d9fc8173802ae15d7f5c3aa39e3c
Test dump hash: S
Hash check failed! Retrying for 5 times.
rm: cannot remove 'h918-twrp-tmp.img': No such file or directory
rm: cannot remove 'test.img': No such file or directory
Attempt 5 - Press ctrl C to break
Flashing TWRP to lafbak. Please wait...
Traceback (most recent call last):
File "/home/android/programs/lglafsploit/lglaf/./partitions.py", line 471, in <module>
main()
File "/home/android/programs/lglafsploit/lglaf/./partitions.py", line 421, in main
lglaf.try_hello(comm)
File "/home/android/programs/lglafsploit/lglaf/lglaf.py", line 401, in try_hello
data = comm.read(0x20, timeout=HELLO_READ_TIMEOUT)
File "/home/android/programs/lglafsploit/lglaf/lglaf.py", line 240, in read
buff = self._read(need, timeout=timeout)
File "/home/android/programs/lglafsploit/lglaf/lglaf.py", line 359, in _read
array = self.usbdev.read(self.ep_in, 2**14, timeout=timeout)
File "/usr/lib/python3.9/site-packages/usb/core.py", line 1029, in read
ret = fn(
File "/usr/lib/python3.9/site-packages/usb/backend/libusb1.py", line 846, in bulk_read
return self.__read(self.lib.libusb_bulk_transfer,
File "/usr/lib/python3.9/site-packages/usb/backend/libusb1.py", line 954, in __read
_check(retval)
File "/usr/lib/python3.9/site-packages/usb/backend/libusb1.py", line 602, in _check
raise USBTimeoutError(_strerror(ret), ret, _libusb_errno[ret])
usb.core.USBTimeoutError: [Errno 110] Operation timed out
Dumping lafbak for hash check...
Traceback (most recent call last):
File "/home/android/programs/lglafsploit/lglaf/./partitions.py", line 471, in <module>
main()
File "/home/android/programs/lglafsploit/lglaf/./partitions.py", line 421, in main
lglaf.try_hello(comm)
File "/home/android/programs/lglafsploit/lglaf/lglaf.py", line 401, in try_hello
data = comm.read(0x20, timeout=HELLO_READ_TIMEOUT)
File "/home/android/programs/lglafsploit/lglaf/lglaf.py", line 240, in read
buff = self._read(need, timeout=timeout)
File "/home/android/programs/lglafsploit/lglaf/lglaf.py", line 359, in _read
array = self.usbdev.read(self.ep_in, 2**14, timeout=timeout)
File "/usr/lib/python3.9/site-packages/usb/core.py", line 1029, in read
ret = fn(
File "/usr/lib/python3.9/site-packages/usb/backend/libusb1.py", line 846, in bulk_read
return self.__read(self.lib.libusb_bulk_transfer,
File "/usr/lib/python3.9/site-packages/usb/backend/libusb1.py", line 954, in __read
_check(retval)
File "/usr/lib/python3.9/site-packages/usb/backend/libusb1.py", line 602, in _check
raise USBTimeoutError(_strerror(ret), ret, _libusb_errno[ret])
usb.core.USBTimeoutError: [Errno 110] Operation timed out
Trimming trailing zeros
sha256sum: test.img: No such file or directory
Checking hash...
TWRP hash: S260cb44d98c67f5ad11fb4512577b6ad4754d9fc8173802ae15d7f5c3aa39e3c
Test dump hash: S
Hash check failed! Retrying for 5 times.
rm: cannot remove 'h918-twrp-tmp.img': No such file or directory
rm: cannot remove 'test.img': No such file or directory
Hash check failed after 5 attempts - exiting
[[email protected] lglaf]$
Strange that it ran 5 times even though appears to have worked the first time? Well let's see if it works.
I followed the instructions to get back into download mode by plugging the USB cable back in while holding VOLUP...
{
"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"
}
It's ****ing volume up and USB. Volume up. UP. UUUUUUUUUUPPPPPPPPP! At some point my brain decided "DOWNload mode is accessed by pressing volume DOWN + USB"
With 10p and the original laf back on the phone I went through the same steps as before for lafsploit and got TWRP 3.6.1_9-0 flashed onto recovery again. I figured that since I have to re-run Magisk after flashing 20g there isn't any point to doing it now so I skipped it this time.
Then w/in recovery I flashed h918-20g-prerooted.zip, wiped cache, and rebooted to System. Once there I went into Magisk and did the recommended Direct Install method for patching the image and rebooted. Tested with a root checker app and we have root!
Sweet, now it is time to debloat the phone and get it set up for actual use, but first I will check to make sure my tools are still accessable.
VOLUP+USB will show TWRP 3.2.1-3 briefly then the phone reboots... which is super odd, but not a dealbreaker since the VOLDN+PWR, release PWR for 1s, press PWR method gets me to actual recovery (TWRP 3.6.1_9-0).
Going into recovery I find that the device is encrypted and asks for a password that I never configured (was this set up on first boot of 20g, or did Magisk do this?). Reading online looks like you can virtually never decrypt your data in TWRP, but if you want to make any changes you'll need to get rid of the encryption. That's a shame because it's like you can have either a secure device (encrypted), or a usable one (rooted and debloated). I need a usable one so goodbye encryption.
Wipe > Format data > reboot
It booted to something called "Secure start-up" and said "Decryption unsuccessful" and that I needed to reset the phone. Sure, whatever. It then rebooted to recovery (TWRP 3.6.1_9-0). Weird. But data was not encrypted this time. Tried rebooting to system and got the same secure startup thing. Tried resetting again and back to recovery. Decided to just flash the 20g zip again and reboot.
I am at Secure start-up again! WTH?! I told it to reset to get me back to TWRP and here under Wipe I selected
Dalvik
System
Data
Internal Storage
Cache
and did a Format Data again. Then told it to reboot to Recovery, not System.
Back in TWRP I told it to mount System and allow modifications. Changed the filesysem of System from vfat to ext4 to make extra sure System was nuked. Reboot System (it shouldn't boot to anything if the ****er is actually wiped this time). Hung on LG logo, so I'm pretty sure I was able to remove the old OS.
Pulled battery, and did the VOLDN+PWR, release PWR for 1s, press PWR dance to get into "factory reset" which in reality leads to TWRP 3.6.1_9-0. Flashed 20g again, hopefully with better success.
Secure start-up! Why won't this thing die?! I initially thought that it was the ROM itself, or wiping data in TWRP irrevokably ****ed it somehow. Further reading lead me to this post by Theraze who clued me in that TWRP for V20 has a bug that doesn't properly clear the encryption flag. Fantastic.
I would go back and start over but I don't think I can. I'd need to use the LGUP utility, but since the phone doesn't present itself as a COM port anymore I
don't think it will work. On a whim I tried LGUP... and after like a full minute it ****ing sees the phone! I will try flashing H91810p_00_0717.kdz onto it again. It booted to TWRP 3.2.1-3 lol. I forgot we replaced the laf dl mode with TWRP.
Went to TWRP 3.6.1_9-0, flashed laf_restore.zip, rebooted to system ~SuCKurE sTarTuP~. Ran LGUP again and told it to flash 10p again. (I really wish the default option was UPGRADE and not REFURBISH; I'm sure I'm going to **** it up one of these times)
I can't believe it. I literally cannot believe it. After flashing H91810p_00_0717.kdz via LGUP I am at the Secure start-up screen. The only difference is it looks slightly different due to it being Nougat this time instead of Oreo. I told it to reset the phone JIC it will actually work, and went to pour myself a stiff drink.
Resetting actually worked. Holy. ****.
FWUL/mAid, lafsploit, flash TWRP 3.6.1_9-0 to recovery, reboot to recovery (no encryption prompt), reboot system, no secure setup.
Tried VOLDN+PWR, release PWR for 1s, press PWR, but it did not put me into recovery. It erased my device. Power off, VOLUP+USB, went into TWRP 3.2.1-3. Reboot recovery. Dead droid "no command" again. GDI.
TWRP 3.2.1-3, flash laf_restore (glad it let me; was worried that I couldn't flash the laf partition while on lafTWRP), reboot system. LGUP to flash 10p AGAIN. Didn't erase the device so didn't need to do setup again at least.
FWUL/mAid, lafsploit again.
In TWRP 3.2.1-3 I did nothing but flash TWRP 3.6.1_9-0 to Recovery and reboot system. Then I ran adb reboot recovery. Dead droid, no command. ****.
LGUP to flash 10p yet again, but this time after it booted up, I did the VOLDN+PWR dance and told it to factory reset. It rebooted and I did setup again, and rebooted to system once before shutting down.
FWUL/mAid and lafsploit yet again.
Unplugged USB and the phone powered off like it should. Then VOLUP+USB. Swiped to allow modifications.
Wiped:
Dalvik
Data
Internal Storage
Cache
Format Data:
Formatting Data using make_ext4fs...
Failed to mount '/data/ (Device or resource busy)
Failed to mount '/data/ (Device or resource busy)
Unable to recreate /data/media folder.
You may need to reboot recovery to be able to use /data again.
Updating partition details...
Failed to mount '/data/ (Device or resource busy)
...done
Unable to mount storage
Opening TWRP's terminal and doing ls shows a /data with lost and found so it's there and empty.
Ran the following command via the TWRP terminal in case the GUI method of flashing is somehow not working:
dd if=/external_sd/Docs/TWRP/twrp-3.6.1_9-0-h918.img of=/dev/block/bootdevice/by-name/recovery
I tried running the following but the file didn't exist:
rm /system/recovery-from-boot.p
Flashed Magisk23.0.zip and again 'Failed to mount '/data/ (Device or resource busy)'. Tried to wipe dalvik/cache but it failed. Reboot System.
Went through initial ****up again. Completed and did adb reboot recovery.
Got to TWRP 3.6.1_9-0. This time. Swiped to allow modifications. Reboot system.
adb reboot recovery
Got TWRP 3.6.1_9-0 so it *might* be working now. Reboot > power off.
Tried VOLDN+PWR dance and it took me to recovery.
I think the lesson is wipe the **** out of the device after getting into lafTWRP both before and after flashing new TWRP to Recovery. Also swipe to allow modification so if there's secret sauce behind the scenes in System that's killing recovery TWRP it is neutralized during the process of getting 3.6.1_9-0 flashed. I am unsure if flashing Magisk is required as part of the process. I don't believe it is as I think mounting system as rw and wiping the other partitions is what's really needed, but I don't think it actually harms anything. (later on I learned that wiping is only part of it; Magisk and no-verity-opt-encrypt are what's needed to stop the encryption that was causing secure startup)
I rebooted to system and again adb reboot recovery. I went to TWRP 3.6.1_9-0 but it did not prompt me about swiping to make modifications so I immediately did reboot system. I was expecting Secure startup but it didn't appear, thank ****.
Back to recovery and I flashed no-verity-opt-encrypt-6.1.zip in the hopes that it would prevent Suckure startup from occuring again when I flash 20g in a minute. Wiped dalv/cache tho probably unnecessary. Reboot system.
No problems thus far. Time to flash 20g again.
Rebooted to recovery and told it to flash 20g. Since I've learned how amazing and cathartic wiping is, I formated data, and then wiped:
Dalvik/Cache
Data (probably not needed)
Internal Storage
Cache
Reboot system.
Secure start-up. *sigh*
VOLDN+PWR dance actually worked this time so that's nice. Swiped to allow modifications. Flashed no-verity-opt-encrypt-6.1.zip. Format data, wipe dalvik data internal cache again. Reboot system.
Secure start-up.
Recovery > flashed laf_restore > reboot system. Secure startup ofc, but I can run LGUP and flash 10p KDZ again to start over. Again.
I'm 99.999% sure that encryption being enabled is the problem.
In https://forum.xda-developers.com/t/twrp-3-1-1-0-touch-recovery.3603760/post-73129295 me2151 says that "Encryption unsuccessful is because you did not do supersu or something to disable force-encrypt". Note that he says "Encryption unsuccessful" but the problem I have is "decryption unsuccessful". Not sure if a typo or a different issue.
Phoenix591 says https://forum.xda-developers.com/t/twrp-3-1-1-0-touch-recovery.3603760/post-75429764 "You need to either root or install no-verity-opt-encrypt to keep stock from replacing twrp with stock recovery iirc"
This makes me think that I'll need to flash Magisk *and* no-verity-opt-encrypt to ensure that there is no encryption at all for the data partition.
FWUL/mAid froze while I was doing this so I hope my notes are correct as they're from my highly fallible memory:
lafsploit
VOLUP+USB > lafTWRP
Left system as ro
Format data (It even mentions we'd need to reenter recovery for data to be accessible again ffs. No wonder I was getting Failed to mount '/data/ (Device or resource busy). I need to learn how to read.)
Reboot > Power off
VOLUP+USB > lafTWRP
System ro
Wipe dalv, data, internal, cache
Flash Magisk (it mentions that forceencryption is enabled and will keep it that way when patching)
Flash no-verity-opt-encrypt-6.1.zip (to override the forced encryption)
Flash TWRP 3.6.1_9-0 to recovery
Reboot recovery
Made it to TWRP 3.6.1_9-0, yay
I would have left ro if prompted; for some reason the prompt about system modifications is inconsistant; sometimes it asks, sometimes not
Reboot system
Did first time setup again, dev options, turn on wifi, let magisk update and let it reboot
Back in system used Magisk's Direct Install method leaving "preserve AVB" UN-checked in case AVB forces encryption back on. Interestingly there wasn't an option for 'Preserve force encryption' so I think no-verity-opt-encrypt is working.
Rebooted
Installed root check app and we have root
Reboot recovery
Format data
Reboot RECOVERY (NOT system!)
Wipe dalv, data, internal, cache
Reboot RECOVERY (NOT system!) <-- not sure if needed, but I'm so sick of secure setup
Flash 20g zip
Flash magisk
Flash no-verity-opt-encrypt
Reboot system this time
Oh my ****ing god it's not at secure setup! It's at the normal first time setup for Oreo!
Did first time setup again, dev options, turn on wifi, let magisk update and let it reboot
Back in system used Magisk's Direct Install method leaving "preserve AVB" UN-checked in case AVB forces encryption back on (still no Preserve force encryption) and rebooted
Installed root checker and it's rooted
Tested adb reboot recovery and it worked
Tested VOLDN+PWR dance and it worked
Time for debloat
Already in recovery from testing the methods to get into recovery
Wipe > advanced > just dalvik and cache this time (hope this is all I need to do)
Flash Auto_Debloat v7.4
Swiped to wipe dalv/cache JIC
Reboot system
Success!
I suspect that (but haven't tried) flashing encrypt-v3.zip at this point will encrypt userdata and have it decryptable in TWRP. It might not work with the official TWRP 3.6.1_9-0, but Phoenix591 says it should with his version of TWRP. However, this adventure has gone on long enough so I'm not keen on trying it. Maybe later when I have some energy.

Well that was a trip. Skimmed through didn't read everything. Liked the touch of memes properly used. Congrats.

lol thank you. It was quite the journey but I feel like I learned from it so it was a good experience.

Oh fer... yep. Lol That's about what a nightmare (journey is a good word, too lol) rooting phones can be & precisely why 7% (at the VERY most) of cell phone users really end up doing it. I'm just glad to be a part of (the even smaller) percentage of us that enjoy helping one another. Thanks to all for being so helpful.
Good job Sidney & thank you.

Nice report. Read bits here and there - as usual.
And very detailed. I should start taking notes too...
SidneyD said:
dead android mascot with a red triangle and the text "No command"
Click to expand...
Click to collapse
Some stock recoveries does this. Next time try pressing power and then Vol Up shortly...

always good to see users sharing their knowledge and congrats that you was steadfast enough going through all this !
Thanks for that and as a little site note: SALT can extract KDZs too, ofc even with the DLL needed for LGup later

I found that attempting to format my thumb drive back to a general purpose storage device only showed 60MB of space. I've experienced this before and knew that I had to use the diskpart command to fix the partitions. I fixed it by following the guide at: https://www.diskpart.com/articles/how-to-format-usb-drive-in-command-prompt-7201.html
Be careful about selecting the correct disk number!

SidneyD said:
I found that attempting to format my thumb drive back to a general purpose storage device only showed 60MB of space. I've experienced this before and knew that I had to use the diskpart command to fix the partitions. I fixed it by following the guide at: https://www.diskpart.com/articles/how-to-format-usb-drive-in-command-prompt-7201.html
Be careful about selecting the correct disk number!
Click to expand...
Click to collapse
Awesome. Thx Sidney.

Thanks for the guide. Were you able to keep VoLTE? Does this re Sim Lock the phone? Thanks from a nervous noob