Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Request: Support for G5 / V20 KDZ format #17

Open
runningnak3d opened this issue Jul 10, 2017 · 5 comments
Open

Request: Support for G5 / V20 KDZ format #17

runningnak3d opened this issue Jul 10, 2017 · 5 comments

Comments

@runningnak3d
Copy link

I read that you are still working on support for the newer KDZ format. I would like to help, but I am not sure where to begin. I have a bricked V20, and need a bootable image, but can't seem to get anyone to dump one from their phone :)

If you could just give me some pointers on where to start, it would be appreciated.

@ehem
Copy link
Owner

ehem commented Jul 14, 2017

I don't know whether this tool can provide what you're looking for. The goal of this was to extract data out of KDZ files and analyzing the KDZ/DZ format in sufficient detail so as to be able to create modified ones.

The biggest difference in the G5/V20 KDZ format is the field marked as "dev" in the chunk headers of the inner DZ file. On prior devices the entire eMMC area appeared as slices/partitions of apparently one physical device (/dev/block/mmcblk0 was the whole device, with slices mmcblk0p1 to mmcblk0p63). As such the dev field was always zero.
On the G5 and V20, the internal "UFS" storage presents as 7 physical devices (/dev/block/sda to /dev/block/sdg). A dev value of 0 equates to /dev/block/sda and a value of 6 equates to /dev/block/sdg.
This means there needs to be another layer in undz.py to represent these.

On a smaller scale a bunch of data appeared between the KDZ headers and the start of the first file inside the KDZ format. I don't know what this data is, perhaps a signature, perhaps something else.

As of right now I'm working on a tool to extract the data from a KDZ file directly onto a phone. The theory is to load a KDZ onto the phone and then the tool would be used for replacing /system and /firmware (ehem/lg-v20-tools#1).

@runningnak3d
Copy link
Author

runningnak3d commented Jul 14, 2017

You are correct. Even if I was able to extract the KDZ, I would not be able to accomplish my goal of debricking my phone since (as you stated) you need to have the SDcard look like multiple physical devices, just like the eMMC -- which it doesn't. With SD800 to SD808, you could create the partitions on the SDcard, and boot from it even if you wiped your eMMC. Not the case anymore with SD820+

Even so, thank you very much for the time you have spent on this tool. It has allowed me to save some older phones :)

@johanneswilm
Copy link

@ehem Ok, I see. Does that mean that the system.image file that I extracted from my Lg V20 kdz file cannot really be extracted/mounted? Or if it can be mounted, should I mount it as a UFS rather than ext4 file system?

I am asking because I am trying to figure out what process is creating the "Invalid battery" message (in order to see if I can detain it). Grep tells me it is inside of the system.image file a few times.

@ehem
Copy link
Owner

ehem commented Aug 12, 2017

@johanneswilm nothing of the sort. /system on a V20 is ext4, the "UFS" being referred to is a hardware standard which is taking over from "eMMC", the UFS filesystem is something unrelated.

@runningnak3d for the G5 and V20 another method has shown up. That one looks to have some interesting additional potential...

@andy19801210
Copy link

Can you make an analysis of Gpt.Bin Partition, rawprogram, patch tools?!

Sent from my 360 1505-A02 using FastHub

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants