READ ON!
I HAVE SUCCESSFULLY BYPASSED VERIZON/ATT OF4 SECURITY ON THE OF4 BUILD for the SM-S975L and have succeeded in downgrading the bootloader by hex editing. I reach the Samsung Galaxy S4 logo. This is quite the accomplishment for me.
However, I need help with unpacking the system image and reworking it to an ATT-based ROM. Knox flat out tells me "No Verizon." when I try the flash. Because you know, aboot knox and all...
Merely hex edit the version number inside your custom boot image to match the system currently installed as you flash to stock. Search for any build number strings inside mbm files and edit accordingly. My documentation is below. Screw you verizon! I just saved myself $200.
Files to keep in Odin tar with matching build number name to pass check:
Changed
S975LUDUANB1_S975LTFNANB1_S975LUDUANB1_HOME.tar.md5
to
S975LUDUAOF4_S975LTFNAOF4_S975LUDUAOF4_HOME.tar
Hex edited version numbers into:
aboot.mpm
rpm.mbm
sbl1.mbm
sbl2.mbm
tz.mbm
boot.img
Guide update: Bootloader error "No Verizon. I suppose thats the CSC?"
deleted other files from that archive.
Made new archive name of:
S975LUDUANB1_S975LTFNANB1_S975LUDUANB1_HOME.tar
Placed system files in it. Rebooted and flashed. WORKED!
It will flash in Odin 3.07. Then reboot into download mode and flash the other ones with the same, you'll be downgraded and bypass the security check since you have the downgraded bootloader.
Give me credit and donate. I just saved the Verizon users' butts. As well as the tracfone ones.
If I can figure out how to unlock the straight talk bootloader I shall do. And make a flashable Odin image.
:laugh::laugh::laugh::laugh:
WORKING! -> SM-S975L Straight Talk on locked down firmware. http://forum.xda-developers.com/galaxy-s4/unified-development/root-sm-s975l-straight-talk-variant-of4-t3279890/post64511525
Documentation
I need a reliable way to edit mbm files I've extracted from the stock NB1 image. OF4 bootloader won't let old versions flash, so I'm going through a hex editor after removing md5 check to see what I can do as far as hex editing the version number to be newer than OF4 from the binaries. We get a fail on aboot.mbm. We are compatable, however Knox says we cannot downgrade.
Documentation on Odin flashable .tars and correct Samsung official mpm formats?
Help unpacking/repacking mpm files and root injection?
Documentation on Qualcomm Snapdragon machine code.
Update: aboot.mpm, modem, and system.img.ext4 version numbers changed, there is some kind of pattern, I see in system.img.ext: NB1 scattered throughout the code pages. I'm wondering if this is safe to change. It looks part of the code, so I'd assume no. I am seeing their routines for checksum as well there too, near there. So to the requests goes documentation on ARM assmelber, machine code. I hope this helps people like for example loki_tool. Would be nice if we had one to patch samsung images. I can make one that searches for the strings in the code in C for all the phone models, it sure would help bypass Verizon's crap. I'm so mad at them, rant rant rant onwards... Towelroot apk is going to need modified to support this build number (OF4, it is rootable since its NB1, but towelroot just checks the build number)
UPDATE 2: Flashed. Successful Nand write start. aboot is write protected even at Download mode level. Will try documented successes on Odin 3.07 for bootloader aboot flashes. Flashing it fails with a security lockup. Odin 3.09 sits there, but Odin 3.07 might work.
Update 3: Hacking the version number to current out of the Samsung Verizon images produces successful NAND write start. Developers, please note this when unlocking boot loaders. I have discovered a compromise which will allow flashing of unofficial aboot and system data. Provided the flashed bootloader does not contain checksum code.
{
"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"
}
Found in codepages of aboot.mpm Don't know if changing this plain text string is enough to make it match, I have a feeling CSC is going to fail which is going to require another hack. Plus half the code pages of aboot are SA1 encrypted. Going to search through mpm packages to make them all match.
In system.img.ext4 NB1 is scattered throughout the codepages. I found it several times but not going to change until I know if it will causes a system boot failure.
Build number hex edited to OF4 to bypass CSC check. Original post updated.
Bump. OP updated with link and working results.
I apologize for my ignorance since I don't fully understand the OP, so allow me to ask: does this wotk on USA AT&T GS4?
If it does work, and even if it doesn't, I think you should re-make the OP because I think the majority of people won't be able to understand what you did. Just an advice, I think it would be great!
Good job btw, you are giving us a little bit of hope!
Could this be reworked to downgrade firmware on the GS4 VZW (SCH-I545) ?
you can't downgrade bootloaders if the qfuse is blown
period end of discussion
you tamper with the bootloader by hexediting its a one way ticket to brick town on qfuse-blown vzw devices
Legitsu said:
you can't downgrade bootloaders if the qfuse is blown
period end of discussion
you tamper with the bootloader by hexediting its a one way ticket to brick town on qfuse-blown vzw devices
Click to expand...
Click to collapse
Unless of course, you have no idea what you're doing.
Does this or my guide look like I know what I'm doing? I'm root, now with disabled knox. So please don't insult me. You can flash modified loki'd aboot no issues. As long as signature matches you're gold. No qfuse. You insult someone who spends hours in a hex editor with this kind of thing, sir. I'm not technically downgrading. I'm tricking it into passing the code the downgraded kernel provides.
Bootloader screen
Verification Check: OK
0x0 KNOX Kernel Lock: Off
0x0 Verification Lock: Off
Warranty bit: 0x1 (Void)
Kernel lock and verification lock where on last night then some more tinkering got them off.
This stuff is to help people. So please mediocre responses like that are not necessary. Makes me not want to share my work sometimes.
rena14 said:
I apologize for my ignorance since I don't fully understand the OP, so allow me to ask: does this wotk on USA AT&T GS4?
If it does work, and even if it doesn't, I think you should re-make the OP because I think the majority of people won't be able to understand what you did. Just an advice, I think it would be great!
Good job btw, you are giving us a little bit of hope!
Click to expand...
Click to collapse
Thank you. I appreciate it. It works on the new Straight Talk / ATT GS4 with the corrected JB 4.3 and locked kernel. But as stated the flash will blow qfuse. But I'm not sure on that one, because I blew qfuse when I tried to flash TWRP, not during my tinkering.
Current issue is that Wi-Fi freezes in the OF4 firmware because the NB1 kernel does boot the OS, but OF4 is for JB 4.3 and NB1 is for JB 4.2. I have not encountered any FCs thus far. Recovery can't be flashed yet, but modified aboot with matching build number hex hacked into it OF4 does not throw a security check fail. I got nand write start, and pass.
Best I can say is try this hack method for your device. Find a sacrificial lamb you where going to throw away with a cracked screen. Ebay works. As long as the device is fully functional. All of my dev phones are old phones I'm getting rid of. So I never wreck a daily driver and a replacement is so cheap because of a damaged model I might only pay $50-100 for a device with a cracked screen.
Samsung's root certificates are in plain code in system.img.ext4. So sign your builds with the root certs, Sha256 pack, hex hack build number, gold.
The best explanation I can offer:
You are passing downgraded code. But Knox thinks you're just re flashing the current build.
LupineDream said:
Thank you. I appreciate it. It works on the new Straight Talk / ATT GS4 with the corrected JB 4.3 and locked kernel. But as stated the flash will blow qfuse. But I'm not sure on that one, because I blew qfuse when I tried to flash TWRP, not during my tinkering.
Current issue is that Wi-Fi freezes in the OF4 firmware because the NB1 kernel does boot the OS, but OF4 is for JB 4.3 and NB1 is for JB 4.2. I have not encountered any FCs thus far. Recovery can't be flashed yet, but modified aboot with matching build number hex hacked into it OF4 does not throw a security check fail. I got nand write start, and pass.
Best I can say is try this hack method for your device. Find a sacrificial lamb you where going to throw away with a cracked screen. Ebay works. As long as the device is fully functional. All of my dev phones are old phones I'm getting rid of. So I never wreck a daily driver and a replacement is so cheap because of a damaged model I might only pay $50-100 for a device with a cracked screen.
Samsung's root certificates are in plain code in system.img.ext4. So sign your builds with the root certs, Sha256 pack, hex hack build number, gold.
The best explanation I can offer:
You are passing downgraded code. But Knox thinks you're just re flashing the current build.
Click to expand...
Click to collapse
Thank you for taking time the to answer my question, I really appreciate the time and effort you are spending on this.
Since you are still working on this, I'll just wait until you finally get all the things together and fully unlock bootloader. My GS4 is also my daily driver so, following your advice, I better don't attempt to do anything until I can fully understand the whole thing.
Wish you the best of luck on this project, and thanks again for your work, dude!
Regards.
LupineDream said:
Unless of course, you have no idea what you're doing.
Does this or my guide look like I know what I'm doing? I'm root, now with disabled knox. So please don't insult me. You can flash modified loki'd aboot no issues. As long as signature matches you're gold. No qfuse. You insult someone who spends hours in a hex editor with this kind of thing, sir. I'm not technically downgrading. I'm tricking it into passing the code the downgraded kernel provides.
Bootloader screen
Verification Check: OK
0x0 KNOX Kernel Lock: Off
0x0 Verification Lock: Off
Warranty bit: 0x1 (Void)
Kernel lock and verification lock where on last night then some more tinkering got them off.
This stuff is to help people. So please mediocre responses like that are not necessary. Makes me not want to share my work sometimes.
Click to expand...
Click to collapse
This sounds very promising. Thank you
This is absolutely huge news to read. I am assuming once recovery is working (ie: TWRP) that perhaps could AOSP ROMs like CM13 be usable on all Verizon S4's once the downgrade is done? I'll be keeping track of the progress on this for sure.
yes you can spoof 'minor' version numbers(pretty sure somebody already did this a awhile back) but it's never going to boot(unless the op has discovered something new and magical that lets you remove the checksum/qfuse + chain of trust checks it most certainly will never get you back to VRUMDK or to a loki-exploitable base,which is what we need to run real custom roms and kernels
when the op demonstrates a working method to get a loki-able aboot flashed and working then I will be impressed until then status-quo remains because this looks extremely dubious from what we know of qualcomm's qfuses and knoxs bootloader shenanigans ...the status-quo has always been you so much as `touch` the aboot and its a automatic no-boot because its cryptographically signed and and there are hard-wired integrity checks in the cpu
the i545 is a completely different beast then all the other variants
@npjohnson ?
Legitsu said:
yes you can spoof 'minor' version numbers(pretty sure somebody already did this a awhile back) but it's never going to boot(unless the op has discovered something new and magical that lets you remove the checksum/qfuse + chain of trust checks it most certainly will never get you back to VRUMDK or to a loki-exploitable base,which is what we need to run real custom roms and kernels
when the op demonstrates a working method to get a loki-able aboot flashed and working then I will be impressed until then status-quo remains because this looks extremely dubious from what we know of qualcomm's qfuses and knoxs bootloader shenanigans ...the status-quo has always been you so much as `touch` the aboot and its a automatic no-boot because its cryptographically signed and and there are hard-wired integrity checks in the cpu
the i545 is a completely different beast then all the other variants
@npjohnson ?
Click to expand...
Click to collapse
Said documentation on CPU integrity checks?
In that case, I'll most likely need more hardware than I currently have... Like a JTAG debugger. At least something thar can get me low level enough to reverse engineer and find out what the CPU I'd trying to verify. And match an aboot to it.
Legitsu said:
yes you can spoof 'minor' version numbers(pretty sure somebody already did this a awhile back) but it's never going to boot(unless the op has discovered something new and magical that lets you remove the checksum/qfuse + chain of trust checks it most certainly will never get you back to VRUMDK or to a loki-exploitable base,which is what we need to run real custom roms and kernels
when the op demonstrates a working method to get a loki-able aboot flashed and working then I will be impressed until then status-quo remains because this looks extremely dubious from what we know of qualcomm's qfuses and knoxs bootloader shenanigans ...the status-quo has always been you so much as `touch` the aboot and its a automatic no-boot because its cryptographically signed and and there are hard-wired integrity checks in the cpu
the i545 is a completely different beast then all the other variants
@npjohnson ?
Click to expand...
Click to collapse
Right know I have a few tools that are providing useful, IDA decompiler being one of them. But I need the documentation on the instruction sets of the CPU and hardwarespec
Going to do some digging. I'm an it student though not enrolled at Penn State. There's a campus local. I'm going to do some asking around (quite cautiously) to find any equipment needed. I need this functional model to work with. I am getting a new DD next month
Shout out to any Penn state students. This is a project that's worth the bounty. Because if a JTAG won't give me access on POST, yeah, that's a disassembly and a chip mount. And that's not something I have the funds for. At all. Even though the most backwater of websites will take an auto deskffile and 3D print me a mount for pennies on the dollar.
Im realizing where there is a bounty on this unlock.... Again. Got to do some digging. If I become neglectful of this thread I am sorry. Its because quite honestly I'm probing for assistance.
Legitsu said:
yes you can spoof 'minor' version numbers(pretty sure somebody already did this a awhile back) but it's never going to boot(unless the op has discovered something new and magical that lets you remove the checksum/qfuse + chain of trust checks it most certainly will never get you back to VRUMDK or to a loki-exploitable base,which is what we need to run real custom roms and kernels
when the op demonstrates a working method to get a loki-able aboot flashed and working then I will be impressed until then status-quo remains because this looks extremely dubious from what we know of qualcomm's qfuses and knoxs bootloader shenanigans ...the status-quo has always been you so much as `touch` the aboot and its a automatic no-boot because its cryptographically signed and and there are hard-wired integrity checks in the cpu
the i545 is a completely different beast then all the other variants
@npjohnson ?
Click to expand...
Click to collapse
I feel like an idiot but this might help: I was I of1(the latest lollipop build) and I Odin'ed oc1(the first lollipop build). Here's the the part that is interesting: I got a soft brick and could fix it through Odin. Sorry if you guys already knew this, just wanted to help.
LupineDream said:
Right know I have a few tools that are providing useful, IDA decompiler being one of them. But I need the documentation on the instruction sets of the CPU and hardwarespec
Going to do some digging. I'm an it student though not enrolled at Penn State. There's a campus local. I'm going to do some asking around (quite cautiously) to find any equipment needed. I need this functional model to work with. I am getting a new DD next month
Shout out to any Penn state students. This is a project that's worth the bounty. Because if a JTAG won't give me access on POST, yeah, that's a disassembly and a chip mount. And that's not something I have the funds for. At all. Even though the most backwater of websites will take an auto deskffile and 3D print me a mount for pennies on the dollar.
Im realizing where there is a bounty on this unlock.... Again. Got to do some digging. If I become neglectful of this thread I am sorry. Its because quite honestly I'm probing for assistance.
Click to expand...
Click to collapse
everything you wanna know is in this thread http://forum.xda-developers.com/showthread.php?t=2500826
pay close attention to the bits at the bottom and the posts about TZ aka trust zone
there has been a pretty massive effort at this for sometime with only sporadic progress
basicly focus shifted from unlocking to getting kexec working,which is just as good
for the record please nobody attempt this on a vzw device you will blow a qfuse or cause a hard brick
Legitsu said:
for the record please nobody attempt this on a vzw device you will blow a qfuse or cause a hard brick
Click to expand...
Click to collapse
i was about too anyone tried it anyways though?
Awesomeslayerg said:
i was about too anyone tried it anyways though?
Click to expand...
Click to collapse
.... why would anyone try it when its a 100% guarantee to hard brick on vzw
Envoyé de mon SM-G903F en utilisant Tapatalk
Related
Sure something will come up soon but it's 3 am and I wanted to throw a few spitballs at this topic.
Word I've been reading on XDA this early am is that Verizon and ATT have an update that broke root.
I'm not going to touch the bootloader issues since that's above my skill set at the moment.
I think we need to break it down into two parts:
1) Fixing the update to work without breaking current root methods.
Looks like Aou's "neutered" ATT update may pull it off for them. Not sure it needed to remove all that he did but that's a separate topic.
If so then the process just needs to be duplicated for Verizon.
My only concern from trying this with Sprint's N2 is that when we tried this (tweaking the zip) we broke the CSC data.
Minor inconveniences and easily fixed by flashing the last cache.img from a Samsung tarball (minus the data wipe).
Odin may be doable so long as the Sprint MF9 modem tar creation process can be duplicated to others.
The only thing I haven't resolved is the CSC update. You'd have to use an older version as mentioned above.
2) Finding a way to get folks rooted that have already applied the update.
My initial thought is this: Since ATT is already ahead, have someone who has kept root and SuperSU to dump system.img. Repack into Odin tar and see if bootloader will let it flash.... and if it does, will it restore root? Adjust as necessary and duplicate the process on Verizon.
If this is possible it should get those folks who wanted root and already applied the update at least rooted. Won't do much else for them though until the bootloader issues are solved.. but it would be movement in the right direction.
Side note: I can't speak for other leaks but with Sprint we saw leaks (unreleased/test builds) between OTAs may have different behaviors than what was released. Might be worth poking previous leak sources and see if they have any such ones between the last Loki-able build and the new OTAs - and if they might be able to share those with devs for further analysis. I did the same but got nothing so far... not surprising though since it's not Sprint.
OK, minor update.
Both now seem to have gone OTA and Voodoo seems to keep it even after for both. So that's good news.
VZW definitely has a new pattern for Loki and it's got to be found.
I'm trying to resolve the addressing Bliss put in the logic versus a hex editor.
I might see if I can get Eclipse running and then run it in debug and see if that will get us closer.
If we can get that far it should be possible to re-test Loki under the new aboot.
(I've removed after a brief discussion with Bliss. I'll still study aboot more but this is now out after that discussion.)
I'm also checking on a hail mary of rolling back. No promises though.
garwynn said:
OK, minor update.
Both now seem to have gone OTA and Voodoo seems to keep it even after for both. So that's good news.
VZW definitely has a new pattern for Loki and it's got to be found.
I'm trying to resolve the addressing Bliss put in the logic versus a hex editor.
I might see if I can get Eclipse running and then run it in debug and see if that will get us closer.
If we can get that far it should be possible to re-test Loki under the new aboot.
(I've removed after a brief discussion with Bliss. I'll still study aboot more but this is now out after that discussion.)
I'm also checking on a hail mary of rolling back. No promises though.
Click to expand...
Click to collapse
Definitely interested in the hail mary of rolling back. I'll be experimenting with the bootloader updates a bit more once I get my device JTAGed (hopefully next week). I'll let you know how it goes.
Meanwhile, I've uploaded the system and kernel that I had working - over in the neutered thread.
garwynn said:
OK, minor update.
Both now seem to have gone OTA and Voodoo seems to keep it even after for both. So that's good news.
VZW definitely has a new pattern for Loki and it's got to be found.
I'm trying to resolve the addressing Bliss put in the logic versus a hex editor.
I might see if I can get Eclipse running and then run it in debug and see if that will get us closer.
If we can get that far it should be possible to re-test Loki under the new aboot.
(I've removed after a brief discussion with Bliss. I'll still study aboot more but this is now out after that discussion.)
I'm also checking on a hail mary of rolling back. No promises though.
Click to expand...
Click to collapse
If you are interested, a poster figured out how to edit the MF3 update to work through ODIN. Maybe, if the same edits are applied to the existing AMDL firmware, ODIN can then be used to rollback phones that already have MF3 on them back to AMDL? Here is a link...
http://forum.xda-developers.com/showthread.php?t=2360859
scott14719 said:
If you are interested, a poster figured out how to edit the MF3 update to work through ODIN. Maybe, if the same edits are applied to the existing AMDL firmware, ODIN can then be used to rollback phones that already have MF3 on them back to AMDL? Here is a link...
http://forum.xda-developers.com/showthread.php?t=2360859
Click to expand...
Click to collapse
In short, this will not work. If it did work, it would appear that the result would be a hard brick. It seems that once the device is fused to MF3+, the device will not only reject the older firmware and refuse to install it (regardless if the Odin software accepts it), the device will actively refuse to boot outdated bootloaders - regardless of how they are applied to the device (dd, recovery, or even JTAG).
However, it might be possible to inject root into a system image and fool both the PC and the phone into flashing it... If not root itself, then maybe whatever method these "OTA rootkeeper" apps use (a hidden root?)?
Once we have a Kies/Odin image of MF3, I'm wondering what would stop us from tampering with the included system image and attempting to write that to the device?
From the sounds of it, Samsung may not be releasing a Kies version of MF3 any time soon.
As for the continuing research of a root for the MF3 update, I've got an excellent testing ground, ready to flash as a rom:
http://forum.xda-developers.com/showthread.php?t=2378946
The purpose and hope for the new rom is to make it easier and safer for any Dev to begin researching a new root method for the MF3 firmware. Best of luck to us all.
I accidentally allowed that stupid program to run and I realized an answer could be staring right at me. Could we possibly trick the program into repairing your phone with an MDK install? (as if you were to repair an actual MDK phone?) Or possible use it to flash MDK thinking it's a newer version? I'd assume it'd basically think it had authority from Verizon themselves.
I definitely no developer but I figured it may be a question outside the box.
J Andersen said:
I accidentally allowed that stupid program to run and I realized an answer could be staring right at me. Could we possibly trick the program into repairing your phone with an MDK install? (as if you were to repair an actual MDK phone?) Or possible use it to flash MDK thinking it's a newer version? I'd assume it'd basically think it had authority from Verizon themselves.
I definitely no developer but I figured it may be a question outside the box.
Click to expand...
Click to collapse
Its defiantly an interesting suggestion, but i doubt it will work because the phone itself check if the signature matches what it has(each version has its own signature) and if it doesn't that's what causes it to brick. also it would require us getting a hold of either the source code of the program or the signature that Samsung signs there installs with.
Mtsprite said:
Its defiantly an interesting suggestion, but i doubt it will work because the phone itself check if the signature matches what it has(each version has its own signature) and if it doesn't that's what causes it to brick. also it would require us getting a hold of either the source code of the program or the signature that Samsung signs there installs with.
Click to expand...
Click to collapse
I thought it was lack of authority to flash roms? Since the ROMs would be legit, combined with Verizon SUA or even Samsung Kies it I'd assume the program would only do what it's told and everything would check out. It'd be interesting to try to say the least.
J Andersen said:
I thought it was lack of authority to flash roms? Since the ROMs would be legit, combined with Verizon SUA or even Samsung Kies it I'd assume the program would only do what it's told and everything would check out. It'd be interesting to try to say the least.
Click to expand...
Click to collapse
If it was just lack of authority to flash the firmware, then anyone with a JTAG box could get around that. On every boot, the bootloader performs several authentication checks. Among other things, a check against hardware q-fuses which cannot be set back once tripped. Either the signature needs to be leaked from the official source (Samsung) or the authentication checks must be bypassed via means of code exploits.
http://forum.xda-developers.com/showthread.php?t=2578566
I don't know if you guys know about this... This allows unsigned kernel modules to be loaded on the equivalent of MI1. If anyone wants to take the steps described by the OP and build for NC5, this would open the ability to work on Kexec and AOSP via Safestrap (with the actual AOSP Kernel!).
npjohnson said:
http://forum.xda-developers.com/showthread.php?t=2578566
I don't know if you guys know about this... This allows unsigned kernel modules to be loaded on the equivalent of MI1. If anyone wants to take the steps described by the OP and build for NC5, then work on Kexec and AOSP via Safestrap (with the actual AOSP Kernel!).
Click to expand...
Click to collapse
So are you basically making this thread not to offer anything new, just to tell people to do more work for you?
Most of the S4 devs already saw that 8 months ago and did what they could with it...
scryan said:
So are you basically making this thread not to offer anything new, just to tell people to do more work for you?
Most of the S4 devs already saw that and did what they could with it...
Click to expand...
Click to collapse
Wow. Way to overreact dude. NO I am not telling you or anyone to do work for me. The ATT and Verizon forums find different things, and therefore, sometimes there is a delay in the info being transferred back and forth. Did anywhere in my post did I say/insinuate that I was forcing people to do work for me? NO, I did not, I just shared some info from the other forum, and you replied by complaining about me cross posting. Thanks for that.
I know that they have probably seen the initial post, but there are some helpful posts later in the thread that seemed interesting about building for later firmwares.
I then even proceeded to try and have been debugging it for the last hour or so...
Update
I tried to follow the steps in the OP of the mentioned thread, but loading an unsigned test module on NC5 fails, although BypassKSLM is loading... More work required.
I think that the fix should be somewhere in the:
if (krsp->ret == 0) {
pr_warn("TIMA: lkmauth--verification succeeded.\n");
ret = 0; /* ret should already be 0 before the assignment. */
As I failed to get ret=0 before assignment.
npjohnson said:
Wow. Way to overreact dude. NO I am not telling you or anyone to do work for me. The ATT and Verizon forums find different things, and therefore, sometimes there is a delay in the info being transferred back and forth. Did anywhere in my post did I say/insinuate that I was forcing people to do work for me? NO, I did not, I just shared some info from the other forum, and you replied by complaining about me cross posting. Thanks for that.
I know that they have probably seen the initial post, but there are some helpful posts later in the thread that seemed interesting about building for later firmwares.
I then even proceeded to try and have been debugging it for the last hour or so...
Click to expand...
Click to collapse
Cross posting from 8 months ago, after the maker of safestrap (who has accepted a job and recently abandoned further development) has tried and moved on from getting a working kexec...
Its great your working on it. But before bringing it to the main forum and getting people worked up it might be good to make even some progress, otherwise we are just looping back to where we were 8 months ago.
Beyond that.... Hasn't this been patched?
jeboo said:
I got this idea after reading about CVE-2013-6282 and seeing the source for it.
Click to expand...
Click to collapse
Its based on get get_user put_user exploit yes?
Surge hints at the same fact later, when he discusses whether or not it could be run on a S3
Surge1223 said:
This depends on whether or not you are able to root using saferoot or not (since its dependent on the get/put_user exploit) and whether your stock kernel was compiled with support for loading modules. You can check your kernel source config file to see.
Click to expand...
Click to collapse
Mentioning being able to run saferoot as an easy method to check and see if the exploit is still avalible, which on NC5 it wasn't right?
scryan said:
Cross posting from 8 months ago, after the maker of safestrap (who has accepted a job and recently abandoned further development) has tried and moved on from getting a working kexec...
Its great your working on it. But before bringing it to the main forum and getting people worked up it might be good to make even some progress, otherwise we are just looping back to where we were 8 months ago.
Beyond that.... Hasn't this been patched?
Its based on get get_user put_user exploit yes?
Surge hints at the same fact later, when he discusses whether or not it could be run on a S3
Mentioning being able to run saferoot as an easy method to check and see if the exploit is still avalible, which on NC5 it wasn't right?
Click to expand...
Click to collapse
My apologies for the misunderstanding on the NC5 part, I am using Surges Downgrade to 4.3, which (4.3) still has the get_user put_user exploit. Still NC5 BL, but 4.3 on /system. Plus if we got kexec working on downgraded 4.3, it wouldn't matter that it was 4.3 because we could just load a 4.4 kernel and rom.
My goal was to try to revive (restart from scratch) the project and see where it got to. I currently got a test module loading (what others have already gotten to), now I want to take my own crack at kexec. It probably won't bear fruit, it could though, and thats the idea... but regardless it is a good learning process.
Plus kexec isn't out only option... It works well with safestrap, but there are many other pieces that when put together can function alike kexec, one being ksplice.
npjohnson said:
My apologies for the misunderstanding on the NC5 part, I am using Surges Downgrade to 4.3, which (4.3) still has the get_user put_user exploit. Still NC5 BL, but 4.3 on /system. Plus if we got kexec working on downgraded 4.3, it wouldn't matter that it was 4.3 because we could just load a 4.4 kernel and rom.
My goal was to try to revive (restart from scratch) the project and see where it got to. I currently got a test module loading (what others have already gotten to), now I want to take my own crack at kexec. It probably won't bear fruit, it could though, and thats the idea... but regardless it is a good learning process.
Click to expand...
Click to collapse
I think part of the issue was something along the lines that the kernel is checked and if it does not pass the phone is shutdown/crippled/set into some mode.
Kexec may be slightly more relevant now that there is some access to the trusted zone, but I really have no idea what I am talking about on that one.
But before you worry too much about "Kexec" make sure you are aware of and understand checks on the kernels validity, if they are performed by the tz, and what/how much access to the tz there is now with Dan's latest... at least that my 2 cents.
It seemed the whole kexec thing kind of dead ended because the issue is a bit deeper then just getting a working kexec module and loading a new kernel.
scryan said:
I think part of the issue was something along the lines that the kernel is checked and if it does not pass the phone is shutdown/crippled/set into some mode.
Kexec may be slightly more relevant now that there is some access to the trusted zone, but I really have no idea what I am talking about on that one.
But before you worry too much about "Kexec" make sure you are aware of and understand checks on the kernels validity, if they are performed by the tz, and what/how much access to the tz there is now with Dan's latest... at least that my 2 cents.
It seemed the whole kexec thing kind of dead ended because the issue is a bit deeper then just getting a working kexec module and loading a new kernel.
Click to expand...
Click to collapse
I know. The main reason I posted this was to work in tandem with Dan's new TZ Exploit. It allows running unsigned code at TZ level, and the possibility of turning off TIMA almost altogether, with TIMA disabled, and low level unsigned code, writing a kexec module would the be the next step.
scryan said:
Cross posting from 8 months ago, after the maker of safestrap (who has accepted a job and recently abandoned further development) has tried and moved on from getting a working kexec...
Its great your working on it. But before bringing it to the main forum and getting people worked up it might be good to make even some progress, otherwise we are just looping back to where we were 8 months ago.
Beyond that.... Hasn't this been patched?
Its based on get get_user put_user exploit yes?
Surge hints at the same fact later, when he discusses whether or not it could be run on a S3
Mentioning being able to run saferoot as an easy method to check and see if the exploit is still avalible, which on NC5 it wasn't right?
Click to expand...
Click to collapse
Well back when I typed that the get_user/put_user exploit was the only exploit we had that could overwrite kernel memory. Now that we have towelroot its also theoretically possible to re-implement bypasslkm on NC5 depending on how they mightve patched it.
I tried doing this but since not many cared or even tried to make use of bypasslkm the first time around I didnt post my findings, nonetheless this info might be useful to future individuals trying to do the same. I really hope someone makes use of what im about to type.
So the first time around jeboo had an error log and was able to find the address to patch since we had kernel source and he probably decompressed the zimage and found the relevent lkmauth address.
There is another way to enable insecure module loading (using the same approach and address as bypasslkm) by using objdump on the vmlinux produced from compiling the kernel from source, then finding the following
1a000002 bne <copy_and_check.isra.22+xxx>
then by doing some math, and guess checking you can use devmem2 to write 0x0 to whatever address returned the ARM opcode 1a000002, for mk2 this address is 0x802c9d58 (may seem familiar if you have looked at bypasslkm.c)
I confirmed by manually writing writing 0x0 at 0x802c9d58 = modules verified and returning the value to 0x1a000002 = modules modified.
I tried to find <copy_and_check.isra.22+xxx> in NC5 kernel source however it is non-existant. I have not yet tried to decompress the zimage and search for the relevant lkmauth messages to see if bypasslkm is still able to be implemented or to see how it may have/may not have been patched. This is probably the first step I should have done, so anyone starting now should start with that step, decompressing the zimage and searching for the lkmauth messages and see how the check is implemented.
Surge1223 said:
Well back when I typed that the get_user/put_user exploit was the only exploit we had that could overwrite kernel memory. Now that we have towelroot its also theoretically possible to re-implement bypasslkm on NC5 depending on how they mightve patched it.
I tried doing this but since not many cared or even tried to make use of bypasslkm the first time around I didnt post my findings, nonetheless this info might be useful to future individuals trying to do the same. I really hope someone makes use of what im about to type.
So the first time around jeboo had an error log and was able to find the address to patch since we had kernel source and he probably decompressed the zimage and found the relevent lkmauth address.
There is another way to enable insecure module loading (using the same approach and address as bypasslkm) by using objdump on the vmlinux produced from compiling the kernel from source, then finding the following
1a000002 bne <copy_and_check.isra.22+xxx>
then by doing some math, and guess checking you can use devmem2 to write 0x0 to whatever address returned the ARM opcode 1a000002, for mk2 this address is 0x802c9d58 (may seem familiar if you have looked at bypasslkm.c)
I confirmed by manually writing writing 0x0 at 0x802c9d58 = modules verified and returning the value to 0x1a000002 = modules modified.
I tried to find <copy_and_check.isra.22+xxx> in NC5 kernel source however it is non-existant. I have not yet tried to decompress the zimage and search for the relevant lkmauth messages to see if bypasslkm is still able to be implemented or to see how it may have/may not have been patched. This is probably the first step I should have done, so anyone starting now should start with that step, decompressing the zimage and searching for the lkmauth messages and see how the check is implemented.
Click to expand...
Click to collapse
I lack the knowledge to even attempt this but I do hope another tries at least. I miss aosp. I'm coming from a HTC with s-off and I'm not used to the restrictions placed on such a locked down phone. I do hope that some work around for running an unsecured kernel will be found at least. Thanks for the information and hopefully it will be put to good use
Sent from my SCH-I545 using Xparent Skyblue Tapatalk 2
Surge1223 said:
Well back when I typed that the get_user/put_user exploit was the only exploit we had that could overwrite kernel memory. Now that we have towelroot its also theoretically possible to re-implement bypasslkm on NC5 depending on how they mightve patched it.
I tried doing this but since not many cared or even tried to make use of bypasslkm the first time around I didnt post my findings, nonetheless this info might be useful to future individuals trying to do the same. I really hope someone makes use of what im about to type.
So the first time around jeboo had an error log and was able to find the address to patch since we had kernel source and he probably decompressed the zimage and found the relevent lkmauth address.
There is another way to enable insecure module loading (using the same approach and address as bypasslkm) by using objdump on the vmlinux produced from compiling the kernel from source, then finding the following
1a000002 bne <copy_and_check.isra.22+xxx>
then by doing some math, and guess checking you can use devmem2 to write 0x0 to whatever address returned the ARM opcode 1a000002, for mk2 this address is 0x802c9d58 (may seem familiar if you have looked at bypasslkm.c)
I confirmed by manually writing writing 0x0 at 0x802c9d58 = modules verified and returning the value to 0x1a000002 = modules modified.
I tried to find <copy_and_check.isra.22+xxx> in NC5 kernel source however it is non-existant. I have not yet tried to decompress the zimage and search for the relevant lkmauth messages to see if bypasslkm is still able to be implemented or to see how it may have/may not have been patched. This is probably the first step I should have done, so anyone starting now should start with that step, decompressing the zimage and searching for the lkmauth messages and see how the check is implemented.
Click to expand...
Click to collapse
I though about TowelRoots ability to do the same as get_put, but understanding exactly how it (TR) works is tough due to llvm-obfuscator. After reading a theoretical writeup of TR, I found this:
Source: http://tinyhack.com/2014/07/07/exploiting-the-futex-bug-and-uncovering-towelroot/
I thought that due ti the nature of the Futex bug that our best bet was a 4.3 downgrade... though what you are saying makes sense... So, your saying that the memory address to be written to 0x0 has merely changed location? (Im probably misunderstanding you...) I thought that they they had moved that flag out of memory to prevent writing...
How are you decompressing zimage? I tried using instructions like these https://github.com/xiaolu/galaxys2_kernel_repack (obviously changed for our model), but I am having some issues..
npjohnson said:
I though about TowelRoots ability to do the same as get_put, but understanding exactly how it (TR) works is tough due to llvm-obfuscator. After reading a theoretical writeup of TR, I found this:
Source: http://tinyhack.com/2014/07/07/exploiting-the-futex-bug-and-uncovering-towelroot/
I thought that due ti the nature of the Futex bug that our best bet was a 4.3 downgrade... though what you are saying makes sense... So, your saying that the memory address to be written to 0x0 has merely changed location? (Im probably misunderstanding you...) I thought that they they had moved that flag out of memory to prevent writing...
How are you decompressing zimage? I tried using instructions like these https://github.com/xiaolu/galaxys2_kernel_repack (obviously changed for our model), but I am having some issues..
Click to expand...
Click to collapse
Do you have the kernel compiled?
Surge1223 said:
Do you have the kernel compiled?
Click to expand...
Click to collapse
I am doing what you were talking about first to learn... Im doing it from an MK2 JB device. So I have the kernel compiled for that one. But I haven't begun on my NC5 KK device yet. We don't have kernel source for NC5 yet, do we?
npjohnson said:
I am doing what you were talking about first to learn... Im doing it from an MK2 JB device. So I have the kernel compiled for that one. But I haven't begun on my NC5 KK device yet. We don't have kernel source for NC5 yet, do we?
Click to expand...
Click to collapse
http://opensource.samsung.com/reception/receptionSub.do?method=search&searchValue=SCH-I545
I've been reading articles on kexec being used for Linux fast reboots, which sounds a lot like our Fastboot. BUT, I have a Fast Reboot option on my phone. Can someone ELI5 the difference bw Linux Fast Reboot, Android Fastboot, and Android Fast Reboot?
FYI, I *know* the S4 doesn't support Fastboot that's why I'm asking about fast reboot and if it is different.
sokrboot said:
I've been reading articles on kexec being used for Linux fast reboots, which sounds a lot like our Fastboot. BUT, I have a Fast Reboot option on my phone. Can someone ELI5 the difference bw Linux Fast Reboot, Android Fastboot, and Android Fast Reboot?
FYI, I *know* the S4 doesn't support Fastboot that's why I'm asking about fast reboot and if it is different.
Click to expand...
Click to collapse
I'll let someone more experienced explain any relevance, if there is any, but as far as the "fast reboot" or "hot reboot" option in your power menu... its a method of rebooting that only restarts the GUI.
http://www.xda-developers.com/windows-mobile/reboot-the-shell-only-with-hot-reboot-for-android/
sokrboot said:
I've been reading articles on kexec being used for Linux fast reboots, which sounds a lot like our Fastboot. BUT, I have a Fast Reboot option on my phone. Can someone ELI5 the difference bw Linux Fast Reboot, Android Fastboot, and Android Fast Reboot?
FYI, I *know* the S4 doesn't support Fastboot that's why I'm asking about fast reboot and if it is different.
Click to expand...
Click to collapse
Fastboot and fast reboot are in no way related, or even similar.
RuggedHunter said:
I'll let someone more experienced explain any relevance, if there is any, but as far as the "fast reboot" or "hot reboot" option in your power menu... its a method of rebooting that only restarts the GUI.
http://www.xda-developers.com/windows-mobile/reboot-the-shell-only-with-hot-reboot-for-android/
Click to expand...
Click to collapse
@RuggedHunter thanks for replying with helpful information, I appreciate it.
Surge1223 said:
http://opensource.samsung.com/reception/receptionSub.do?method=search&searchValue=SCH-I545
Click to expand...
Click to collapse
Kernel Compiled
Hello everyone,
Right now I have another thread for the root over ADB with DirtySanta, I've that far. I have a potential method but I need more information on it from somebody else so I am waiting on a response from him, once i have that I'll work on it. If you guys have any other potential ideas that'd be great.
Thanks,
Abine45
This is my link to the root on ADB. I will be updating it tonight or tomorrow for the convenience of others. Thanks for waiting.
http://forum.xda-developers.com/verizon-lg-v10/general/temporary-root-adb-t3523538
NEW INFORMATION FOUND! I GOT SIGNIFICANT ROOT ACCESS WITH DIRTYSANTA!!!
SO i used the DirtySanta fearing for my life I wouldn't ruin my device, well the v10 failed it. rebooted and it didn't do anything but reboot back into the normal bootloader and stuff. But what i found is that he go the dirty cow to just work under root, so maybe from there we could do something, anybody have any ideas?
people care but it seems kind of like you expect people who have no clue to do any of this to assist. Hence the reason they are willing to pay a rather large sum of money for a bounty.
1. You cannot repackage a TOT file, well you can but, because it is digitally signed so that the locked boot loader will recognize it and allow it access to image the system. Repacking a rooted version on MM or Nougat will brick the phone if it is not digitally signed by LG.
2. You can pull a copy of the boot image with dirty cow but you can do that from the TOT or KDZ. You cannot put a new one in with dirty cow with out bricking the phone.
3. Most likely not. SELINUX policies combined with updates and fixes have removed most of the previous exploits.
4. Nothing personal but if you are asking us where the boot image resides... that does not inspire anyone here to give you a hand. You need to be in the android devs forum asking these questions.
http://forum.xda-developers.com/android/software-hacking
Haxcid said:
people care but it seems kind of like you expect people who have no clue to do any of this to assist. Hence the reason they are willing to pay a rather large sum of money for a bounty.
1. You cannot repackage a TOT file, well you can but, because it is digitally signed so that the locked boot loader will recognize it and allow it access to image the system. Repacking a rooted version on MM or Nougat will brick the phone if it is not digitally signed by LG.
2. You can pull a copy of the boot image with dirty cow but you can do that from the TOT or KDZ. You cannot put a new one in with dirty cow with out bricking the phone.
3. Most likely not. SELINUX policies combined with updates and fixes have removed most of the previous exploits.
4. Nothing personal but if you are asking us where the boot image resides... that does not inspire anyone here to give you a hand. You need to be in the android devs forum asking these questions.
http://forum.xda-developers.com/android/software-hacking
Click to expand...
Click to collapse
How did Tungkick manage to repackage it then? The dirty cow exploit can exchange recovery though on an unlocked bootloader so shouldn't I be able to replace the boot image if done correctly wouldn't it work? I could possibly unpack everything and modify it all and test it but the issue comes back to repacking and flashing?
Ask him, but if you attempt to do this on a locked and encrypted boot loader then you will brick the phone. I mean think about it, if it was really just that simple every phone would be rooted and rom'd. Most phones running 6 or above have had the security vastly increased to make the phone secure so they can be used by government employees. Hence the introduction to SELINUX polices into the kernel which is why getting root is so unbelievably difficult. The locked boot loader resets everything at boot so getting root and maintaining is so hard combined with SELINUX does not allow standard root to perm. write anything to the system partition and then good old hboot kills anything you did mange to write on reboot... you can start to see how difficult this really is.
Tungkick did this on 5.1 Lollipop not 6.0 Marshmallow. The above mentioned difficulties with increased SELunix security plus 6.0 and up requires systemless root.
Still would love to know why no dev will go near this Phone. Does XDA have some deal with LG to not hack their phones? Very fishy why every dev avoids this device like it has the plague.
beavis5706 said:
Tungkick did this on 5.1 Lollipop not 6.0 Marshmallow. The above mentioned difficulties with increased SELunix security plus 6.0 and up requires systemless root.
Still would love to know why no dev will go near this Phone. Does XDA have some deal with LG to not hack their phones? Very fishy why every dev avoids this device like it has the plague.
Click to expand...
Click to collapse
LG are just not popular devices for hacking due to they make if extremely difficult. LG is a Corp. friendly company it is why Verizon loves them where companies like HTC are a bit more user sympathetic.
Funny you say that
beavis5706 said:
Tungkick did this on 5.1 Lollipop not 6.0 Marshmallow. The above mentioned difficulties with increased SELunix security plus 6.0 and up requires systemless root.
Still would love to know why no dev will go near this Phone. Does XDA have some deal with LG to not hack their phones? Very fishy why every dev avoids this device like it has the plague.
Click to expand...
Click to collapse
Funny you say that! Tungick said to me, and i quote "[email protected]#$g you" and blocked me from Facebook. He also told me that he wouldn't tell me because it's a secret. He didn't speak very great English, that's why there is an ing at the end of the F-bomb. I asked Jcase through XDA and he said he wouldn't and so i put it better explanation of help through an email and he said I was harassing him... In which case before hand he said he doesn't develop for LG because he says basically we are A-holes sadly and that we don't live up to our donation pledges.
That's what I'm saying though. It's like no dev will go anywhere near an LG device, at least the newer ones anyway.
They can't be much harder to crack than Samsung and those are getting cracked.
The person who rooted 5.1 on V10 basically tells you to F off. Yeah there is nothing odd about that.
beavis5706 said:
That's what I'm saying though. It's like no dev will go anywhere near an LG device, at least the newer ones anyway.
They can't be much harder to crack than Samsung and those are getting cracked.
The person who rooted 5.1 on V10 basically tells you to F off. Yeah there is nothing odd about that.
Click to expand...
Click to collapse
True, that's why I'm going to try to do it. If you know anything and want to help could use it.
Wish I could help. All I know here is you need systemless root on 6.0+. This has nothing to do with the v10 in particular. Systemless root should work on all devices 6.0+. It has already been achieved on the Galaxy s7 and it has locked bootloader. I don't see any reason why this can't work on the v10.
I just installed Linux on my computer gonna try somethings this weekend... We need to keep in touch
qujuanmiller said:
I just installed Linux on my computer gonna try somethings this weekend... We need to keep in touch
Click to expand...
Click to collapse
For sure, message me on xda.
beavis5706 said:
Wish I could help. All I know here is you need systemless root on 6.0+. This has nothing to do with the v10 in particular. Systemless root should work on all devices 6.0+. It has already been achieved on the Galaxy s7 and it has locked bootloader. I don't see any reason why this can't work on the v10.
Click to expand...
Click to collapse
Anybody can help! Do some research and send it and whatever you would like to do. Try different things, Try to modify bits of code and see what you can do! Always gotta start somewhere!
Modify code? You just went way above my head. I know about root, certainly don't know how to achieve it. That's why I count on the folks at XDA. I only have one v10, can't afford to brick it. Plus I already have root on 5.1.1 and I heard that 6.0 causes this phone to have problems.
Many, many v10's were offered up in order to attain root. Not one was taken by any dev. Maybe you can still get your hands on one of those.
You need to find someone that knows about systemless root. Without that you aren't getting anywhere.
beavis5706 said:
Modify code? You just went way above my head. I know about root, certainly don't know how to achieve it. That's why I count on the folks at XDA. I only have one v10, can't afford to brick it. Plus I already have root on 5.1.1 and I heard that 6.0 causes this phone to have problems.
Many, many v10's were offered up in order to attain root. Not one was taken by any dev. Maybe you can still get your hands on one of those.
You need to find someone that knows about systemless root. Without that you aren't getting anywhere.
Click to expand...
Click to collapse
The thing with that is the fact that even if I know how systemless root works, I still have no way to install it, so first I need to find a way to get in the system.
Think I might have a way though
From what I understand systemless root will modify the boot image to attain root. Super SU will decide how to flash based on firmware version. Will automatically root normal with Lollipop and down, will automatically modify boot image on Marshmallow and up. How you will be able to modify the boot image on a VS990 without bricking it I don't know.
In order to do system less root we need a unlocked bootloader... It says that everywhere I'm reading
Hi abine45,
Please read this post completely, the guys here are close to obtain the perma root on android 6, using dirty cow.
https://github.com/timwr/CVE-2016-5195/issues/9
Sent from my E2006 using Tapatalk
I looked at this thread... a bit more technical than I am able to do... did it end up working? Looks like no, but I might have missed something.
Thanks!
Please be kind if this is a stupid question - I'm very new to this and learning fast.
Would it be possible to add a signature to aromafm or to a lock pattern removal script, using the leaked Samsung platform certificate (as recently reported), and if so would that allow it to be sideloaded to stock recovery in a Galaxy S9?
I recently had to add a pattern lock - which I somehow managed to immediately forget. Even though it was a simple pattern specifically chosen to fall naturally under the hand so that I wouldn't forget it... I've tried so many variations that it's now making me wait 24 hours between attempts. It also turns out that data that I thought was backing up externally was actually only going to internal storage, so I really don't want to do a factory reset without trying absolutely everything else first.
Galaxy S9
Not rooted
Bootloader is locked
USB debugging is enabled
ADB can see the phone but it's not authorised
ADB sideload does work - but of course any scripts need the Samsung signature.
The phone is not registered with Samsung, so I can't unlock it through my Samsung account.
I realise it's clutching at straws but would the leaked platform key be a way in?
missmilla said:
Please be kind if this is a stupid question - I'm very new to this and learning fast.
Would it be possible to add a signature to aromafm or to a lock pattern removal script, using the leaked Samsung platform certificate (as recently reported), and if so would that allow it to be sideloaded to stock recovery in a Galaxy S9?
I recently had to add a pattern lock - which I somehow managed to immediately forget. Even though it was a simple pattern specifically chosen to fall naturally under the hand so that I wouldn't forget it... I've tried so many variations that it's now making me wait 24 hours between attempts. It also turns out that data that I thought was backing up externally was actually only going to internal storage, so I really don't want to do a factory reset without trying absolutely everything else first.
Galaxy S9
Not rooted
Bootloader is locked
USB debugging is enabled
ADB can see the phone but it's not authorised
ADB sideload does work - but of course any scripts need the Samsung signature.
The phone is not registered with Samsung, so I can't unlock it through my Samsung account.
I realise it's clutching at straws but would the leaked platform key be a way in?
Click to expand...
Click to collapse
While XDA prides itself on being hacker friendly, we shy away from anything that could result in legal liability, which is why we do not permit the sharing of any proprietary material, even if it's already in the public domain.
So in a nutshell....I imagine that if one did have a valid key, and signed an update package using that key, they could potentially use it to exploit their device, such as changing the props to allow bootloader unlocking, thereby permitting custom recoveries. Samsung as far as I know does not protect the system image with Verified Boot, so it is possible to modify /system without incurring a boot failure.
All that being said, the point is pretty moot, because as I pointed out we do not allow sharing anything that is licensed intellectual property, so any discussions on the topic would have to be rather...vague.
V0latyle said:
While XDA prides itself on being hacker friendly, we shy away from anything that could result in legal liability, which is why we do not permit the sharing of any proprietary material, even if it's already in the public domain.
So in a nutshell....I imagine that if one did have a valid key, and signed an update package using that key, they could potentially use it to exploit their device, such as changing the props to allow bootloader unlocking, thereby permitting custom recoveries. Samsung as far as I know does not protect the system image with Verified Boot, so it is possible to modify /system without incurring a boot failure.
All that being said, the point is pretty moot, because as I pointed out we do not allow sharing anything that is licensed intellectual property, so any discussions on the topic would have to be rather...vague.
Click to expand...
Click to collapse
Thank you, that's really helpful. I was thinking more whether simply adding a signature to a script would let that script be used directly with stock recovery, rather than unlocking the bootloader to flash a custom recovery (which I suspect would be beyond me), but it sounds as though in theory it might be worth a try. At this stage I probably have nothing left to lose as I'll have to to a full reset anyway if I can't find anonther way in.
missmilla said:
Thank you, that's really helpful. I was thinking more whether simply adding a signature to a script would let that script be used directly with stock recovery, rather than unlocking the bootloader to flash a custom recovery (which I suspect would be beyond me), but it sounds as though in theory it might be worth a try. At this stage I probably have nothing left to lose as I'll have to to a full reset anyway if I can't find anonther way in.
Click to expand...
Click to collapse
I'm honestly no expert on this kind of thing, but if I'm correct in my assumption that Samsung does not protect the system image, then yes - you could, in theory, use the leaked key to sign an update package that could patch /system to gain root. This would require knowledge of exactly how Samsung signs their updates. However, if the system image is protected, this would cause a boot failure, as AVB would detect the modification.
But.
If the above were possible, then the best course of action would be to create a script that would set ro.oem_unlock_ability=1 and sys.get_unlock_ability=1, after which the user would immediately reboot to download mode and unlock the bootloader, because once you've unlocked the bootloader, you've removed a lot of restrictions - you can flash a custom recovery, flash a root patch, flash anything you damn well pleased.
I doubt it's that easy unless you have in depth detailed knowledge of the encryption system and precisely how it's implemented. It's designed to be hard to hack. As for the stolen Samsung data be careful what you download. You may end up with something extra like a partition worming rootkit(s). boom. That was too easy.
A data recovery specialist that works with Samsung's is your best shot if you really need the data. Around $800 seems to be a going rate, maybe less but expect to pay a couple hundred.
In the future redundantly backup critical data to at least 2 hdds that are physically and electronically isolated from each other and the PC. Copy/paste only then verify the copy file size and that the backups are readable. Otherwise sooner or later you will lose data, money or both.
V0latyle said:
I'm honestly no expert on this kind of thing, but if I'm correct in my assumption that Samsung does not protect the system image, then yes - you could, in theory, use the leaked key to sign an update package that could patch /system to gain root. This would require knowledge of exactly how Samsung signs their updates. However, if the system image is protected, this would cause a boot failure, as AVB would detect the modification.
But.
If the above were possible, then the best course of action would be to create a script that would set ro.oem_unlock_ability=1 and sys.get_unlock_ability=1, after which the user would immediately reboot to download mode and unlock the bootloader, because once you've unlocked the bootloader, you've removed a lot of restrictions - you can flash a custom recovery, flash a root patch, flash anything you damn well pleased.
Click to expand...
Click to collapse
Thank you, I will do some more digging around. Would unlocking the bootloader that way not wipe the data?
blackhawk said:
I doubt it's that easy unless you have in depth detailed knowledge of the encryption system and precisely how it's implemented. It's designed to be hard to hack. As for the stolen Samsung data be careful what you download. You may end up with something extra like a partition worming rootkit(s). boom. That was too easy.
A data recovery specialist that works with Samsung's is your best shot if you really need the data. Around $800 seems to be a going rate, maybe less but expect to pay a couple hundred.
In the future redundantly backup critical data to at least 2 hdds that are physically and electronically isolated from each other and the PC. Copy/paste only then verify the copy file size and that the backups are readable. Otherwise sooner or later you will lose data, money or both.
Click to expand...
Click to collapse
Do you think it would brick the phone if I tried and it didn't like it, or would it just give the signature verification error like it does now?
Actually, looking again, I think I might have misunderstood. I thought the certificates themselves had been published (so wouldn't have to download anything), but what's shown may just be a hash of the certificate and so wouldn't give me the actual key anyway... I'm finding it all rather confusing.
It's ludicrous that Samsung won't let you unlock a phone if you can prove it's your own.
missmilla said:
Do you think it would brick the phone if I tried and it didn't like it, or would it just give the signature verification error like it does now?
Actually, looking again, I think I might have misunderstood. I thought the certificates themselves had been published (so wouldn't have to download anything), but what's shown may just be a hash of the certificate and so wouldn't give me the actual key anyway... I'm finding it all rather confusing.
It's ludicrous that Samsung won't let you unlock a phone if you can prove it's your own.
Click to expand...
Click to collapse
If in the US try a Samsung Experience center at a Best buy.
I never set locks on my phones, bios's or use encryption on data backup drives because you are always the one most likely to be locked out, sometimes through no fault of your own
Digital data is fragile unless it's redundantly backed up.
blackhawk said:
I doubt it's that easy unless you have in depth detailed knowledge of the encryption system and precisely how it's implemented. It's designed to be hard to hack. As for the stolen Samsung data be careful what you download. You may end up with something extra like a partition worming rootkit(s). boom. That was too easy.
A data recovery specialist that works with Samsung's is your best shot if you really need the data. Around $800 seems to be a going rate, maybe less but expect to pay a couple hundred.
In the future redundantly backup critical data to at least 2 hdds that are physically and electronically isolated from each other and the PC. Copy/paste only then verify the copy file size and that the backups are readable. Otherwise sooner or later you will lose data, money or both.
Click to expand...
Click to collapse
Do you think it would brick the phone if I tried and it didn't like it, or would it just give the signature verification error like it does now?
Actually, looking again, I think I might have misunderstood. I thought the certificates themselves had been published (so wouldn't have to download anything), but what's shown may just be a hash of the certificate and so wouldn't give me the actual key anyway... I'm finding it all rather confusing.
It's ludicrous that Samsung won't let you unlock a phone if you can prove it's your own.
blackhawk said:
If in the US try a Samsung Experience center at a Best buy.
I never set locks on my phones, bios's or use encryption on data backup drives because you are always the one most likely to be locked out, sometimes through no fault of your own
Digital data is fragile unless it's redundantly backed up.
Click to expand...
Click to collapse
Thank you. I'm in the UK but we do have a couple of Samsung Experience Centres here so I'll try asking. Oh I will definitely be making multiple, unencrypted backups from now on! I will also be rooting the phone and installing a custom recovery just in case.
If you start playing with the firmware bricking the device is always a real possibility especially if you don't follow the protocols correctly. I never had to flash any of my Samsung's in 12 years, all are still working today. I don't do OTA updates either, ever, the potential to brick them like that is higher with you having zero control.
Samsung would really love to sell you a new expensive phone...
Some lessons you end up learning the hard way. I lost a 30yo database that is irreplaceable
Learn from your mistakes and press on. It's a lot easier though to learn from other's mistakes.
missmilla said:
Thank you, I will do some more digging around. Would unlocking the bootloader that way not wipe the data?
Click to expand...
Click to collapse
Unlocking the bootloader will always require a data wipe.
missmilla said:
Do you think it would brick the phone if I tried and it didn't like it, or would it just give the signature verification error like it does now?
Actually, looking again, I think I might have misunderstood. I thought the certificates themselves had been published (so wouldn't have to download anything), but what's shown may just be a hash of the certificate and so wouldn't give me the actual key anyway... I'm finding it all rather confusing.
Click to expand...
Click to collapse
The stock recovery will refuse any packages that are not signed, or are signed with an unrecognized key. There's other measures in place as well.
blackhawk said:
If you start playing with the firmware bricking the device is always a real possibility especially if you don't follow the protocols correctly. I never had to flash any of my Samsung's in 12 years, all are still working today. I don't do OTA updates either, ever, the potential to brick them like that is higher with you having zero control.
Samsung would really love to sell you a new expensive phone...
Some lessons you end up learning the hard way. I lost a 30yo database that is irreplaceable
Learn from your mistakes and press on. It's a lot easier though to learn from other's mistakes.
Click to expand...
Click to collapse
Probably not something to be messing around with when I don't know what I'm doing then.
Ouch! No wonder you're so careful with backing up... as I will be too from now on. Lesson learned
V0latyle said:
Unlocking the bootloader will always require a data wipe.
The stock recovery will refuse any packages that are not signed, or are signed with an unrecognized key. There's other measures in place as well.
Click to expand...
Click to collapse
It's sounding like I'd probably better count my losses and leave it alone. And be more careful in future. All this has got me itching to try stuff out though. Possibly not on my one and only phone, but maybe if I can get a cheap second hand one to play with, or the S9 once I eventually upgrade - it sounds so much fun!
You can use the key to sideload an update, if I were you I'll try to flash a blank vbmeta and magisk boot so that you can bypass dm-verity and other measures, but the problem on this is where you can find the certificate? Nobody will tell you where you can find it because who has it remains silent and also communities do not allow this kind of sharing.
Skorpion96 said:
You can use the key to sideload an update, if I were you I'll try to flash a blank vbmeta and magisk boot so that you can bypass dm-verity and other measures, but the problem on this is where you can find the certificate? Nobody will tell you where you can find it because who has it remains silent and also communities do not allow this kind of sharing.
Click to expand...
Click to collapse
Thank you. Yeah, I thought I had seen someone publish the certificate, but I misunderstood. So wouldn't be able to get hold of it what with not being familiar with the dark web!
Skorpion96 said:
if I were you I'll try to flash a blank vbmeta and magisk boot so that you can bypass dm-verity and other measures
Click to expand...
Click to collapse
you can always flash blank vbmeta on low level (such as usbdl, edl or bootrom mode) but that's not how it works.
aIecxs said:
you can always flash blank vbmeta on low level (such as edl or bootrom mode) but that's not how it works.
Click to expand...
Click to collapse
Depends, if your device is made in USA you can't. I was only suggesting a way to bypass flashing restrictions hoping that bootloader lock don't block you. Normally bootloader lock blocks unsigned flashing but if you are able to bypass it during flash maybe you can boot unsigned firmware, I'm not sure though. To flash stuff you can use an exploit or escalate privileges with a signed app that updates a system one to become uid 1000 and after that you can do setenforce 0 or setenforce permissive to set kernel permissive
No no, locked bootloader prevents booting unsigned boot, vbmeta, etc (not flashing in first place)
@missmilla just realized you wanna break into your device? this was always possible for S9 (encrypted with default_password) but it's not easy
https://www.forensicfocus.com/news/samsung-exynos-support-in-oxygen-forensic-detective
aIecxs said:
@missmilla just realized you wanna break into your device? this was always possible for S9 (encrypted with default_password) but it's not easy
https://www.forensicfocus.com/news/samsung-exynos-support-in-oxygen-forensic-detective
Click to expand...
Click to collapse
Apparently the Qualcomm variants aren't suspectable to this hack. Only Exynos models are listed.