Related
I've been examining CSC's with a hex editor an they seem to be some kind of *.nb0 imagefile containing a RAW filesystem with a *.CAB inside that contains a *.rgu and an a *.reg with the custom settings fot the zone/operator code (XEN, XEC, etc.). I tried to hexedit it but I can't calcule the md5 checksum, it seems to be located at the bottom header of the file but doesn't match with any of file's sections or the whole rest of the binary before the checksum code. Anyone could upload AnDim's new HTCRIE (the one with OMNIA 7 support) to see if it helps editing this kind of *.nb0 ??
Edit: HCTRIE has a fixed method for *.nb0 reading that is only compatible with *.nb0 files containing typical partitions (ULDR, SLDR ,etc) and also is not capable of writting changes so there is no way to create custom csc's for now. I will be investigating for more ways to calculate the image checksum.
Only for development purposes:
Download Hashcheck-less* firmware flasher
*The actual checking is done but it allways says that the firmware's md5 matches the binary header and allows you to flash. I still have to change the code so it shows the error message but allows you to continue.
MD5 chechsum is not the main problem
I uploaded Andim's tools here: http://forum.xda-developers.com/showthread.php?t=1117513.
Any information on the flash-tool is very welcome. But, as xbores already stated, the MD5 is not the main problem. If you manage to create a file that will be accepted by the flash-tool, then there is another problem. The rom-files are signed as "WP7_PRODUCT". The bootloader checks this. If the signature is not valid (which happens when the file is tampered with), the bootloader will probably refuse to boot. So you would also need a patched bootloader. I have no idea how difficult that is. I would assume it isn't to hard to do. But if that were true, then probably other people would already have done it already.
If we have a patched bootloader that accepts cooked roms, and a patched flash-tool or correct checksum calculation, so we can actually flash the cooked rom, that would open up a lot of possibilities. I don't have time to spend to on this, but maybe in the future I will have a look at it. Any info is very appreciated.
Patching the tool would be so easy as I have located the code section where it decides to show md5 hash error or continue with the flash process. It would just require to replace a "jz" instruction by "jmp" one in the code with a hex editor.
It would be thankful that those who downloaded the Hascheck-less flasher reported if it was useful for something...
The absolute hash that checks the flash tool is simple MD5, just depends on from where to where (probably from beginning to the last few bytes except the WP_PRODUCT and the md5 hash itself?).
The main problem is the data between 64h and 8000h - they are signature. I am trying to figure out how is it signed, but it is all weird.
In case of CSC, it seems like it is 1byte per ~512B.
In case of eboot, it is 1byte per ~1024B.
In case of PDA, it is 1byte per ~25kB.
Anyone knows anything about Ra000FF and signing it?
I'm not so sure that it is a signature, if you compare different csc's you find repeating parts in it. And that is IMHO not very typical for signatures.
Is there a thread anywhere describing Ra000FF? I already found file size(without MD5 at the end), size of signature what ever thingy and size of eboot image + entry point.
I did a bit of research and I think I have most (pretty much all?) parts of it. When I get home, I will post my findings.
Code:
Ra000FF container
HEADER:
Offset Length [B] Encoding Description
00 8 Big Endian Ra000FF\x0B
08 2 ?? -- "imagestart" (D000FF)
0C 2 ?? -- "imageend" (D000FF)
11 1 Always 24
15 1 Always 01
18 2 Always 04 80
1D 2 Little Endian Sector size (IMGFS, imageupdate = 808; CSC, eboot = 80)
1F 4 Little Endian File content size in sectors: content size = (value*sector size - (8000 + 13F)) (beginning and ending headers)
The content starts at offset 8000
FOOTER (last 13F bytes)
00 1 Always 7E
04 1 Content type (CSC = A9, EBOOT=C7, IMAGEUPDATE=B8, PDA (IMGFS)=B8, PHONE (Radio)=D6)
05 - 11B In case of PHONE -- some unknown data (another hashes? Some XORs?), in other cases always filled with 00s
11C - 127 Target device type (WP7_PRODUCT or WP7_ENGINEER)
12C - 13B 10 Hash of (whole?) file - probably MD5 (10 bytes)
13C 1 Always 7D
13D - 13F 3 Filled with 00s
ALL NUMBERS ARE IN HEX!
OndraSter said:
The absolute hash that checks the flash tool is simple MD5, just depends on from where to where (probably from beginning to the last few bytes except the WP_PRODUCT and the md5 hash itself?).
Click to expand...
Click to collapse
I have tried the md5 from diferent sections and it doesn't work anyway the goal here is to edit the *.cab.pkg as the md5 checksum check can be bypassed with my patched tool (tested changing random bits inside the imgfs). The *.cab.pkg with header MSCF and ending with an FF heap till the end of the IMGFS is signed with the same certificate as the *.dsm inside it (both can be extracted). As the *.cab.pkg is loaded by the the kernel and not by the bootloader the signature could be meaningless here if the *.cab.pkg inside the IMGFS is properly edited. Considering the FF heap as remaining space we could even add more registry tweaks that would also be loaded at first boot.
Also this is the full set of image signature types:
WP7_ENGINEER_4K
WP7_ENGINEER
WP7_PRODUCT_4K
WP7_PRODUCT
ROISSY_ENGI_4K
ROISSY_ENGI
ROISSY_PROD_4K
ROISSY_PROD
Isn't the CSC file checked when uploading to phone for the certificate signature (RSA MD5, RSA SHA1? Who knows - I don't) in the beginning of the file (from offet 0x64) too?
OndraSter said:
Isn't the CSC file checked when uploading to phone for the certificate signature (RSA MD5, RSA SHA1? Who knows - I don't) in the beginning of the file (from offet 0x64) too?
Click to expand...
Click to collapse
My patched tool ignores md5. It was as simple as changing a jz instruction by a jmp and now no matter if the md5 checksum is correct or not it allways says it's ok (even trough the checking routine is done md5 ok => md5 ok and md5 wrong => md5 ok). About the top header binary sections I don't know but for sure my patched tool allows you to flash images with incorrect md5 checksum.
Yes, but try really flashing some device with not proper signature at offset $64 and down.
I talked with Olipro and this should be similar to R000FF - these data are signed with RSA MD5, every block in file. When data block is sent to phone, it is checked against that ^ and if it is okay, the data is written to NAND. I am not talking about the bottom, I am talking about the top.
4ndr01d presents a Stock ROM!
Donations Appreciated!
Click here to donate via PayPal if you like my work and want to support further versions of my ROMs.
Features
Rooted
Init.d Support
Script to easily Calibrate Overscan
Improved Performance for Games
Improved Streaming (Video and Audio)
Improved Connection to Google Services
Buttery Smooth
Blazing Fast
Changelog
1.0 (md5: 8c4acc39406a3f3b2d3ec0b74dc33a4c)
initial release
Download
Mod edit: Links removed
Instructions
1. extract zip file on your desktop
2. run installer script and follow instructions
Credits
Google - for Android!
You guys - for all your support and feedback!
reserved
Cool will check it out soon
No go - wont flash the system.img gives the following error:
target reported max download size of 536870912 bytes
Invalid sparse file format at header magi
erasing 'system'...
OKAY [ 0.218s]
sending sparse 'system' (497013 KB)...
OKAY [ 17.226s]
writing 'system'...
FAILED (remote: flash_cmds error!
)
finished. total time: 17.679s
Click to expand...
Click to collapse
alltubetone said:
No go - wont flash the system.img gives the following error:
Click to expand...
Click to collapse
You are unlocked, right?
Also, if you have issues with the installer, you can just fastboot flash both system.IMG and boot.IMG.
okibi said:
Also, if you have issues with the installer, you can just fastboot flash both system.IMG and boot.IMG.
Click to expand...
Click to collapse
good luck man, paying attention. seems like i had a lot more setup on my nexus player so staying on 5.0 for now.
Yes im unlocked - I also tried to manually fastboot flash the system image but no luck. same error message.
---------- Post added at 10:05 AM ---------- Previous post was at 09:57 AM ----------
Looks like people in the Q&A thread are having the same issues
The ops lack of response is rather concerning.
lafester said:
The ops lack of response is rather concerning.
Click to expand...
Click to collapse
Being at work is concerning? Ok...
Are you guys already on 5.1? If not, you need to flash the 5.1 bootloader. I'll look to improving the process tonight.
Also, are you guys using the fastboot in the zip? Perhaps I bundled the wrong one!
Nothing wrong with fastboot and yes I am on 5.1 bootloader.
lafester said:
Nothing wrong with fastboot and yes I am on 5.1 bootloader.
Click to expand...
Click to collapse
Which fastboot are you using? The one in the package or your sdk version?
Tried yours first, then mine with the same result.
First off, yay for more devs and a new rom for the Nexus Player!
2nd, screenshots or more details would be very helpful. Is casting working? Are bluetooth game pads, Bluetooth keyboards and mice, and most importantly Bluetooth audio devices working? I really want to use Bluetooth headphones!
Is anything currently not working?
Does this rom require a keyboard/mouse to setup initially?
What differentiates you from LolliRock?
I pushed up an R2 build to the primary download link. Can you guys please test this one?
With "stock" do you mean the real Android TV stock image or stock AOSP with a tablet interface which needs a mouse / keyboard combination?
MaluNoPeleke said:
With "stock" do you mean the real Android TV stock image or stock AOSP with a tablet interface which needs a mouse / keyboard combination?
Click to expand...
Click to collapse
Stock means based on the stock Android TV image.
I cannot it install the r2 version because it fails to write the system:
sending sparse 'system' (523231 KB)...
OKAY [ 22.614s]
writing 'system'...
FAILED (remote: flash_cmds error!
The same command works with the Google System Image without a problem
Must be something wrong with the system.img. I'll take a look at it today and get this resolved. Sorry!
Thanks in advance and what exactly have you improved in performance, streaming and connectivity in comparison to the stock image?
First, here is the link to the TWRP zip I made to crossflash the sprint g8 to Open US 20c: https://forum.xda-developers.com/showthread.php?t=4181557
Second, crossflashing is really only useful for two cases: you have an at&t or sprint g8 that you bootloader unlocked for other reasons and want to get updates, or you absolutely need volte and/or vowifi to work. Bootloader unlocking just to crossflash in the way explained below without further reasons is practically pointless.
I'll just repeat some things I said in that post to clarify why the following steps need to be done: on the g8 and v50, LG implemented a hardware lock, where you have an OPID (operator ID, such as sprint), and a value of either 1 or 0 for IMPL. I'm not entirely certain about this, but I think the IMPL value being true or false determines whether the OPID will be checked or not, and IMPL can only be made 0 with some hardware mods. The OPID exists somewhere in the hardware and is then crosschecked with an OPID in the software, and if they don't match, you're greeted with the words "OPID mismatch" on boot (unless IMPL = 0). However, I discovered that the OPID checked during boot is just /OP/totc.cfg, which is a just a one line .cfg file containing something like "SPR_US." So, we can just flash most of the relevant partitions that get updated in OTAs from a different kdz, including system, vendor, boot (although using dragonfly or metaphysics kernel is better), and product. There are a bunch of other partitions like the abls and xbls that will stay the same during a major android update release, are probably the same across variants, and are generally just safer to leave be. For the OP partition, we can flash it, and since TWRP still works even when you face OPID mismatch when trying to boot into system, we can just replace the totc.cfg in the new /OP with one we saved from the original one. All that said, here are the steps to do all that after you choose a variant to crossflash to. Beware that on the korean v50, after crossflashing, changing NT code appears to be necessary for networks to work, which can only be done when IMPL = 0. This might apply to the Korean g8 as well or other models, but I think all US models should be fine (just don't crossflash to the korean variant). A prerequisite of the guide is also to have backups of your partitions, so you can just flash them back if you run into any unfixable issues.
Prerequisites:
- Have a backup of all the partitions that will be altered / flashed in this guide (system, product, vendor, boot, and most importantly, OP)
- Have a working TWRP where you can mount OP configs and successfully see /OP/totc.cfg
- This will wipe your data along with your internal storage, so make sure to backup what you need
- Have the disable dm verity force encrypt twrp zip, which is included in either of the bl unlock guides
- Half optional: have metaphysics or dragonfly kernel as your boot img so that you don't end up using an old stock boot img on a newer software version and potentially not boot
- At least half a brain
1. Go to /OP/totc.cfg either in a root file manager or in TWRP and copy it to your computer, sdcard, or wherever will survive an internal storage wipe
2. Go on lg-firmwares and download your desired kdz. I would use either the latest Open Canada or Open US one. Just because canada might be on 20h and OPEN US is on 20c, that doesn't mean OPEN US is really that far behind in updates, it just received less in total, so it could have arrived at the same security patch as Open Canada while having a much lower version number. If you live in the US, just go with OPEN US (same goes for Canada), and if you live elsewhere maybe go with the Canadian kdz
3. https://github.com/steadfasterX/kdztools READ the documentation
4. Use the documentation to figure out how to extract the system, vendor, and product partitions from your downloaded kdz and do so!
5. https://bbs.lge.fun/thread-75.htm Use this guide to extract the OP partition from your kdz. This is by far the hardest part because kdztools can't do it correctly on its own.
6. Transfer all the partitions to your phone: system, vendor, product, OP
7. Flash all those partitions in TWRP
8. Hold down vol- + power until you reboot from within TWRP, and keep holding that key combination until you get back into TWRP again
9. Format data in TWRP
10. Mount OP configs, go to /OP in TWRP's file manager, and delete totc.cfg
11. Transfer your saved totc.cfg (from your original OP partition), to your internal storage, and then copy that to /OP again using TWRP's file manager
12. Flash the disable dm verity force encrypt zip
13. Done
Hello, I have a question, does this procedure unlock the carrier? Or, is it still locked for sprint SIM cards?, Thanks.
Nice guide. Thank you so much! Now I can use Open firmware without unused operation apps.
Since we have the programmer file for EDL I would like to do this for my g8x sprint variant. However I still need to sim unlock it first before I attempt to boot loader unlock it. The OPID is in the first 2 offsets of hex code in the OP_a.bin image.
For example my partition dump for my G8x g850um reads the below
Code:
TMO_US
MSVN 0
So I extracted the tot file from the phone image dump and verified this for myself and am confused as to why it says TMO_US if I have a sprint splash screen. Was my phone cross flashed before I got it? How to I verify what the IMPL value is? Where is that stored?
antintin said:
First, here is the link to the TWRP zip I made to crossflash the sprint g8 to Open US 20c: https://forum.xda-developers.com/showthread.php?t=4181557
Second, crossflashing is really only useful for two cases: you have an at&t or sprint g8 that you bootloader unlocked for other reasons and want to get updates, or you absolutely need volte and/or vowifi to work. Bootloader unlocking just to crossflash in the way explained below without further reasons is practically pointless.
I'll just repeat some things I said in that post to clarify why the following steps need to be done: on the g8 and v50, LG implemented a hardware lock, where you have an OPID (operator ID, such as sprint), and a value of either 1 or 0 for IMPL. I'm not entirely certain about this, but I think the IMPL value being true or false determines whether the OPID will be checked or not, and IMPL can only be made 0 with some hardware mods. The OPID exists somewhere in the hardware and is then crosschecked with an OPID in the software, and if they don't match, you're greeted with the words "OPID mismatch" on boot (unless IMPL = 0). However, I discovered that the OPID checked during boot is just /OP/totc.cfg, which is a just a one line .cfg file containing something like "SPR_US." So, we can just flash most of the relevant partitions that get updated in OTAs from a different kdz, including system, vendor, boot (although using dragonfly or metaphysics kernel is better), and product. There are a bunch of other partitions like the abls and xbls that will stay the same during a major android update release, are probably the same across variants, and are generally just safer to leave be. For the OP partition, we can flash it, and since TWRP still works even when you face OPID mismatch when trying to boot into system, we can just replace the totc.cfg in the new /OP with one we saved from the original one. All that said, here are the steps to do all that after you choose a variant to crossflash to. Beware that on the korean v50, after crossflashing, changing NT code appears to be necessary for networks to work, which can only be done when IMPL = 0. This might apply to the Korean g8 as well or other models, but I think all US models should be fine (just don't crossflash to the korean variant). A prerequisite of the guide is also to have backups of your partitions, so you can just flash them back if you run into any unfixable issues.
Prerequisites:
- Have a backup of all the partitions that will be altered / flashed in this guide (system, product, vendor, boot, and most importantly, OP)
- Have a working TWRP where you can mount OP configs and successfully see /OP/totc.cfg
- This will wipe your data along with your internal storage, so make sure to backup what you need
- Have the disable dm verity force encrypt twrp zip, which is included in either of the bl unlock guides
- Half optional: have metaphysics or dragonfly kernel as your boot img so that you don't end up using an old stock boot img on a newer software version and potentially not boot
- At least half a brain
1. Go to /OP/totc.cfg either in a root file manager or in TWRP and copy it to your computer, sdcard, or wherever will survive an internal storage wipe
2. Go on lg-firmwares and download your desired kdz. I would use either the latest Open Canada or Open US one. Just because canada might be on 20h and OPEN US is on 20c, that doesn't mean OPEN US is really that far behind in updates, it just received less in total, so it could have arrived at the same security patch as Open Canada while having a much lower version number. If you live in the US, just go with OPEN US (same goes for Canada), and if you live elsewhere maybe go with the Canadian kdz
3. https://github.com/steadfasterX/kdztools READ the documentation
4. Use the documentation to figure out how to extract the system, vendor, and product partitions from your downloaded kdz and do so!
5. https://bbs.lge.fun/thread-75.htm Use this guide to extract the OP partition from your kdz. This is by far the hardest part because kdztools can't do it correctly on its own.
6. Transfer all the partitions to your phone: system, vendor, product, OP
7. Flash all those partitions in TWRP
8. Hold down vol- + power until you reboot from within TWRP, and keep holding that key combination until you get back into TWRP again
9. Format data in TWRP
10. Mount OP configs, go to /OP in TWRP's file manager, and delete totc.cfg
11. Transfer your saved totc.cfg (from your original OP partition), to your internal storage, and then copy that to /OP again using TWRP's file manager
12. Flash the disable dm verity force encrypt zip
13. Done
Click to expand...
Click to collapse
Do you think this method can be tried for flashing G8S partitions on a T-mobile G8 ? I really need VoLTE and my G8S has it.
antintin said:
LG implemented a hardware lock, where you have an OPID (operator ID, such as sprint), and a value of either 1 or 0 for IMPL.
Click to expand...
Click to collapse
as far as I discovered, there is no HW lock but it seems it is about sth like a serial number (maybe device id) which is later checked by software and determines the original opid of the device. you can check device id by the query "at%deviceid" in modem while port check is enabled.
however, erasing some partitions will hinder sw to check and inspect opid. In Open_ca 20 you can erase modem (not modemst) and it fails to check and determine the original opid so it lets device to get flashed by any kdz, although later it is needed to modify opid in op partition.
hello i'm new to the forum and i have a doubt, my lg g8 is blocked to use only at&t chip, if i do the bootloader deblocking and change the rom i can use another operator's chip ?, i'm in brazil and i can't use an operator local
At the moment no custom Rom for lg g8
I followed every step exactly as described for extracting OP partition but the resulting file size is around 16 MBs larger than my device's OP partition (LG V50 V450) , and TWRP cannot flash it (throws file size larger than device error), so I flashed in EDL mode by QFIL but it has a warning (file overflow) and it flashed without issue but the device gets stuck at boot and off course I copied over my original totc.cfg to the OP partition but still stuck on the boot screen, I also flashed boot image from the KDZ to the boot partition still the same , BTW my active slot is A , and it doesn't matter which kdz I use I always end up with same file size of 716 MBs , but my device's OP partition is 700 MBs, I backed everything up and I have no issue going back to stock sprint.
On many occasions I didn't copy the totc.cfg back to the device on purpose and I did not get OPID mismatch error which concludes that OP Decryption method from KDZ is buggy (at least for V450)
So is there something that I missed here ? or is this only working for G8 ?
Same size mismatch error with trying to crossflash OP partition on my LG G8. So not working either.
armodons said:
Same size mismatch error with trying to crossflash OP partition on my LG G8. So not working either.
Click to expand...
Click to collapse
So I was not the only one, there has to be a better way to extract the OP partition , deleting the first 512 bytes of code may not be enough , maybe in the middle or at the there are other things that need to be deleted using Ultra edit.
Bronnel said:
So I was not the only one, there has to be a better way to extract the OP partition , deleting the first 512 bytes of code may not be enough , maybe in the middle or at the there are other things that need to be deleted using Ultra edit.
Click to expand...
Click to collapse
I think the extracted OP partition after eliminating the 512 bytes of data is probably the correct version because it can be extracted and the contents viewed--different phone variants may just have differently sized partitions. No idea how to get around this issue though...
armodons said:
I think the extracted OP partition after eliminating the 512 bytes of data is probably the correct version because it can be extracted and the contents viewed--different phone variants may just have differently sized partitions. No idea how to get around this issue though...
Click to expand...
Click to collapse
you are correct but I tried many KDZs including pie and all of them end up the same file size (roughly 716 MBs), I mean shouldn't there be at least a minor difference ?
I can't help those with issues creating the OP partition, although one would have to think others have tried to do that / had probs / posted results. There must be help for that in some threads somewhere...
I used the OP partition (from us 20c) in this thread, and was able to accomplish what I needed with a lot less effort then doing this 'crossflashing' (thnx Cloud Man).
So, what I needed? Really only wanted volte and vowifi to work with my mint mobile sim. My sprint phone with a10 20f continuously tried to connect to 'carrier services' (it couldn't, I'm not on sprint), and vowifi or volte didn't work with other carrier even though it was sim unlocked.
A simple fix was to use twrp and flash only the OP partition (as described in this thread), then also restore the original totc.cfg (also as described in this thread).
Edit 11/8/21: Note: You don't need to flash the totc.cfg if you have a sprint device and flashing the us Open OP provide here, it already has the totc changed to sprint.
That's it, didn't flash any of the other partitions (did try that way initially but got boot loop). So now my sprint device is basically indistinguishable from a US Open device. No sprint bloat, no more constantly trying to 'configure carrier services', and vowifi and volte work.
cheers
Not sure if this is terribly different than the one in the OirgPost (20c), but this is the OP from latest US OP kdz (20f).
Also, as in op notes, have to put your original totc file in place of the one that this comes with.
cheers
antintin said:
First, here is the link to the TWRP zip I made to crossflash the sprint g8 to Open US 20c: https://forum.xda-developers.com/showthread.php?t=4181557
Second, crossflashing is really only useful for two cases: you have an at&t or sprint g8 that you bootloader unlocked for other reasons and want to get updates, or you absolutely need volte and/or vowifi to work. Bootloader unlocking just to crossflash in the way explained below without further reasons is practically pointless.
I'll just repeat some things I said in that post to clarify why the following steps need to be done: on the g8 and v50, LG implemented a hardware lock, where you have an OPID (operator ID, such as sprint), and a value of either 1 or 0 for IMPL. I'm not entirely certain about this, but I think the IMPL value being true or false determines whether the OPID will be checked or not, and IMPL can only be made 0 with some hardware mods. The OPID exists somewhere in the hardware and is then crosschecked with an OPID in the software, and if they don't match, you're greeted with the words "OPID mismatch" on boot (unless IMPL = 0). However, I discovered that the OPID checked during boot is just /OP/totc.cfg, which is a just a one line .cfg file containing something like "SPR_US." So, we can just flash most of the relevant partitions that get updated in OTAs from a different kdz, including system, vendor, boot (although using dragonfly or metaphysics kernel is better), and product. There are a bunch of other partitions like the abls and xbls that will stay the same during a major android update release, are probably the same across variants, and are generally just safer to leave be. For the OP partition, we can flash it, and since TWRP still works even when you face OPID mismatch when trying to boot into system, we can just replace the totc.cfg in the new /OP with one we saved from the original one. All that said, here are the steps to do all that after you choose a variant to crossflash to. Beware that on the korean v50, after crossflashing, changing NT code appears to be necessary for networks to work, which can only be done when IMPL = 0. This might apply to the Korean g8 as well or other models, but I think all US models should be fine (just don't crossflash to the korean variant). A prerequisite of the guide is also to have backups of your partitions, so you can just flash them back if you run into any unfixable issues.
Prerequisites:
- Have a backup of all the partitions that will be altered / flashed in this guide (system, product, vendor, boot, and most importantly, OP)
- Have a working TWRP where you can mount OP configs and successfully see /OP/totc.cfg
- This will wipe your data along with your internal storage, so make sure to backup what you need
- Have the disable dm verity force encrypt twrp zip, which is included in either of the bl unlock guides
- Half optional: have metaphysics or dragonfly kernel as your boot img so that you don't end up using an old stock boot img on a newer software version and potentially not boot
- At least half a brain
1. Go to /OP/totc.cfg either in a root file manager or in TWRP and copy it to your computer, sdcard, or wherever will survive an internal storage wipe
2. Go on lg-firmwares and download your desired kdz. I would use either the latest Open Canada or Open US one. Just because canada might be on 20h and OPEN US is on 20c, that doesn't mean OPEN US is really that far behind in updates, it just received less in total, so it could have arrived at the same security patch as Open Canada while having a much lower version number. If you live in the US, just go with OPEN US (same goes for Canada), and if you live elsewhere maybe go with the Canadian kdz
3. https://github.com/steadfasterX/kdztools READ the documentation
4. Use the documentation to figure out how to extract the system, vendor, and product partitions from your downloaded kdz and do so!
5. https://bbs.lge.fun/thread-75.htm Use this guide to extract the OP partition from your kdz. This is by far the hardest part because kdztools can't do it correctly on its own.
6. Transfer all the partitions to your phone: system, vendor, product, OP
7. Flash all those partitions in TWRP
8. Hold down vol- + power until you reboot from within TWRP, and keep holding that key combination until you get back into TWRP again
9. Format data in TWRP
10. Mount OP configs, go to /OP in TWRP's file manager, and delete totc.cfg
11. Transfer your saved totc.cfg (from your original OP partition), to your internal storage, and then copy that to /OP again using TWRP's file manager
12. Flash the disable dm verity force encrypt zip
13. Done
Click to expand...
Click to collapse
Hello, I don't want to bother you but by any chance do you have any idea in which file or partition the "sim" network lock is, I want to test if I can unlock the network of an LG G8 ThinQ Xfinity mobile
AsItLies said:
Not sure if this is terribly different than the one in the OirgPost (20c), but this is the OP from latest US OP kdz (20f).
Also, as in op notes, have to put your original totc file in place of the one that this comes with.
cheers
Click to expand...
Click to collapse
Would I be able to do a simple update to A11 US OPEN using LGUP when /if the kdz comes?
mangojain said:
Would I be able to do a simple update to A11 US OPEN using LGUP when /if the kdz comes?
Click to expand...
Click to collapse
No, I don't think so. You could try it, might work, don't know that anyone has tried that as we don't have updates coming.
But worse case scenario is you follow the OP and re crossflash and go through setup again. Not that big of a deal.
cheers
AsItLies said:
No, I don't think so. You could try it, might work, don't know that anyone has tried that as we don't have updates coming.
But worse case scenario is you follow the OP and re crossflash and go through setup again. Not that big of a deal.
cheers
Click to expand...
Click to collapse
You see, extracting the OP partition is beyond me, so i would have to wait for an expert like you to do it, IF the update comes. Actually I'm fairly hopeful that it will, considering that the CA OPEN has come.
mangojain said:
You see, extracting the OP partition is beyond me, so i would have to wait for an expert like you to do it, IF the update comes. Actually I'm fairly hopeful that it will, considering that the CA OPEN has come.
Click to expand...
Click to collapse
well thanks, but as far as the US version becoming available, keep in mind that LG has a long history here. It seems that their contracts with other US carriers stipulate the US op version can't be released until the carriers release their version. So if one of the carriers doesn't do the update, the US will never be available.
I may try the ca open soon and will modify the latest US open OP to work with it, that may well be the best (latest) update ever available?
cheers
I am trying to flash an Android 12 GSI onto my Samsung Galaxy Tab Active3. Goal is to install the GSI without root / voiding the warranty. My company produces an app which is primarily used on Android on Galaxy Tab Active devices. It's expected Galaxy Tab Active3 will get Android 12 update in the next few months and we wanted to do some regression testing in advance of that. Hence the need to get Android 12 GSI onto the Tab Active3.
Device is an arm64 so I downloaded the arm64+gms version of Android 12 GSI (from Google's website). I have successfully unlocked the bootloader, and enabled DSU support. The device supports Project Treble and the VNDK isolated namespace, so in theory should support GSIs.
Everything I tried so far has failed. Any ideas to get it working?
Manual DSU
I have tried to install the GSI by manually starting the DSU via activity manager ("am start-activity -n com.android.dynsystem/com.android.dynsystem.VerificationActivity..." etc). Every time it just says "Installation failed" after reaching about 50% progress. I have tried setting different sizes for the USERDATA: 8GB (Google's recommended size), 2GB and 1GB. I get the same error every time. The device has around 40GB free space and the GSI image size is around 2GB (1GB gzipped), so it shouldn't be anything to do with the space requirements.
Logcat reports an error:
11-11 13:10:09.620 1103 3695 I DynamicSystemService: Failed to install system
11-11 13:10:09.621 16445 23403 E InstallationAsyncTask: java.io.IOException: Failed to start installation with requested size: 1257738436
This doesn't help unfortunately; it is thrown from the following file and this is just thrown if there is any error in the underlying dynamic installation:
packages/DynamicSystemInstallationService/src/com/android/dynsystem/InstallationAsyncTask.java - platform/frameworks/base - Git at Google
PS: Unfortunately the device does not support DSU Loader even though it's running Android 11 (searching for "dsu" in the settings returns no relevant results). Apparently none of the Samsung devices are supporting DSU Loader.
Fastboot / FastbootD
The device can be rebooted into fastboot mode ("adb reboot bootloader") but every command just hangs forever (except for "fastboot devices", which does detect the device). I tried "fastboot reboot fastboot", but it just reboots into the standard mode of the device and does not enter a fastboot userspace mode (fastbootd mode) as some have suggested it should.
Heimdall
At least one person has said they can patch GSIs using Heimdall: https://forum.xda-developers.com/t/can-i-flash-gsi-roms-with-odin.4029921/
That person was able to flash their GSI to the SYSTEM partition, but my device doesn't have a SYSTEM partition. The partitions are like SUPER, PRISM, etc.
I'm not able to get Heimdall working properly on Windows 10. I have tried with WinUSB, libusb0 and libusbK, but the same is true for all of them. After rebooting the device into ODIN mode, the device can be detected with "heimdall detect", but I can't do anything more including "heimdall print-pit", as I get a "Failed to access device. libusb error: -12" error.
I managed to set up Heimdall on an Ubuntu instance of WSL and map the USB using USBIPD. Inside WSL, "heimdall print-pit" does work but I can't get further to flashing anything (I tried to flash the GSI to SUPER, not sure if this was a good idea but anyway it failed) as I get a "Protocol initialisation failed!" error.
Odin
I am not sure if Odin itself even supports GSIs and I can't find anyone saying it supports them. I have tried flashing the GSI as an AP in Odin 3.12, 3.13, 3.14 and the patched 3.14 which removes signature checks. But every time it just fails.
Custom recovery
Just to also note, it seems none of the custom recoveries (TWRP, SHRP, Orangefox etc) support the Tab Active3, or I could have tried to flash those using Heimdall/Odin and then use them to flash the GSI. But I feel it's likely I would have had the same issues, at least with Heimdall.
you need custom recovery with dynamic partition support
aIecxs said:
you need custom recovery with dynamic partition support
Click to expand...
Click to collapse
as I mentioned, I couldn't find any custom recovery which supports my device...
Also, if I did have say TWRP or LOS recovery for my device, it seems I could run fastboot through the custom recovery (fastbootd). Then I assume I could just flash GSI using instructions like these: https://forum.xda-developers.com/t/...devices-with-dynamic-super-partition.4256667/
But it's a moot point because no such custom recovery exists for my device. There are custom recoveries for Tab Active 1 and 2, but not 3. So I'm trying to see what I can do with Heimdall
Also, quote from the above-linked thread in response to someone who asked about flashing using TWRP:
kusti420 said:
you can only do it in twrp if you rebuild the whole super partition with the gsi of your choice and flash that
Click to expand...
Click to collapse
if someone could tell me how to "rebuild the whole super partition with the gsi of your choice", that may help. because if I could convert gsi to super partition and if I could get Heimdall working (e.g. using native Linux version off a live USB or whatever), then I could use Heimdall to flash SUPER (in theory)
On that note, I found a couple of possible leads:
(1) https://forum.xda-developers.com/t/...r-img-and-flashing-our-modifications.4196625/ - shows how to unpack and re-pack super image using lpunpack and lpmake. I am wondering if I could use this to replace the system.img in my existing super partition with the one from GSI. But how to get the vendor.img and product.img? I don't think Heimdall has any command to backup existing partitions from a device
(2) https://source.android.com/devices/tech/ota/dynamic_partitions/implement#factory-images - it suggests that you can use "make dist" to build super.img, but I'm not sure if this requires me to completely rebuild AOSP from source or I can do it from existing system.img (i.e. GSI)
super_image_dumper
regarding build TWRP from source there are helpful users here
I ran Heimdall on native Linux rather than on WSL or the Windows version. This worked better and fixed the issues I was having before with Heimdall.
I then tried to flash VBMETA (the one bundled with the GSI) using Heimdall which worked, however my device was then soft-bricked, could only boot into Download Mode, and gave the following error:
ODIN MODE (AVB fail)
vbmeta: Public key used to sign data rejected. (5)
vbmeta: VERIFICATION_DISABLED bit is set.
CUSTOM VBMETA
VBMETA : No sign info
VBMETA ,
I also tried a VBMETA from avbtool, which gave a very similar error on boot:
ODIN MODE (AVB fail)
vbmeta: Error verifying vbmeta image: OK_NOT_SIGNED (3)
vbmeta: VERIFICATION_DISABLED bit is set.
CUSTOM VBMETA
VBMETA : No sign info
VBMETA ,
I managed to restore my stock vbmeta by extracting it from the stock ROM and installing using Heimdall, so my device can boot again, but it's back to vbmeta with verification enabled. How can I resolve this?
I tried to run lpmake, but I don't know my super partition size ("--device super:...") I thought it might be the partition block count from the PIT. but that is 1740800 for SUPER, whereas my system.img has size 2752909312, so surely it doesn't fit inside?
Got it fixed eventually (i.e. I am now able to run the GSI on Samsung Galaxy Tab Active3). I had made a really stupid error when running the DSU command. For KEY_SYSTEM_SIZE I was passing the gzipped system size, not original system image size. This is why the installation always failed after 50%, because it was only installing 50% of the system image. Also another really important thing to note is that after running DSU, you have to restart the system from the DSU notification and not from the normal power menu of the device.
In addition, I did flash "vbmeta_samsung.img" but I'm not sure if this was strictly necessary or not (I happened to notice that vbmeta_samsung.img has the same file size as the vbmeta disable images - 4KB vs 10KB for stock vbmeta). I'm going to be trying to help one of my colleagues to follow the same process, probably in the next few days, so will hopefully be able to report back on whether this flash is strictly necessary.
Also, I found that both Heimdall on native Linux and Heimdall on WSL actually suffer from the same problem. You can only post one command to the device, then subsequent commands fail with "protocol initialisation failed". On WSL I was doing things like "heimdall print-pit --no-reboot" and that's why I was facing issues when flashing. Basically, if you get protocol initialisation failed, just reboot the device and it should work.
ajbcc said:
I tried to run lpmake, but I don't know my super partition size ("--device super:...") I thought it might be the partition block count from the PIT. but that is 1740800 for SUPER, whereas my system.img has size 2752909312, so surely it doesn't fit inside?
Click to expand...
Click to collapse
stumbled across this post
https://forum.xda-developers.com/showpost.php?p=82241115&postcount=70
edit: bytes = block count × block size
aIecxs said:
stumbled across this post
https://forum.xda-developers.com/showpost.php?p=82241115&postcount=70
edit: bytes = block count × block size
Click to expand...
Click to collapse
Thanks for pointing this out, but this doesn't help me unfortunately. The number I'm trying to calculate here is the number 4294967296 in that post, which is the one number the guide doesn't explain how to calculate. Also, the PIT doesn't give my block size, only the "block size/offset". This seems to be just a plain offset, as it increases for every partition, even the small ones. So I have no idea what my block size is.
Just ran through the install steps with one of my colleagues (also with Samsung Galaxy Tab Active3) and there was no need to disable AVB as part of the process. We managed to get through with just the vanilla steps from Google. So all that stuff about "vbmeta_samsung.img" was just a red herring.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
This is the support thread of PixelFlasher
(PixelFlasher is an open-source self contained GUI tool to facilitate Pixel phone device flashing/rooting/updating with extra features).
Note: This thread is meant for issues and problems faced in Google Pixel 7 devices, generic issues that are device agnostic should be discussed in the main thread.
For full details on where to download / usage and feature set of the tool, visit the main thread at XDA or the project's Github page.
Troubleshooting:
If you need support or assistance, the best way to get is by generating a support file from within PixelFlasher.
You can hit that big Support button on the main screen, or select it from the Help menu.
The generated support.zip file is sanitized (redacted) to keep your sensitive information (username device id ...) private.
Placeholder
Placeholder
Placeholder
Hi, thank you for doing this. My rooted pixel 7 pro is prompting me to install a security update. I tried to update via pixel flasher.
Flashed with the latest platform tools from offical android site and downloaded the latest factory image. Pixelflasher showed no error
And then my phone still prompts me to download updates,
phone android version = 13
build = TD1A.220804.009.A2
android security update = sept 5 2022
Did I flash the old factory image? or am I doing something wrong? or the pixel update prompt is an error?
dangercl0se said:
Hi, thank you for doing this. My rooted pixel 7 pro is prompting me to install a security update. I tried to update via pixel flasher.
Flashed with the latest platform tools from offical android site and downloaded the latest factory image.
And then my phone still prompts me to download updates, phone android version = 13 and build = TD1A.220804.009.A2
Am I flashing the old factory image? or am I doing something wrong? or the pixel update prompt is an error?
Click to expand...
Click to collapse
You need to download the factory image at the bottom. It's sorted from oldest to newest. So currently TD1A.220804.031 is the latest.
@dangercl0se , like what @Tiebe says.
Tiebe said:
You need to download the factory image at the bottom. It's sorted from oldest to newest. So currently TD1A.220804.031 is the latest.
Click to expand...
Click to collapse
thank you, i am noob.
badabing2003 said:
@dangercl0se , like what @Tiebe says.
Click to expand...
Click to collapse
all good, operator error!
thank you so much for making this, saved me so much time!!!
New Release:
Oct 27, 2022 v4.3.1.0 release
Bug Fix: Magisk modules not listed on MacOS / Linux
Ok so im currently Bootloader unlocked, rooted and custom kernel on Slot B. I would like to update Slot A with verity and verification disabled using the same firmware currently in Slot B. Do I select processed firmware zip first or can I jump right to the patched magisk.img. I tried switching slots and flashing the firmware(no patched init_boot.img) with verity and verification disabled first. It goes through the steps and ends on the Fastbootd screen. When I reboot, it reboots 3 times and ends up on slot b. Not sure what Im doing wrong. I even tried checking "flash to inactive slot" and still boots to slot B.
schmeggy929 said:
Do I select processed firmware zip first or can I jump right to the patched magisk.img.
Click to expand...
Click to collapse
If you intend to flash the firmware on that slot, then yes, you have to select it.
schmeggy929 said:
I tried switching slots and flashing the firmware(no patched init_boot.img) with verity and verification disabled first. It goes through the steps and ends on the Fastbootd screen. When I reboot, it reboots 3 times and ends up on slot b. Not sure what Im doing wrong. I even tried checking "flash to inactive slot" and still boots to slot B.
Click to expand...
Click to collapse
This sounds like the flashing is not going past fastbootd stage.
I have read reports that it takes long in that stage (even doing things manually) with no feedback, so make sure you are waiting long enough.
You should also make sure your cable / USB drivers are good, and preferably use USB 2.0 port.
Few reboots and then back to B indicates that A is not bootable.
badabing2003 said:
If you intend to flash the firmware on that slot, then yes, you have to select it.
This sounds like the flashing is not going past fastbootd stage.
I have read reports that it takes long in that stage (even doing things manually) with no feedback, so make sure you are waiting long enough.
You should also make sure your cable / USB drivers are good, and preferably use USB 2.0 port.
Few reboots and then back to B indicates that A is not bootable.
Click to expand...
Click to collapse
Looks like third time's a charm, I also swapped my usb type-c to type-c cable with a USB-A cable.
When the next update comes around, is it recommended to check the box for "Flash to both slots" along with checking disable Verity and verification?
schmeggy929 said:
When the next update comes around, is it recommended to check the box for "Flash to both slots" along with checking disable Verity and verification?
Click to expand...
Click to collapse
I don't disable verity and verification, Magisk patches properly.
However if you are using custom ROM, then you want to check with the ROM maker if either or both are necessary.
As for monthly update, I recommend you flash to inactive slot, not both slots, this way it is similar to OTA A/B, ie if anything goes wrong, your current setup in the current slot is not effected.
badabing2003 said:
I don't disable verity and verification, Magisk patches properly.
However if you are using custom ROM, then you want to check with the ROM maker if either or both are necessary.
As for monthly update, I recommend you flash to inactive slot, not both slots, this way it is similar to OTA A/B, ie if anything goes wrong, your current setup in the current slot is not effected.
Click to expand...
Click to collapse
thank you, I will "Flash to inactive slot" route. And yes for now, the available Kernels require Verity and verification disabled. I only want to have both slots verity and verification disabled just in case something goes wrong and I have to boot the other slot. I do not want to have to full wipe because I booted a verity and verification enabled slot.
New Release:
Nov 09, 2022 v4.4.0 release
New feature: Font and Font size should be configurable by the user #33
New feature: Added WiFi-ADB connect / disconnect button. Left click to connect, Right click to disconnect.
Handy to access a device remotely.
Note: This only works in adb mode, so no fastboot or flashing features work for remote devices, but for patching / installing apks, managing Magisk modules it works well (basically anything that is done in adb).
I personally use this to test patching on remote devices, and also use it to access / install apps to my watch.
Ground work for future features: Get installed Package list, and list which are disabled, enable / disable / uninstall apps. (Will be available in future release).
Move Flash Option Flash to inactive slot to Basic mode from Advanced mode..
Minor UI Improvements
If Magisk does not create a backup attempt to trigger Magisk to create one.
Update readme to include Pixel 7 / 7P specific info.
Typically I do everything manually but I decided to try this tool out on OSX and so far everything has worked flawlessly. Thank you for your work.
This is my first time using PixelFlasher; I usually do updates the manual way. I'm trying to install the November update and after flashing I'm getting the message about the device being corrupted.
If I hit the power button to continue it boots fine and everything seems to be good, but when doing this manually with the browser based Android flash tool, I don't end up with this message that I have to manually continue through.
Anyone have a guess as to what I'm doing wrong? FWIW, I'm trying to do this update while keeping data. TIA.
Edit: Attached Support.zip
dpotter38 said:
This is my first time using PixelFlasher; I usually do updates the manual way. I'm trying to install the November update and after flashing I'm getting the message about the device being corrupted.
If I hit the power button to continue it boots fine and everything seems to be good, but when doing this manually with the browser based Android flash tool, I don't end up with this message that I have to manually continue through.
Anyone have a guess as to what I'm doing wrong? FWIW, I'm trying to do this update while keeping data. TIA.
Edit: Attached Support.zip
Click to expand...
Click to collapse
FYI, I was able to get this fixed by flashing the Oct init_boot, then manually patching the November init_boot and flashing it.
I must have missed it the first time, but when trying to patch the November init_boot there was an error in the PixelFlasher console, "Foreign Key constraint failed", but it still showed the patched boot file as available in the list. Just wanted to put this out here in case anyone else runs up against a similar issue.
dpotter38 said:
This is my first time using PixelFlasher; I usually do updates the manual way. I'm trying to install the November update and after flashing I'm getting the message about the device being corrupted.
If I hit the power button to continue it boots fine and everything seems to be good, but when doing this manually with the browser based Android flash tool, I don't end up with this message that I have to manually continue through.
Anyone have a guess as to what I'm doing wrong? FWIW, I'm trying to do this update while keeping data. TIA.
Edit: Attached Support.zip
Click to expand...
Click to collapse
Looking at your logs I have the following observation.
You started with an old SDK, which is not a good idea, and PF warned you about it, and you chose to proceed regardless. Don't do this again, specially on the latest phones / firmware.
Code:
2022-11-17 20:08:35 ERROR: Detected older Android Platform Tools version 29.0.6-6198805
2022-11-17 20:08:51 User accepted older version 29.0.6-6198805 of Android platform tools.
SDK Version: 29.0.6-6198805
At this point Magisk was not installed, and your phone was on slot b
You first processed the 220804 firmware file, and when you tried to patch, PF told you that there was no Magisk on your device.
You then manually (outside of PF) installed Magisk Manager 25.2:25200, or if it was hidden, you restored it. (just for my curiosity, which was it?)
You created a patch from 220804 firmware's init_boot
Then followed by creating a patch from 221105 factory image
The above two patches was created by PF using binaries from Magisk Manager.
Tried to flash the patched file and the phone got stuck at fastbootd.
Most likely due to using an older Platform tools.
Code:
extracting super_empty.img (0 MB) to disk... took 0.002s
Rebooting into fastboot OKAY [ 0.000s]
< waiting for REDACTED >
You then upgraded the SDK to
Code:
Android SDK Version: 33.0.3-8952118
But at this point your phone was already on slot a in bootloader mode, probably due to the previous botched flashing.
You tried to flash slot a and ran into this issue.
Code:
< waiting for REDACTED >
fastboot: error: Failed to boot into userspace fastboot; one or more components might be unbootable.
Still on slot a, next attempt was to flash both slots
This worked without errors and the system booted to slot b
You hid the Magisk Manager
you then processed 221105 factory image, (FYI this is unnecessary, if you do it once, nothing changes if you repeat it)
You patched this time PF using rooted Magisk
Interestingly the generated patch had a different SHA1: f44feb1bc2b8643333af5e14f0a12755b537f076
Whereas the previous patch SHA1 was 8753990ce4374d5a4509e0bae48f54e2553be216
This is a curious case, the only differences are.
875399 was patched using non-hidden Manager binaries
f44feb was patched using rooted Magisk
both same versions of Magisk.
I'd be very interested if you could share these files for me to inspect.
if you could zip the following (replace redacted with your username)
Code:
C:\Users\REDACTED\AppData\Roaming\PixelFlasher\boot_images4
You then proceeded to flash to both slots again
Which went well.
End of logs
At this point your system is probably on slot a and working well.
dpotter38 said:
FYI, I was able to get this fixed by flashing the Oct init_boot, then manually patching the November init_boot and flashing it.
I must have missed it the first time, but when trying to patch the November init_boot there was an error in the PixelFlasher console, "Foreign Key constraint failed", but it still showed the patched boot file as available in the list. Just wanted to put this out here in case anyone else runs up against a similar issue.
Click to expand...
Click to collapse
No you didn't, or at least I didn't see that you did, If you don't mind I'd be interested in getting another support.zip from you which would include this along with the Foreign key error you encountered.
That error is benign, as PF knows how to handle it, but it is included so that I can troubleshoot and find the root cause (it happens very rarely and I'm trying to see what conditions are causing that)
Thanks and sorry for the delayed response, it takes time to process these logs.