Working kdz extractor for V30 - LG V30 Questions & Answers

Hello,
is there any working linux script for extracting v30 kdz firmware and dz files?
Big thanks for help

---

H930g - lgv30 - kdz extract - linux
djsven said:
Hello,
is there any working linux script for extracting v30 kdz firmware and dz files?
Big thanks for help
Click to expand...
Click to collapse
Yes sir , I have found one
https://github.com/ehem/kdztools
Here are the output from my first test:
[email protected]:~/Android/kdztools-master$ ./unkdz -f H93011m_00_OPEN_EU_OP_1229.kdz -l
[!] Warning: Data between headers and payload! (offsets 826 to 83768)
[+] KDZ Partition List (format v2)
=========================================
0 : H93011m_00.dz (3563995785 bytes)
1 : LGUP_c.dll (3079120 bytes)
2 : LGUP_c.dylib (1229456 bytes)
[email protected]:~/Android/kdztools-master$ ./unkdz -f H93011m_00_OPEN_EU_OP_1229.kdz -x
[!] Warning: Data between headers and payload! (offsets 826 to 83768)
[+] Extracting all partitions from v2 file!
[+] Extracting H93011m_00.dz to kdzextracted/H93011m_00.dz
[+] Extracting LGUP_c.dll to kdzextracted/LGUP_c.dll
[+] Extracting LGUP_c.dylib to kdzextracted/LGUP_c.dylib
[+] Extracting extra data to kdzextracted/kdz_extras.bin
So far this is the only steps I have tried, I will give a later try to extract the whole DZ file
For your information I m running Ubuntu 16.04 LTS
I wish you good luck
Edit : Unfortunately I got this error when I try to list the DZ file
[email protected]:~/Android/kdztools-master$ ./undz -f H93011m_00.dz -l
[!] Error: Value supposed to be zero in field "reserved5" is non-zero (0x5900)
Sorry For this deception, maybe you know what this error is meaning ?

---

The format changed slightly, but the extraction still works. I didn't feel like figuring out what the data in the reserved field is for, so just comment out the two sys.exit(1).
You can use this patch...
Code:
diff --git a/undz.py b/undz.py
index 1078248..aa386a0 100755
--- a/undz.py
+++ b/undz.py
@@ -74,7 +74,7 @@ class UNDZUtils(object):
dz_item[key] = dz_item[key].rstrip(b'\x00')
if b'\x00' in dz_item[key]:
print("[!] Error: extraneous data found IN "+key, file=sys.stderr)
- sys.exit(1)
+ #sys.exit(1)
elif type(dz_item[key]) is int:
if dz_item[key] != 0:
print('[!] Error: Value supposed to be zero in field "'+key+'" is non-zero ('+hex(dz_item[key])+')', file=sys.stderr)
@@ -86,7 +86,7 @@ class UNDZUtils(object):
# To my knowledge this is supposed to be blank (for now...)
if len(dz_item['pad']) != 0:
print("[!] Error: pad is not empty", file=sys.stderr)
- sys.exit(1)
+ #sys.exit(1)
return dz_item
@@ -195,7 +195,7 @@ class UNDZChunk(dz.DZChunk, UNDZUtils):
zdata = self.dz.dzfile.read(self.dataSize)
# Decompress the data
- buf = zlib.decompress(zdata)
+ buf = zlib.decompress(zdata)
crc = crc32(buf) & 0xFFFFFFFF
-- Brian

---

runningnak3d said:
The format changed slightly, but the extraction still works. I didn't feel like figuring out what the data in the reserved field is for, so just comment out the two sys.exit(1).
You can use this patch...
Code:
diff --git a/undz.py b/undz.py
index 1078248..aa386a0 100755
--- a/undz.py
+++ b/undz.py
@@ -74,7 +74,7 @@ class UNDZUtils(object):
dz_item[key] = dz_item[key].rstrip(b'\x00')
if b'\x00' in dz_item[key]:
print("[!] Error: extraneous data found IN "+key, file=sys.stderr)
- sys.exit(1)
+ #sys.exit(1)
elif type(dz_item[key]) is int:
if dz_item[key] != 0:
print('[!] Error: Value supposed to be zero in field "'+key+'" is non-zero ('+hex(dz_item[key])+')', file=sys.stderr)
@@ -86,7 +86,7 @@ class UNDZUtils(object):
# To my knowledge this is supposed to be blank (for now...)
if len(dz_item['pad']) != 0:
print("[!] Error: pad is not empty", file=sys.stderr)
- sys.exit(1)
+ #sys.exit(1)
return dz_item
@@ -195,7 +195,7 @@ class UNDZChunk(dz.DZChunk, UNDZUtils):
zdata = self.dz.dzfile.read(self.dataSize)
# Decompress the data
- buf = zlib.decompress(zdata)
+ buf = zlib.decompress(zdata)
crc = crc32(buf) & 0xFFFFFFFF
-- Brian
Click to expand...
Click to collapse
hey , this doesnt work at all, its still showing the same error as before , im trying to extract G7 ThinQ kdz
[email protected]:~/kdztools-master$ ./undz.py -x -f G71010b_00.dz
[!] Error: Value supposed to be zero in field "reserved5" is non-zero (0x5900)
[email protected]:~/kdztools-master$
Click to expand...
Click to collapse

