As far as i know, someone in a china forum said that he had unlocked the F600S' bootloader successfully.
He first flashed a pre-rooted 5.0 TOT and change the build.prop to h901. Then, he flashed h901 6.0 kdz to his phone and the bootloader became h901 version.
Therefore, he could unlock the bootloader simply by entering "fastboot oem unlock", flashing H901's recovery and rooted the phone.
Some users said this method works but some said didn't and even bricked their phones into "Qualcomm HS-USB QDLoader 9008" mode.
I open this thread for raising attention and investigate whether this method really works or not, but please, DO NOT intend to perform this method unless it was proved to be safe.
If you can read Chinese, here is the source (please remove this link if it violates xda's rules):
http://bbs.gfan.com/android-8325666-1-1.html
i recommend, don't... unless u needed to do that then go
I was attempting something like this awhile back. But I wasn't using the normal build.prop. There is one hiding in /cust/open_com_ds/cust_open_hk.prop that I assumed was what the LGUP program used to check vs the one in /system but apparently I was mistaken. Theoretically there isn't anything hardware wise different between the H901 and the H961N besides the dual sim. Those that don't use dual sim might try this. Otherwise I would wait. If there are any people out there that can make kdz's then all it takes is one person to do it right then everyone else can benefit. I might go ahead and try for shizas and googles.
DarkestSpawn said:
I was attempting something like this awhile back. But I wasn't using the normal build.prop. There is one hiding in /cust/open_com_ds/cust_open_hk.prop that I assumed was what the LGUP program used to check vs the one in /system but apparently I was mistaken. Theoretically there isn't anything hardware wise different between the H901 and the H961N besides the dual sim. Those that don't use dual sim might try this. Otherwise I would wait. If there are any people out there that can make kdz's then all it takes is one person to do it right then everyone else can benefit. I might go ahead and try for shizas and googles.
Click to expand...
Click to collapse
Thanks for your reply. According to the source, those people changed their build.prop as below in order to flash h901's kdz:
{
"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"
}
By the way, as a H961N user, I also wonder that whether it works on dual sim model. Can we flash the modem and related apps separately in order to make dual sim working if bootloader has unlocked?
If memory serves correctly, Yes with an unlocked bootloader you could adb flash modem *BLAHBLAHBLAH* but idk how that works with dual sim phones.
I honestly get aggravated when I see certain users that say they make TOT or KDZ files when really they took it from other sites that aren't English and say they made it. If that was the case they would make a KDZ with stock everything for the device its for but replace the bootloader to the version from H901 and every LG v10 would be bootloader unlockable but somehow they are too busy or working on other TOTs and kdzs... Assinine lies. Sorry had to throw my two cents out there.
I'm so glad I didn't do this attempt yet. Just remembered I gave my backup phone away so I have nothing to fall back on if this fails. If no one tries this before I get it back I will try.
DarkestSpawn said:
I was attempting something like this awhile back. But I wasn't using the normal build.prop. There is one hiding in /cust/open_com_ds/cust_open_hk.prop that I assumed was what the LGUP program used to check vs the one in /system but apparently I was mistaken. Theoretically there isn't anything hardware wise different between the H901 and the H961N besides the dual sim. Those that don't use dual sim might try this. Otherwise I would wait. If there are any people out there that can make kdz's then all it takes is one person to do it right then everyone else can benefit. I might go ahead and try for shizas and googles.
Click to expand...
Click to collapse
Even though many of the pieces are the same, there could well be some fairly significant differences hardware-wise between the H901 and H961N. The two that I know are really close are the H961N (Hong Kong) and H962, if the kernel sources are identical then there isn't much difference between the two.
On the flip side though, there could be enough similarity to flash the H901's bootloader onto another device. The bootloader wouldn't need to worry about how any of the radio bits work, just avoid touching them.
DarkestSpawn said:
I'm so glad I didn't do this attempt yet. Just remembered I gave my backup phone away so I have nothing to fall back on if this fails. If no one tries this before I get it back I will try.
Click to expand...
Click to collapse
Please do report if you do this. Anyone else out there who is reading, we'd love to hear from you if you try this. While I hope you succeed, failure could well occur. Could you report what device you're thinking of trying this on?
There is a tool from Qualcomm which can allow you to write to the flash before the device boots. If your try fails, that tool could be used to write back what is "supposed" to be there and hopefully you won't have a complete brick. A simpler solution might be to use that tool to simply overwrite your device's bootloader with the H901 bootloader. Note there are 2 copies of the bootloader on the H962 and likely other devices and you'd need to get both. I imagine there are several, but here is one tool for extracting the KDZ files (my goal is to be able to construct modified KDZ files, but I haven't analyzed things enough yet, will likely take some time).
EDIT: What look to be the bootloader areas in the H901, H961N and H962 KDZ files appear to be at the same offsets and the same sizes. I cannot be certain, but this might very well be a workable strategy.
EDIT2: If someone does this, it may be helpful to know which H901BK firmware version you use. The known KDZ file is for 20c, so it may be handy to keep links to that. Once you've done the process, it would be helpful for you to dump copies of all the block devices on the phone. Knowing which one(s) have changed could lead us to how LG's bootloader marks a device as unlocked, leading to easier methods of unlocking (hmm, really need a binary diff utility).
emdroidle said:
Even though many of the pieces are the same, there could well be some fairly significant differences hardware-wise between the H901 and H961N. The two that I know are really close are the H961N (Hong Kong) and H962, if the kernel sources are identical then there isn't much difference between the two.
On the flip side though, there could be enough similarity to flash the H901's bootloader onto another device. The bootloader wouldn't need to worry about how any of the radio bits work, just avoid touching them.
Please do report if you do this. Anyone else out there who is reading, we'd love to hear from you if you try this. While I hope you succeed, failure could well occur. Could you report what device you're thinking of trying this on?
There is a tool from Qualcomm which can allow you to write to the flash before the device boots. If your try fails, that tool could be used to write back what is "supposed" to be there and hopefully you won't have a complete brick. A simpler solution might be to use that tool to simply overwrite your device's bootloader with the H901 bootloader. Note there are 2 copies of the bootloader on the H962 and likely other devices and you'd need to get both. I imagine there are several, but here is one tool for extracting the KDZ files (my goal is to be able to construct modified KDZ files, but I haven't analyzed things enough yet, will likely take some time).
EDIT: What look to be the bootloader areas in the H901, H961N and H962 KDZ files appear to be at the same offsets and the same sizes. I cannot be certain, but this might very well be a workable strategy.
EDIT2: If someone does this, it may be helpful to know which H901BK firmware version you use. The known KDZ file is for 20c, so it may be handy to keep links to that. Once you've done the process, it would be helpful for you to dump copies of all the block devices on the phone. Knowing which one(s) have changed could lead us to how LG's bootloader marks a device as unlocked, leading to easier methods of unlocking (hmm, really need a binary diff utility).
Click to expand...
Click to collapse
I think the only worry of trying this method is a complete hard brick. As you have mentioned, any qualcomm phone has a recovery mode and i guess it should be the "Qualcomm HS-USB QDLoader 9008" mode.
I have searched some information and turn out there are two 9008 mode. It depends on whether the phone messed with Qualcomm’s stuffs, if not, then the phone will enter the "new 9008 mode" and it can let you recover the phone easily by a backup emmc image. If it is, then the phone will enter the "old 9008 mode" and it required specific files and "programmer", however, file suitable for msm8992 hasn't been discovered. Therefore, if this method brick the phone into old 9008 mode, no solution at all.
The information i have refered to, don't know if it is correct:
http://www.droidsavvy.com/unbrick-qualcomm-mobiles/
EDIT: The ro.expect.recovery_id should be "0x9260d50f08bef4a761309001fe20e5ab59508e78000000000000000000000000" (if you try it, double check by yourself)
some people said that they bricked the phone because of typing it incorrectly, but i don't know whether it is true or not
I have asked the people who bricked their phones from trying this method. It seems that they really made a typo on ro.expect.recovery_id and cause brick.
Also, i am pretty sure that those phones have gotten into the "old 9008 mode", therefore, "rawprogram0.xml, patch0.xml and prog_emmc_firehose_8992.mbn" are required for using QPST the fix the hard brick.
However, no suitable prog_emmc_firehose_8992.mbn for V10 has been discovered on the internet (even for the G4).
Personally, I injected the H901 aboot into an H962 DZ and flashed it onto my device a few months ago.
Long story made short, it was completely bricked, even without 9008 mode. I recommend you guys to be cautious with this method.
Edit: As I can understand Chinese, I'm currently looking into the tutorial.
ivangundampc said:
I think the only worry of trying this method is a complete hard brick. As you have mentioned, any qualcomm phone has a recovery mode and i guess it should be the "Qualcomm HS-USB QDLoader 9008" mode.
I have searched some information and turn out there are two 9008 mode. It depends on whether the phone messed with Qualcomm’s stuffs, if not, then the phone will enter the "new 9008 mode" and it can let you recover the phone easily by a backup emmc image. If it is, then the phone will enter the "old 9008 mode" and it required specific files and "programmer", however, file suitable for msm8992 hasn't been discovered. Therefore, if this method brick the phone into old 9008 mode, no solution at all.
The information i have refered to, don't know if it is correct:
http://www.droidsavvy.com/unbrick-qualcomm-mobiles/
Click to expand...
Click to collapse
Useful, though I cannot speak to the reliability of that information. A different source has a tool they say comes from Qualcomm, which may be more reliable with newer devices. Please note, this is a source of claims, I don't know how reliable they are (they also don't provide much detail on the limits of the tool).
WillyPillow said:
Personally, I injected the H901 aboot into an H962 DZ and flashed it onto my device a few months ago.
Long story made short, it was completely bricked, even without 9008 mode. I recommend you guys to be cautious with this method.
Edit: As I can understand Chinese, I'm currently looking into the tutorial.
Click to expand...
Click to collapse
I look forward to more detail/reports from that tutorial. Exact details would be invaluable.
I hoped that would work, but I feared the above possibility. The problem is which portions of the flash image sign which other portions of the image, and how many different keys does LG use? Your observation seems to suggest either the key used for signing the H901 aboot was not honored by the rest of the H962 firmware, or the key used for signing the H962 kernel wasn't honored by the non-unlocked H901 aboot (or both).
If the former case, then which are the pieces prior to aboot and can only those pieces be transplanted from a H901 while still preserving the dual-SIM functionality of the H962 (and H961N)? If the latter case, then I suspect you merely need to run a H901 kernel long enough to unlock the bootloader, then you can put back the H962 kernel and run that with the unlocked bootloader.
The other question is, which portions of the data unlock the bootloader? Is it a small change to the aboot portion? Is it changes elsewhere? Can those changes be isolated from the rest of the H901 firmware?
Just in case you didn't notice, I've got lots of questions. I hope I can figure out answers to some, but others I may not be able to answer. I'm currently targeting the kdztools portion.
@emdroidle
TBH I don't see anything not mentioned already. Basically the process is just
Flash 5.1 rooted -> modify build.prop -> flash H901 KDZ
Personally, I'm not going to do more risky experiments since I already RMA'd my last hard brick
Also, you might want to use IDA to take a look at aboot, which is basically an ELF binary. I had been doing that, but stopped after the brick.
WillyPillow said:
@emdroidle
TBH I don't see anything not mentioned already. Basically the process is just
Flash 5.1 rooted -> modify build.prop -> flash H901 KDZ
Personally, I'm not going to do more risky experiments since I already RMA'd my last hard brick
Also, you might want to use IDA to take a look at aboot, which is basically an ELF binary. I had been doing that, but stopped after the brick.
Click to expand...
Click to collapse
I understand. You're in a better position since LG will honor the warranty on your H962. They're a bit tougher if you get one outside Taiwan.
I was fearing we would have to take that approach. Worse, it looks like the firmware updates change aboot, which suggests settling on one version and trying to crack that is best. I wanted to try Plasma, but IDA is likely far enough ahead to beat Plasma. I'm just glad IDA has a Linux version.
WillyPillow said:
Personally, I injected the H901 aboot into an H962 DZ and flashed it onto my device a few months ago.
Long story made short, it was completely bricked, even without 9008 mode. I recommend you guys to be cautious with this method.
Click to expand...
Click to collapse
After some thought, I realized I should ask for some detail about the failed process you used for this. Did you flash both the aboot and abootbak slices? (/dev/mmcblock0p9 and /dev/mmcblock0p15 if I recall correctly)
If you flashed only aboot and ended up bricked, this seems to suggest it did in fact successfully execute the H901BK aboot, but the aboot decided the signature on boot was incorrect and halted. In this scenario if the portion before aboot had decided aboot had a bad signature, then it should have restored abootbak, which likely would have successfully booted the H962 kernel.
If you flashed both aboot and abootbak, this suggests the portion before aboot decided aboot's signature was wrong and it halted there. This doesn't rule out it successfully executing aboot and aboot deciding boot had the wrong signature, but it makes that less likely.
Hate to say it, but flashing only aboot doesn't really give us much information on the likelihood of flashing a full H901BK image onto a H962 being successful or not. The problem is there could be signatures in many places and any one of those could fail yet reproducing the original scenario would work perfectly.
emdroidle said:
After some thought, I realized I should ask for some detail about the failed process you used for this. Did you flash both the aboot and abootbak slices? (/dev/mmcblock0p9 and /dev/mmcblock0p15 if I recall correctly)
If you flashed only aboot and ended up bricked, this seems to suggest it did in fact successfully execute the H901BK aboot, but the aboot decided the signature on boot was incorrect and halted. In this scenario if the portion before aboot had decided aboot had a bad signature, then it should have restored abootbak, which likely would have successfully booted the H962 kernel.
If you flashed both aboot and abootbak, this suggests the portion before aboot decided aboot's signature was wrong and it halted there. This doesn't rule out it successfully executing aboot and aboot deciding boot had the wrong signature, but it makes that less likely.
Hate to say it, but flashing only aboot doesn't really give us much information on the likelihood of flashing a full H901BK image onto a H962 being successful or not. The problem is there could be signatures in many places and any one of those could fail yet reproducing the original scenario would work perfectly.
Click to expand...
Click to collapse
Hmm, I've never thought this deep. I was just like "Sxxt, my phone bricked! Must be a bad signature somwhere..." and stopped messing around with it
To answer your question, I only flashed aboot, without anything else. And for the details of the brick, you can't even see the "powered by Android" bootloader screen. The device just viberates if you want to turn it on. The only way to make the screen display something is remove the battery and connect it to a computer, for which a "no battery" icon is showed. So my guess then was the aboot signature was invalidated. But now you reminded me the existance of abootbak...
I'll do some research and thinking right now
WillyPillow said:
Hmm, I've never thought this deep. I was just like "Sxxt, my phone bricked! Must be a bad signature somwhere..." and stopped messing around with it
To answer your question, I only flashed aboot, without anything else. And for the details of the brick, you can't even see the "powered by Android" bootloader screen. The device just viberates if you want to turn it on. The only way to make the screen display something is remove the battery and connect it to a computer, for which a "no battery" icon is showed. So my guess then was the aboot signature was invalidated. But now you reminded me the existance of abootbak...
I'll do some research and thinking right now
Click to expand...
Click to collapse
Well, i think that you have bricked your phone into the "Qualcomm HS-USB QDLoader 9008" mode
The phone should be able to fix if you can see "Qualcomm MMC Storage USB Device" in "Devices Manager" when the phone is connecting to the computer.
WillyPillow said:
Hmm, I've never thought this deep. I was just like "Sxxt, my phone bricked! Must be a bad signature somwhere..." and stopped messing around with it
Click to expand...
Click to collapse
I was thinking about it, since I would very much like to somehow unlock the bootloader. While this way may or may not be tweaked to work, it does sound plausible. Analyzing failures can be very valuable.
WillyPillow said:
To answer your question, I only flashed aboot, without anything else. And for the details of the brick, you can't even see the "powered by Android" bootloader screen. The device just viberates if you want to turn it on. The only way to make the screen display something is remove the battery and connect it to a computer, for which a "no battery" icon is showed. So my guess then was the aboot signature was invalidated. But now you reminded me the existance of abootbak...
Click to expand...
Click to collapse
So this may suggest aboot successfully executed, but found a mismatched signature and halted. At which point, flashing the H901BK aboot and boot may be enough to make this work. This may though also require the H901BK recovery image. I do not know where the unlock process actually does its magic, so part of it could be in recovery.
I'd love to hear if you can get it to be successful.
Two threads relevant to this topic have shown up.
First, apparently someone somehow managed to accidentally flash a H901 firmware onto a H960A. That person was looking for help with restoring their device, but it leaves me hopeful this method could in fact work on other devices. Most likely you'd end up with a mix of some portions of the flash being copied from a H901 and some from whatever your phone is normally supposed to run, but this does confirm it is possible to run H901 firmware on other devices.
Second, a method has been found to recover devices from Qualcomm 9008 mode. This is big news since it greatly lessens the danger of a bad flash. Problem is it requires root on the phone to generate the initial image, though I suspect the images produced by my kdztools may well work for the job too.
I very much want to unlock the bootloader of my device, so I'm still doing research trying to estimate how plausible this method is. At this point there are enough reports of wrong V10 device images not being fatal to other V10-type devices for me to consider this method "likely".
Examining KDZ files for several devices, there is quite a bit of overlap between device images. There are 9 slices though which seem to warrant special attention based upon them having backup copies. These are named "sbl1", "pmic", "hyp", "tz", "rpm", "aboot", "sdi", and "raw_resources".
My guess is install a H901 image, do `fastboot oem unlock` and then you can copy everything aside these slices from your original device. My concern is these may need to remain the H901 versions in order to remain unlocked (unless all V10 devices share the unlock method, which may or may not be the case).
It may also work to use my KDZ Tools to copy the PrimaryGPT and BackupGPT areas from the target device onto a H901 image, at which point the process could be done without even needing a factory reset!
I'm pretty sure "sbl1"/"sbl1bak" are the first-stage bootloader. All the others aside from "raw_resources" look to be ELF executables.
Open request to Qualcomm here, could you please make your chips either alternate between trying to boot off of "sbl1" and "sbl1bak" (a single MRAM or PCRAM cell should take too much space, should it?), or else make them randomly choose between booting off them upon power-on? Too often one or the other gets corrupted in such a way that booting fails, but either isn't so corrupt to trigger them to try the backup, or else the primary is so badly damaged it is unable to try the backup. Alternating (and passing to the Linux kernel which one it successfully booted off of!) would greatly increase the chances of successful recovery without specialized tools.
Wiki + Likelyhood evaluation
Having examined the situation enough, I'm pretty sure this method should work. Experimentation though is risky.
I'm now working on creating 2 software tools for this project. One is a simple tool to remark the device a KDZ is for. This is pretty simple and the reports are, once this is done LGUP will happily flash a KDZ onto other devices. The second goal is a tool for modifying the GPT afterwords. While the H901 has a GPT similar to other V10s, it isn't quite identical. Of major note, many other devices have a /cust partition which has some extra software.
These two tools may actually be unnecessary. My KDZ Tools expose all of the data in an inconvenient, but workable format. The KDZ Tools can also be used to replace the GPT for the H901 with a GPT from another device, and they also expose the areas which mark which device a KDZ is for. Problem with using the KDZ Tools for this is there is what looks to be an extra checksum, and I've got no idea whether it covers the GPT (I hope not, but...).
I'm now looking to create the above two tools on GitHub, the LGE Tools. Alas, what may be more valuable is the Wiki on GitHub. I've got speculative instructions a little ways from the top. Towards the bottom I've got a list of which areas you'd need to restore from your original device. I guess I'm a bit unsure of "persist", the content is identical for my device, but the differing timestamps might trigger a flag that something has happened.
Hopefully we can get some testers who can risk needing to RMA their devices (I hope they don't need to, but this IS risky).
emdroidle said:
Having examined the situation enough, I'm pretty sure this method should work. Experimentation though is risky.
I'm now working on creating 2 software tools for this project. One is a simple tool to remark the device a KDZ is for. This is pretty simple and the reports are, once this is done LGUP will happily flash a KDZ onto other devices. The second goal is a tool for modifying the GPT afterwords. While the H901 has a GPT similar to other V10s, it isn't quite identical. Of major note, many other devices have a /cust partition which has some extra software.
These two tools may actually be unnecessary. My KDZ Tools expose all of the data in an inconvenient, but workable format. The KDZ Tools can also be used to replace the GPT for the H901 with a GPT from another device, and they also expose the areas which mark which device a KDZ is for. Problem with using the KDZ Tools for this is there is what looks to be an extra checksum, and I've got no idea whether it covers the GPT (I hope not, but...).
I'm now looking to create the above two tools on GitHub, the LGE Tools. Alas, what may be more valuable is the Wiki on GitHub. I've got speculative instructions a little ways from the top. Towards the bottom I've got a list of which areas you'd need to restore from your original device. I guess I'm a bit unsure of "persist", the content is identical for my device, but the differing timestamps might trigger a flag that something has happened.
Hopefully we can get some testers who can risk needing to RMA their devices (I hope they don't need to, but this IS risky).
Click to expand...
Click to collapse
Wow, i am very surprised that you are still working on this method! You have really paid a lot of effort on it!
After taking a look on your works, i really think that this method may really works to help us to unlock the bootloader.
In fact, the T-Mobile variant of both G5 and V20 have bootloader unlocked and so other version of G5 and V20 may also be able to unlock their booloader through a method like this, therefore, I think we should be able to draw more attention (more devs?) on studying this method.
Related
Hey Guys,
I've been using the OnePlus One (Bacon) for the past year and I'd like to switch however the OnePlus One has no 'Secure Boot' not to be confused with 'Locked Bootloader'
I can modify partitions like the SBL (Secondary Bootloader), ABOOT (Android Bootloader) and the Modem without the phone not booting.
Can anyone recommend a phone that either ships without any boot verification chain or has the option to disable 'Secure Boot'
(dylanger) said:
Hey Guys,
I've been using the OnePlus One (Bacon) for the past year and I'd like to switch however the OnePlus One has no 'Secure Boot' not to be confused with 'Locked Bootloader'
I can modify partitions like the SBL (Secondary Bootloader), ABOOT (Android Bootloader) and the Modem without the phone not booting.
Can anyone recommend a phone that either ships without any boot verification chain or has the option to disable 'Secure Boot'
Click to expand...
Click to collapse
I would assume the OPX and OP2 and possibly the OPPO [Find] devices would be similar in this regard, given their relationship. I have access to the OPX/OP2 but haven't had the time to dig into them yet. The new Intels might also be an option with the `fastboot flash keystore` function, so that you can use your own key for boot verification. I haven't had a chance to dig into it yet to see how much you can modify, but from what I gather, they will try to verify boot using the user keystore, followed by the OEM keystore.
binsol said:
I would assume the OPX and OP2 and possibly the OPPO [Find] devices would be similar in this regard, given their relationship. I have access to the OPX/OP2 but haven't had the time to dig into them yet. The new Intels might also be an option with the `fastboot flash keystore` function, so that you can use your own key for boot verification. I haven't had a chance to dig into it yet to see how much you can modify, but from what I gather, they will try to verify boot using the user keystore, followed by the OEM keystore.
Click to expand...
Click to collapse
Cheers for your response. Yeah I haven't even looked at the new Intel CPUs yet, oooo damn a 'fastboot flash keystore' would be very nice. This feature should be on all devices? I wonder why vendors don't just give consumers full access to the hardware.
A quick question. Is the OEM Keystore stored on the Flash or CPU? I guess it would be protected once the OS has booted but that wouldn't protect it against JTAG if its stored on Flash.
(dylanger) said:
Cheers for your response. Yeah I haven't even looked at the new Intel CPUs yet, oooo damn a 'fastboot flash keystore' would be very nice. This feature should be on all devices? I wonder why vendors don't just give consumers full access to the hardware.
A quick question. Is the OEM Keystore stored on the Flash or CPU? I guess it would be protected once the OS has booted but that wouldn't protect it against JTAG if its stored on Flash.
Click to expand...
Click to collapse
I originally thought the OEM keys were burnt-in on a ROM chip, but the more I read about it, it sounds like they're stored in a protected partition on eMMC. The eMMC 4.x+ spec suggests this is the case with the "Replay Protected Memory Block," little kernel source has references to similar protected memory. I'm just starting to dig into into it, but I'm pretty interested to know if it can be DMA'd.
I'm expecting the fastboot flash keystore to become common with late M or N devices with how Google is pushing the verified boot stuff (alerting the user about tampered boot). This would give their warnings a lot more value, since then you could sign your own modifications and only be alerted if something else then made changes to the boot.
The flash keystore seems to have a bunch in common with the (Windows) UEFI secureboot. I would assume that's a reason Intel has a jump on it.
binsol said:
I originally thought the OEM keys were burnt-in on a ROM chip, but the more I read about it, it sounds like they're stored in a protected partition on eMMC. The eMMC 4.x+ spec suggests this is the case with the "Replay Protected Memory Block," little kernel source has references to similar protected memory. I'm just starting to dig into into it, but I'm pretty interested to know if it can be DMA'd.
I'm expecting the fastboot flash keystore to become common with late M or N devices with how Google is pushing the verified boot stuff (alerting the user about tampered boot). This would give their warnings a lot more value, since then you could sign your own modifications and only be alerted if something else then made changes to the boot.
The flash keystore seems to have a bunch in common with the (Windows) UEFI secureboot. I would assume that's a reason Intel has a jump on it.
Click to expand...
Click to collapse
Interesting... I'm guessing Google will use qFuses to track weather or not the boot process has been tampered with. I wonder where the splash screens are located as I guess one could just replace the Tampered Boot screen with the normal boot one.
Surely all areas of the eMMC would be accessible via something like JTAG?
Hmm, yeah it would make sense for Little Kernel to check the OS'es Kernel integrity, something like Get Key from Keystore into a variable, then check against the actual Kernel image?
Little Kernel pretty interesting actually, from what I've gathered it controls stuff like entering modes (Holding Power + VolUp will enter Recovery or Fastboot etc) and Fastboot, have you ever tried to load LK into IDA? Integrating something like the Cerberus App into ABOOT would be awesome, Anti-Theft at the bootloader!
(dylanger) said:
Interesting... I'm guessing Google will use qFuses to track weather or not the boot process has been tampered with. I wonder where the splash screens are located as I guess one could just replace the Tampered Boot screen with the normal boot one.
Surely all areas of the eMMC would be accessible via something like JTAG?
Hmm, yeah it would make sense for Little Kernel to check the OS'es Kernel integrity, something like Get Key from Keystore into a variable, then check against the actual Kernel image?
Little Kernel pretty interesting actually, from what I've gathered it controls stuff like entering modes (Holding Power + VolUp will enter Recovery or Fastboot etc) and Fastboot, have you ever tried to load LK into IDA? Integrating something like the Cerberus App into ABOOT would be awesome, Anti-Theft at the bootloader!
Click to expand...
Click to collapse
I would guess the splash screen is in aboot, since it's the first thing with graphics output, and its alerting you that boot.img onward has been tampered with. If you can replace the splash screens, I'd assume you could break the whole chain since you'd already be altering aboot.
I think if you had raw access to the eMMC, you could replace the keystore. Do you know if JTAG is accessible on the OPO or similar devices? I read somewhere that JTAG is generally disabled/removed from non-engineering devices with 800+ series snapdragons. I've had no luck tracking down the JTAG so far on the board. All I've been able to get is UART.
binsol said:
I would guess the splash screen is in aboot, since it's the first thing with graphics output, and its alerting you that boot.img onward has been tampered with. If you can replace the splash screens, I'd assume you could break the whole chain since you'd already be altering aboot.
I think if you had raw access to the eMMC, you could replace the keystore. Do you know if JTAG is accessible on the OPO or similar devices? I read somewhere that JTAG is generally disabled/removed from non-engineering devices with 800+ series snapdragons. I've had no luck tracking down the JTAG so far on the board. All I've been able to get is UART.
Click to expand...
Click to collapse
Ah true, I didn't know ABOOT was the first process with Graphics Output, cheers for that
Really!? I'd assume that JTAG access is enabled for support purposes? The whole "My phones doesn't work" so you send it in? And they'd just re-partition everything?
I bought a RiffBox along time ago (Never actually used it -_-), that allowed direct access to eMMC, read and write you could dump and write whole bin images.
Another quick question, it was my understanding that some of the boot process used ARM's TrustZone or TZ to store keys.
(dylanger) said:
Ah true, I didn't know ABOOT was the first process with Graphics Output, cheers for that
Really!? I'd assume that JTAG access is enabled for support purposes? The whole "My phones doesn't work" so you send it in? And they'd just re-partition everything?
I bought a RiffBox along time ago (Never actually used it -_-), that allowed direct access to eMMC, read and write you could dump and write whole bin images.
Another quick question, it was my understanding that some of the boot process used ARM's TrustZone or TZ to store keys.
Click to expand...
Click to collapse
The source on the JTAG is evading me at the moment, but iirc the reasoning is that its a huge security hole (shocker...), and not really necessary as the new QC chips are generally regarded as unbrickable, though I have one here that would disagree. You can put the OPO into Qcom download mode and push stock images to the (logical) disk. Will get you out of most bricks, like if you delete boot/recovery and lock the bootloader. I haven't spent enough time digging into it yet to know if you can get raw emmc access that way.
TrustZone is used for secure execution and protected memory. From the LK source it looks like the eMMC keystore is dropped into TZ early in the boot. https://www.codeaurora.org/cgit/qui...rget/msm8974/init.c?h=LA.BR.1.3.2_rb3.16#n362
binsol said:
The source on the JTAG is evading me at the moment, but iirc the reasoning is that its a huge security hole (shocker...), and not really necessary as the new QC chips are generally regarded as unbrickable, though I have one here that would disagree. You can put the OPO into Qcom download mode and push stock images to the (logical) disk. Will get you out of most bricks, like if you delete boot/recovery and lock the bootloader. I haven't spent enough time digging into it yet to know if you can get raw emmc access that way.
TrustZone is used for secure execution and protected memory. From the LK source it looks like the eMMC keystore is dropped into TZ early in the boot. https://www.codeaurora.org/cgit/qui...rget/msm8974/init.c?h=LA.BR.1.3.2_rb3.16#n362
Click to expand...
Click to collapse
Oh the "Download" mode (The sort of last defence, I think its Power in + Volup + Power Button or something), would that be controlled by ABOOT or is it a SoC function? If it is controlled by ABOOT then it could be corrupted pretty easily.
If its controlled by the SoC then where would the code be stored?
(dylanger) said:
Oh the "Download" mode (The sort of last defence, I think its Power in + Volup + Power Button or something), would that be controlled by ABOOT or is it a SoC function? If it is controlled by ABOOT then it could be corrupted pretty easily.
If its controlled by the SoC then where would the code be stored?
Click to expand...
Click to collapse
The key combo trigger is in ABOOT: https://www.codeaurora.org/cgit/quic/la/kernel/lk/tree/app/aboot/aboot.c?h=LA.BR.1.3.2_rb3.16#n3280
However, I wouldn't be surprised if its stored in a different partition (ie dbi), then sbl could auto-boot it in the event of corrupt ABOOT. That would make sense to me, but I haven't purposefully erased or flashed a bad ABOOT yet to find out. The one I bricked here can still get into download mode, yet I cant get any other response from ABOOT if I boot it normally, pretty anecdotal, but leads me to believe the download mode is affected by corrupted ABOOT.
binsol said:
The key combo trigger is in ABOOT: https://www.codeaurora.org/cgit/quic/la/kernel/lk/tree/app/aboot/aboot.c?h=LA.BR.1.3.2_rb3.16#n3280
However, I wouldn't be surprised if its stored in a different partition (ie dbi), then sbl could auto-boot it in the event of corrupt ABOOT. That would make sense to me, but I haven't purposefully erased or flashed a bad ABOOT yet to find out. The one I bricked here can still get into download mode, yet I cant get any other response from ABOOT if I boot it normally, pretty anecdotal, but leads me to believe the download mode is affected by corrupted ABOOT.
Click to expand...
Click to collapse
I've successfully nulled out some fastboot commands before for Anti-Theft, but I'm pretty sure if you have access to Qualcomm's download mode you should be able to re-flash the ABOOT partition and get out of that brick?
Do you think that OnePlus would ever make LK/ABOOT open source? I'd love to be able to create my own bootloader, I wonder if any vendors do this because I'd buy one of their phones immediately!
Going off topic a little bit:
Have you ever looked into Qualcomm's DIAG mode with QPST? A lot of interesting stuff, I know they lock the modem's NV data down with an SPC (Special Programming Code) its a 6 digit PIN. I wonder if anyone has tried to brute-force this PIN? Because the data would allow you to do lots of interesting stuff like have the phone run on completely unsupported frequencies.
(dylanger) said:
I've successfully nulled out some fastboot commands before for Anti-Theft, but I'm pretty sure if you have access to Qualcomm's download mode you should be able to re-flash the ABOOT partition and get out of that brick?
Do you think that OnePlus would ever make LK/ABOOT open source? I'd love to be able to create my own bootloader, I wonder if any vendors do this because I'd buy one of their phones immediately!
Going off topic a little bit:
Have you ever looked into Qualcomm's DIAG mode with QPST? A lot of interesting stuff, I know they lock the modem's NV data down with an SPC (Special Programming Code) its a 6 digit PIN. I wonder if anyone has tried to brute-force this PIN? Because the data would allow you to do lots of interesting stuff like have the phone run on completely unsupported frequencies.
Click to expand...
Click to collapse
I doubt they will, I think support is a pretty big reason they dont release it. That and the number of people who would actually roll their own would be pretty small. Though I would love if they did.
Were you able to make changes to the OPO ABOOT? I saw your IDA post the other day.
It's bee a while since I was digging around in QPST, there was quite a bit of research done for unlocking additional bands on the OPO, generally being inconclusive. http://forum.xda-developers.com/one...ock-aditional-bands-qualcomm-t2877031/page100
https://nathanpfry.com/wip-band-4-band-17-on-chinamobile-oneplus-one/
binsol said:
I doubt they will, I think support is a pretty big reason they dont release it. That and the number of people who would actually roll their own would be pretty small. Though I would love if they did.
Were you able to make changes to the OPO ABOOT? I saw your IDA post the other day.
It's bee a while since I was digging around in QPST, there was quite a bit of research done for unlocking additional bands on the OPO, generally being inconclusive. http://forum.xda-developers.com/one...ock-aditional-bands-qualcomm-t2877031/page100
https://nathanpfry.com/wip-band-4-band-17-on-chinamobile-oneplus-one/
Click to expand...
Click to collapse
Indeed I was, I used a Hex Editor to null out (\x00) commands like "fastboot flash", "fastboot erase" and "fastboot oem"
Its very irritating, IDA can read everything up until the apps_init function.
Here's a snippet of the apps_init boot process from Reverse Engineering Android's Aboot book (http://newandroidbook.com/Articles/aboot.html)
{
"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"
}
When IDA got to loading any app, I.E fastboot it would get obfuscated and just render as hex. Have you tried to play around with ABOOT before? So close to actually seeing ARM Assembly.
(dylanger) said:
Indeed I was, I used a Hex Editor to null out (\x00) commands like "fastboot flash", "fastboot erase" and "fastboot oem"
Its very irritating, IDA can read everything up until the apps_init function.
Here's a snippet of the apps_init boot process from Reverse Engineering Android's Aboot book (http://newandroidbook.com/Articles/aboot.html)
When IDA got to loading any app, I.E fastboot it would get obfuscated and just render as hex. Have you tried to play around with ABOOT before? So close to actually seeing ARM Assembly.
Click to expand...
Click to collapse
That's cool, I'll start probing around. I haven't messed with aboot in IDA at all, but I've used IDA a lot in a past.
Do you think the obfuscation is deliberate? Also have you tried some of the mbn scripts around? http://forum.xda-developers.com/showthread.php?t=2641245
I've seen a few references to them when people are reversing bootloaders.
binsol said:
That's cool, I'll start probing around. I haven't messed with aboot in IDA at all, but I've used IDA a lot in a past.
Do you think the obfuscation is deliberate? Also have you tried some of the mbn scripts around? http://forum.xda-developers.com/showthread.php?t=2641245
I've seen a few references to them when people are reversing bootloaders.
Click to expand...
Click to collapse
Really? Reverse Engineering is pretty fun, really getting into the mind of the developer.
Yeah use that plugin,
Oooo I have have found the code that loads fastboot.c
The obfuscation may have been my fault, I've loaded in ABOOT from Color OS and it looks like everything is okay now.
Woohoo! Check that out!
After poking around a little bit more, ColorOS is a KitKat ROM that uses an older ABOOT, that's why it successfully opened in IDA.
If I open ABOOT from OnePlus One's latest firmware (cm-12.1-YOG4PAS1N0-bacon-signed) I get this
Now I think its doing this because the plugin provided by MemoryController is outdated, I have no idea how to create these scripts/plugins for IDA, if anyone does know please let me know, I think this could also unlock the ability to change the boot splash screens on newer firmware as the images in the LOGO partition are encrypted, the code inside of this newer ABOOT could contain the decryption process.
Back to the older KitKat ABOOT here is the boot.img (Kernel) loading code just FYI:
We should probably move this thread over to your OPO topic, It'll probably get move views over there:
http://forum.xda-developers.com/oneplus-one/general/oneplus-one-lk-little-kernel-bootloader-t3269111
binsol said:
I read somewhere that JTAG is generally disabled/removed from non-engineering devices with 800+ series snapdragons.
Click to expand...
Click to collapse
This isn't specifically the source I was thinking of when I wrote that, but it also suggests that JTAG is generally disabled:
http://recon.cx/2013/slides/Recon20...uditing Android's Proprietary Bits-public.pdf
Slides 31,48
binsol said:
This isn't specifically the source I was thinking of when I wrote that, but it also suggests that JTAG is generally disabled:
http://recon.cx/2013/slides/Recon20...uditing Android's Proprietary Bits-public.pdf
Slides 31,48
Click to expand...
Click to collapse
Ah yeah I've seen this, I'm actually digging into the vendor-ril driver (libril-qc-qmi-1.so) as I'd like to share the baseband of one device to another.
Interesting I've found come code referencing "QCRIL_EVT_HOOK_UNSOL_ENGINEER_MODE", UNSOL means Unsolicited Command, meaning its an incoming command from the base band to the upper layers of the RIL, looks kind of backdoor-ey to me, perhaps remote enabling of Engineer Mode?
I've also just seen (I guess) is the SIM PIN and PUK verification code?
Should I create another thread? Would you be interested in discussing further?
There were a lot of interesting strings in the modem last time I looked, like stuff relating to http and hdmi (video drm?). Is this the OnePlus One modem? It would probably make sense to make a thread in that forum. I'm not sure how much interest it would generate here.
Hello, I made the mistake of trying to use a remote unlocking service on eBay to unlock my LS992, but the person performing the operation somehow managed to brick my phone. The device is stuck on download mode, and though he attempted to re-flash the firmware it was unsuccessful. I was on the line with him for several hours with no fix in sight. He claims that the phone was on software version ZVA, but I am unable to confirm that as the phone is bricked, however, when I connect to LGUP it reports the version as LS992V3. I'm not sure if it is correct.
So the bottom line is, I would like to try to reflash the phone for myself, but I am unable to find the .dll files for the Sprint variant anywhere to flash with LG UP. I'm also unsure of what version stock firmware I should flash, as he said that flashing the wrong firmware might hard brick. Any insight on what to do will be greatly appreciated, or at the very the correct .dll file to use when flashing.
Thank you for your time and consideration.
Guys, Is there any way to get rid of that ugly bootloader unlock warning when phone is reboot?
EDIT September 11, 2020:
Here you go:
LG V30 Unlocked Bootloader Warning Disabler
I would add it to the WTF Instructions but I've run out of room on that LONG post. It's posted in the mods/themes/apps section. People will just have to find it.
Thats the bootloader, telling you its unlocked.... thats before/during the splash screen i think...
I doubt we can get rid of it, except locking your bootloader again probably? (is that even possible on a H930/US998?)
No,like on the G5 it's not possible to remove it.
Unlocked bootloader = warning screen.
There is nothing we can do.
Regards
mkpcxxl
On my old Moto G was the similar bootloader unlock warrning and someone made the flashable zip that this turn, off but that was message instead of the Motorola logo. This was annoying for everyone.
https://forum.xda-developers.com/2015-moto-g/themes-apps/remove-unlocked-bootloader-warning-t3294590
SGCMarkus said:
Thats the bootloader, telling you its unlocked.... thats before/during the splash screen i think...
I doubt we can get rid of it, except locking your bootloader again probably? (is that even possible on a H930/US998?)
Click to expand...
Click to collapse
Bootloader unlock warning has always been able to be replaced on Motorola phones. It's simply a static boot logo graphic.
When you unlock a Motorola bootloader, the "regular" M logo gets replaced by a scary "bootloader unlocked warning". Both are simple static graphic files. I've made lots of them for Motorola phones, which could be flashed via ADB or even TWRP. Surely LG is the same?
What do people do for the bootloader unlocked open market LG G5, V20, LG G6? They don't put up with that annoyance do they?
I suppose if the image the bootloader draws for a short time over the splash screen is stored somewhere else than the bootloader itself (aka not hardcoded), im sure it could be replaced, but someone has to find out where its stored how xD
SGCMarkus said:
I suppose if the image the bootloader draws for a short time over the splash screen is stored somewhere else than the bootloader itself (aka not hardcoded), im sure it could be replaced, but someone has to find out where its stored how xD
Click to expand...
Click to collapse
Yes, on some phones it's called the splash screen. Also, called the boot logo, not to be confused with the boot animation.
Surely people have done it. I've not messed with LG phones since LG G2/G3 and then I never really unlocked the bootloader but used exploits to install TWRP and root. But it's common with Motorola phones.
If you want to figure out the format of the raw_resources partition, that is where all the images are stored. It is possible to change them, but if you mess up, then your phone is a brick since abl will not load -- which is why the risk just wasn't worth it for me.
They are RLE so they have no header. There is an index that gives the name and offset for the location of the image, but not the size (either they are all the same size, or the size is stored somewhere else).
-- Brian
runningnak3d said:
If you want to figure out the format of the raw_resources partition, that is where all the images are stored. It is possible to change them, but if you mess up, then your phone is a brick since abl will not load -- which is why the risk just wasn't worth it for me.
They are RLE so they have no header. There is an index that gives the name and offset for the location of the image, but not the size (either they are all the same size, or the size is stored somewhere else).
-- Brian
Click to expand...
Click to collapse
What if you just want a different boot animation?
Is replacing the Zips in system - media safe?
Or just out right delete them? I hate that T-Mobile logo with a passion.
Sent from my LG-H932 using XDA Labs
Edit, I figured it was safe but to be sure I tested on my V20.
Now I customized my v30 .
Perhaps better yet (though I need some more people to help confirm this)...
I have successfully removed the bootloader warning for my unlocked US998.
The process is simple but try at your own risk for other variants more dissimilar to the US998 etc.. etc..
Steps:
Verizon (in their infinite wisdom) thought "Oh hey, no one will ever ever ever get the LG V30 with our software and have an unlocked bootloader, so why even bother having an unlock warning. "
Lets prove them wrong.
Take a backup (of course)
Go grab yourself the latest VS996_20d kdz file (available here on XDA or "LG-Firmwares")
Get your phone in LGUP mode (/w power off hold Vol-UP while inserting USB to computer)
In LGUP select PARTITION-DL and point it to the shiny VS996-20d kdz you waited so long for the download to complete
Click start then in the partitions list ONLY select raw_resources.
Click Ok.
The phone will do its thing and it will reboot and you will notice a black screen instead of annoying warning... Thanks Verizon. :silly:
Hope this helps!
That warning screen is nothing to even care about.
Sent from my LG-H932 using XDA Labs
SaberShip said:
Perhaps better yet (though I need some more people to help confirm this)...
I have successfully removed the bootloader warning for my unlocked US998.
The process is simple but try at your own risk for other variants more dissimilar to the US998 etc.. etc..
Steps:
Verizon (in their infinite wisdom) thought "Oh hey, no one will ever ever ever get the LG V30 with our software and have an unlocked bootloader, so why even bother having an unlock warning. "
Lets prove them wrong.
Take a backup (of course)
Go grab yourself the latest VS996_20d kdz file (available here on XDA or "LG-Firmwares")
Get your phone in LGUP mode (/w power off hold Vol-UP while inserting USB to computer)
In LGUP select PARTITION-DL and point it to the shiny VS996-20d kdz you waited so long for the download to complete
Click start then in the partitions list ONLY select raw_resources.
Click Ok.
The phone will do its thing and it will reboot and you will notice a black screen instead of annoying warning... Thanks Verizon. :silly:
Hope this helps!
Click to expand...
Click to collapse
It does get rid of the bootloader unlock warning, yes. However it now says you have a V30, even if you have a V30+. Depends on if that matters to you.
If someone has a phone under warranty and wants to be really brave -- null out raw_resources and you should just have a black screen.
Again, that is a risk since the loading routine in abl could have bugs and get wigged out and go into a loop or something. If that happens -- 9008 brick.
If someone wants to try it, boot to TWRP and:
Code:
adb shell dd if=/dev/zero of=/dev/block/bootdevice/by-name/raw_resources
reboot and tell us what happened
-- Brian
I thought about this because I liked customizing the boot on my old Motorola phones.
But then I thought, how many times do I actually restart my phone to care about how the boot screen looks?
95% of the time, your phone is on standby.
LOL @runningnak3d ^
Considering you can no longer decompile abl since it is encrypted, the only way to find out is to test it
-- Brian
I'd like to, but this phone as of Saturday, is still worth nearly 500 in-store trade. I'm on the fence.
I can tell you that the only thing in raw_resources are the images that you see for things like the big errors and the charging images, and crap like that.
Someone has to do it. I would, but for some reason eBay doesn't want me to have a V30 .. they just want to tie up my money.
-- Brian
runningnak3d said:
I can tell you that the only thing in raw_resources are the images that you see for things like the big errors and the charging images, and crap like that.
Someone has to do it. I would, but for some reason eBay doesn't want me to have a V30 .. they just want to tie up my money.
-- Brian
Click to expand...
Click to collapse
I think I'd rather take my chances poking around in the binary with a hex editor before zeroing the whole partition. Zeroing would be asking for null pointer exceptions in your bootloader. I don't want to speculate what that might do. Who knows with LG... maybe it will re-lock the bootloader bahhaha....
As others have pointed out i'm not sure the reward is worth the time right now. There are a lot bigger problems yet to be solved with this device in terms of development.
Hey guys,
So thanks to this thread : https://forum.xda-developers.com/pixel-2-xl/how-to/guide-qxdm-port-activation-pixel-2-xl-t3884967
I got my com ports open (see attached photo)
I cant however get past the part about pdc , as pdc gives me "QMI connection not ready, please use USB driver version 1.00.32 or later and fix the connection before using PDC tool."
I'm not sure how to go about fixing this but if we can, then there is the possibility that we could enable voLTE/voWIFI on the pixel 3 with carriers who don't support it(such as bouygues, who supports voLTE but not anything else)
I'm wondering if it is the qpst version I am using or something else?
I am on windows 7 and also had to disable driver signature enforcement.
Hello!
Did you achieve progress in this issue after the publication of the message?
Any success?? I have this damn same issue on my Redmi 4x...
Has anyone figured out the correct drivers yet?
Ingenium13 said:
Has anyone figured out the correct drivers yet?
Click to expand...
Click to collapse
Check this method! Hope this helps.
crok.bic said:
Check this method! Hope this helps.
Click to expand...
Click to collapse
He already mentioned in his last line that he is using windows 7 and also disabled driver signature enforcement.
can you tell me steps for enable QPST on pixel 3
Xdevillived666 said:
Hey guys,
So thanks to this thread : https://forum.xda-developers.com/pixel-2-xl/how-to/guide-qxdm-port-activation-pixel-2-xl-t3884967
I got my com ports open (see attached photo)
I cant however get past the part about pdc , as pdc gives me "QMI connection not ready, please use USB driver version 1.00.32 or later and fix the connection before using PDC tool."
I'm not sure how to go about fixing this but if we can, then there is the possibility that we could enable voLTE/voWIFI on the pixel 3 with carriers who don't support it(such as bouygues, who supports voLTE but not anything else)
I'm wondering if it is the qpst version I am using or something else?
I am on windows 7 and also had to disable driver signature enforcement.
Click to expand...
Click to collapse
can you tell me steps for enable QPST on pixel i am unable to open port on my pixel
Gautamgzb2 said:
can you tell me steps for enable QPST on pixel i am unable to open port on my pixel
Click to expand...
Click to collapse
Hey. I honestly dont remember now. Its been a long time and it was a lot of trial and error by reading that thread I linked. In the end it was useless because A-google no longer provides images for debugging purposes and B-PDC tool doesnt recognize pixel 3 even after opening the ports. Sorry man.
i hve enabled diag port fully edited values in qxdm took ota updates but upon re locking bootloader pixel 3 resets every change i made what the hell how can factory reset revert nvram changes.
"QPST" stands for "Qualcomm Product Support Tool". It's a proprietary tool used to directly write a binary image to the NAND devices on the device. Neither QPST nor the binary images are freely available, and are generally only used during the factory process to flash the initial firmware to the device.
V0latyle said:
"QPST" stands for "Qualcomm Product Support Tool". It's a proprietary tool used to directly write a binary image to the NAND devices on the device. Neither QPST nor the binary images are freely available, and are generally only used during the factory process to flash the initial firmware to the device.
Click to expand...
Click to collapse
Hmmm, no, not true. Qpst / qfil is freely available, We've used it many times with various LG devices especially.
The binary images are freely available for many devices, here's a list of the binary images free to download for the pixel 3 (from google):
In addition, for LG devices, anyone can freely download the kdz image, which is the entire rom, and use the kdz extraction tool to retrieve any individual partition image.
Not all carriers, like at&t / sprint, don't make their kdz available, thus no access to those images, but most do.
AsItLies said:
Hmmm, no, not true. Qpst / qfil is freely available, We've used it many times with various LG devices especially.
The binary images are freely available for many devices, here's a list of the binary images free to download for the pixel 3 (from google):
In addition, for LG devices, anyone can freely download the kdz image, which is the entire rom, and use the kdz extraction tool to retrieve any individual partition image.
Not all carriers, like at&t / sprint, don't make their kdz available, thus no access to those images, but most do.
Click to expand...
Click to collapse
So QPST can be used to flash bootloader, at which point someone should be able to use adb to flash the factory images? Wouldn't someone need to know the starting/ending addresses when writing to block devices?
Is there a reputable source from which to download QPST?
V0latyle said:
So QPST can be used to flash bootloader, at which point someone should be able to use adb to flash the factory images? Wouldn't someone need to know the starting/ending addresses when writing to block devices?
Is there a reputable source from which to download QPST?
Click to expand...
Click to collapse
QPST / qfil links can be found in many places, I've found them in LG v35, v40, v50, G8 forums in guides section, usual title names include 'unlock bootloader' as qfil is used to flash the 'engineering abl' to gain fastboot.
addresses of the partitions are in the partition table of ea device. Depending on how you flash a partition you may need to know it specifically, but almost always you don't. The RawprogramX.xml has them in it if needed though.
There is one caveat, for qfil to work (or any EDL access to happen), with any device, one has to have the 'programmer firehose', which is a signed specific file, for that specific device type. Many mfgs make that file available, Google does not.
AsItLies said:
QPST / qfil links can be found in many places, I've found them in LG v35, v40, v50, G8 forums in guides section, usual title names include 'unlock bootloader' as qfil is used to flash the 'engineering abl' to gain fastboot.
addresses of the partitions are in the partition table of ea device. Depending on how you flash a partition you may need to know it specifically, but almost always you don't. The RawprogramX.xml has them in it if needed though.
There is one caveat, for qfil to work (or any EDL access to happen), with any device, one has to have the 'programmer firehose', which is a signed specific file, for that specific device type. Many mfgs make that file available, Google does not.
Click to expand...
Click to collapse
This was going to be my next question. We aren't talking about LG devices here; we're talking specifically about the Pixel 3. So if the firehose files aren't available, exactly how is QPST any good to anyone?
V0latyle said:
This was going to be my next question. We aren't talking about LG devices here; we're talking specifically about the Pixel 3. So if the firehose files aren't available, exactly how is QPST any good to anyone?
Click to expand...
Click to collapse
I know what we're talkin about here, and I know it's not LG devices. And I never said qpst was any good to anybody here, I just said that it is available, and you said it wasn't, and I said the stock images are available, and you said they weren't.
AsItLies said:
I know what we're talkin about here, and I know it's not LG devices. And I never said qpst was any good to anybody here, I just said that it is available, and you said it wasn't, and I said the stock images are available, and you said they weren't.
Click to expand...
Click to collapse
I think you misunderstand me. As I asked before, please post a legitimate and trustworthy source of QPST. According to Qualcomm, it's only available for specific commercial use.
Secondly, I was specific by what I meant by "binary images" - files to be flashed directly to the NAND devices by means of JTAG or other hardware level protocols. This would include the firehose images, although I admit I'm not sure if those are binary.
Either way, I reiterate that we are talking about the Pixel 3 here. If you know of a trustworthy source for QPST, that's a start. However, the fact remains that the files needed are not available, so what may or may not be possible with LG devices is not relevant in this thread.
V0latyle said:
I think you misunderstand me. As I asked before, please post a legitimate and trustworthy source of QPST. According to Qualcomm, it's only available for specific commercial use.
Secondly, I was specific by what I meant by "binary images" - files to be flashed directly to the NAND devices by means of JTAG or other hardware level protocols. This would include the firehose images, although I admit I'm not sure if those are binary.
Either way, I reiterate that we are talking about the Pixel 3 here. If you know of a trustworthy source for QPST, that's a start. However, the fact remains that the files needed are not available, so what may or may not be possible with LG devices is not relevant in this thread.
Click to expand...
Click to collapse
I think you misunderstood me. You indicated that QPST / qfil is not availabel, it is, I told you where to find it, put in the effort.
And what you mean by 'binary images' is obviously open to interpretation, how in the world would I (or anyone) know you mean anything other than what is available (from google), which are the binary images one would flash with qfil for that device. So again, you're wrong as they are available.
And I'll repeat again, I know we're talking about the p3 and not LG devices. You're using that as a deflection, to try to avoid that your post was obviously wrong in it's information. I bring up LG devices only because they have lots of documentation here on XDA re these utilities, while the p3 does not.
"what may or may not be possible with LG"... yer again wrong. Ea and every qualcomm device can be put in EDL mode, that's what QPST is used for, it's relevant to all devices that have a qualcomm chip.
AsItLies said:
I think you misunderstood me. You indicated that QPST / qfil is not availabel, it is, I told you where to find it, put in the effort.
Click to expand...
Click to collapse
I asked you to provide a specific source. I don't know which forums you're talking about on what site. They could be here on XDA, or Reddit, or any LG forum out there. Your response is akin to "just Google it". The only reputable source I know of is Qualcomm themselves, who, as I stated, are pretty picky about who gets access to the software. Sure, a Google search will turn up a handful of third party sites that claim to have it, but are they trustworthy?
AsItLies said:
And what you mean by 'binary images' is obviously open to interpretation
Click to expand...
Click to collapse
Not really. Binary images = files in purely binary format. Not Java, not hex - ones and zeroes, the file you would use to directly flash a memory device. I was pretty specific about that.
AsItLies said:
how in the world would I (or anyone) know you mean anything other than what is available (from google), which are the binary images one would flash with qfil for that device. So again, you're wrong as they are available.
Click to expand...
Click to collapse
Two posts ago you stated:
AsItLies said:
for qfil to work (or any EDL access to happen), with any device, one has to have the 'programmer firehose', which is a signed specific file, for that specific device type. Many mfgs make that file available, Google does not.
Click to expand...
Click to collapse
So, since no "firehouse" files are available from Google, could QPST be used to flash the partition images in the factory zips?
AsItLies said:
And I'll repeat again, I know we're talking about the p3 and not LG devices. You're using that as a deflection, to try to avoid that your post was obviously wrong in it's information. I bring up LG devices only because they have lots of documentation here on XDA re these utilities, while the p3 does not.
Click to expand...
Click to collapse
No, I'm pointing out that information on LG devices is not relevant. There might be documentation regarding the use of QPST but if the necessary files are not available, that's not much use.
AsItLies said:
"what may or may not be possible with LG"... yer again wrong. Ea and every qualcomm device can be put in EDL mode, that's what QPST is used for, it's relevant to all devices that have a qualcomm chip.
Click to expand...
Click to collapse
I'm specifically referring to the possibility of hardware level device recovery which may be possible on LG devices due to the availability of the required files, but is not currently possible on the Pixel series because we do NOT have the required files.
I'm not going to continue this argument as we are rather OT at this point. This isn't conducive to finding a solution.
XDA thrives on the willingness of users to help out everyone else - the ability and willingness to solve problems. You said there is a solution to this problem; I am asking you provide it. It doesn't matter who is right or wrong in the end; it only matters that we find a solution.
Hi, @ante0 , @Pretoriano80 and everyone else!
Been lurking on these forums ever since mate 10 Pro was released, but due to being one of the folks to downgrade from emui 9 to brick I had to take my phone to service for board swapping as I wasn't in a situation to do the testpoint fix myself.
Now, I'm looking to get the bootloader unlock code again and to my surprise even the 3rd party sites are down.
There's a guy at minstryofsolutions that offers bootloader unlock code using testpoint but he asks for 40$ + access to pc for 2 hours + refuses to describe in any way what he's doing to the device and why will the device end up rebranded + new imei and with it new bootloader code ( Obviously device in that condition can't be taken into a Huawei service center) .
So, upon searching and trying to find if anyone had found a way to unlock using testpoint I stumbled upon this : https://forum.xda-developers.com/mediapad-m5/how-to/downgrade-unbrick-huawei-device-methods-t3915693
Op and several others seem successful with downgrading their devices and using dc unlocker to get the code once the security patch is no more.
Op even mentions that for kirin 970 it's probably the same process but I haven't seen anyone sharing their experience doing the same on 979 devices.
Couple users are having issues as well and while op was quite helpful he and several others that were helping out seem to have been gone missing. There's a guy helping out with issues regarding this process but it seems rather finicky when even after doing all this and flashing with dload certain parts like lte modem remain present on a WiFi only tablet.
Does anyone have passes for easy firmware or dc unlocker firmware database? Is anyone willing to give these a try and see if the process will work on our devices or if it will ask for verification of some kind for images being flashed?
It looks quite promising, so if anyone has a bricked device ( Maybe someone that was refused at the Huawei repair center during the wave of downgrades ) would you be willing to give it a try?
I've got no tools, no passes and no other device to use while playing with this.
Obviously, I'm not asking for you guys to go out of your way and brick the device so I can know whether this is a viable option or not lol.
Just thought about sharing and seeing if anyone more knowledgeable has anythiny they'd like to add to this as a tip or personal experience trying this method.
This might be what we are looking for when it comes to unlocking device / downgrading to lower versions.
Hopefully the post I linked helps someone, in case anyone has experience with this please share as well!
Anyways thanks in advance!
Rstment ^m^ said:
Hi, @ante0 , @Pretoriano80 and everyone else!
Been lurking on these forums ever since mate 10 Pro was released, but due to being one of the folks to downgrade from emui 9 to brick I had to take my phone to service for board swapping as I wasn't in a situation to do the testpoint fix myself.
Now, I'm looking to get the bootloader unlock code again and to my surprise even the 3rd party sites are down.
There's a guy at minstryofsolutions that offers bootloader unlock code using testpoint but he asks for 40$ + access to pc for 2 hours + refuses to describe in any way what he's doing to the device and why will the device end up rebranded + new imei and with it new bootloader code ( Obviously device in that condition can't be taken into a Huawei service center) .
So, upon searching and trying to find if anyone had found a way to unlock using testpoint I stumbled upon this : https://forum.xda-developers.com/mediapad-m5/how-to/downgrade-unbrick-huawei-device-methods-t3915693
Op and several others seem successful with downgrading their devices and using dc unlocker to get the code once the security patch is no more.
Op even mentions that for kirin 970 it's probably the same process but I haven't seen anyone sharing their experience doing the same on 979 devices.
Couple users are having issues as well and while op was quite helpful he and several others that were helping out seem to have been gone missing. There's a guy helping out with issues regarding this process but it seems rather finicky when even after doing all this and flashing with dload certain parts like lte modem remain present on a WiFi only tablet.
Does anyone have passes for easy firmware or dc unlocker firmware database? Is anyone willing to give these a try and see if the process will work on our devices or if it will ask for verification of some kind for images being flashed?
It looks quite promising, so if anyone has a bricked device ( Maybe someone that was refused at the Huawei repair center during the wave of downgrades ) would you be willing to give it a try?
I've got no tools, no passes and no other device to use while playing with this.
Obviously, I'm not asking for you guys to go out of your way and brick the device so I can know whether this is a viable option or not lol.
Just thought about sharing and seeing if anyone more knowledgeable has anythiny they'd like to add to this as a tip or personal experience trying this method.
This might be what we are looking for when it comes to unlocking device / downgrading to lower versions.
Hopefully the post I linked helps someone, in case anyone has experience with this please share as well!
Anyways thanks in advance!
Click to expand...
Click to collapse
You can as I've done it.
Use testpoint (this will void warranty as you have to remove back of the phone) and flash bootloader files from DC Phoenix, there are several Kirin970 to choose from but only one should work. DC will tell you when phone is in fastboot mode after flashing.
Then I used IDT (Image Download Tool) to flash board firmware. Boot to board firmware and used HCU to repair imeis and all that. Then used HCU to get an unlock code. After this flash dload firmware back to Oreo (needs to be a new dload because of updated bootloader).
HCU fix guide for BLA:
1)Flash oeminfo (own backup) from fastboot OR dump existing oeminfo using adb pull (adb pull /dev/block/bootdevice/by-name/oeminfo) then flash it from fastboot.
2)Backup modemnvm_system, modemnvm_factory and modemnvm_backup using adb pull from a command prompt (/dev/block/bootdevice/by-name/modemnvm_system and so on)
3)Flash backed up modemnvm_system, modemnvm_factory and modemnvm_backup from fastboot
3)Modify and brand with HCU in the CDMA tab (check everything but those that erase/flash empty board) (remember to fill vendor and cust)
4)Unlock sim 'Direct SIM Unlock'
5)Read Bootloader code if you ever used HCU to get code before or if you need unlock code
6)Download and flash Oreo service firmware from androidhost.ru using a OTG cable and a memory stick. Pick the latest Oreo one you find for your cust
If you fail to do any of the steps above you will end up with no IMEIs or 'No Network' and/or Sim lock
So you'd need: DC/HCU pass and unencrypted board firmware (gem-flash and easy-firmware has them but they're paid.).
I have not tested using DCs own board firmware.
ante0 said:
You can as I've done it.
Use testpoint (this will void warranty as you have to remove back of the phone) and flash bootloader files from DC Phoenix, there are several Kirin970 to choose from but only one should work. DC will tell you when phone is in fastboot mode after flashing.
Then I used IDT (Image Download Tool) to flash board firmware. Boot to board firmware and used HCU to repair imeis and all that. Then used HCU to get an unlock code. After this flash dload firmware back to Oreo (needs to be a new dload because of updated bootloader).
HCU fix guide for BLA:
1)Flash oeminfo (own backup) from fastboot OR dump existing oeminfo using adb pull (adb pull /dev/block/bootdevice/by-name/oeminfo) then flash it from fastboot.
2)Backup modemnvm_system, modemnvm_factory and modemnvm_backup using adb pull from a command prompt (/dev/block/bootdevice/by-name/modemnvm_system and so on)
3)Flash backed up modemnvm_system, modemnvm_factory and modemnvm_backup from fastboot
3)Modify and brand with HCU in the CDMA tab (check everything but those that erase/flash empty board) (remember to fill vendor and cust)
4)Unlock sim 'Direct SIM Unlock'
5)Read Bootloader code if you ever used HCU to get code before or if you need unlock code
6)Download and flash Oreo service firmware from androidhost.ru using a OTG cable and a memory stick. Pick the latest Oreo one you find for your cust
If you fail to do any of the steps above you will end up with no IMEIs or 'No Network' and/or Sim lock
So you'd need: DC/HCU pass and unencrypted board firmware (gem-flash and easy-firmware has them but they're paid.).
I have not tested using DCs own board firmware.
Click to expand...
Click to collapse
Thanks a lot!
Will any of this process leave bootloader unlocked / relocked along the way?
I'm experiencing screen burn in due to outdated firmware and was gonna get the code, apply new adhesive I buy online and have them replace the device's screen + seal it properly in the process so the water resistance remains - kinda essential to hide any signs of tampering like bootloader unlock '-' ( 2nd burn in on Oreo firmware now, both happened within few months of the device running old firmw )
Thanks for the guide as well!
I'm not completely sure how to do the whole process yet but I'll try getting all the software I can right now and try figuring it out.
One question tho, do you have any screenshots you can share of which firmware will work out of those several that you mentioned and is there any possibility of brick by flashing wrong xload, etc.?
I'm on 8.0.0.156 c432 and was gonna drop to 142 or 143 - will have to check which one is the latest without security patch.
Glad to know this is a possibility! Will order the tools required for this and when / if I'm successful I'll create seperate thread under guides as there prolly are peps still trying to unlock.
Rstment ^m^ said:
Thanks a lot!
Will any of this process leave bootloader unlocked / relocked along the way?
I'm experiencing screen burn in due to outdated firmware and was gonna get the code, apply new adhesive I buy online and have them replace the device's screen + seal it properly in the process so the water resistance remains - kinda essential to hide any signs of tampering like bootloader unlock '-' ( 2nd burn in on Oreo firmware now, both happened within few months of the device running old firmw )
Thanks for the guide as well!
I'm not completely sure how to do the whole process yet but I'll try getting all the software I can right now and try figuring it out.
One question tho, do you have any screenshots you can share of which firmware will work out of those several that you mentioned and is there any possibility of brick by flashing wrong xload, etc.?
I'm on 8.0.0.156 c432 and was gonna drop to 142 or 143 - will have to check which one is the latest without security patch.
Glad to know this is a possibility! Will order the tools required for this and when / if I'm successful I'll create seperate thread under guides as there prolly are peps still trying to unlock.
Click to expand...
Click to collapse
I doubt that the burn-in is because of the old firmware, probably the oled panel it's getting old.
You should do the other way around, first send it to Huawei for a display replacement and then get the unlock code.
The procedure it's not really easy and the water resistant part it's the last of your problem, first you must make sure that you don't break the glass back cover when you open it up. xD
Probably Huawei's repair center won't even bother to replace the display only, but they will replace almost everything, so you would endup with a locked bootloader again.
Pretoriano80 said:
I doubt that the burn-in is because of the old firmware, probably the oled panel it's getting old.
You should do the other way around, first send it to Huawei for a display replacement and then get the unlock code.
The procedure it's not really easy and the water resistant part it's the last of your problem, first you must make sure that you don't break the glass back cover when you open it up. xD
Probably Huawei's repair center won't even bother to replace the display only, but they will replace almost everything, so you would endup with a locked bootloader again.
Click to expand...
Click to collapse
The display literally burned in couple months after I boguht the device and and we still had the emui 8 only. Replaced it and switched to the 9 the same month. All was good for a year or so untill they replaced motherboard. Now the same thing all over again, few months have passed - literally 2/3 months and the screen burned in again at the same spot - navigation bar.
The opening part doesn't look that complicated, was thinking of buying a heating plate, heat phone to 120°C and go back and forward cutting adhesive then heating the phone again. Should be fast and efficient this way.
The finicky part that I'm worried about has to do with bricking the device or shorting the motherboard in some way '-' Maybe service also uses some repair stickers that aren't present on any of the guides and will get dmged when I open the device - after all, I took the device for repairs under warranty at least 5+ times by now
Last time for the replacement they indeed replace almost everything - display, battery, back cover, new frame - essentially a new device w same motherboard.
Pretoriano80 said:
I doubt that the burn-in is because of the old firmware, probably the oled panel it's getting old.
You should do the other way around, first send it to Huawei for a display replacement and then get the unlock code.
The procedure it's not really easy and the water resistant part it's the last of your problem, first you must make sure that you don't break the glass back cover when you open it up. xD
Probably Huawei's repair center won't even bother to replace the display only, but they will replace almost everything, so you would endup with a locked bootloader again.
Click to expand...
Click to collapse
Rstment ^m^ said:
The display literally burned in couple months after I boguht the device and and we still had the emui 8 only. Replaced it and switched to the 9 the same month. All was good for a year or so untill they replaced motherboard. Now the same thing all over again, few months have passed - literally 2/3 months and the screen burned in again at the same spot - navigation bar.
The opening part doesn't look that complicated, was thinking of buying a heating plate, heat phone to 120°C and go back and forward cutting adhesive then heating the phone again. Should be fast and efficient this way.
The finicky part that I'm worried about has to do with bricking the device or shorting the motherboard in some way '-' Maybe service also uses some repair stickers that aren't present on any of the guides and will get dmged when I open the device - after all, I took the device for repairs under warranty at least 5+ times by now
Last time for the replacement they indeed replace almost everything - display, battery, back cover, new frame - essentially a new device w same motherboard.
Click to expand...
Click to collapse
Also, if they do replace stuff the code you get through DC will not work.
It works by modifying some strings in the oeminfo partition, so if they were to wipe and reflash everything your code would be lost.
If they replace motherboard you will need a new unlock code.
There is a sticker on one of the screws you need to remove, so they will know you did open it anyway.
Bricking is no problem as you can unbrick using testpoint. Shorting shouldn't be a problem. I tried all the visible points and only 1 or 2 actually send current back so USB devices in computer restarted xD But none of them shorted my phone.
ante0 said:
Also, if they do replace stuff the code you get through DC will not work.
It works by modifying some strings in the oeminfo partition, so if they were to wipe and reflash everything your code would be lost.
If they replace motherboard you will need a new unlock code.
There is a sticker on one of the screws you need to remove, so they will know you did open it anyway.
Bricking is no problem as you can unbrick using testpoint. Shorting shouldn't be a problem. I tried all the visible points and only 1 or 2 actually send current back so USB devices in computer restarted xD But none of them shorted my phone.
Click to expand...
Click to collapse
I see on pictures online that there are some points exposed with the shield on. Will take a look at picture you posted earlier for testpoint location to determine if indeed you can access it without removing the shield - hence not touching the stickers you mentioned - ty!
Wdym by losing dc unlocker code tho?
Does it not read the bootloader code of the device - meaning after they wipe / flash their stuff I can use the same code again to unlock via fastboot?
Or can it not read the code and just modifies the nvme files or whatev inside the partition to allow for a custom bootloader code?
Thanks for all the info! Will go look now for the picture then decide whether I'll open before or afterwards depending on the position of test point.
Rstment ^m^ said:
I see on pictures online that there are some points exposed with the shield on. Will take a look at picture you posted earlier for testpoint location to determine if indeed you can access it without removing the shield - hence not touching the stickers you mentioned - ty!
Wdym by losing dc unlocker code tho?
Does it not read the bootloader code of the device - meaning after they wipe / flash their stuff I can use the same code again to unlock via fastboot?
Or can it not read the code and just modifies the nvme files or whatev inside the partition to allow for a custom bootloader code?
Thanks for all the info! Will go look now for the picture then decide whether I'll open before or afterwards depending on the position of test point.
Click to expand...
Click to collapse
When you use HCU to get code it writes stuff to oeminfo, replacing 2 strings with "DC-UNLOC". So that's used in calculation of code. If you flash back stock, unmodified, oeminfo after using HCU you won't be able to use the code it generated.
Testpoint is located under the shield, so it's not possible to get to it without removing the shield. I have my phone with shield on infront of me. And I can't remember which screw had the sticker on it. If it's on one of the corners I guess you could try to bend it up to get to testpoint.
I just can't understand why the won't release the bootloader unlock at this point? The phone is now 'outdated' and old.... where is the harm?
ante0 said:
When you use HCU to get code it writes stuff to oeminfo, replacing 2 strings with "DC-UNLOC". So that's used in calculation of code. If you flash back stock, unmodified, oeminfo after using HCU you won't be able to use the code it generated.
Testpoint is located under the shield, so it's not possible to get to it without removing the shield. I have my phone with shield on infront of me. And I can't remember which screw had the sticker on it. If it's on one of the corners I guess you could try to bend it up to get to testpoint.
Click to expand...
Click to collapse
Thanks but I'm still having hard of a time following ?
After you use hcu it modifies the oeminfo to get strings it needs for calculations - You get the code aftwerards and your oeminfo is modified, right?
What I don't get is how flashing stock makes code unusable tho?
Is it not original bootloader code we'd get if Huawei site was still up? That code should be usable even after all modifications were reflashed with stock, no?
Or is it a custom code that depends on modified oeminfo to work?
Rstment ^m^ said:
Thanks but I'm still having hard of a time following ?
After you use hcu it modifies the oeminfo to get strings it needs for calculations - You get the code aftwerards and your oeminfo is modified, right?
What I don't get is how flashing stock makes code unusable tho?
Is it not original bootloader code we'd get if Huawei site was still up? That code should be usable even after all modifications were reflashed with stock, no?
Or is it a custom code that depends on modified oeminfo to work?
Click to expand...
Click to collapse
It's a custom code. If you use HCU to generate a code it invalidates your stock code. If you flash back stock oeminfo you can use the code Huawei gave you but not the HCU code (until you use HCU again to generate code).
Iirc on Kirin960 (and probably below it) you can use both HCU and stock code, so it uses another way of generating it I guess
Has anyone tried this approach for a MATE 10? or would you recommend it?
FUHuawei said:
Has anyone tried this approach for a MATE 10? or would you recommend it?
Click to expand...
Click to collapse
What method are you talking about?
If through testpoint, then yes!
Everything works perfectly
geogsm_1 said:
What method are you talking about?
If through testpoint, then yes!
Everything works perfectly
Click to expand...
Click to collapse
Yes, of course, I meant through test point. Do you know of any good step by step guide on how to do it? I want to try it and post here my results, if everything goes well I hope everyone ditches huawei software.
Also, I have searched around for options regarding ROMs, does anyone recommend anything in particular?
FUHuawei said:
Yes, of course, I meant through test point. Do you know of any good step by step guide on how to do it? I want to try it and post here my results, if everything goes well I hope everyone ditches huawei software.
Also, I have searched around for options regarding ROMs, does anyone recommend anything in particular?
Click to expand...
Click to collapse
Yes, I know the method) and have long written instructions on another forum with the permission of my teacher.
Decision made
On Huawei Mate 10 / Mate 10 Pro /, you can get the bootloader unlock code using a testpoint. But you need to have a programmer such as MRT / SIGMA / HDE / HCu-Client