Professional Documents
Culture Documents
-------------------------------------------
These two scripts will allow you to extract both KDZ files and DZ files
-l or --list
Lists all files contained in the archive
-x or --extract
Extract all portions or as chunk-files. See -h or below for
more detail.
-c or --chunks
(undz-only) Extract archive as chunks, unless a specific
chunk number is give, all chunks will be extracted.
-s ID or --single ID
Extract a single slice/partition by ID (can be found with
--list). With undz multiple IDs can be given and the whole
slice/partition will be extracted
-i or --image
(undz-only) Extract who archive as a disk image
$ unkdz -f H90120j_00_0712.kdz -l
[+] KDZ Partition List (format v2)
=========================================
0 : H90120j_00.dz (1988019978 bytes)
1 : LGUP_c.dll (2875560 bytes)
2 : LGUP_c.dylib (1170000 bytes)
$ unkdz -f H90120j_00_0712.kdz -x
[+] Extracting all partitions from v2 file!
The theory was at this point you can modify out/system.image to your liking.
For this particular device (LG H901), system.image is an EXT4 filesystem. Many
tools exist for modifying EXT4 filesystems and these should work fine.
The next step would be reconstructing the file. There are three steps, turning
the files into chunks, merging them together into a DZ file, and then merging
everything back into a KDZ file. The first step has some quirks.
The next two strategies are utilizing support for SEEK_DATA and SEEK_HOLE, or
probing for the presence of holes. Operating System support for
SEEK_DATA/SEEK_HOLE is decent, though to my knowledge no versions of Windows
include this. This seems a bit of a cheat since it is relying on knowledge of
which areas of the image haven't been written to. Probing marks an awful lot
of areas as holes, which leaves me uncomfortable believing the results to be
sane. As such I reccommend the first if available (ext2simg is known to work
for Linux, but I'm unsure Windows binaries are available).
$ mkdz -f kdzextracted/H90120j_00.dz -m
[+] Writing 60 chunks to H90120j_00.dz:
There is also the quirk of the backup GPT's chunk extending near the front of
the "grow" slice/partition. My suspicion is this is a weakness of the tools LG
is using to generate the files. Perhaps they don't understand the concept of
chunks which don't start at a slice/partition boundary, they also may not
correctly handle the case of chunks which *begin* with a hole.
Lastly, I'm concerned about the number of unknowns in the DZ header. Several
look to be harmless to simply copy the value from an existing file, but others
are totally unknown to me at this time. Two fields look to be date codes of
some flavor (easy, simply copy). I worry more of these need to be regenerated,
but I've got no idea what to put in new files.
WARNING: As of this writing it appears the fear of the unknowns was valid.
According to reports it appears there is an additional verification mechanism
which needs to be worked around. At the moment I'm guessing "unknown1" (saved
in dzextracted/.dz.params) is a MD5 of some portion of the image.
Unfortunately without knowing which portion, it cannot be adjusted. Similarly
"unknown3" could be a CRC-32 of the same area. My fear is "unknown1" could be
a keyed hash at which point fixing is impossible unless we discover what/where
the key is.
One piece of good news is I'm pretty confident unpacking mostly works
correctly. The one quirk is newer LGE devices (the G5) the DZ format is
somewhat modified and unpacking doesn't yet meet my expectations.
-------------------------------------------
-------------------------------------------