---

This was a quick hack to get V30 Nougat KDZs to extract. V30 Oreo KDZs require additional work, and I haven't even looked at G7 KDZs yet.
-- Brian

---

Encounter the same issue, patched the sys.exit() calls and flipped this line to avoid the error with reserved5:
('reserved5', ('I', False)), # currently always zero
But still errors. Further info at: hxxxs://github.com/ehem/kdztools/issues/16#issuecomment-435356938

---

SALT works perfectly fine with V30 oreo kdzs, doesnt work though with G7/V40 kdzs ?
i mean... SALT actually can do way more than just extracting kdzs ... but thats the only use i have for it atm

---

SGCMarkus said:
SALT works perfectly fine with V30 oreo kdzs, doesnt work though with G7/V40 kdzs ?
i mean... SALT actually can do way more than just extracting kdzs ... but thats the only use i have for it atm
Click to expand...
Click to collapse
Managed to unpack a modem partition LG changed the compression algorithm from zlib to zstd on LG V40 kdzs

---

SGCMarkus said:
SALT works perfectly fine with V30 oreo kdzs, doesnt work though with G7/V40 kdzs ?
i mean... SALT actually can do way more than just extracting kdzs ... but thats the only use i have for it atm
Click to expand...
Click to collapse
Thank you very much for posting this.
It turns out I had a corrupt download of the H932 20o KDZ and no -- LG hasn't made any additional changes to the KDZ format.
When I saw that SALT was working for you, then I knew my extractor should work as well and that lead me to start looking elsewhere.
-- Brian

---

BINGO! LGV40 unpacked!
Code:
[20:10 [email protected] dzextracted] > sudo mount -t ext4 vendor_a.image /media/edu/ext4_tmp
[sudo] password for edu:
[20:10 [email protected] dzextracted] > cd /media/edu/ext4_tmp
[20:10 [email protected] ext4_tmp] > ll
total 220K
drwxr-xr-x. 10 root 2000 4.0K Dec 31 2008 app
drwxr-xr-x. 6 root 2000 8.0K Dec 31 2008 bin
drwxr-xr-x. 2 root 2000 4.0K Dec 31 2008 carrier
drwxr-xr-x. 2 root 2000 4.0K Dec 31 2008 dsp
drwxr-xr-x. 2 root 2000 4.0K Dec 31 2008 els
drwxr-xr-x. 2 root 2000 4.0K Dec 31 2008 eri
drwxr-xr-x. 23 root 2000 4.0K Dec 31 2008 etc
drwxr-xr-x. 2 root 2000 4.0K Dec 31 2008 ffu
drwxr-xr-x. 3 root 2000 4.0K Dec 31 2008 firmware
drwxr-xr-x. 2 root 2000 4.0K Dec 31 2008 fota
drwxr-xr-x. 2 root 2000 4.0K Dec 31 2008 framework
drwxr-xr-x. 11 root 2000 16K Dec 31 2008 lib
drwxr-xr-x. 9 root 2000 16K Dec 31 2008 lib64
drwx------. 2 root root 16K Dec 31 2008 lost+found
drwxr-xr-x. 2 root 2000 4.0K Dec 31 2008 media
drwxr-xr-x. 2 root 2000 4.0K Dec 31 2008 mpt
drwxr-xr-x. 83 root 2000 4.0K Dec 31 2008 overlay
drwxr-xr-x. 3 root 2000 4.0K Dec 31 2008 package
drwxr-xr-x. 3 root 2000 4.0K Dec 31 2008 persdata
drwxr-xr-x. 2 root 2000 4.0K Dec 31 2008 persist-lg
drwxr-xr-x. 2 root 2000 4.0K Dec 31 2008 power
drwxr-xr-x. 3 root 2000 4.0K Dec 31 2008 priv-app
drwxr-xr-x. 3 root 2000 4.0K Dec 31 2008 radio
drwxr-xr-x. 5 root 2000 4.0K Dec 31 2008 rfs
drwxr-xr-x. 2 root 2000 4.0K Dec 31 2008 sns
drwxr-xr-x. 2 root 2000 4.0K Dec 31 2008 srtc
drwxr-xr-x. 3 root 2000 4.0K Dec 31 2008 vzw
-rw-------. 1 root root 8.8K Dec 31 2008 build.prop
-rw-r--r--. 1 root root 1.9K Dec 31 2008 compatibility_matrix.xml
-rw-------. 1 root root 684 Dec 31 2008 default.prop
lrw-r--r--. 1 root root 12 Dec 31 2008 factory_data -> /system/data
lrw-r--r--. 1 root root 19 Dec 31 2008 factory_etc -> /system/factory_etc
lrw-r--r--. 1 root root 19 Dec 31 2008 factory_lib -> /system/factory_lib
lrw-r--r--. 1 root root 21 Dec 31 2008 factory_lib64 -> /system/factory_lib64
-rw-r--r--. 1 root root 36K Dec 31 2008 manifest.xml
-rw-r--r--. 1 root root 16K Dec 31 2008 ueventd.rc

