Hey all
A little background :
I have a Nexus and a Desire. Both phones are pretty much identical when you look at the hardware. The Desire (GSM) version has a way to repartition its NAND chip in order to resize the /system , /data and /cache partitions on the device. Details can be found in alpharev. The method requires 2 hacks to be implemented,
1. to unlock the security and obtain s-off status
2. to fastboot flash a modified hboot that repartitions the NAND.
My question is:
Is it possible for us to do the same with the N1, seeing that with just "fastboot oem unlock", we can flash anything we want from the fastboot interface, negating the need to implement the first part of the alpharev hack.
all we need is a modified hboot image.
Check the alpharev page for the 4 choices of partition sizes.
str4vag said:
Hey all
A little background :
I have a Nexus and a Desire. Both phones are pretty much identical when you look at the hardware. The Desire (GSM) version has a way to repartition its NAND chip in order to resize the /system , /data and /cache partitions on the device. Details can be found in alpharev. The method requires 2 hacks to be implemented,
1. to unlock the security and obtain s-off status
2. to fastboot flash a modified hboot that repartitions the NAND.
My question is:
Is it possible for us to do the same with the N1, seeing that with just "fastboot oem unlock", we can flash anything we want from the fastboot interface, negating the need to implement the first part of the alpharev hack.
all we need is a modified hboot image.
Check the alpharev page for the 4 choices of partition sizes.
Click to expand...
Click to collapse
Probably not easy as this requires updating fastboot whose source code is not available.
Probably, but seeing as the HW of N1 and Desire is so similar, there is a chance that the code used in the alpharev hack might work, after a little modification to fit the N1.
But then I don't know anything about coding/hacking. I need more input from the dev community.
This requires modification of the bootloader, which wasn't done and requires quite a lot of effort with unknown results. Checking Desire bootloader compatibility might (and probably will) result in a bricked N1, I don't know many people that are willing to take the risk. I know I wouldn't. Without bootloader, repartitioning isn't possible.
Jack_R1 said:
This requires modification of the bootloader, which wasn't done and requires quite a lot of effort with unknown results. Checking Desire bootloader compatibility might (and probably will) result in a bricked N1, I don't know many people that are willing to take the risk. I know I wouldn't. Without bootloader, repartitioning isn't possible.
Click to expand...
Click to collapse
I understand. But what I mean was not flashing the desire bootloader directly to a N1, but using it (or the code base) as a reference for a modified N1 bootloader.
Again, more input is needed from people who have done this kind of thing before.
If i remember correctly,
Firerat has something like this for the G1.
Nobody bothered trying to hack N1 bootloader until now because it has the unlock function built-in - the main reason for reverse-engineering bootloaders isn't there. Bootloader code is binary, no code base there.
Given those facts, the future of bootloader modifications on N1 doesn't look too promising.
I see. Cool.
Thanks for the answers
Related
After searching for this, from what I've gathered, customizing the static boot splash image (splash1) is still not currently possible on the Nexus One.
Is any progress being made in this area or has it been left alone?
This is something I'm really interested in. On my Desire, I had set a nice splash image with all of my contact info on it, making it very difficult to sell the phone or pass it off as yours if it is lost or stolen.
Until someone manages to get either an S-OFF patched SPL on there or been able to somehow exploit the radio to get real S-OFF it's not possible to flash that partition.
Yeah devs have moved on really.
Ah, nertz :\
blunden said:
Until someone manages to get either an S-OFF patched SPL on there or been able to somehow exploit the radio to get real S-OFF it's not possible to flash that partition.
Click to expand...
Click to collapse
I have S-OFF and still can't flash a new splash. It's a non-starter.
~David said:
After searching for this, from what I've gathered, customizing the static boot splash image (splash1) is still not currently possible on the Nexus One.
Click to expand...
Click to collapse
is splash1 the "X" ?
Yes it is.
People wanted this way back when we were still concerned about whether or not htc would cover an unlocked bootloader N1, but we're all pretty much over it now.
It would be nice but I dont think anyone will work on it anymore
Found some instructions here (Desire) http://androidforums.com/desire-tips-tricks/220322-splash-screen-s-off-linux-osx-terminal-way.html
It does say s-off is required.
Yep, that method doesn't work on the N1 even with the unlocked bootloader.
Hi,
I'm looking to root my HTC One. I know the easy way is to unlock bootloader, flash recovery, flash su, done, but there is that part about "may void your warranty". I read that HTC will still repair hardware issues even if the bootloader is unlocked, but still I'm curious about different ways to root.
So... as far as I can tell by looking at the htcdev kernel source the kernel is vulnerable to the sw_perf_event exploit (http://packetstormsecurity.com/files/121616/semtex.c), and than there is this project https://github.com/android-rooting-tools/libperf_event_exploit.
I was wondering if anyone made that exploit work on the M7 (aka found the right offset) and also if you think it would be worth rooting with that. I guess I won't be able to flash new ROMs as the bootloader would still be locked, right? Or will I be able to flash the recovery partition withoud needing to unlock the bootloader (I guess not)?
Thanks
sciepy said:
Hi,
I'm looking to root my HTC One. I know the easy way is to unlock bootloader, flash recovery, flash su, done, but there is that part about "may void your warranty". I read that HTC will still repair hardware issues even if the bootloader is unlocked, but still I'm curious about different ways to root.
Click to expand...
Click to collapse
this is false. you will have to pay for any repairs performed on the device.
Blanket statements like this are troublesome. The warranty coverage varies by country. I've had warranty replaced phones that were rooted with no problem here in the US
I've safestrapped a rooted 4.4.2 rom on my AT&T locked moto x for quite some time and I can't see any real downsides.
I even had a look to see if it's possible to flash non-stock roms with it and from what I understand it's totally possible.
So my question is: What's the point of unlocking the bootloader on non-DE devices (with, say, the chinese middleman method, which costs about 40-50$), when you can simply bypass the protected /system directory by using safestrap?
If I understand though, the only real limitation is that we have to wait for the sbf of the newer versions of android to be released for our specific device, in order to flash the correct kernels and all. I think.
Please correct my statements as they may be wrong, and thanks for your replies!
frenchie007 said:
I've safestrapped a rooted 4.4.2 rom on my AT&T locked moto x for quite some time and I can't see any real downsides.
I even had a look to see if it's possible to flash non-stock roms with it and from what I understand it's totally possible.
So my question is: What's the point of unlocking the bootloader on non-DE devices (with, say, the chinese middleman method, which costs about 40-50$), when you can simply bypass the protected /system directory by using safestrap?
If I understand though, the only real limitation is that we have to wait for the sbf of the newer versions of android to be released for our specific device, in order to flash the correct kernels and all. I think.
Please correct my statements as they may be wrong, and thanks for your replies!
Click to expand...
Click to collapse
Once you have updated your CORE SOFTWARE (and bootloader) to 4.4.2, safestrap is useless. The 4.4.2 bootloader is impervious to known write-protect-disable exploits.
Many people updated to 4.4.2 without reading the consequences and now BL unlock is the ONLY method to achieve Root AND Write-protect-disable.
Additionally, the process is much more streamlined and far less complicated than installing and configuring safestrap. Simply unlock, and flash TWRP. Done.
Also, non-stock-based ROMS (AFAIK) cannot be used with safestrap because as I understand, it uses an "overlay" technique which would not work on a non-stock-based ROM.
Good Luck
frenchie007 said:
I've safestrapped a rooted 4.4.2 rom on my AT&T locked moto x for quite some time and I can't see any real downsides.
I even had a look to see if it's possible to flash non-stock roms with it and from what I understand it's totally possible.
So my question is: What's the point of unlocking the bootloader on non-DE devices (with, say, the chinese middleman method, which costs about 40-50$), when you can simply bypass the protected /system directory by using safestrap?
If I understand though, the only real limitation is that we have to wait for the sbf of the newer versions of android to be released for our specific device, in order to flash the correct kernels and all. I think.
Please correct my statements as they may be wrong, and thanks for your replies!
Click to expand...
Click to collapse
Also, using safestrap takes up more space on your device, since you have an underlying core OS (as samwathegreat puts it), essentially meaning that you have two full ROMs on your phone. If you have the 16gb Moto X, that will suck up a good chunk of space (though that's not the end of the world). If you have the 32gb version, you are probably ok. I agree with everything else samwathegreat says though.
Thought I would add my two cents in here as someone who ran safestrap for a while before getting my bootloader unlocked through the guy in China. First, a small correction, running safestrap doesn’t have to take up much/any more memory as you can flash the ROM to your “stock” slot. As of right now I believe the other slots are not even working. Now, as for why unlock your bootloader, I think there are a number of reasons. Yes, you have an up-to-date ROM on your phone currently, but you are going to be dependent on a dev making a safestrap compatible ROM for any new software releases. This may or may not happen. You are at the mercy of the few devs who are currently doing this. That is probably the biggest reason for me deciding to unlock. Another reason, as samwathegreat stated, is I do not believe you can run AOSP ROMs currently on safestrap. If it works like it did on my old Droid 4, you would need to use something like the kexec exploit to in order to flash custom kernels in order to run an AOSP based ROM. I haven’t seen anyone working on anything like that. The last big reason I can see is safestrap does not seem to be in active development on the Moto X anymore. Numerous other devices have seen safestrap updates recently (including the Droid 4) but not so the Moto X version. I would definitely recommend unlocking. I know I’m glad I did.
kwyrt said:
First, a small correction, running safestrap doesn’t have to take up much/any more memory as you can flash the ROM to your “stock” slot.
Click to expand...
Click to collapse
Thanks for clarifying that. I stand corrected.
kwyrt said:
Thought I would add my two cents in here as someone who ran safestrap for a while before getting my bootloader unlocked through the guy in China. First, a small correction, running safestrap doesn’t have to take up much/any more memory as you can flash the ROM to your “stock” slot. As of right now I believe the other slots are not even working. Now, as for why unlock your bootloader, I think there are a number of reasons. Yes, you have an up-to-date ROM on your phone currently, but you are going to be dependent on a dev making a safestrap compatible ROM for any new software releases. This may or may not happen. You are at the mercy of the few devs who are currently doing this. That is probably the biggest reason for me deciding to unlock. Another reason, as samwathegreat stated, is I do not believe you can run AOSP ROMs currently on safestrap. If it works like it did on my old Droid 4, you would need to use something like the kexec exploit to in order to flash custom kernels in order to run an AOSP based ROM. I haven’t seen anyone working on anything like that. The last big reason I can see is safestrap does not seem to be in active development on the Moto X anymore. Numerous other devices have seen safestrap updates recently (including the Droid 4) but not so the Moto X version. I would definitely recommend unlocking. I know I’m glad I did.
Click to expand...
Click to collapse
thanks for making things clearer for me, and everyone for taking the time to answer my question.
as i've got a 2013 model I guess I'll just have to hope that safestrap supported roms will keep being released for the moto x for future updates!
OP - long story short:
locked bootloader = some dev/hobbyist, etc finding a security flaw in the system that exploits the ability to obtain root (and hopefully system r/w).
Requires an adoption rate from other users.
Is only as "reliable" as the device is relevant.
Exploits have the potential to insert malicious code.
unlocked bootloader/dev edition = "free range" to do whatever you want, regardless of security flaws.
Potential to extend the longevity of your device.
Rooting methods are common among most devices with DEV Edition/unlocked bootloader option.
Permanent.
640k said:
OP - long story short:
locked bootloader = some dev/hobbyist, etc finding a security flaw in the system that exploits the ability to obtain root (and hopefully system r/w).
Requires an adoption rate from other users.
Is only as "reliable" as the device is relevant.
Exploits have the potential to insert malicious code.
unlocked bootloader/dev edition = "free range" to do whatever you want, regardless of security flaws.
Potential to extend the longevity of your device.
Rooting methods are common among most devices with DEV Edition/unlocked bootloader option.
Permanent.
Click to expand...
Click to collapse
I am quite aware of the difference between locked and unlocked boot loaders. My question was really regarding if safe strapping offered as much as a regular recovery. But thanks for clearing that up as well!
What are the benefits of s-off over just unlocked boot loader
by unlocking bootloader u can root ur device, can flash custom recovery & custom roms on ur android device....
shad0wboss said:
What are the benefits of s-off over just unlocked boot loader
Click to expand...
Click to collapse
I don't have this particular device but I will tell you the general information and you can work with that.
About Bootloader(Unlocked Bootloader):
The bootloader is like a BIOS of your PC. It is the thing that is powered on and verifies all hardware and is responsible for making connection with the hardware. This can either be unlocked or locked. When you have a locked bootloader you can still root (if an exploit is available). You can even install a recovery or custom rom if an exploit is available (like BUMP was). What was it doing? Signing the images for your so the locked bootloader will think it is the OEM image. In most of the cases this is not so happy. Usually you can't flash a recovery or a custom rom or stuff like that with a locked bootloader. Some OEM's provide websites to unlock the bootloader (with the cost of losing warranty; well not really). This is the case of Sony, HTC. Some Oem's don't provide this.
About S-off:
What does S-off mean? Security off. Your device will come with S-ON always unless it's a Dev edition (correct me if I am wrong). What this does is it doesn't leave you to do very advanced operations related to the EMMC (the Nand chip). You can't flash a bootloader you wish or stuff like that. Update radio partition. In some cases system partition is also secured so you can't flash a custom ROM. By S-off you get full control of your device but if a mistakes occurs you will end up with a hard-bricked device.
Peace. Hope you understood.
neutrondev said:
I don't have this particular device but I will tell you the general information and you can work with that.
About Bootloader(Unlocked Bootloader):
The bootloader is like a BIOS of your PC. It is the thing that is powered on and verifies all hardware and is responsible for making connection with the hardware. This can either be unlocked or locked. When you have a locked bootloader you can still root (if an exploit is available). You can even install a recovery or custom rom if an exploit is available (like BUMP was). What was it doing? Signing the images for your so the locked bootloader will think it is the OEM image. In most of the cases this is not so happy. Usually you can't flash a recovery or a custom rom or stuff like that with a locked bootloader. Some OEM's provide websites to unlock the bootloader (with the cost of losing warranty; well not really). This is the case of Sony, HTC. Some Oem's don't provide this.
About S-off:
What does S-off mean? Security off. Your device will come with S-ON always unless it's a Dev edition (correct me if I am wrong). What this does is it doesn't leave you to do very advanced operations related to the EMMC (the Nand chip). You can't flash a bootloader you wish or stuff like that. Update radio partition. In some cases system partition is also secured so you can't flash a custom ROM. By S-off you get full control of your device but if a mistakes occurs you will end up with a hard-bricked device.
Peace. Hope you understood.
Click to expand...
Click to collapse
Thanks!
Things is, i was more concerned about the practical info about this device specifically because I have read that with just bootloader unlocked, the roms that i'll be able to flash will only change the visual and not so much with the kernel etc. I don't understand why people would choose to S-OFF for this device for other than just relocking the bootloader.
shad0wboss said:
Thanks!
Things is, i was more concerned about the practical info about this device specifically because I have read that with just bootloader unlocked, the roms that i'll be able to flash will only change the visual and not so much with the kernel etc. I don't understand why people would choose to S-OFF for this device for other than just relocking the bootloader.
Click to expand...
Click to collapse
Sorry I can't really help you with that information I don't know if you can flash a Custom kernel with S-on. Never had a sony. Someone will help you out soon.I hope.
i'l bump this question up then :/
I think S-off is a term unique to HTC devices. Its the equivalent of an unlocked bootloader
tonysunshine said:
I think S-off is a term unique to HTC devices. Its the equivalent of an unlocked bootloader
Click to expand...
Click to collapse
yes but nth to lose on HTC except warranty (still subject to which svc ctr tho) while on Sony, losing DRM keys (w/o backup) are like downgrading ur phone full capabilities.
monx® said:
yes but nth to lose on HTC except warranty (still subject to which svc ctr tho) while on Sony, losing DRM keys (w/o backup) are like downgrading ur phone full capabilities.
Click to expand...
Click to collapse
Is there a way to root without losing keys? I have Z3 LTE D6603 atm.
Sorry if it's a dumb question, I'm new here. And also new to sony rooting, which seems much more complex than my old Nexus 5 lol
tonysunshine said:
I think S-off is a term unique to HTC devices. Its the equivalent of an unlocked bootloader
Click to expand...
Click to collapse
Not really, you can flash kernels, roms ( aosp roms etc ) with unlocked bootloader, S-off gives you other stuff like changing mid, cid, sim unlock, downgrading/upgrading bootloader, converting to full GPE or dev edition, unlocking bootloader without need of HTC, flashing splash image, custom bootloaders, even converting to Windows ( if available of course ) locking it instead of re-locking it, restoring it to full stock state ( which is not possible without S-off ), simply put your device has no limits with S-off on HTC.
Anyway S-off isn't really needed unless you care for the things above ( if Sony even has S-off ), Sony has poor development so S-off isn't even needed or unlocking bootloader since basically all you get is aosp roms, stock alike roms are flashable with locked bootloader as far as I remember.
Sent from my HTC One M8 using Tapatalk
I looked into using SamDunk for unlocking the bootloader for my AT&T galaxy s5 but noticed that the code posted on the git was Verizon-specific (in that the bits it writes over in the cid of the phone is verizon-specific). This makes it to where running the code does not unlock the bootloader on a AT&T galaxy s5.
I wrote some python code parsing my original cid and the cid resulting from the current exploit code and noticed that the only difference pertained to the product's serial number (bits 47-16 of the cid). Even then, only certain bits within the product serial number are different. I suspect that some bits within product serial pertain to carrier, and some bits pertain to the bootloader, but I could be wrong.
My hunch is that if I can figure out which bits from the original cid's product serial number correspond to developer bootloader access then I may be able to modify the SamDunk code to allow for unlocking AT&T bootloaders. Or provide some method of calculating a dev bootloader cid from an original.
Has anyone else looked into this, and is this worth pursuing?
edit: looking further through SamDunk code. It appears that there is a dev signature associated with the cid (?) that gets written to aboot. Not sure if this is different between phones... If so then experimenting with only the cid may be futile.
product serial numbers are different for the first 12 bits then bits 25-32. I could post a link to my git if anyone is interested in experimenting with their cids
_ibis said:
I looked into using SamDunk for unlocking the bootloader for my AT&T galaxy s5 but noticed that the code posted on the git was Verizon-specific (in that the bits it writes over in the cid of the phone is verizon-specific). This makes it to where running the code does not unlock the bootloader on a AT&T galaxy s5.
I wrote some python code parsing my original cid and the cid resulting from the current exploit code and noticed that the only difference pertained to the product's serial number (bits 47-16 of the cid). Even then, only certain bits within the product serial number are different. I suspect that some bits within product serial pertain to carrier, and some bits pertain to the bootloader, but I could be wrong.
My hunch is that if I can figure out which bits from the original cid's product serial number correspond to developer bootloader access then I may be able to modify the SamDunk code to allow for unlocking AT&T bootloaders. Or provide some method of calculating a dev bootloader cid from an original.
Has anyone else looked into this, and is this worth pursuing?
edit: looking further through SamDunk code. It appears that there is a dev signature associated with the cid (?) that gets written to aboot. Not sure if this is different between phones... If so then experimenting with only the cid may be futile.
product serial numbers are different for the first 12 bits then bits 25-32. I could post a link to my git if anyone is interested in experimenting with their cids
Click to expand...
Click to collapse
I wouldn't mind taking a look.
NavSad said:
I wouldn't mind taking a look.
Click to expand...
Click to collapse
Thanks man, I appreciate all the help I can get.
I read further into the Verizon S5 bootloader unlock thread and it appears that only changing the cid may not work. If I remember correctly (looked at it yesterday) the cid is hashed/compared to the aboot somehow to determine whether its a developer edition or not. If we could get a regular cid/aboot and compare it to the verizon regular cid/aboot, then cross compare to the verizon dev edition cid/aboot then we may have a shot at possibly re-creating a at&t dev edition cid/aboot
_ibis said:
Thanks man, I appreciate all the help I can get.
I read further into the Verizon S5 bootloader unlock thread and it appears that only changing the cid may not work. If I remember correctly (looked at it yesterday) the cid is hashed/compared to the aboot somehow to determine whether its a developer edition or not. If we could get a regular cid/aboot and compare it to the verizon regular cid/aboot, then cross compare to the verizon dev edition cid/aboot then we may have a shot at possibly re-creating a at&t dev edition cid/aboot
Click to expand...
Click to collapse
If the bootloader uses SHA1 it may be easier.
Meanwhile us CID 11s over here just watching you guys from the distance..lol
AptLogic said:
Meanwhile us CID 11s over here just watching you guys from the distance..lol
Click to expand...
Click to collapse
I'm CID 11 too.
NavSad said:
I'm CID 11 too.
Click to expand...
Click to collapse
Oh okay lol.. really wish we could unlock all of the S5 bootloaders instead of just CID 15... what if we try doing like MultiROM with the "no-hardboot" thing like they do on HTC devices? We wouldn't need to patch the Kernel so we'd be able to flash other ROMs.
I know we have Odin mode instead of fastboot and we can not do the "OEM Unlock" in the Developer Options as it does not show up in there. I found this thread (https://www.xda-developers.com/how-to-discover-hidden-fastboot-commands/) on how to discover hidden fastboot commands.
So I followed the instructions there to extract the aboot.img (bootloader) and then "read" the contents of that to see what fastboot commands are available. To my surprise, it has "oem unlock" listed and a few other oem options, see attached image. Although, back to the beginning of my post, we can not fastboot in.
I would assume we could unlock the bootloader via fastboot commands if we only had a way in for it. I am not that experienced with Odin but I think that is only to flash images. I spent most of this weekend searching for any way to alternately try to fastboot in or use Odin but came up with nothing feasible. I used ADB to reboot the phone into all modes and tried doing "fastboot devices" in all modes but it just came back with nothing.
I just wanted to post this in the case of being useful in our attempt to unlock the bootloader.
What do you mean by a way in ?
There is no way, that I know of, to put the s5 in fastboot mode. I was thinking that if there is a way to boot to fastboot, or at least have the phone listed as a fastboot device in ADB, we could possibly run the oem unlock command.
Ok that's what I thought u had meant .... I used to have a few HTC devices I believe was the my touch 4g I'm thinking about ...Anyway some of the roms I had to use ADB and fastboot to flash a kernal sometimes ADB wouldn't pick up device to communicate with fastboot someone had found that by installing PDA.net (I think this was name of app for Windows) it enabled ADB to see the device at any rate .... I no it's a long shot but something to look into if your bored sometime lol I'm not sure why or how it worked or if wouldn't help us at all but I no for a fact it worked on a HTC device so felt was worth mentioning
I'll have a look at that when I get a chance. Anything is worth mentioning as you never know what little piece completes the puzzle!
sorry guys, been out of it for the last two weeks. Projects got crazy but should be able to begin working on this again soon.
I'm fairly certain Thier is still a bounty on this .... I no I pledged 100 bux to whoever unlocks my bootloader and saves me from having to buy a new phone lol but been waiting damn near 4 years not gonna start holding my breath now lol
Towelroot gives kernel memory access, downgrade, use kexec.
This is the easiest way and only one that is guaranteed to work since all exploits have already been made.
Guicrith said:
Towelroot gives kernel memory access, downgrade, use kexec.
This is the easiest way and only one that is guaranteed to work since all exploits have already been made.
Click to expand...
Click to collapse
If, of course, we could get kexec to WORK. Any modification of the Kernel breaks the chain of trust and the phone goes into a bootloop.
We dont need to modify the kernel, TowelRoot would write kexec from a file(/system/userlandbootloader.img) into the kernel after boot, then the kernel would boot a new kernel from /system/oskernel.img (which is writable on rooted 4.4-5.0)
The only kernel being modified is the one running in ram and that is deleted and replaced every reboot so trust chain is never broken.
Guicrith said:
We dont need to modify the kernel, TowelRoot would write kexec from a file into the kernel after boot, then the kernel would boot a new kernel from /system/oskernel.img (which is writable on rooted 4.4-5.0)
The only kernel being mdifyed is the one running in ram and that is deleted and replaced every reboot so trust chain is never broken.
Click to expand...
Click to collapse
But for everything to work correctly we need to be able to hardboot to the new kernel, so we need to patch the existing one to support it.
Why?
If you have kernel access you can just set all values to there boot time default.(unless there is hardware locked values like the gameboy color bootloader)
Clear the mmu mappings.
memset((void*)0x00000000, 0x00, sizeof(systemram));
Now it is in a pre boot state.
If that does not work triggering a crash that does not reload the kernel from rom but hardboots the system may work too.
Guicrith said:
Why?
If you have kernel access you can just set all values to there boot time default.(unless there is hardware locked values like the gameboy color bootloader)
Clear the mmu mappings.
memset((void*)0x00000000, 0x00, sizeof(systemram));
Now it is in a pre boot state.
If that does not work triggering a crash that does not reload the kernel from rom but hardboots the system may work too.
Click to expand...
Click to collapse
If we can code this and get consistent successful results we'd basically have a workaround for most locked BL devices to boot a custom ROM.
Of course the only theoretical hurdle left would be to actually code something like this.