[Q] IMEI Repair - Nexus 5 Q&A, Help & Troubleshooting

I own the D-820 model of the phone. I was trying to change the PRL, and the IMEI is showing up as 0 now.
Having said that, I flashed the kernel with diagnostic mode enabled and installed LG United drivers. I was successful at getting the device SPC. Using DFS, I was able to change the "Ruim mode" as well. The changes got successfully written so far. Changing PRL screwed up the IMEI.
Ever since, I've been trying to set ESN, MEID and IMEI using DFS, CDMADevTerm, QPST NV Manager, and EFS Pro (Qualcomm NV Tools). All fail (the IMEI reverts to 0; the original IMEI does not get written back).
I have even tried changing the connection mode in Qualcomm NV Tools (EFS Pro) to factory test mode, before writing. It results in "Unknown" baseband and blank IMEI (upon dialing *#06# on the phone). "Low power" connection mode also fails to write the IMEI back.
I've read the MEID fields are secured in some way. Anybody have any pointers to make it work?
By the way, the phone accepts any 16-digit diagnostic password in the aforementioned tools. I've been told it may not apply to phones other than Samsung devices. Could it be possible the phone is waiting for the correct 16-digit password to "unlock" the MEID fields, and simply accepts other passwords but does NOT unlock the fields?
I have also tried flashing stock firmware, and it appears it wasn't the case where phone is not able to read the stored IMEI.

Anybody have any clues about the security used?

Writing IMEI isn't allowed to discuss over here since it's illegal. Just send it to a LG center and let them write it for you.
May be @bitdomo can help you will the partition/security query you've got

halfbytecode said:
Anybody have any clues about the security used?
Click to expand...
Click to collapse
I am not familiar with efs yet.
Maybe try to follow the guide about fix imei on lg g2. It could serve as a good base. http://forum.xda-developers.com/showthread.php?t=2701861
If you have a backup of your efs before you started editing the nvitems then restore it. It is important to make efs backup before you start to play with those kind of efs tools.

vin4yak said:
Writing IMEI isn't allowed to discuss over here since it's illegal. Just send it to a LG center and let them write it for you.
May be @bitdomo can help you will the partition/security query you've got
Click to expand...
Click to collapse
I'm just trying to fix my device here on my own, by writing back the IMEI found on my phone's sim tray, box, etc. I'm kind of broke these days, so it's hard.
bitdomo said:
I am not familiar with efs yet.
Maybe try to follow the guide about fix imei on lg g2. It could serve as a good base. http://forum.xda-developers.com/showthread.php?t=2701861
If you have a backup of your efs before you started editing the nvitems then restore it. It is important to make efs backup before you start to play with those kind of efs tools.
Click to expand...
Click to collapse
I had indeed tried out NV Manager in QPST, but it failed to write to item number 550 (IMEI).
In fact I found this exact same guide and a bunch of others too.
I'm kind of surprised it works on LG g2 and not for me on nexus 5.
Could it be possible the diagnostic mode that was enabled by modifying the kernel (found here on XDA) didn't enable it fully?

halfbytecode said:
I'm just trying to fix my device here on my own, by writing back the IMEI found on my phone's sim tray, box, etc. I'm kind of broke these days, so it's hard.
I had indeed tried out NV Manager in QPST, but it failed to write to item number 550 (IMEI).
In fact I found this exact same guide and a bunch of others too.
I'm kind of surprised it works on LG g2 and not for me on nexus 5.
Could it be possible the diagnostic mode that was enabled by modifying the kernel (found here on XDA) didn't enable it fully?
Click to expand...
Click to collapse
It could be. What if we find a lg g2 as a donor. You flash the efs from your nexus to lg g2 and try to fix it, then if it worked you move the fixed efs from lg g2 back to nexus 5.
Nexus 5 has a second recovery it is on the LAF partition, this is called download mode. By exteacting the ramdisk of it I found traces that it could be used with qpst. To enable it I have to edit the ramdisk. The file which have to be edited is usb.init.rc or something similar. I dont remember well.
I can extract ramdisk and change the content, but I dont know the command parameters for put the kernel image and the ramdisk together as a whole boot.img

bitdomo said:
It could be. What if we find a lg g2 as a donor. You flash the efs from your nexus to lg g2 and try to fix it, then if it worked you move the fixed efs from lg g2 back to nexus 5.
Nexus 5 has a second recovery it is on the LAF partition, this is called download mode. By exteacting the ramdisk of it I found traces that it could be used with qpst. To enable it I have to edit the ramdisk. The file which have to be edited is usb.init.rc or something similar. I dont remember well.
I can extract ramdisk and change the content, but I dont know the command parameters for put the kernel image and the ramdisk together as a whole boot.img
Click to expand...
Click to collapse
I'm not really sure where I could find a donor g2. The plan could work though.
The boot IMG with diag mode is on page 3 here http://forum.xda-developers.com/showthread.php?t=2535478 if you want to look.
I may be able to figure out how to put ramdisk together with the zimage (of the diag mode kernel above). I've analyzed some kernels which do it using updater-script. In the past I've also used tools like android kitchen (not sure about the exact name).

@bitdomo Are you referring to this file?
https://android.googlesource.com/device/lge/hammerhead/+/kitkat-release/init.hammerhead.usb.rc

halfbytecode said:
I'm not really sure where I could find a donor g2. The plan could work though.
The boot IMG with diag mode is on page 3 here http://forum.xda-developers.com/showthread.php?t=2535478 if you want to look.
I may be able to figure out how to put ramdisk together with the zimage (of the diag mode kernel above). I've analyzed some kernels which do it using updater-script. In the past I've also used tools like android kitchen (not sure about the exact name).
Click to expand...
Click to collapse
hm... comparing the laf ramdis and the diag enabled ramdisk I have to say that I was wrong, but still this is a interesting thing in the init.laf.usb.rc file:
# it can run as user cable for QCT PID
on property:ro.boot.laf=QCOM
wait /sys/class/android_usb/android0/enable
write /sys/class/android_usb/android0/enable 0
write /sys/class/android_usb/android0/idVendor 05C6
write /sys/class/android_usb/android0/idProduct 903A
write /sys/class/android_usb/android0/f_acm/acm_transports tty
write /sys/class/android_usb/android0/f_diag/clients diag
write /sys/class/android_usb/android0/functions mtp,laf
write /sys/class/android_usb/android0/enable 1
Click to expand...
Click to collapse
What could this QCT PID be? I thought these are the lines for teh diag mode.
Here is the laf image with extracted ramdisk and some from here to build the kernel
You could also try this early key lime pie rom. This is an internal test version of android 4.4 from september or august. Maybe this kernel can be used to enable diag mode. If I remember well it may have an app called hidden menu where you can change the usb port settings so you dont need root an use adb commands. Before you flash it backup you misc partition because at the first booting this rom will change the device factory version string on the misc partition to something else which will cause cause that LG flashtool will stop wokring for you device unless you change that string back from "FACTORY" to "USER"
to backup your misc: dd if=/dev/block/platform/msm_sdcc.1/by-name/misc of=/sdcard/misc.img
from your sdcard copy it to you pc just for safety reasones
To return to stock flash back any stock rom from google then restore your misc partition using this command:
dd if=/sdcard/misc.img of=/dev/block/platform/msm_sdcc.1/by-name/misc

Well that is really intriguing. I was oblivious to the laf mode. I did know about .tot files and lg flash tool, but nothing more than that.
I see laf has seprate a kernel and a ramdisk, which is what you were talking about all along. It makes sense to me now.
I will give this a shot when I have some free time on my hands and will let you know.
Thanks for the key lime pie leak too!

halfbytecode said:
Well that is really intriguing. I was oblivious to the laf mode. I did know about .tot files and lg flash tool, but nothing more than that.
I see laf has seprate a kernel and a ramdisk, which is what you were talking about all along. It makes sense to me now.
I will give this a shot when I have some free time on my hands and will let you know.
Thanks for the key lime pie leak too!
Click to expand...
Click to collapse
I already extracted it for you, the original laf is the "laf.img" everything is untouched.

bitdomo said:
I already extracted it for you, the original laf is the "laf.img" everything is untouched.
Click to expand...
Click to collapse
Yes I will give that a shot soon and see what happens. Thanks for the help so far.

@bitdomo I modified the file that you mentioned, swapping USER and QCOM lines. Repacked the ramdisk, and then put together the laf image by supplying the base address, ramdisk address, command line value and page size from the the original laf dump. I flashed it on my phone using Terminal Emulator using the following command:
Code:
dd if=/sdcard/laf1.img of=/dev/block/platform/msm_sdcc.1/by-name/laf
Now when I connect the phone in download mode, the phone is stuck at the tiny "Download Mode" logo and windows does not detect any USB device.
Further, I observed the original dump size is 22 MB and the repacked laf image size is merely 13.2 MB. The size of the extracted kernel and ramdisk sums up to 13.2 MB.
It gets me to think these tools are missing out on the remaining stuff in the laf image. Ive uploaded the modified laf image. https://www.sendspace.com/file/f31xi1

I didn't read these posts just wanted to share my experience...
This happened to me 2x months and months ago ( lost Imei) I don't remember what I was doing to cause it but the only thing that fixed it for me was my TWRP backup . my backup efs file did nothing factory IMG did nothing and everything else I tries did nothing . agn this probably helps u NONE but wanted share anyways ...

Tampering with the imei is illegal
Sent from my Nexus 5

drawde40599 said:
I didn't read these posts just wanted to share my experience...
This happened to me 2x months and months ago ( lost Imei) I don't remember what I was doing to cause it but the only thing that fixed it for me was my TWRP backup . my backup efs file did nothing factory IMG did nothing and everything else I tries did nothing . agn this probably helps u NONE but wanted share anyways ...
Click to expand...
Click to collapse
Yes, it may help someone reading this thread.
dicecuber said:
Tampering with the imei is illegal
Sent from my Nexus 5
Click to expand...
Click to collapse
Just trying to restore the IMEI. I'm not attempting to do something illegal.

halfbytecode said:
@bitdomo I modified the file that you mentioned, swapping USER and QCOM lines. Repacked the ramdisk, and then put together the laf image by supplying the base address, ramdisk address, command line value and page size from the the original laf dump. I flashed it on my phone using Terminal Emulator using the following command:
Code:
dd if=/sdcard/laf1.img of=/dev/block/platform/msm_sdcc.1/by-name/laf
Now when I connect the phone in download mode, the phone is stuck at the tiny "Download Mode" logo and windows does not detect any USB device.
Further, I observed the original dump size is 22 MB and the repacked laf image size is merely 13.2 MB. The size of the extracted kernel and ramdisk sums up to 13.2 MB.
It gets me to think these tools are missing out on the remaining stuff in the laf image. Ive uploaded the modified laf image. https://www.sendspace.com/file/f31xi1
Click to expand...
Click to collapse
@bitdomo I compared the original laf dump and my modified image using a hex editor.
Just as I had suspected, the original dump is padded with zeros. Disregarding that, their actual size looks similar.
So I take back what I said about the tools not being able to extract from the laf image completely.
Do you know what could be the issue here?
EDIT: There was an interesting tidbit from unmkbootimg output. (The full command line output is attached with this post, ramdisk was repacked separately using the tool in the package - not in the output)
Code:
*** WARNING ****
This image is built using NON-standard mkbootimg!
OFF_KERNEL_ADDR is 0xFD908100
OFF_RAMDISK_ADDR is 0x00200100
OFF_SECOND_ADDR is 0xFE800100
Please modify mkbootimg.c using the above values to build your image.
****************
Could compiling mkbootimg with the above be of any help, since the mkbootimg had been modified to include ramdisk address parameter in the links you posted?

halfbytecode said:
@bitdomo I compared the original laf dump and my modified image using a hex editor.
Just as I had suspected, the original dump is padded with zeros. Disregarding that, their actual size looks similar.
So I take back what I said about the tools not being able to extract from the laf image completely.
Do you know what could be the issue here?
EDIT: There was an interesting tidbit from unmkbootimg output. (The full command line output is attached with this post, ramdisk was repacked separately using the tool in the package - not in the output)
Code:
*** WARNING ****
This image is built using NON-standard mkbootimg!
OFF_KERNEL_ADDR is 0xFD908100
OFF_RAMDISK_ADDR is 0x00200100
OFF_SECOND_ADDR is 0xFE800100
Please modify mkbootimg.c using the above values to build your image.
****************
Could compiling mkbootimg with the above be of any help, since the mkbootimg had been modified to include ramdisk address parameter in the links you posted?
Click to expand...
Click to collapse
what was the command you used to put the kernel and the modified ramdisk together?

halfbytecode said:
Yes, it may help someone reading this thread.
Just trying to restore the IMEI. I'm not attempting to do something illegal.
Click to expand...
Click to collapse
U no what I just remembered how I lost my IMEI back then . I was updating to 4.4.3 from factory .IMG and did the command "Fastboot wipe cache" after fastbooting the system.IMG . ( I no it makes no sense) but that's how mine was lost . now I just Fastboot system.IMG with new updates no wipe cache and works perfect . but ya a restore of TWRP was only thing that fixed it .

bitdomo said:
what was the command you used to put the kernel and the modified ramdisk together?
Click to expand...
Click to collapse
I used
Code:
mkbootimg --kernel laf_dump.img-kernel --ramdisk new-ramdisk.cpio.gz --base 0x026fff00 --cmdline '"console=ttyHSL0,115200,n8 androidboot.hardware=hammerhead user_debug=31 maxcpus=2 msm_watchdog_v2.enable=1"' --pagesize 2048 --ramdiskaddr 0x02900000 -o laf_q_mod_3.img
Just a note, this is the modified mkbootimg which has "ramdiskaddr" parameter (from the thread you linked to in one of your previous posts). Version shipped with bbqlinux distribution has "ramdisk_offset" instead. The original version does not have either, as you may know.

Related

Requesting expert help on collecting MD5 on Xoom (virgin) Wifi image files

So, I've picked up my replacement Xoom after bricking my first. I decided to rip my system and recovery partitions again for completeness, after discovering BeagleBoy's system.img was different from mine. I've posted my Xoom WiFi (MZ604) recovery.img in another thread. Anyway, I can confirm the WiFi recovery partition on both my old Xoom and new Xoom have an MD5 of 1f853c8636ab22b5d651a5512f0865c0. Great success! I hope others with a virgin Xoom Wi-Fi can confirm with me.
And here's something interesting... After ripping a new system.img (MD5 4b7b974a0cc8cdc00521de970b7fc611) from my new Xoom, I did a compare against my first system.img from my bricked Xoom. And also against BeagleBoy's. ALL 3 ARE DIFFERENT. I think I may have compromised my first system.img from my bricked Xoom by doing an "adb remount" before ripping the partition.
Now to confirm... With system.img having been extracted (and backed up) from my new Xoom. I performed an "adb remount" and immediately ripped the system partition again. Did a new MD5 check and... It changed... It's looking like a RW remount does compromise the "virginity" of the system.img file.
One more thing... I'm hoping someone with a factory locked WiFi Xoom can replicate BeagleBoy's boot.img file (MD5 051d1f7e150d4077adb388b5f8e53462). He flashed the Tiamat kernel onto the recovery partition instead of the boot partition (to maintain its integrity) and booted into recovery (Beagle, if you can elaborate on how to do this, please do).
I asked for expert help so I will not be doing step-by-step instructions.
Testing method 1 (retrieving system.img and recovery.img):
1. Put virgin Xoom in fastboot mode (if you can't do this, you shouldn't be helping)
2. Do a "fastboot oem unlock" and "fastboot flash boot.img" where boot.img is the Tiamat boot image to give you basic root. Reboot into normal mode.
3. With USB debugging on, do an "adb shell". Do not do a remount during test!
4. At the root (#) prompt, extract your system and recovery using the following commands (do recovery first, much faster):
dd if=/dev/block/platform/sdhci-tegra.3/by-name/recovery of=/mnt/sdcard/recovery_wifi_virgin.img
dd if=/dev/block/platform/sdhci-tegra.3/by-name/system of=/mnt/sdcard/system_wifi_virgin.img
Click to expand...
Click to collapse
5. Do an "adb pull" of the two .img files you created in /mnt/sdcard/.
6. Run a MD5 on the two files and report here.
7. ???
8. Profit
Test method 2 (install Tiamat into recovery partition and extract boot.img and system.img)
1. I will edit this section as needed. But the gist of it is to install Tiamat into recovery partition and then extract boot.img and system.img using a similar method to above...
...
8. In fastboot, reflash the recovery partition I saved on
References:
BeagleBoy's thread for his boot.img and system.img (http://forum.xda-developers.com/showthread.php?t=1017398)
My thread for the recovery.img file I first extracted (and hoping is consistant between all Xoom WiFi's of varying regions) at http://forum.xda-developers.com/showthread.php?t=1036574
Placeholder for an external link to my system.img file (when I have time to upload it somewhere for hosting)
Scourge1024's MD5 test results on old Xoom (fail?):
boot.img - (not tested)
system.img - 203465c9fb9d6bc926dd0dea9b85ebc4 (not valid as a clean image after remount)
recovery.img - 1f853c8636ab22b5d651a5512f0865c0 (matches my new Xoom; may not)
Scourge1024 new Xoom (Win?):
boot.img - (not tested)
system.img - 4b7b974a0cc8cdc00521de970b7fc611 (never RW mounted, hoping this is consistant)
recovery.img - 1f853c8636ab22b5d651a5512f0865c0 (matches my new Xoom; may not)
BeagleBoy:
boot.img - 051d1f7e150d4077adb388b5f8e53462 (trying to find out if this is consistent)
system.img - fd78a2297290c3fdc7377ded6090e2ae (does not match either of mine)
recovery.img - (not tested; overwritten)
Now to see if people can get a consistant MD5 for boot.img...
My expectation is that the kernel images (not the entire boot images) should be identical across devices and between boot and recovery.
The system image differences you're experiencing are probably expected -- remember *access* times are logged within the file system, it is ext4 after all -- and because you're pulling a system image, rather than the files themselves, you see a difference. Things like that are going to be difficult to eliminate.
ydaraishy said:
My expectation is that the kernel images (not the entire boot images) should be identical across devices and between boot and recovery.
The system image differences you're experiencing are probably expected -- remember *access* times are logged within the file system, it is ext4 after all -- and because you're pulling a system image, rather than the files themselves, you see a difference. Things like that are going to be difficult to eliminate.
Click to expand...
Click to collapse
If system is left in read-only access, would the access times be affected? I'm thinking this is possibly the reason why my "fastboot oem lock" failed. I had been able to relock my device before touching the boot, system and recovery partitions. Userdata was obviously changed the moment I booted up normally so I think that can be taken out of the equation. Plus, it gets wiped each lock/unlock anyway.
Anyway, I'm NOT going to try relocking my new Xoom... One heart attack was enough. And Best Buy might catch on I'm doing something I shouldn't be.
Can someone grab their MZ604 recovery partition? I'd like to see if they get the same MD5 I do. I doubt anyone has a modified recovery partition besides BeagleBoy. I'm trying to isolate if there's any difference between Canadian Wi-Fi Xooms (like my own) and the US ones. I already know my recovery partition is different than the MZ600 Verizon Xoom.
Think about this people... If Moto isn't going to give us Wi-Fi guys official img files, we'll have to get them ourselves.
Scourge1024 said:
If system is left in read-only access, would the access times be affected? I'm thinking this is possibly the reason why my "fastboot oem lock" failed. I had been able to relock my device before touching the boot, system and recovery partitions. Userdata was obviously changed the moment I booted up normally so I think that can be taken out of the equation. Plus, it gets wiped each lock/unlock anyway.
Anyway, I'm NOT going to try relocking my new Xoom... One heart attack was enough. And Best Buy might catch on I'm doing something I shouldn't be.
Can someone grab their MZ604 recovery partition? I'd like to see if they get the same MD5 I do. I doubt anyone has a modified recovery partition besides BeagleBoy. I'm trying to isolate if there's any difference between Canadian Wi-Fi Xooms (like my own) and the US ones. I already know my recovery partition is different than the MZ600 Verizon Xoom.
Think about this people... If Moto isn't going to give us Wi-Fi guys official img files, we'll have to get them ourselves.
Click to expand...
Click to collapse
I'd say mounting ro might help, but I'm not sure. It's possible filesystem metadata might change even if mounted read-only. I'd need to know more about ext4 to make a firm call.
One really needs to know what the "fastboot oem lock" procedure is using to validate the currently written images -- I have a feeling a signature check is being made, but I can't be sure of that. It might be fruitful to diff the Moto-provided images with ones dd'd off a running MZ600, perhaps. All just guesses though.
(let alone how cruddily designed it is to be only transitioned between lock and unlock states with correct firmware and no validation being made -- ie., it's very nicely easy to brick)

[GUIDE] Changing the Bootloader Graphic

WARNING: This guide involves modifying your phone's boot loader and may brick your phone if done incorrectly. It is most likely to soft brick your phone if something goes wrong, meaning it should be recoverable.
NOTE: This guide instructs how to replace the boot graphic in the boot loader but does not modify the kernel graphic. Doing this requires compiling the kernel.
Prerequisites:
Heimdall or Odin, with appropriate drivers. (The guide is for Heimdall)
A replacement.jpg graphic that is not greater than 68,849 bytes. The file should be 480x800.
A copy of param.lfs for your phone. This file is included in the Heimdall one-click packages, and probably other places.
Running Gingerbread bootloaders.
Steps:
Open both replacement.jpg and param.lfs in a hex editor.
Go to offset 532480 in param.lfs. At this location, there should be a JPG beginning of file (BOF) marker FF D8.
Verify that offset 601327 contains the JPG end of file (EOF) marker, FF D9. There are other JPG BOF and EOF markers between these two offsets because this JPG file contains embedded thumbnails for some stupid reason.
Go back to offset 532480. Use your hex editor to paste the contents of replacement.jpg into param.lfs at offset 532480 in overwrite mode. Use of overwrite mode will ensure that the file does not change size and other offsets are not affected. Use of a replacement.jpg less than 68,849 bytes ensures that other data within param.lfs is not overwritten.
Save new file as param2.lfs. Verify it is the same size as param.lfs
Heimdall:
Ensure that Heimdall, the Heimdall front-end, and appropriate drivers are installed.
Connect your phone via USB and start the Heimdall front-end.
Under the Utilities tab, click Save As and save your PIT as device.pit.
Click Download.
Under Flash tab, in the PIT subwindow, click Browse and select device.pit.
Click Add in the Partitions (Files) subwindow, and select PARAM from the Partition Details subwindow. NOTE: if you do not select the PARAM partition, there is potential to hard brick your device when you flash.
Click Browse in the File subwindow, and select your modified param2.lfs. NOTE: If your param2.lfs is corrupted, or if the flash otherwise fails, your device will be soft bricked and your device will be in download mode (although it will not have the familiar yellow screen). Attempt to reflash the PARAM partition with param.lfs.
Verify that PARAM is selected in the Partition Details subwindow. Click Start to flash param2.lfs with Heimdall to the PARAM partition.
Credit:
hexedit method: http://forum.xda-developers.com/showthread.php?t=1315401
These are some handy utility functions I wrote in Python.
This script finds most of the JPG files in param.lfs. It will choke on JPG files with embedded images.
Code:
import re
jpg = re.compile(b'\xff\xd8.*?\xff\xd9', re.DOTALL);
data = open('param.lfs','rb').read()
jpgs = re.findall(jpg, data)
for i,image in enumerate(jpgs):
open( str(i)+'.jpg', 'wb' ).write(image)
This lists all the JPG BOF and EOF file markers. Helps for spotting images with embedded thumbnails.
Code:
import re
import binascii
jpg = re.compile(b'\xff[\xd8\xd9]', re.DOTALL);
data = open('param.lfs','rb').read()
markers = re.findall(jpg, data)
for i, m in enumerate(markers):
print "%i: %s" % (i, binascii.hexlify(m))
An update to this post. I have written a script which is run on your desktop with a Python installation that perofrms the modification of the param.lfs binary. Attached to this post is a package containing (1) logoreplace.py, (2) param.lfs [from GB bootloader], (3) Sgs4g.pit [also from GB bootloader].
Also, I have attached a param_acid.lfs with the Team Acid logo. This will go well with your team acid kernels.
(1) ./logoreplace.py logo.jpg param.lfs
(2) adb reboot download
(3) Run heimdall-frontend
(4) Click "Flash" tab.
(5) Browse to Sgs4g.pit. Add.
(6) Select PARAM partition.
(7) Browse to param_acid.lfs
(8) Click "Start" to flash.
Here is the code:
Code:
#!/usr/bin/env python
import sys,os
if __name__ == "__main__":
if len(sys.argv) != 3:
print "Usage: %s <logo.jpg> <param.lfs>" % (sys.argv[0],)
else:
image = open(sys.argv[1],'rb').read()
fw = open(sys.argv[2],'rb+')
if len(image) <= 68849:
fw.seek(532480)
fw.write(image)
else:
print "Image file is too long. Must be <= 68849 bytes."
@tablador How do I use the script that performs the modification of the param.lfs binary (logoreplace.zip)?
I tired running the logoreplace.py after inserting my replacement.jpg in the directory on my phone and got:
Code:
/sdcard/logoreplace.py
import: not found
/sdcard/logoreplace.py 5:syntax error word unexpected (expecting ")")
I used both methods listed in the OP as well with no luck (Did not find the offsets mentioned in the first method and was a little lost on what to copy from the replacement.jpg).
I did read both OPs that you linked to in the credits.
I using the alternate method, I received an error when trying to copy replacement.jpg (In both ADB and Terminal):
Code:
cp: can't create '/mnt/.lfs/logo_T759.jpg': file exists
I am using vb final, and bh's rc1.
thomas.raines said:
@tablador How do I use the script that performs the modification of the param.lfs binary (logoreplace.zip)?
Click to expand...
Click to collapse
Are you running the script on your phone? The script runs on your desktop via Python. Sorry if that wasn't clear. Once you create the file, you flash it using Heimdall.
Also, I removed the alternate method information. As I noted, that method was untried and untested on this phone, and from what I can tell after trying it, does not seem to work. My best guess is that phone's bootloader has the offset of that information stored directly (e.g. bypasses the filesystem) so renaming the file does not work. OP all revised to reflect this.
Yes, I ran it in python. But it didn't change anything. I also renamed my image (replacement.jpg) to logo.jpg.
I added a raw_input() to see if I could see an error or something to indicate any kind of activity.
This is the output I got:
Code:
Usage: C:\Users\mydirectory\desktop\logoreplace\logoreplace.py <logo.jpg> <param.lfs>
Which is what you have set to print. Otherwise, there are no errors. I have my logo.jpg in the same directory as the logoreplace.py. What can I possibly be doing wrong?
How exactly are you running the script? And what OS?
tablador said:
How exactly are you running the script? And what OS?
Click to expand...
Click to collapse
Windows 7 (32)
I have double clicked on it, and tried running it manually using python.exe terminal and no errors. Am I suppose to copy my logo.jpg to /mtn/.lfs?
Would it be easier to just send you my logo and you could hook it up? lol...
How exactly are you running the script? If you don't tell me, I can't figure out what the problem is. Are you typing something into the commandline in windows? If so, what?
tablador said:
How exactly are you running the script? If you don't tell me, I can't figure out what the problem is. Are you typing something into the commandline in windows? If so, what?
Click to expand...
Click to collapse
I have tried typing the code you wrote in a python terminal for windows.
I have tried just running it by double clicking on it.
I just tried it in portable ubuntu by double clicking on it, but cannot get it to run (only open in text editor). I also changed it to open with python and I Usage: /home/pubunto/Desktop/logoreplace/logoreplace.py <logo.jpg> <param.lfs>.
I would think I would need to add my logo.jpg to .mnt/.lfs so it knew what image to look for.
I just tried running the logoreplace.py via pubuntu terminal. Here is the output:
Code:
[email protected]:/home/pubuntu/Desktop/logoreplace# ./logoreplace.py <logo.jpg> param.lfs
bash: ./logoreplace.py: Permission denied
[email protected]:/home/pubuntu/Desktop/logoreplace#
thomas.raines said:
I have tried typing the code you wrote in a python terminal for windows.
I have tried just running it by double clicking on it.
I just tried it in portable ubuntu by double clicking on it, but cannot get it to run (only open in text editor). I also changed it to open with python and I Usage: /home/pubunto/Desktop/logoreplace/logoreplace.py <logo.jpg> <param.lfs>.
I would think I would need to add my logo.jpg to .mnt/.lfs so it knew what image to look for.
I just tried running the logoreplace.py via pubuntu terminal. Here is the output:
Code:
[email protected]:/home/pubuntu/Desktop/logoreplace# ./logoreplace.py <logo.jpg> param.lfs
bash: ./logoreplace.py: Permission denied
[email protected]:/home/pubuntu/Desktop/logoreplace#
Click to expand...
Click to collapse
This is what you need to type:
Code:
./logoreplace.py logo.jpg param.lfs
tablador said:
This is what you need to type:
Code:
./logoreplace.py logo.jpg param.lfs
Click to expand...
Click to collapse
Yep. Just figured that out right after I sent the output. But now it change the param.lfs icon from a text icon to an blank icon with "usage" on the top. I flahsed it with heimdall which said heimdall crashed and got a oddly colorful strip on the top of the screen and now the phone is soft bricked... lol... I checked the size of my jpeg and see that it is 3 bytes over the allocated size...lol... Going to shrink it and try again... Will keep you posted...
EDIT
I got it to work! YAY!
Thanks for your help man!
The only thing, it displays before the normal boot splash logo (logo_vibrantplus.jpg). Is there a way to either replace logo_vibrantplus.jpg, or make it display after the default boot splash?
thomas.raines said:
Yep. Just figured that out right after I sent the output. But now it change the param.lfs icon from a text icon to an blank icon with "usage" on the top. I flahsed it with heimdall which said heimdall crashed and got a oddly colorful strip on the top of the screen and now the phone is soft bricked... lol... I checked the size of my jpeg and see that it is 3 bytes over the allocated size...lol... Going to shrink it and try again... Will keep you posted...
EDIT
I got it to work! YAY!
Thanks for your help man!
The only thing, it displays before the normal boot splash logo (logo_vibrantplus.jpg). Is there a way to either replace logo_vibrantplus.jpg, or make it display after the default boot splash?
Click to expand...
Click to collapse
That image is in the kernel. You would have to do your own compile. I know how to do it but it involves setting up a toolchain. I will make a guide when I have time...
Also, it is interesting that the script didn't give you an error when the filesize was bigger than it should have been. I will check that out.
tablador said:
That image is in the kernel. You would have to do your own compile. I know how to do it but it involves setting up a toolchain. I will make a guide when I have time...
Also, it is interesting that the script didn't give you an error when the filesize was bigger than it should have been. I will check that out.
Click to expand...
Click to collapse
Oh... I have no idea about setting up a toolchain or doing anything related to the kernel... yet...lol
thomas.raines said:
Oh... I have no idea about setting up a toolchain or doing anything related to the kernel... yet...lol
Click to expand...
Click to collapse
http://forum.xda-developers.com/wiki/Samsung_Galaxy_S/SGH-T959V/Building_From_Source
@FBis251 Thanks man, but still a little above my knowledge/experience level...lol...
I have attached a modified param.lfs file. I gzipped it. This should match the latest teamacid logo pretty well. Also attached is the jpg I used, which hopefully is viewable.
tablador said:
I have attached a modified param.lfs file. I gzipped it. This should match the latest teamacid logo pretty well. Also attached is the jpg I used, which hopefully is viewable.
Click to expand...
Click to collapse
not bad. gotta love plugins that modify already made images. plus if you're using team acid's latest kernel, you'll notice that they're already using the logo i made them.
sent from within pure darkness
tablador said:
I have attached a modified param.lfs file. I gzipped it. This should match the latest teamacid logo pretty well. Also attached is the jpg I used, which hopefully is viewable.
Click to expand...
Click to collapse
I was meaning to ask you for this. I really liked the video you linked us to on IRC. It makes it look so sleek.
droidmyst said:
not bad. gotta love plugins that modify already made images. plus if you're using team acid's latest kernel, you'll notice that they're already using the logo i made them.
sent from within pure darkness
Click to expand...
Click to collapse
This image will display for the one second or two before the kernel image you made loads up. Yep, used a simple Photoshop plugin because I am not much artistically inclined, at least with photoshop. Still, this kinda gives a fade-in effect when combined with your image used as the kernel image.
http://www.youtube.com/watch?v=kxBpKKDmnFY
FB, I was thinking this could be put into any one clicks you guys made if you wanted to get this in somewhere.

[IMP] [SCRIPTS] IMEI backup scripts for MOTO G /E(all variants) Rooted.

This script creates backup of partitions related to IMEI number. If you have not unlocked your boot-loader then you do not have to worry, you're safe. But read this in case you root someday!
DISCLAIMER:
I am not responsible for any damage caused to your device in any manner, you should be careful while doing anything. Before you proceed please read everything.
DESCRIPTION
The IMEI number is like an identifier to your cellphone for network operators. The phones will not be able to communicate in case IMEI is lost. The IMEI number is generally stored in PDS partition of the EMMC but the Moto g is an exception, there is no physical EFS partition so NV-Items are inaccessible for manipulation which means backing up PDS partition only will not make any sense.
The EFS is created on the fly: the modem reads HOB and DHOB partitions and after manipulations it creates a EFS file-system which is isolated from rest of the system. The modem finds the baseband, MEID, IMEI etc. and reports it to the OS.
The DHOB partition is encrypted and the key used is a PBKFD2 derived key for which the details like passkey, salt and iterations are unknown. HOB partition is XML-formatted and contains encrypted base64 text items. The secret is yet to be discovered.
Reference
http://forum.xda-developers.com/moto-g/help/info-moto-g-imei0-t2925970/post62064474#post62064474
http://forum.xda-developers.com/showthread.php?t=2640677
What does the script do?
This script simply creates the dumps of HOB, DHOB, FSC and PDS partition.
REQUIREMENTS:
A rooted phone is bare minimum and rest depends upon the method you choose. Download the archive one is for Linux and other is for Windows.
Choose any one.
FROM PHONE:-
1. Download and install any “Terminal Emulator” application from App store.
2. Type su and press enter to have superuser privileges.
3. Run these commands one-by-one.
HTML:
su
mkdir /sdcard0/imei_backup
dd if=/dev/block/platform/msm_sdcc.1/by-name/hob" of=/sdcard0/imei_backup/hob.img
dd if=/dev/block/platform/msm_sdcc.1/by-name/dhob" of=/sdcard0/imei_backup/dhob.img
dd if=/dev/block/platform/msm_sdcc.1/by-name/fsc" of=/sdcard0/imei_backup/fsc.img
dd if=/dev/block/platform/msm_sdcc.1/by-name/pds" of=/sdcard0/imei_backup/pds.img
4. Copy imei_backup from the top folder of internal storage or SD-card.
FROM PC:-
1. Enable ROOT for both apps and adb from developer options.
2. Open cmd or terminal hange current location to folder imei_linux or imei_windows extracted from archive.
3. Run the below commands from cmd or terminal.
Windows
Make sure you have Motorola drivers installed (Motorola device manager).
HTML:
imei_backup.bat
Linux
Superuser privileges are necessary.
HTML:
sudo bash imei_backup.sh
or
su -C 'bash imei_backup.sh'
4. Once finished save imei_backup folder to someplace safe. The folder sits in the same folder the commands are run and in phone's internal storage or SD card.
FOR RESTORATION
1. Copy imei_backup folder to /sdcard (both internal or SD-Card in case you are not sure)
2. Open terminal emulator on phone and run these commands, all of them do not miss any. Run all of them twice to be sure.
HTML:
dd if=/sdcard0/imei_backup/hob.img of=/dev/block/platform/msm_sdcc.1/by-name/hob"
dd if=/sdcard0/imei_backup/dhob.img of=/dev/block/platform/msm_sdcc.1/by-name/dhob"
dd if=/sdcard0/imei_backup/fsc.img of=/dev/block/platform/msm_sdcc.1/by-name/fsc"
dd if=/sdcard0/imei_backup/pds.img of=/dev/block/platform/msm_sdcc.1/by-name/pds"
4. Reboot your phone.
How to keep IMEI safe:
1. Do not use incompatible Roms or firmware.
2. Never run these commands.
Don't even try, I have screwed my phone already. Misspelled for safety.
HTML:
Fast-boot erasee all (Don't)
Fast-boot erasee recovery (Don't)
Fast-boot erasee HOB (Don't)
Fast-boot erasee DHOB (Don't)[/COLOR]
Fast-boot erasee earth (Please Don't)
Run any of these commands and your phone turn into a tablet forever.
3. Create backup of the partitions i mentioned using one of the methods.
FAQS:-
Does it work on Dual-Sim or CDMA ?
Yes, it works. It just creates partition dumps, nothing more nothing less. It should work on Moto G (1st and 2nd gen) all variants and Moto E (1st and 2nd).
Is it safe to share my imei_backup folder if anyone asks?
Yes, the content is encrypted and there is no chance of manipulation of IMEI, the NV-ITEMS are written after verification. No two phones can have same IMEI. If it was possible then I wouldn't be so mad or worried or you would not be reading this. The best he could achieve is base-band change and signal but IMEI stays zero. No Cheating!
I have PDS partition backup, why should I care about this?
The PDS partition alone is no good for recovery, there are other partitions which help phone get a working cellular and valid IMEI number, those partition are HOB and DHOB. You can create backup through terminal emulator.
Why should I believe you?
I am a victim and did research on this for like 30 days. I do have a clear idea of what the problem really is. Please refer to mentioned threads for more information.
I have lost my IMEI because of “fast-boot erase all” command, can I get my IMEI back?
Sorry! But there is no working solution at the moment. All you can do right now is either buy a new motherboard or a spare phone to do work. The cure has not been found till now and hopes are really low unless some guy with good cryptography knowledge comes to rescue. So far i only know the problem
Very useful, thanks. Just want to add my experience - actually I did run "fast-boot erasee recovery" once in the past and did lost IMEI, but it was possible to recover it in an easy way. But those other commands seem to be really catastrophic indeed (though I haven´t tried them )
Here´s the original story: http://forum.xda-developers.com/showthread.php?p=52648789
drfr said:
Very useful, thanks. Just want to add my experience - actually I did run "fast-boot erasee recovery" once in the past and did lost IMEI, but it was possible to recover it in an easy way. But those other commands seem to be really catastrophic indeed (though I haven´t tried them )
Here´s the original story: http://forum.xda-developers.com/showthread.php?p=52648789
Click to expand...
Click to collapse
It is always better to be safe than sorry. The thing is if you lose hob and dhob partitions, you are doomed. I am glad to know that your phone is intact.
Script works well - thanks for this.
Well I'm here to ask something related to the problems issued in this thread.
I got a XT1032 with IMEI fully written but, for some reasons I still don't know, the damn phone does not "read" the signal. The bars just stay empty and nothing, not even a full original firmware restore, seems to help.
Now I wonder if the problem is in a non-working modem partition, but I'd see that problem solved when I fully flashed the stock FW.
Is there any solution? I also tried to flash all the european (I'm italian) basebands known to mankind and nothing happens.
Dionysus2389 said:
Well I'm here to ask something related to the problems issued in this thread.
I got a XT1032 with IMEI fully written but, for some reasons I still don't know, the damn phone does not "read" the signal. The bars just stay empty and nothing, not even a full original firmware restore, seems to help.
Now I wonder if the problem is in a non-working modem partition, but I'd see that problem solved when I fully flashed the stock FW.
Is there any solution? I also tried to flash all the european (I'm italian) basebands known to mankind and nothing happens.
Click to expand...
Click to collapse
When you dial *#06# do you see your IMEI number?
PuLKit4xd said:
When you dial *#06# do you see your IMEI number?
Click to expand...
Click to collapse
Yep, the IMEI is there as it is in the phone info. That's why I can't figure out what the heck is wrong with it. I also tried to flash any baseband and still no signal.
Dionysus2389 said:
Well I'm here to ask something related to the problems issued in this thread.
I got a XT1032 with IMEI fully written but, for some reasons I still don't know, the damn phone does not "read" the signal. The bars just stay empty and nothing, not even a full original firmware restore, seems to help.
Now I wonder if the problem is in a non-working modem partition, but I'd see that problem solved when I fully flashed the stock FW.
Is there any solution? I also tried to flash all the european (I'm italian) basebands known to mankind and nothing happens.
Click to expand...
Click to collapse
PuLKit4xd said:
When you dial *#06# do you see your IMEI number?
Click to expand...
Click to collapse
Dionysus2389 said:
Yep, the IMEI is there as it is in the phone info. That's why I can't figure out what the heck is wrong with it. I also tried to flash any baseband and still no signal.
Click to expand...
Click to collapse
Aaaaan then I managed to fix everything. Simply, kitkat european firmwares have some issues with basebands, so I wipe everything and flash via mfastboot the 5.0.2 brazillian stock firmware. Everything is flawless now!
Hi all, thanks for this huge piece of info, very usefull, but i need from you if you have the backup of the files for XT1540 (moto g3 4g).
Cheers
PuLKit4xd said:
This script creates backup of partitions related to IMEI number. If you have not unlocked your boot-loader then you do not have to worry, you're safe. But read this in case you root someday!
DISCLAIMER:
I am not responsible for any damage caused to your device in any manner, you should be careful while doing anything. Before you proceed please read everything.
DESCRIPTION
The IMEI number is like an identifier to your cellphone for network operators. The phones will not be able to communicate in case IMEI is lost. The IMEI number is generally stored in PDS partition of the EMMC but the Moto g is an exception, there is no physical EFS partition so NV-Items are inaccessible for manipulation which means backing up PDS partition only will not make any sense.
The EFS is created on the fly: the modem reads HOB and DHOB partitions and after manipulations it creates a EFS file-system which is isolated from rest of the system. The modem finds the baseband, MEID, IMEI etc. and reports it to the OS.
The DHOB partition is encrypted and the key used is a PBKFD2 derived key for which the details like passkey, salt and iterations are unknown. HOB partition is XML-formatted and contains encrypted base64 text items. The secret is yet to be discovered.
Reference
http://forum.xda-developers.com/moto-g/help/info-moto-g-imei0-t2925970/post62064474#post62064474
http://forum.xda-developers.com/showthread.php?t=2640677
What does the script do?
This script simply creates the dumps of HOB, DHOB, FSC and PDS partition.
REQUIREMENTS:
A rooted phone is bare minimum and rest depends upon the method you choose. Download the archive one is for Linux and other is for Windows.
Choose any one.
FROM PHONE:-
1. Download and install any “Terminal Emulator” application from App store.
2. Type su and press enter to have superuser privileges.
3. Run these commands one-by-one.
HTML:
su
mkdir /sdcard0/imei_backup
dd if=/dev/block/platform/msm_sdcc.1/by-name/hob" of=/sdcard0/imei_backup/hob.img
dd if=/dev/block/platform/msm_sdcc.1/by-name/dhob" of=/sdcard0/imei_backup/dhob.img
dd if=/dev/block/platform/msm_sdcc.1/by-name/fsc" of=/sdcard0/imei_backup/fsc.img
dd if=/dev/block/platform/msm_sdcc.1/by-name/pds" of=/sdcard0/imei_backup/pds.img
4. Copy imei_backup from the top folder of internal storage or SD-card.
FROM PC:-
1. Enable ROOT for both apps and adb from developer options.
2. Open cmd or terminal hange current location to folder imei_linux or imei_windows extracted from archive.
3. Run the below commands from cmd or terminal.
Windows
Make sure you have Motorola drivers installed (Motorola device manager).
HTML:
imei_backup.bat
Linux
Superuser privileges are necessary.
HTML:
sudo bash imei_backup.sh
or
su -C 'bash imei_backup.sh'
4. Once finished save imei_backup folder to someplace safe. The folder sits in the same folder the commands are run and in phone's internal storage or SD card.
FOR RESTORATION
1. Copy imei_backup folder to /sdcard (both internal or SD-Card in case you are not sure)
2. Open terminal emulator on phone and run these commands, all of them do not miss any. Run all of them twice to be sure.
HTML:
dd if=/sdcard0/imei_backup/hob.img of=/dev/block/platform/msm_sdcc.1/by-name/hob"
dd if=/sdcard0/imei_backup/dhob.img of=/dev/block/platform/msm_sdcc.1/by-name/dhob"
dd if=/sdcard0/imei_backup/fsc.img of=/dev/block/platform/msm_sdcc.1/by-name/fsc"
dd if=/sdcard0/imei_backup/pds.img of=/dev/block/platform/msm_sdcc.1/by-name/pds"
4. Reboot your phone.
How to keep IMEI safe:
1. Do not use incompatible Roms or firmware.
2. Never run these commands.
Don't even try, I have screwed my phone already. Misspelled for safety.
HTML:
Fast-boot erasee all (Don't)
Fast-boot erasee recovery (Don't)
Fast-boot erasee HOB (Don't)
Fast-boot erasee DHOB (Don't)[/COLOR]
Fast-boot erasee earth (Please Don't)
Run any of these commands and your phone turn into a tablet forever.
3. Create backup of the partitions i mentioned using one of the methods.
FAQS:-
Does it work on Dual-Sim or CDMA ?
Yes, it works. It just creates partition dumps, nothing more nothing less. It should work on Moto G (1st and 2nd gen) all variants and Moto E (1st and 2nd).
Is it safe to share my imei_backup folder if anyone asks?
Yes, the content is encrypted and there is no chance of manipulation of IMEI, the NV-ITEMS are written after verification. No two phones can have same IMEI. If it was possible then I wouldn't be so mad or worried or you would not be reading this. The best he could achieve is base-band change and signal but IMEI stays zero. No Cheating!
I have PDS partition backup, why should I care about this?
The PDS partition alone is no good for recovery, there are other partitions which help phone get a working cellular and valid IMEI number, those partition are HOB and DHOB. You can create backup through terminal emulator.
Why should I believe you?
I am a victim and did research on this for like 30 days. I do have a clear idea of what the problem really is. Please refer to mentioned threads for more information.
I have lost my IMEI because of “fast-boot erase all” command, can I get my IMEI back?
Sorry! But there is no working solution at the moment. All you can do right now is either buy a new motherboard or a spare phone to do work. The cure has not been found till now and hopes are really low unless some guy with good cryptography knowledge comes to rescue. So far i only know the problem
Click to expand...
Click to collapse
Need help!!
It does not work for me. whenever any command with /sdcard is written, it replies "/sdcard/hob.img :File or directory not found."
Please help.
Thanks in advance : )

[TOOL] KDZ Writer

Tool for writing portions of KDZ files to LG devices. As long as KDZ files for the particular device are available and LGE doesn't change the format in an incompatible fashion, this will handle upgrades. Presently this tool targets the format as is used with UFS devices. The LG G5 and LG V20 are examples; the G6 and V30 may turn out to be compatible.
KDZ files are available for several LG V20 variants. Notably H918TN (US T-Mobile), H990 (non-US single-SIM), H990DS (non-US dual-SIM), H990N (Korea dual-SIM), US996 (US unlocked), and VS995 (US Verizon).
The primary goal of this tool is updating /system and /firmware, though updating other areas is in theory possible.
XDA:DevDB Information
KDZ Writer, Tool/Utility for the LG V20
Contributors
emdroidle
Source Code: https://github.com/ehem/lg-v20-tools
Instructions
Boot into TWRP. Upload an appropriate KDZ for your phone somewhere on your phone. This can be on a SD card, since all known KDZ files are just under 3GB even TWRP's in-memory filesystem is sufficient. Download(the Downloads tab, above), and upload kdzwriter to your phone:
Code:
adb push kdzwriter.gz /
Then in a shell (`adb shell`):
Code:
gunzip -c /kdzwriter.gz >/sbin/kdzwriter
chmod 755 /sbin/kdzwriter
[STRIKE]umount /system
ln -s /sbin /system/bin[/STRIKE]
The `umount` command may give an error. If you're on TWRP 3.0.2-1 /system won't have been mounted and you'll get "invalid argument"; if you get an error saying "busy" there is a problem. If using version 1.95 or later, the second two commands are unnecessary.
From here you can invoke `kdzwriter` with various arguments to write /system and /firmware:
-v
Increase verbosity. At lower levels not too much is added, at level 3 `kdzwriter` starts gushing debugging information.
-r
Report mode, tells you about how the chunks in the KDZ file match your phone.
-t
Test mode, tells you whether `kdzwriter` has decided the KDZ is an appropriate match for your phone (safety check). If used with other options, `kdzwriter` will run through the write procedure and tell you whether all the steps succeed.
-a
Write areas known safe to apply to the device. As of right now this is /system, /firmware and /cust. (equivalent to -s -m -a)
-s
Write /system. If you only want to update /system, this is the option for you. By default -s will attempt to preserve the kernel modules present on /system and overwrite the ones on the new /system image with those. This is appropriate if you've installed a custom kernel.
-M
Disables preserving kernel modules from the current /system. If you've got a stock kernel you want this option. If /system has been corrupted, this also avoids mounting /system and ensures -s succeeds.
-m
Write /firmware (aka modem).
-c
Write /cust. Some files of these files appear related to VoLTE. I'm unsure whether they're critical or optional. One (seemingly harmless) error message generated when switching regions can be avoided by writing this area.
-k
Write boot (/dev/block/bootdevice/by-name/boot). If you're opting to stay with the stock kernel then you'll want this option. This can also be used to recover from a failed Magisk/SuperSU/Superuser installation.
-P
GPT restoration mode. If a "ROM" has modified the GPTs this will attempt to restore them closer to stock. There are plans to have LineageOS do just this, so I wanted to be prepared to return to stock.
-R
Modified GPT restoration mode. "userdata" is moved closer to the begining of the device potentially allowing additional data to be merged without needing to wipe.
The most common invocation will be `kdzwriter -a <some location>/<KDZ_for_your_device>.kdz`, as noted you can use "-at" to simulate the process and confirm no errors occur.
The -b option has been allocated, but are not yet implemented. A deliberate attempt to minimize flash wear has been made. Blocks will not be rewritten if possible. Empty areas will be discarded/TRIMed.
`kdzwriter` attempts to preserve some files when writing areas. When writing /system unless -M is specified, `kdzwriter` will attempt to preserve kernel modules. When writing /cust, `kdzwriter` attempts to preserve "official_op_resize.cfg" (see GPT restoration mode for details). There are plans for v2.0 to try to preserve the contents of "open_path_mapping.cfg" and "op_list.cfg".
If you get an error message about "Failed while writing /system, major problem, PANIC!" this is most likely to be caused by a corrupt KDZ file. In this case retrying the download is the most likely solution.
Apparently for some devices/KDZ files it is necessary not to skip too many revisions. Notably going from H990N version 10b to version 10o does not work; instead you need to do 10b -> 10e ->10o. This hasn't yet been observed on other devices, but beware big skips can fail.
GPT Restoration mode
There are plans to have a future version of LineageOS hack off a piece of /system to utilize as /vendor. This is reasonable for LineageOS (or another "ROM"), but a problem if you desire to return to stock. As such v1.95 has been brought out which features the ability to restore the GPTs.
Crucial item: In the interest of safety this operation demands a KDZ which is a better match for your device! You will need to use a KDZ file matching what your device was at when you initially rooted! (H990ds10b* or so for most devices)
You can confirm whether a given KDZ is appropriate using the "-t" option. If `kdzwriter -t <someKDZfile>.kdz` gives the message "KDZ appears applicable to this device" then kdzwriter will not use that file for this operation, that command must give the output "KDZ appears applicable to this device and matches original" in order to be acceptable for this operation.
On the H990 some space is stolen from userdata for use as /OP. Everything in /OP appears to be bloatware, but since I'm trying to make it possible to go back close to stock, I've got to do something about /OP. The size of /OP is controlled by the file "/cust/official_op_resize.cfg". As I didn't have a better way of handling it, I simply grab the first line and use that. If /cust is unavailable (hasn't been restored?) a size of 0 will be assumed. If a size of 0 is found, `kdzwriter` will wipe the slice^Wpartition and the space will in fact end up as part of /data (hint, hint).
Important note: Since the normal order is system, cache, cust, OP then userdata, modifying the size of /OP will require wiping /data!
The -R option restores a modified GPT. The modified GPT mode tries to reorders the slices^Wpartitions as userdata, OP, cust, system, cache. The theory is that if cust isn't needed in LineageOS, cust could be removed from the GPT and the space merged into userdata. Since userdata is then first, it could be enlarged without the need to wipe and restore.
Examples
I expect by far the most common usage to be `kdzwriter -a <somekdz>.kdz`, but as typed there extra flags for certain situations:
Recovering from bad flash attempt -sM
If there was a problem when attempting to write /system there is a decent chance it won't be possible to mount /system for saving kernel modules. In this case using `kdzwriter -sM <somekdz>.kdz` is your need. This skips mounting /system at the cost of being unable to preserve kernel modules, you will need to reinstall whatever kernel you were using.
Partial unrooting -k
If you want to switch between Magisk, SuperSU, and Superuser this is your need. `kdzwriter -k <somekdz>.kdz` overwrites the boot/kernel area with the image from the KDZ file. Your next step will likely be to reinstall whatever kernel you were using. Afterwords all traces of a systemless install will have been wiped and you can install a different `su` implementation.
Going mostly back to stock -ak
For owners of the V20s where the stock kernel works, you can use a combination of these two options to update /system and to a newer kernel (you don't want to be hit by DirtyCOW). After doing this you'll need to reinstall whichever `su` implementation you were using.
Version Information
Status: Stable
v1.98a
Identified which check was preventing installation of 20a KDZ files. That is now disabled. There is also a force option which will override the safety check, but please be careful. That safety check was written to try to make it hard to generate bricks...
v1.98
Implemented modified GPT restoration mode. This mode reorders the slices^Wpartitions during restoration. This allows for potentially merging more space into /data without needing to wipe /data again.
v1.95
Found the appropriate compiler flag for setting the runtime linker. Thanks to the TWRP folks, kdzwriter is now a bit easier to use.
Implemented GPT restoration mode. This allows for restoring modified GPTs back to stock. This is valuable if a "ROM" has modified the GPTs. Given how there are plans to have LineageOS do just that, I'm figuring a number of people may be rather interested in this feature.
v1.3
Fixed testing for whether a KDZ is applicable to the device. This should merely be a safety precaution, but I need it there so I don't get fingers pointed my way on failure.
Finally tracked down the issue with kernel module preservation. This is a really stupid bug. There should no longer be any need to reinstall modified kernels after updates!
v1.2
Added additional debugging information around calls to Zlib. There has been a report of difficulty around Zlib so extra information is available. Some of this is only available at verbosity level 3 though.
Created 2017-07-31
Last Updated 2019-01-02
v1.2
MD5: 49b06410f8f90606f9829cc8ff8ed82a
SHA1: ce1f84f579c94e788539e462febc2f2e293a64ff
SHA512: 47a94ae6c6d1157dd406319d2d44ba72c9f954c3f0ad6b892eafbb818d01a7bf9c14b0a9f01ab6f092c07537d3273f8981b83c80ebf67f2cf9e33c26f8838ad3
v1.3
MD5: a412c7fe58722b6e63560c5074bc59b7
SHA1: 8e7e1fbd2edef0ff10516c57a84b642a1a92a758
SHA512: a5b9d3a66bf4237138264a5756f1637ba849a3aeb78d935e0fe6033486de41ad56a0ca5c62b3d94546fd2b4fe86e9edf7958e80481f1f10ef7ef2b6b562a412a
v1.95
MD5: 5f8797b5829ca5a919d1d685404a2726
SHA1: 62d7476ec50a2ea3a682b86654dd1ddc03da0c24
SHA512: ee717f3803e43862dc6faac3788e16267d9661bf98f8fdeebedd6b871dcd4cadb7dc4ee5208dc6072f5f7ba44e46440a759425536a354b530584f824570283c7
v1.98
MD5: 7dfee90d7e0711f5742b94efb81a8b18
SHA1: f020345935b078ebc336e88e3b0623e0792f71ad
SHA512: 71e82f535d33cc64fe023425db0b6d924c6d11677b04843628a9c6ca90cc6700d0a6c5e868c964e31d54f7d3c835d9ecd3b6c33108926da29e75e3be3e1456b2
v1.98a
MD5: 31f207a865b453472271eed29544833e
SHA1: 42ab0486cfc100b52dde9c6bac9bca684eccfde2
SHA512: fe127bece0e25ae4927f3499d708d1533b5fe0a00513de9cb8565ffc24b3e4ee08e9000d828a0177feb4b3b449137836b63cda72cf178b5cd67ae377997a1d37
@emdroidle I'm getting "permission denied" from KDZWriter when I execute the kdzwriter -a /external_sd/H990_something.kdz command in TWRP Terminal. I noticed that I can't umount /system either, it says it's an invalid argument?
Would this be something to do with the locking of /system I read about earlier? I did try manually mounting /system in TWRP before trying anything too, but that doesn't seem to have helped at all.
I've also tried doing mount -o rw,remount,rw /system
I'm running rooted 10C-TWN firmware with Magisk (interestingly, phone will flat out refuse to boot if I flash SuperSU, so Magisk it is). When I go to install Magisk it says "mounting /system" with no problems at all
Thanks very much for your work.
Iam confused about the instructions im not very familiar with adb shell . can you please elaborate more the steps for easy running of kdzwriter. thank you and let me tell you that you are awesome
Where is kdzwriter.gz? No attachment? Works kdzwriter from Dirty Santa thread?
i am getting kdzwriter: permission denied
iDefalt said:
I'm running rooted 10C-TWN firmware with Magisk (interestingly, phone will flat out refuse to boot if I flash SuperSU, so Magisk it is). When I go to install Magisk it says "mounting /system" with no problems at all
Click to expand...
Click to collapse
My first attempt to install Magisk failed, "Unable to repack ramdisk". At which point I had a problem. Suddenly the "-k" option came into existence and a retry succeeded.
iDefalt said:
@emdroidle I'm getting "permission denied" from KDZWriter when I execute the kdzwriter -a /external_sd/H990_something.kdz command in TWRP Terminal. I noticed that I can't umount /system either, it says it's an invalid argument?
Would this be something to do with the locking of /system I read about earlier? I did try manually mounting /system in TWRP before trying anything too, but that doesn't seem to have helped at all.
I've also tried doing mount -o rw,remount,rw /system
Click to expand...
Click to collapse
Okay, I guess I'm not that great at writing instructions. The added `chmod` will fix the "permission denied" error.
The `umount` is more an issue if you've updated to TWRP 3.1.1-0 which does successfully mount /system, whereas TWRP 3.0.2-1 didn't. The "invalid argument" is saying it isn't mounted and you can simply proceed. It is a problem if it says "busy". In this case you would get an error "Failed mounting system for kmod saving: <message>", then "kdzwriter: Failed while reading kernel modules" and `kdzwriter` wouldn't proceed.
Also replace "/external_sd/H990_something.kdz" with the filename/where you installed it (did you really rename the KDZ file to H990_something.kdz?).
dadme said:
Where is kdzwriter.gz? No attachment? Works kdzwriter from Dirty Santa thread?
Click to expand...
Click to collapse
Notice the "Download" tab at the top of this thread?
does anyone have the link to TWRP 3.1.1-0 for the h990ds? My device didn't seem to like the command 'kdzwriter -a /external_sd/H990ds10f_00_OPEN_TW_DS_OP_0622.kdz' I received the error "Failed while writing /system, major problem, PANIC!" . It's in a bootloop now should have run '-at' first!
second attempt...
You have to try harder than that message to make me panic
i figure my 10f kdz must be corrupt, so tried 10e
kdzwriter -a /external_sd/H990ds10e_00_OPEN_TW_DS_OP_0517.kdz
errors recieved were:
Failed mounting system for kmod restoring: Invalid argument
kdzwriter: Failed while restoring kernel modules, recommend kernel reinstall!
I reinstalled the kernel. Not sure what the kmod error means?
Anyway android upgraded and works a charm. Didn't fix my camera focus issue but i guess that must be down to the kernel.
Thanks for this awesome tool emdroidle, are you taking donations?
Sorry, Emdroidle i use classic theme, so download tab is not visible. Can use this TWRP https://forum.xda-developers.com/v20/development/recovery-twrp-3-1-0-0-touch-recovery-t3603760, elsa version? TWRP can be updated from TWRP 3.0.2.1 or from fastboot?
Got this on 10f H990DS TWN,
Failed mounting system for kmod restoring: Invalid argument
kdzwriter: Failed while restoring kernel modules, recommend kernel reinstall!
Finished rewrite of system area
Begining rewrite of modem area
ooo...ooo.oooooooo.ooooo...oooooooo.o*
Finished rewrite of modem area
dadme said:
Sorry, Emdroidle i use classic theme, so download tab is not visible. Can use this TWRP https://forum.xda-developers.com/v20/development/recovery-twrp-3-1-0-0-touch-recovery-t3603760, elsa version? TWRP can be updated from TWRP 3.0.2.1 or from fastboot?
Got this on 10f H990DS TWN,
Failed mounting system for kmod restoring: Invalid argument
kdzwriter: Failed while restoring kernel modules, recommend kernel reinstall!
Finished rewrite of system area
Begining rewrite of modem area
ooo...ooo.oooooooo.ooooo...oooooooo.o*
Finished rewrite of modem area
Click to expand...
Click to collapse
Either TWRP should work, just there is a small behavior difference. TWRP 3.0.2-1 has a small bug and never manages to mount /system; while TWRP 3.1.1-0 does manage to mount /system. With 3.0.2-1 the `umount /system` can be skipped, with 3.1.1-0 that command needs to be run before /system is upgraded.
Mars104 said:
does anyone have the link to TWRP 3.1.1-0 for the h990ds? My device didn't seem to like the command 'kdzwriter -a /external_sd/H990ds10f_00_OPEN_TW_DS_OP_0622.kdz' I received the error "Failed while writing /system, major problem, PANIC!" . It's in a bootloop now should have run '-at' first!
second attempt...
You have to try harder than that message to make me panic
i figure my 10f kdz must be corrupt, so tried 10e
kdzwriter -a /external_sd/H990ds10e_00_OPEN_TW_DS_OP_0517.kdz
errors recieved were:
Failed mounting system for kmod restoring: Invalid argument
kdzwriter: Failed while restoring kernel modules, recommend kernel reinstall!
I reinstalled the kernel. Not sure what the kmod error means?
Click to expand...
Click to collapse
Well seeing that "PANIC" message means something rather problematic occurred, and the state of /system is Bad(tm).
"kmod" is short for "kernel module". The Linux kernel has the capability to load/unload extra bits of code (generally drivers) while the kernel is running. These are specific to the particular kernel and trying to load modules for the wrong kernel could fail or cause problems.
I was surprised to learn the Bluetooth and FM Radio drivers are modules, as well as the exfat filesystem is a module. The userspace portion of talking to the Bluetooth chip won't load unless it successfully loads "brcm_bt_drv.ko" into the kernel.
The kernel modules are located in /system/lib/modules. When writing /system, `kdzwriter` first tries to mount /system and save copies of the modules. Once /system has been rewritten it tries to restore them. If either of those steps fails, there is need to reinstall the kernel since the modules on /system will match LG's stock kernel, not the static-fixed kernel I built.
Mars104 said:
Thanks for this awesome tool emdroidle, are you taking donations?
Click to expand...
Click to collapse
Well I don't send them back.
emdroidle said:
The added `chmod` will fix the "permission denied" error. (did you really rename the KDZ file to H990_something.kdz?).
Click to expand...
Click to collapse
Haha no mate I didn't, was just using the name for the KDZ from your example
Just wanted to say thanks as well. Used your tool with the updated instructions. Booted into TWRP, plugged into PC, used ADB from Command Prompt to do the whole thing. Went perfectly. It gave me a line when it was done about recommending a kernel re-install, so once the tool was finished I re-flashed the H990 kernel zip from your other thread, Magisk, the latest Aroma GAPPS package, and then rebooted. After the optimization process, I'm now on V10F-TWN with a patch date of 1st June, and rooted.
It's a touch of a process to get to this point, but if you follow everything properly to the letter, it works. Cheers mate.
i rename my kdz into "some.kdz" i run kdzwriter -at /external_sd/some.kdz itsays : Next chunk starts beyond end of file, Failed to open KDZ file, aborting what does this mean thank you
iDefalt said:
Haha no mate I didn't, was just using the name for the KDZ from your example
Click to expand...
Click to collapse
Okay, fine. I just wanted to make sure since there are people who don't realize you're supposed to adapt the name and complain when things don't work. Just one of those things that makes one go wait-a-minute...
kuachi00 said:
i rename my kdz into "some.kdz" i run kdzwriter -at /external_sd/some.kdz itsays : Next chunk starts beyond end of file, Failed to open KDZ file, aborting what does this mean thank you
Click to expand...
Click to collapse
Most likely you don't have the full file. Were you downloading it and the download got interrupted?
Success! Upgraded to 10f with root
emdroidle
Can you please make a small tool that extract the content of the KDZ file and the system.img file to modify things with ease on PC, and can easier interchange between versions to see what bugs can be avoided....
zinou213 said:
emdroidle
Can you please make a small tool that extract the content of the KDZ file and the system.img file to modify things with ease on PC, and can easier interchange between versions to see what bugs can be avoided....
Click to expand...
Click to collapse
There already are tools for this. https://github.com/Bigcountry907/kdztools and https://forum.xda-developers.com/showthread.php?t=2600575
Though I'm not sure they are completely compatible with the newest kdz's. Simple extraction should work.
-------
Nice tool btw. Now if only it where possible to flash kdz's directly in EDL mode, that would be great !!
askermk2000 said:
There already are tools for this. https://github.com/Bigcountry907/kdztools and https://forum.xda-developers.com/showthread.php?t=2600575
Though I'm not sure they are completely compatible with the newest kdz's. Simple extraction should work.
-------
Nice tool btw. Now if only it where possible to flash kdz's directly in EDL mode, that would be great !!
Click to expand...
Click to collapse
Thank you, I know this tools but i want a confirmation about there compatibility with v20's KDZs, and what is the EDL mode you talk about ??
zinou213 said:
Thank you, I know this tools but i want a confirmation about there compatibility with v20's KDZs, and what is the EDL mode you talk about ??
Click to expand...
Click to collapse
That last part was not for you specifically. It's Sahara Download Mode, or Emergency Download Mode I was talking about, something you probably won't know much about until you brick your phone
askermk2000 said:
That last part was not for you specifically. It's Sahara Download Mode, or Emergency Download Mode I was talking about, something you probably won't know much about until you brick your phone
Click to expand...
Click to collapse
OK Sahara Download Mode i know, i saw this with my old bricked gflex 2 that i unbricked with too many tools and processes that i forget now...
why is it that only the android security patch has been changed and the version is still v10e iam trying to upgrade to v10g thanks
---------- Post added at 11:09 PM ---------- Previous post was at 10:47 PM ----------
also my cpu load is alway going 90 to 100 percent even tho im not using any app did not also do cpu adjustments . it drains my battery fast
@emdroidle
Your donation button doesn't work:
We cannot process this transaction because there is a problem with the PayPal email address supplied by the seller. Please contact the seller to resolve the problem. If this payment is for an eBay listing, you can contact the seller via the "Ask Seller a Question" link on the listing page. When you have the correct email address, payment can be made at www.paypal.com.
Click to expand...
Click to collapse

Question Bootloader Unlocked Warning

Has anybody figured out how to get rid of the Bootloader Unlocked warning when booting this phone? It certainly slows down the booting process.
I haven't figured it out yet. To be honest I've been trying to figure out what apps are safe to uninstall and a custom ROM or how to update to Android 12. But I'll definitely let you know if I figure a way out.
dfreedom834 said:
I haven't figured it out yet. To be honest I've been trying to figure out what apps are safe to uninstall and a custom ROM or how to update to Android 12. But I'll definitely let you know if I figure a way out.
Click to expand...
Click to collapse
I have been trying to build TWRP for this device. I am very close, but the mkbootimg command script is issuing a bad argument and I have been unable to trace it down so far.
Code:
[100% 4/4] Target boot image: /mnt/audio/android/twrp/out/target/product/minsk/boot.img
FAILED: /android/twrp/out/target/product/minsk/boot.img
/bin/bash -c "(/android/twrp/out/host/linux-x86/bin/mkbootimg --kernel /mnt/audio/android/twrp/out/target/product/minsk/kernel --ramdisk /android/twrp/out/target/product/minsk/ramdisk.img --base 0x00000000 --pagesize 4096 --cmdline \"console=ttyMSM0,115200n8 androidboot.hardware
=qcom androidboot.console=ttyMSM0 androidboot.memcg=1 lpm_levels.sleep_disabled=1 video=vfb:640x400,bpp=32,memsize=3072000 msm_rtb.filter=0x237 servic
e_locator.enable=1 swiotlb=1 androidboot.usbcontroller=a600000.dwc3 earlycon=msm_geni_serial,0x880000 loop.max_part=7 printk.devkmsg=on androidboot.ha
b.csv=10 androidboot.hab.product=minsk androidboot.hab.cid=50 firmware_class.path=/vendor/firmware_mnt/image buildvariant=user buildvariant=eng\" --os
_version 16.1.0 --os_patch_level 2099-12-31 --ramdisk_offset 0x01000000 --tags_offset 0x00000100 --dtb device/motorola/minsk/prebuilt/dtb.img --header
_version 2 --output /mnt/audio/android/twrp/out/target/product/minsk/boot.img ) && (true )"
mkbootimg: error: unrecognized arguments: --dtb device/motorola/minsk/prebuilt/dtb.img
ninja: build stopped: subcommand failed.
15:01:24 ninja failed with: exit status 1
So the --dtb should be --recovery_dtbo I believe. Not sure where this command is being generated in order to fix it.
I was running into problems like that I factor rest it and turned it off. Where did you compile the boot.img from? And ya it would work better if it was trying to go to the right path. I had to find a boot.img from one of the over seas ones I kept getting it were it would root but the screen did respond.
lexridge said:
So the --dtb should be --recovery_dtbo I believe. Not sure where this command is being generated in order to fix it.
Click to expand...
Click to collapse
I could be wrong but the recovery I'm using (orange fox) does use a kernel_dtb. So it seems your recovery image kernel doesn't have the right path to the dtb binary it needs. Try searching the build directory for any _dtb/.dtb and rename accordingly. I'd you need to alter the dtb from a related SoC there are tools for unpacking and modifying those.
The recovery and boot ones would be similar I imagine since those files are a map of the device's hardware.
dfreedom834 said:
I was running into problems like that I factor rest it and turned it off. Where did you compile the boot.img from? And ya it would work better if it was trying to go to the right path. I had to find a boot.img from one of the over seas ones I kept getting it were it would root but the screen did respond.
Click to expand...
Click to collapse
I took the boot.img from the full device A11 factory image.
MINSK_RETUS_11_RPCS31.Q2-109-16-2_subsidy-DEFAULT_regulatory-DEFAULT_CFC.xml.zip
I used the same one to create my magisk boot.img as well. I used dumpyara to build the device tree using the above file for my source which seemed to work properly. No errors in other words.
elrod16 said:
I could be wrong but the recovery I'm using (orange fox) does use a kernel_dtb. So it seems your recovery image kernel doesn't have the right path to the dtb binary it needs. Try searching the build directory for any _dtb/.dtb and rename accordingly. I'd you need to alter the dtb from a related SoC there are tools for unpacking and modifying those.
The recovery and boot ones would be similar I imagine since those files are a map of the device's hardware.
Click to expand...
Click to collapse
I have a dtbo directory containing these files:
Code:
00_kernel
01_dtbdump_amxbr.dtb
02_dtbdump_amxbr.dtb
03_dtbdump_amxbr.dtb
04_dtbdump_amxbr.dtb
05_dtbdump_amxbr.dtb
I also have a dtb.img in the root of the device tree. I will copy it to dtbo.img and see what happens. Thanks for the hint.
lexridge said:
I have a dtbo directory containing these files:
Code:
00_kernel
01_dtbdump_amxbr.dtb
02_dtbdump_amxbr.dtb
03_dtbdump_amxbr.dtb
04_dtbdump_amxbr.dtb
05_dtbdump_amxbr.dtb
I also have a dtb.img in the root of the device tree. I will copy it to dtbo.img and see what happens. Thanks for the hint.
Click to expand...
Click to collapse
I think dtb.img probably has all of the dtb files compiled together
elrod16 said:
I think dtb.img probably has all of the dtb files compiled together
Click to expand...
Click to collapse
That is my thought as well.
lexridge said:
That is my thought as well.
Click to expand...
Click to collapse
I just recently had to deal with all this crap because I didn't know GPD changed which revision of the mediatek SoC they used in the GPD XD while keeping the serial numbers the same. Flashed my old one's backup on it and half the cores were stuck offlined when it booted up. Ended up having to get ahold of the stock kernel for that board revision and patch in the correct dtb for that SoC.
I don't have links but some of the sites that delve into generic Linux kernel porting have tools for decompiling kernel_dtb files to an editable form that you can then recompile if you do have device/driver issues. Also the magisk module for enabling TWRP sdcard storage backups has some Android arm64 native binaries in it that can help with tearing apart kernel/recovery images. (They both are technically kernel images, just one boots a minimal OS).
Edit: I think any dtbo files would be individual compiled object files that get linked into the final dtb image.
Edit 2: I just saw your other comment above. Congrats, that sounds like a viable (and probably long term stable) way you found.
On another topic, I have been trying to mount /system as r/w (thru adb). It appears /system is not actually a mount point but under a different mount point. Any idea what that might be? Doing a cat on /proc/mounts yeilds a crapload of mounts, with many belonging to magisk, but no /system.
I know its been 4 month since last activity, but has there been any progress on this?
There does not seem to have been much progress on this, but I read somewhere recently that the G Stylus (2021) was either the most popular or best-selling Moto phone in 2021. Who knows if that is exactly true, but if it is indeed so popular, here's to hoping that some capable developers will take an interest in it eventually!
Several folks have mentioned that loading a GSI (Generic System Image) should be possible, but I have not had any extended downtime myself to be able to try this. But if you do, you can find some guidance for the 2020 version of the G Stylus at:
https://forum.xda-developers.com/t/...ic-system-image-on-the-moto-g-stylus.4131199/

Categories

Resources