---

runningnak3d said:
Thank you very much for posting this.
It turns out I had a corrupt download of the H932 20o KDZ and no -- LG hasn't made any additional changes to the KDZ format.
When I saw that SALT was working for you, then I knew my extractor should work as well and that lead me to start looking elsewhere.
-- Brian
Click to expand...
Click to collapse
I PM you with the URL. I guess you don't need it but figured you would want an official link from LG Bridge.
Sent from my LG-H932 using XDA Labs

---

eduuk said:
Managed to unpack a modem partition LG changed the compression algorithm from zlib to zstd on LG V40 kdzs
Click to expand...
Click to collapse
Hello eduuk,
What did you do to get V40 to unpack? I have a feeling it could work for the LG G7. Thanks for any help.

---

Dvalin21 said:
Hello eduuk,
What did you do to get V40 to unpack? I have a feeling it could work for the LG G7. Thanks for any help.
Click to expand...
Click to collapse
I am also unable to get a useful unpack of a G7 or V40 KDZ.
@eduuk You don't even need to share your code, but if you could just point out the differences between the V30 and V40 KDZ format it would be appreciated.
-- Brian

---

@eduuk i got passed the reserved5 but now i get this error: [!] Error: extraneous data found IN pad
Also, if you can provide help with changing the compression algorithm from zlib to zstd i would appreciate it.

---

Dvalin21 said:
@eduuk i got passed the reserved5 but now i get this error: [!] Error: extraneous data found IN pad
Also, if you can provide help with changing the compression algorithm from zlib to zstd i would appreciate it.
Click to expand...
Click to collapse
I hate doing work that someone else has already done -- it is just a waste of time, but since it seems that he isn't willing to share the changes, I am spending the day mapping out the structure of the G7 / V40 KDZ format, and updating the extractor so that it can deal with the new version.
As soon as I have it functional, I will post a link to the repo.
-- Brian

---

runningnak3d said:
I hate doing work that someone else has already done -- it is just a waste of time, but since it seems that he isn't willing to share the changes, I am spending the day mapping out the structure of the G7 / V40 KDZ format, and updating the extractor so that it can deal with the new version.
As soon as I have it functional, I will post a link to the repo.
-- Brian
Click to expand...
Click to collapse
You rock sir, thank you

---

