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.
So i woke up today to my device telling me it is rent a center locked, what the hell does this mean? I bought it from CL and and its been working for months, anyway to get rid of this or am i screwed?
Does CL stand for Clove, the UK electronics vendor? What variant and any modifications?
It sounds like you bought a phone that was rented from rac and not paid for.
Pphish20 said:
Does CL stand for Clove, the UK electronics vendor? What variant and any modifications?
Click to expand...
Click to collapse
Craigslist sorry, and its the RS988
Anyone? My phone is screwed im stuck with nothing;(
After looking around for you, I noticed most of the people with the Samsungs that had that issue ended up having to go to cm13 until they finally found a way to get around it. Considering the RS988 is not bootloader unlocked, doesn't have root or twrp available for it it looks like you are pretty much out of luck. One file I have seen mentioned is sec.abt, however I have also read that people have had issues removing it. Have you tried flashing factory firmware back to it again or a factory reset? Both didn't work on the samsungs, however it seems like there isn't any info for the lg's. Google searching also shows there are imei repair companies that can supposedly do it for $40-$80 from what I have seen. If you figure out how to fix it, share it in case anyone else gets burned by a scammer.
LG RS988 Rent a center lock Remove
Any one have any lg rent a center lock lg G5
Email me at : [email protected]
I know this is a dead thread, but I think I figured out how to get rid of the RAC (rent a center) lock for good. The rac lock uses a system administrator profile along with a program called sec.abt that can not be removed or frozen. If you manage to uninstall it is just reinstalls itself. I was not able to find any information on how to remove this without using special hardware like an octopus box that costs hundreds of dollars.
I used LGUP with the uppercut modification (can be found here on XDA) along with the KDZ files from here https://lg-firmwares.com/lg-rs988-firmwares/
I was only able to find the USA RSS 11C firmware until I found the page linked above with the BPT 10D firmware. Whenever you flash the stock 11C USA firmware the RAC program comes back, however if you use LGUP and uppercut to flash the BPT 10D firmware using the upgrade option (refurbish will error out) I found that my device booted correctly and seemed to work, however I did not have any fastboot options and it said there were no updates available (you need fastboot to unlock the bootloader and the latest update grants that ability). I then reinstalled the USA 11C firmware and to my delight found that the RAC software and device administrator profile were gone.
I then checked for updates and it started download the latest update. I believe I will not have a problem unlocking the bootloader and rooting from this point on. I'll let you guys know if anything changes.
I'm only posting this because I have been sitting on a RAC locked phone for months that got locked over six months after I bought it used and really hope this can help someone else that got screwed over.
I have an octopus box and can you point me to the partition this security sits on? I have an unlocked bootloader us996 and I can use fastboot to erase the partition . Do you know?
Nailed it
inaudible101 said:
I know this is a dead thread, but I think I figured out how to get rid of the RAC (rent a center) lock for good. The rac lock uses a system administrator profile along with a program called sec.abt that can not be removed or frozen. If you manage to uninstall it is just reinstalls itself. I was not able to find any information on how to remove this without using special hardware like an octopus box that costs hundreds of dollars.
I used LGUP with the uppercut modification (can be found here on XDA) along with the KDZ files from here
I was only able to find the USA RSS 11C firmware until I found the page linked above with the BPT 10D firmware. Whenever you flash the stock 11C USA firmware the RAC program comes back, however if you use LGUP and uppercut to flash the BPT 10D firmware using the upgrade option (refurbish will error out) I found that my device booted correctly and seemed to work, however I did not have any fastboot options and it said there were no updates available (you need fastboot to unlock the bootloader and the latest update grants that ability). I then reinstalled the USA 11C firmware and to my delight found that the RAC software and device administrator profile were gone.
I then checked for updates and it started download the latest update. I believe I will not have a problem unlocking the bootloader and rooting from this point on. I'll let you guys know if anything changes.
I'm only posting this because I have been sitting on a RAC locked phone for months that got locked over six months after I bought it used and really hope this can help someone else that got screwed over.
Click to expand...
Click to collapse
This worked for me on a LG G5 i've had in a box since last October because of the same kind of craigslist scam BS. Thank you so much!
Could you walk me through this I need to get my phone unlocked, Tia