Dvalin21 said:
You rock sir, thank you
Click to expand...
Click to collapse
Well, that was more of a pain in the butt than it needed to be, but repo is incoming once I clean up some of my debug code:
Code:
[swango:~/dev/kdztools/kdzextracted] master(+11/-8)* ± ../undz2.py -f G71010f_00.dz -l
[+] DZ Partition List
=========================================
0/ 0 : PrimaryGPT_0.bin (1363 bytes)
0/ 1 : PrimaryGPT_0.bin (277 bytes)
0/ 2 : PrimaryGPT_0.bin (277 bytes)
0/ 3 : PrimaryGPT_0.bin (335 bytes)
0/ 4 : PrimaryGPT_0.bin (2355 bytes)
0/ 5 : PrimaryGPT_0.bin (404 bytes)
0/ 6 : PrimaryGPT_0.bin (213 bytes)
1/?? : mpt (<empty>)
2/?? : drm (<empty>)
3/?? : sns (<empty>)
4/?? : ssd (<empty>)
5/ 7 : persist_13446.bin (743 bytes)
6/?? : misc (<empty>)
7/ 8 : ftm_21894.bin (75 bytes)
8/?? : power (<empty>)
9/?? : encrypt (<empty>)
10/?? : eksst (<empty>)
11/?? : rct (<empty>)
12/?? : fota (<empty>)
13/?? : srtc (<empty>)
14/?? : pstore (<empty>)
15/?? : els (<empty>)
16/?? : carrier (<empty>)
17/?? : persdata (<empty>)
18/ 9 : oem_a_77574.bin (738 bytes)
<snip>
and
Code:
θ78° [swango:~/dev/kdztools/kdzextracted] master(+11/-8)* 3s ± ../undz2.py -f G71010f_00.dz -s 20
[+] Extracting single slice^Wpartition!
[+] Extracting vendor_a_81670.bin to vendor_a.image
[+] Extracting vendor_a_114503.bin to vendor_a.image
[+] Extracting vendor_a_147206.bin to vendor_a.image
[+] Extracting vendor_a_147701.bin to vendor_a.image
<snip>
[swango:~/dev/kdztools/kdzextracted] master(+11/-8)* 130 ± cd dzextracted/
[swango:~/dev … ols/kdzextracted/dzextracted] master(+11/-8)* ± mkdir mnt
[swango:~/dev … ols/kdzextracted/dzextracted] master(+11/-8)* ± sudo mount vendor_a.image ./mnt
[swango:~/dev … ols/kdzextracted/dzextracted] master(+11/-8)* ± cd mnt
[swango:~/dev … kdzextracted/dzextracted/mnt] $ ls -al
total 208
drwxr-xr-x 27 root root 4096 Dec 31 1969 .
drwxr-xr-x 3 swango swango 4096 Dec 15 10:29 ..
drwxr-xr-x 8 root 2000 4096 Dec 31 2008 app
drwxr-xr-x 6 root 2000 8192 Dec 31 2008 bin
-rw------- 1 root root 8664 Dec 31 2008 build.prop
drwxr-xr-x 2 root 2000 4096 Dec 31 2008 carrier
<snip>
The quick and dirty is that the header changed -- which is why there was data in the pad (that is the zero padding at the end of the header to make it 512 bytes) -- so I defined those, and they also changed the compression from zlib to zstandard (you need version 0.9 or greater) NOT zstd.
Lastly, when the compress, they don't include the size in the zstandard header, so I just picked a value that was big enough to decompress the largest partition.
Again, I have a lot of cleanup to do, and then I will commit this. Eventually I will make it so you can pass something like --zlib or --zst so that one file can be used to extract both old and new format KDZs, but for now there is undz2.py
-- Brian

---

OK - thread and link are here.
Please let me know if you come across any KDZs that you can't extract, but please post the errors in that thread.
-- Brian

---

Dvalin21 said:
Hello eduuk,
What did you do to get V40 to unpack? I have a feeling it could work for the LG G7. Thanks for any help.
Click to expand...
Click to collapse
runningnak3d said:
OK - thread and link are here.
Please let me know if you come across any KDZs that you can't extract, but please post the errors in that thread.
-- Brian
Click to expand...
Click to collapse
hey guys,
sorry but I didnt get the time to answer you. Took me an entire day to patch the python code. It's so so ugly code, so I would prefer not share it if anyone can code it better than me
There was a guy who was sending me private messages to do the same as me, and he got it too. The only thing to do is to change the algorithm and patch out asserts and other checks.
Please let me know if you can do it without my ugly code. Otherwise, I will share it of course.
---------- Post added at 12:54 AM ---------- Previous post was at 12:51 AM ----------
runningnak3d said:
Well, that was more of a pain in the butt than it needed to be, but repo is incoming once I clean up some of my debug code:
Code:
[swango:~/dev/kdztools/kdzextracted] master(+11/-8)* ± ../undz2.py -f G71010f_00.dz -l
[+] DZ Partition List
=========================================
0/ 0 : PrimaryGPT_0.bin (1363 bytes)
0/ 1 : PrimaryGPT_0.bin (277 bytes)
0/ 2 : PrimaryGPT_0.bin (277 bytes)
0/ 3 : PrimaryGPT_0.bin (335 bytes)
0/ 4 : PrimaryGPT_0.bin (2355 bytes)
0/ 5 : PrimaryGPT_0.bin (404 bytes)
0/ 6 : PrimaryGPT_0.bin (213 bytes)
1/?? : mpt (<empty>)
2/?? : drm (<empty>)
3/?? : sns (<empty>)
4/?? : ssd (<empty>)
5/ 7 : persist_13446.bin (743 bytes)
6/?? : misc (<empty>)
7/ 8 : ftm_21894.bin (75 bytes)
8/?? : power (<empty>)
9/?? : encrypt (<empty>)
10/?? : eksst (<empty>)
11/?? : rct (<empty>)
12/?? : fota (<empty>)
13/?? : srtc (<empty>)
14/?? : pstore (<empty>)
15/?? : els (<empty>)
16/?? : carrier (<empty>)
17/?? : persdata (<empty>)
18/ 9 : oem_a_77574.bin (738 bytes)
<snip>
and
Code:
θ78° [swango:~/dev/kdztools/kdzextracted] master(+11/-8)* 3s ± ../undz2.py -f G71010f_00.dz -s 20
[+] Extracting single slice^Wpartition!
[+] Extracting vendor_a_81670.bin to vendor_a.image
[+] Extracting vendor_a_114503.bin to vendor_a.image
[+] Extracting vendor_a_147206.bin to vendor_a.image
[+] Extracting vendor_a_147701.bin to vendor_a.image
<snip>
[swango:~/dev/kdztools/kdzextracted] master(+11/-8)* 130 ± cd dzextracted/
[swango:~/dev … ols/kdzextracted/dzextracted] master(+11/-8)* ± mkdir mnt
[swango:~/dev … ols/kdzextracted/dzextracted] master(+11/-8)* ± sudo mount vendor_a.image ./mnt
[swango:~/dev … ols/kdzextracted/dzextracted] master(+11/-8)* ± cd mnt
[swango:~/dev … kdzextracted/dzextracted/mnt] $ ls -al
total 208
drwxr-xr-x 27 root root 4096 Dec 31 1969 .
drwxr-xr-x 3 swango swango 4096 Dec 15 10:29 ..
drwxr-xr-x 8 root 2000 4096 Dec 31 2008 app
drwxr-xr-x 6 root 2000 8192 Dec 31 2008 bin
-rw------- 1 root root 8664 Dec 31 2008 build.prop
drwxr-xr-x 2 root 2000 4096 Dec 31 2008 carrier
<snip>
The quick and dirty is that the header changed -- which is why there was data in the pad (that is the zero padding at the end of the header to make it 512 bytes) -- so I defined those, and they also changed the compression from zlib to zstandard (you need version 0.9 or greater) NOT zstd.
Lastly, when the compress, they don't include the size in the zstandard header, so I just picked a value that was big enough to decompress the largest partition.
Again, I have a lot of cleanup to do, and then I will commit this. Eventually I will make it so you can pass something like --zlib or --zst so that one file can be used to extract both old and new format KDZs, but for now there is undz2.py
-- Brian
Click to expand...
Click to collapse
Yeah 0x200 bytes of header, i removed that first with dd and then I coded in python changing offsets. Sorry but I dont have the time of coding this properly.
---------- Post added at 12:59 AM ---------- Previous post was at 12:54 AM ----------
eduuk said:
hey guys,
sorry but I didnt get the time to answer you. Took me an entire day to patch the python code. It's so so ugly code, so I would prefer not share it if anyone can code it better than me
There was a guy who was sending me private messages to do the same as me, and he got it too. The only thing to do is to change the algorithm and patch out asserts and other checks.
Please let me know if you can do it without my ugly code. Otherwise, I will share it of course.
---------- Post added at 12:54 AM ---------- Previous post was at 12:51 AM ----------
Yeah 0x200 bytes of header, i removed that first with dd and then I coded in python changing offsets. Sorry but I dont have the time of coding this properly.
Click to expand...
Click to collapse
The best way is to do a pull request at the main repo https://github.com/ehem/kdztools
---------- Post added at 01:00 AM ---------- Previous post was at 12:59 AM ----------
runningnak3d said:
I hate doing work that someone else has already done -- it is just a waste of time, but since it seems that he isn't willing to share the changes, I am spending the day mapping out the structure of the G7 / V40 KDZ format, and updating the extractor so that it can deal with the new version.
As soon as I have it functional, I will post a link to the repo.
-- Brian
Click to expand...
Click to collapse
Dude, did you read this by any chance? https://github.com/ehem/kdztools/issues
Cheers mate

---

Thanks for the answer @eduuk, however Brian did a kdztool working that I was able to fully extract all the image files for the G710TM10n firmware for T-Mobile. Still with that said we still appreciate all your work!