If we are serious about unlocking the bootloader

Search This thread
By:
Advanced…
S

scryan

Senior Member
Oct 19, 2013
780
687
Surge1223 said:
Sure. Problem is I refer to a lot of documentation lol Im currently reading this, doesnt seem very useful though

https://www.google.com/url?sa=t&sou...VmrL9NpydO4WPibXw&sig2=RDpqpZWQq6oZ_qRVNHo4wA

Im not at home, but when I get home I can link you to more documentation (the more people reading things the better)




Sent from my SCH-I545 using XDA Premium 4 mobile app
Click to expand...
Click to collapse

Was actually going to PM you.
I remember you asking about posting some documents here earlier, and was wondering if that just never happened or if you were trying to keep it to PM.
If it is going up publicly, is there a decent place we can consolidate them for everyone to look through? Someplace that would allow adding info either by anyone or at least by a few different people (so who ever is doing work can add what they may find?)
A central place would be nice to refer to, as a list of links in a post is likely to get buried quickly.

Not sure how much would be over my head, but I'd like to take a look as well.
 
Surge1223

Surge1223

Recognized Contributor
Nov 6, 2012
2,622
7,466
Florida
Google Pixel 6 Pro
scryan said:
Was actually going to PM you.
I remember you asking about posting some documents here earlier, and was wondering if that just never happened or if you were trying to keep it to PM.
If it is going up publicly, is there a decent place we can consolidate them for everyone to look through? Someplace that would allow adding info either by anyone or at least by a few different people (so who ever is doing work can add what they may find?)
A central place would be nice to refer to, as a list of links in a post is likely to get buried quickly.

Not sure how much would be over my head, but I'd like to take a look as well.
Click to expand...
Click to collapse

I dont know what it is but im liking the vibe around here recently. Ive been getting quite a few pms about this and some other stuff. Ill look into how we can get something like this going, I have a folder in my pc called "Samsung/Qualcomm pdfs" im not at home to upload this to my dropbox or elsewhere (visiting fam for holidays) but Friday I get back and ill ask some individuals I know about the best way about doing this.

(Watch I get home and all of a sudden that folder along with some others go miraculously missing, lol)

Sent from my SCH-I545 using XDA Premium 4 mobile app
 
  • Like
Reactions: JavaManRules-GS4, Brooklynsour, brobinson2102 and 2 others
C

coolsilver

Senior Member
Dec 23, 2007
234
15
Just an idea. I know sometimes methods are found through jtag or another method to get into a programmable flash mode. Thinking back to PSP hacking, anyway the battery/interface with battery has say a backdoor? Considering it has NFC data also going through it.... Wonder if there is any documents that have been leaked in that regard. I know original PSP's had battery firmware hack that could help downgrade the device.
 
  • Like
Reactions: Bait-Fish
Surge1223

Surge1223

Recognized Contributor
Nov 6, 2012
2,622
7,466
Florida
Google Pixel 6 Pro
coolsilver said:
Just an idea. I know sometimes methods are found through jtag or another method to get into a programmable flash mode. Thinking back to PSP hacking, anyway the battery/interface with battery has say a backdoor? Considering it has NFC data also going through it.... Wonder if there is any documents that have been leaked in that regard. I know original PSP's had battery firmware hack that could help downgrade the device.
Click to expand...
Click to collapse

Actually had a similar idea. I posted a pic a couple pages back to see if anyone could identify anything useful in that regard. The documentation we have says theres a t-flash, sdcard mode, and ramdump available but so far I havent been able to activate any of the 3. Though I should mention im not an expert on the hardware side of this.

Sent from my SCH-I545 using XDA Premium 4 mobile app
 
  • Like
Reactions: Bait-Fish and JavaManRules-GS4
k1mu

k1mu

Senior Member
Apr 11, 2011
1,945
1,620
Virginia
I've been looking into kernel module loading and how the Knox framework blocks custom kernel modules.
Several have said that only signed kernel modules can be loaded, but that's actually not the case.

The key is that Trust Zone again. Whenever you try to load a module into the kernel, the trustzone is called and asked to verify the hash of the module contents. If the hash value is known, then the module is allowed to load. This isn't a digital signature, just a hash. For practical purposes, the difference isn't important as we really can't hack a file to make it match the original hash any easier than we can hack a digital signature.
The hash is validated using a Trust Zone application called tima_lkm. That's executed out of the trust zone, and can't be accessed by normal kernel processes.

However, I have a couple of pretty good ideas for ways to allow kernel modules to load. I seem to recall that's needed to allow kexec to work and allow arbitrary kernels to be executed. Can someone point me to information on what needs to be loadable to make this work?
I'm willing to risk the "Knox Warranty Void" flag if this will end up with with removing some of the Safestrap limitations.
 
  • Like
Reactions: Bait-Fish, JavaManRules-GS4, Bradh024 and 1 other person
Surge1223

Surge1223

Recognized Contributor
Nov 6, 2012
2,622
7,466
Florida
Google Pixel 6 Pro
k1mu said:
I've been looking into kernel module loading and how the Knox framework blocks custom kernel modules.
Several have said that only signed kernel modules can be loaded, but that's actually not the case.

The key is that Trust Zone again. Whenever you try to load a module into the kernel, the trustzone is called and asked to verify the hash of the module contents. If the hash value is known, then the module is allowed to load. This isn't a digital signature, just a hash. For practical purposes, the difference isn't important as we really can't hack a file to make it match the original hash any easier than we can hack a digital signature.
The hash is validated using a Trust Zone application called tima_lkm. That's executed out of the trust zone, and can't be accessed by normal kernel processes.

However, I have a couple of pretty good ideas for ways to allow kernel modules to load. I seem to recall that's needed to allow kexec to work and allow arbitrary kernels to be executed. Can someone point me to information on what needs to be loadable to make this work?
I'm willing to risk the "Knox Warranty Void" flag if this will end up with with removing some of the Safestrap limitations.
Click to expand...
Click to collapse

I get what you're saying but sorry cant understand your question are you asking whats needed for kexec to work? Or?

Sent from my SCH-I545 using XDA Premium 4 mobile app
 
Surge1223

Surge1223

Recognized Contributor
Nov 6, 2012
2,622
7,466
Florida
Google Pixel 6 Pro
k1mu said:
Simply stated, what module do I need to install into the MJ7 kernel to enable kexec. If that's all, then I'll see if I can get it to load.
Click to expand...
Click to collapse

Maybe Im rusty on what exactly is needed to get kexec working but from my understanding I thought it would need to run at boot by hijacking the kernel during the boot process, so we'd need something to either bypass or mimic the signature. Also this is complicated by the fact that aboot has to verify the boot.img. Maybe my understanding is wrong though...

Sent from my SCH-I545 using XDA Premium 4 mobile app
 
  • Like
Reactions: Bait-Fish and JavaManRules-GS4
H

hemirunner426

Senior Member
May 29, 2008
166
76
Samsung Galaxy S22
Surge1223 said:
Maybe Im rusty on what exactly is needed to get kexec working but from my understanding I thought it would need to run at boot by hijacking the kernel during the boot process, so we'd need something to either bypass or mimic the signature. Also this is complicated by the fact that aboot has to verify the boot.img. Maybe my understanding is wrong though...

Sent from my SCH-I545 using XDA Premium 4 mobile app
Click to expand...
Click to collapse

I believe kexec loads a module into the currently running kernel allowing another kernel image to write itself to memory.

It skips the bootloader stage completely, where all our issues are.

You can run kexec ant any point in the init process of the default kernel.

The only problem is the kexec module will need the correct hash or the Samsung kernel wont load it.
 
  • Like
Reactions: kalestew, Bait-Fish and JavaManRules-GS4
S

scryan

Senior Member
Oct 19, 2013
780
687
Surge1223 said:
Maybe Im rusty on what exactly is needed to get kexec working but from my understanding I thought it would need to run at boot by hijacking the kernel during the boot process, so we'd need something to either bypass or mimic the signature. Also this is complicated by the fact that aboot has to verify the boot.img. Maybe my understanding is wrong though...

Sent from my SCH-I545 using XDA Premium 4 mobile app
Click to expand...
Click to collapse

Not sure how it works on android...

But just in general from what I have read about, Kexec is.... Well lets just go to the source of all true knowledge...Wikipedia.
:cowboy:


In computing, kexec (coming from kernel execution, derived from the Unix/Linux kernel call exec) is a mechanism of the Linux kernel that allows "live" booting of a new kernel "over" the currently running kernel. Essentially, kexec skips the bootloader stage (hardware initialization phase by the system firmware, BIOS or UEFI) and directly loads the new kernel into memory, where it starts executing immediately. This avoids the long times associated with a full reboot, and can help systems to meet high-availability requirements by minimizing downtime
Click to expand...
Click to collapse
So not sure how it works with android, or how it is even called/executed/invoked/whatevered in general... But the general idea of kexec is allowing the kernel to be loaded into memory on top of the booted one.


I would guess that its not a native part of the stock kernel and he needs to know what would need to be added to the kernel to support Kexec?

Is my understanding correct that if we can get Kexec, we can then effectively update everything needed to keep the phone up to date with out taking anything directly from Verizon? That is all I want :)
 
Last edited:
  • Like
Reactions: Bait-Fish and JavaManRules-GS4
H

hemirunner426

Senior Member
May 29, 2008
166
76
Samsung Galaxy S22
scryan said:
Not sure how it works on android...

But just in general from what I have read about, Kexec is.... Well lets just go to the source of all true knowledge...Wikipedia.
:cowboy:



So not sure how it works with android, or how it is even called/executed/invoked/whatevered in general... But the general idea of kexec is allowing the kernel to be loaded into memory on top of the booted one.


I would guess that its not a native part of the stock kernel and he needs to know what would need to be added to the kernel to support Kexec?

Is my understanding correct that if we can get Kexec, we can then effectively update everything needed to keep the phone up to date with out taking anything directly from Verizon? That is all I want :)
Click to expand...
Click to collapse

You can currently regulate your update process from Verizon. Safestrap will give you the ability to run custom roms based on the TW(default) kernel which are debloated and won't take OTA updates from Verizon. You can even disable/freeze the firmware upgrader apks on MJ7/MK to disable OTAs. The update process will be in your hands then. That means, you will have to manually install an updated default kernel/baseband/bootloader, etc.

kexec is a different animal. kexec can be built as a module for any kernel. It all depends on what you select before you start the kernel build. What we would do here with the default Samsung kernel is attempt to load a pre-built kexec module into it. We can then run a kexec command to load a custom unsigned kernel image. This totally bypasses the bootloader of the phone because the bootloader process has already happened while booting the default kernel. The only obstacle is the fact that the default kernel will try to verify the kexec module is trusted before loading it.

If the verification process can be worked around, the next step would to build a custom kexec kernel for the S4. I know there are quite a few already, but kexec is a different animal once again. The hardware on the phone is already initialized when booted to the default kernel. There could be quite a few obstacles to work around as some devices may not react well to be reinitialized on the fly outside of the normal boot process. Not saying that this can't be done, but its going to take time.

EDIT:
In fact, this is a major security issue with kexec. This ability does allow an unsigned image to run on a system that would otherwise verify images before loading them. The workaround was to implement module trust verification... which is what we are facing now.
 
Last edited:
  • Like
Reactions: Bait-Fish, decaturbob and JavaManRules-GS4
R

ryanbg

Inactive Recognized Developer
Jan 3, 2008
858
1,739
movr0.com
hemirunner426 said:
You can currently regulate your update process from Verizon. Safestrap will give you the ability to run custom roms based on the TW(default) kernel which are debloated and won't take OTA updates from Verizon. You can even disable/freeze the firmware upgrader apks on MJ7/MK to disable OTAs. The update process will be in your hands then. That means, you will have to manually install an updated default kernel/baseband/bootloader, etc.

kexec is a different animal. kexec can be built as a module for any kernel. It all depends on what you select before you start the kernel build. What we would do here with the default Samsung kernel is attempt to load a pre-built kexec module into it. We can then run a kexec command to load a custom unsigned kernel image. This totally bypasses the bootloader of the phone because the bootloader process has already happened while booting the default kernel. The only obstacle is the fact that the default kernel will try to verify the kexec module is trusted before loading it.

If the verification process can be worked around, the next step would to build a custom kexec kernel for the S4. I know there are quite a few already, but kexec is a different animal once again. The hardware on the phone is already initialized when booted to the default kernel. There could be quite a few obstacles to work around as some devices may not react well to be reinitialized on the fly outside of the normal boot process. Not saying that this can't be done, but its going to take time.

EDIT:
In fact, this is a major security issue with kexec. This ability does allow an unsigned image to run on a system that would otherwise verify images before loading them. The workaround was to implement module trust verification... which is what we are facing now.
Click to expand...
Click to collapse

TrustZone/TIMA are preventing us from inserting any kernel modules. Unless we can get inside TrustZone with a new exploit, kexec will most likely be not happening.
 
S

scryan

Senior Member
Oct 19, 2013
780
687
hemirunner426 said:
You can currently regulate your update process from Verizon. Safestrap will give you the ability to run custom roms based on the TW(default) kernel which are debloated and won't take OTA updates from Verizon. You can even disable/freeze the firmware upgrader apks on MJ7/MK to disable OTAs. The update process will be in your hands then. That means, you will have to manually install an updated default kernel/baseband/bootloader, etc.
Click to expand...
Click to collapse
You have to match the base kernel with safestrap, you have to use an update from verizon to officially update your phone to update the kernel, you cannot just flash new updates yourself. I will not be able to use anything past 4.2 roms with out taking the MJ7 update given the currently available tools. I'd love for you to prove me wrong though :p

Appreciate your input, but you largely just quoted my post and then repeated the fact that we would have to build a kexec module and add that to the kernel for the phone to have kexec support.

That was what we were just talking about. K1mu asked what in particular needed to be added to the kernel as he had some ideas on how to accomplish it.
k1mu said:
However, I have a couple of pretty good ideas for ways to allow kernel modules to load. I seem to recall that's needed to allow kexec to work and allow arbitrary kernels to be executed. Can someone point me to information on what needs to be loadable to make this work?
I'm willing to risk the "Knox Warranty Void" flag if this will end up with with removing some of the Safestrap limitations.
Click to expand...
Click to collapse

hemirunner426 said:
What we would do here with the default Samsung kernel is attempt to load a pre-built kexec module into it
Click to expand...
Click to collapse
Do you have any ideas on what that pre-built module would be?
 
Last edited:
  • Like
Reactions: kalestew and JavaManRules-GS4
H

hemirunner426

Senior Member
May 29, 2008
166
76
Samsung Galaxy S22
That's right. I reiterated you're post to further explain the process. I wanted to add further explanation to what was already known.

As far as kexec, a module built for the kernel version, perhaps from the tw kernel source will work fine. The problem is getting it through verification on load.

Edit: lots of people have questions on what all this means. My only intent was to lay those questions to rest. I see where what the direction is and where the problems lie. I just want to answer those questions so the devs can spend their time doing what they do best.

Sent from my SCH-I545 using xda app-developers app
 
Last edited:
  • Like
Reactions: kalestew, Bait-Fish and JavaManRules-GS4
jeboo

jeboo

Recognized Developer
Apr 2, 2010
817
4,059
hemirunner426 said:
That's right. I reiterated you're post to further explain the process. I wanted to add further explanation to what was already known.

As far as kexec, a module built for the kernel version, perhaps from the tw kernel source will work fine. The problem is getting it through verification on load.


Sent from my SCH-I545 using xda app-developers app
Click to expand...
Click to collapse

What you need to do is bypass the verification checks in the stock kernel. If you look at the source, I believe they lie in /kernel/module.c (there may be some newer ones related to SELinux). To bypass them we need to use an exploit that allows for kernel memory overwriting. I believe the get/put_user exploit recently discovered *can* do that. Finding the addresses to patch in memory should be pretty trivial.
 
  • Like
Reactions: kalestew, Bait-Fish, Brooklynsour and 3 others
Surge1223

Surge1223

Recognized Contributor
Nov 6, 2012
2,622
7,466
Florida
Google Pixel 6 Pro
jeboo said:
What you need to do is bypass the verification checks in the stock kernel. If you look at the source, I believe they lie in /kernel/module.c (there may be some newer ones related to SELinux). To bypass them we need to use an exploit that allows for kernel memory overwriting. I believe the get/put_user exploit recently discovered *can* do that. Finding the addresses to patch in memory should be pretty trivial.
Click to expand...
Click to collapse

Ah never thought about using the same exploit to bypass verification. Have you been working towards this on the AT&T end?

Sent from my SCH-I545 using XDA Premium 4 mobile app
 
  • Like
Reactions: kalestew, Bait-Fish and JavaManRules-GS4
k1mu

k1mu

Senior Member
Apr 11, 2011
1,945
1,620
Virginia
jeboo said:
What you need to do is bypass the verification checks in the stock kernel. If you look at the source, I believe they lie in /kernel/module.c (there may be some newer ones related to SELinux). To bypass them we need to use an exploit that allows for kernel memory overwriting. I believe the get/put_user exploit recently discovered *can* do that. Finding the addresses to patch in memory should be pretty trivial.
Click to expand...
Click to collapse

That's what I'm looking at.
The kernel module loader (kernel/module.c) makes a Trust Zone call to verify the hash of any module that you try to load. The question that I'm hoping to answer is if there are any other checks done. The TIMA (Trust Zone-based Integrity Measurement Architecture) stuff checks the integrity of the kernel in real time, and shuts the device down if the kernel is found to be tampered with. The question that I'm hoping to answer is if we can slip a new module into the kernel without tripping the integrity check.
 
  • Like
Reactions: Bait-Fish
JLow0214

JLow0214

Senior Member
Sep 11, 2011
229
43
Google Pixel 4 XL
Google Pixel 7 Pro
k1mu said:
That's what I'm looking at.
The kernel module loader (kernel/module.c) makes a Trust Zone call to verify the hash of any module that you try to load. The question that I'm hoping to answer is if there are any other checks done. The TIMA (Trust Zone-based Integrity Measurement Architecture) stuff checks the integrity of the kernel in real time, and shuts the device down if the kernel is found to be tampered with. The question that I'm hoping to answer is if we can slip a new module into the kernel without tripping the integrity check.
Click to expand...
Click to collapse

Maybe we could just remove the lines that tell it to check and verify the kernel all together

Sent from my SCH-I545 using Xparent Skyblue Tapatalk 2
 
You must log in or register to reply here.

Similar threads

open1your1eyes0
  • Locked
[BOUNTY] New Root Method Exploit or Full Bootloader Unlock ***Updated Daily***
Replies
2K
Views
452K
KennyG123
KennyG123
invisiblek
[ROM][Official][4.3] CyanogenMod 10.2 for the Verizon Galaxy S4
Replies
3K
Views
542K
Ibuprophen
Ibuprophen
invisiblek
[ROM][Official][4.4.4] CyanogenMod 11.0 Nightlies for the Verizon Galaxy S4 (jflte)
Replies
4K
Views
399K
D
Deleted member 11818907
V
[HOWTO] Enable Hidden Menus for Verizon Galaxy S4
Replies
122
Views
413K
ryanallaire
ryanallaire
open1your1eyes0
[GUIDE] Root for Verizon Galaxy S4 ***VRUAME7 Build Only!***
Replies
650
Views
364K
P
pagerj

Top Liked Posts

24 Hours All time
  • There are no posts matching your filters.
  • 64
    Surge1223
    Surge1223
    Scroll down for recent updates;

    Has anyone ever heard more from h311sdr0id about his post (see here) to get more info about this "state" that allows you to flash MDK over ME7 in Odin? I'm curious to see if we can use that state, maybe in QDL mode to somehow either push an image to the phone or communicate with it using some methods/commands that E:V:A refers to on this page and a few pages after and before. It's also possible that we then might be able to use a modified unbrick.img (see here) to restore an MDK bootloader. So far those are the two ideas that I think have the best chance.

    Also in this thread I started with the intention of compiling the entire stock firmware for the Dev edition (OYUAMDK), I mentioned at the bottom that when flashing the stock MDK restore Odin tar on an ME7 phone users usually get a "SW REV. CHECK FAIL: FUSED: 3, Binary: 1" message meaning that your current fuse counter in aboot is set to 3 but the binary your attempting to flash is set to 1 so the flashing attempt will fail and I'm willing to bet if you're on VRUDMI1 and you attempt to flash the MDK restore you will get a similar message but the FUSED: value will be set to 4, you can see the counter upped in this post from jeboo here. However, with flashing the dev OYUAMDK aboot file on S4's with a ME7 bootloader users will receive a "SECURE CHECK FAIL: aboot" message instead, I don't know if we might be able to use dev OYUAMDK aboot file and bypass the fused counter entirely, since the dev edition has an unlocked bootloader and the fuse is an efuse, so software enforced, not a hardware enforced qfuse. If anyone wants to go into more detail, or wants to expand on these ideas we I can expand on this info or we can collaborate ideas in the Dev discussion thread.

    Other points to consider:

    • If you know how to use IDA pro, and can help with the base address of the binaries, that is probably our best bet to find a vulnerability in aboot, you can see jeboo and djrbliss discuss this a bit (here) and you can see Ralekdev show his findings here, also this gives the explanation of why you see the "custom unlock" boot screen that people constantly post about in the Q&A thread. Both of these threads along with djrbliss' blog discussing the S4 aboot vulnerability that lead to Loki (here), and exploiting the TrustZone (tz.mbn) on Moto's bootloaders (here) are good starting points in trying to find a new vulnerability.
    • If you know how to hexedit, then hexedit aboot.mbn from MDK, ME7, OYUAMDK, and MI1. You can see ME7 and MI1 are similar in both size and content, while MDK and OYUAMDK are more similar to each other in size and content. Obviously OYUAMDK differs from the others in the way it checks the recovery and boot partitions, (in djrbliss' blog on the S4 exploit he says "This bootloader differs between "locked" and "unlocked" variants of the Galaxy S4 in its enforcement of signature checks on the boot and recovery partitions.") but we are able to flash all bootloader partitions from the OYUAMDK firmware restore Odin file I made except aboot, so if you have any ideas on how we might be able to exploit any of that, please feel free to share.
    • If you do hexedit a dd'ed partition (if you copy mmcblk0p6 from your phone to your pc) you will see that its padded with zeroes at the end. You have to cut the padded zeros from the dd'ed image in order for the partition to be registered as a signed partition in Odin, etc. To do this, use Linux, open a terminal and type
      Code: 
      sudo apt-get install hexedit
      then enter your password and hit enter. Then go to the folder that contains the partitions you want to hexedit (for instance type cd /home/Your user name folder/Desktop/S4partitionbackups/" where "your user name folder" is whatever your username is and "S4partitionbackups" is a folder you create on your desktop containing a backup of your partitions) If you don't have a back up of your partitions you can create them using something like the command below, substituting mmcblk0p6 and aboot.mbn with the partition(s) you are interested in.
    Code: 
    adb shell su -c 'dd if=/dev/block/mmcblk0p6 of=/sdcard/backup/aboot.mbn'
    then
    Code: 
    adb pull /sdcard/backup/aboot.mbn /home/Your user name folder/Desktop/S4partitionbackups/
    then
    Code: 
    cd /home/Your user name folder/Desktop/S4partitionbackups/
    Code: 
    hexedit aboot.mbn
    Quick guide on Hexedit controls/keys

    • shift+> will take you to the end of the hex file
    • shift+< will take you to the beginning
    • page up/page down it will take you up a page and down a page respectively
    • ctrl+c you will exit the hex file without saving any changes
    • esc+t you will truncate the file at the current location
    • ctrl+x you will save the file with all changes you have done.
    This is an example of a padded aboot.mbn, before hexediting, and prior to truncating the file a at the first "0" in the string "00 01" found between the end of the actual file and the padded zero's and repeating F's
    View attachment 2353922
    This is an example of a properly signed aboot.mbn after hexediting
    View attachment 2353923

    How to find start addresses

    First you have to open the selected bootloader with a hex file editor and look at the header, converting for little endian you can find the start addresses and offsets

    Code: 
    [B]sbl1.mbn = 0x2a000000[/B]
00000000   D1 DC 4B 84  34 10 D7 73  15 00 00 00  FF FF FF FF  ..K.4..s........
00000010   FF FF FF FF  50 00 00 00  [COLOR=Red]00 00 00 2A[/COLOR]  40 72 01 00  ....P......*@r..
00000020   40 41 01 00  40 41 01 2A  00 01 00 00  40 42 01 2A  @A..@A.*....@B.*
00000030   00 30 00 00  01 00 00 00  04 00 00 00  FF FF FF FF  .0..............

[B] sbl2.mbn = 0x2e000000[/B]
00000000   16 00 00 00  03 00 00 00  00 00 00 00  [COLOR=Red]00 00 00 2E[/COLOR]  ................
00000010   40 51 02 00  40 20 02 00  40 20 02 2E  00 01 00 00  @Q..@ ..@ ......
00000020   40 21 02 2E  00 30 00 00  12 00 00 EA  5F 00 00 EA  @!...0......_...
00000030   62 00 00 EA  65 00 00 EA  68 00 00 EA  6B 00 00 EA  b...e...h...k...

[B] sbl3.mbn = 0x8ff00000[/B]
00000000   18 00 00 00  03 00 00 00  00 00 00 00  [COLOR=Red]00 00 F0 8F[/COLOR]  ................
00000010   20 20 04 00  20 EF 03 00  20 EF F3 8F  00 01 00 00    .. ... .......
00000020   20 F0 F3 8F  00 30 00 00  D3 F0 21 E3  D3 F0 21 E3   ....0....!...!.
00000030   00 70 A0 E1  09 02 A0 E3  00 D0 A0 E1  DB F0 21 E3  .p............!.

[B] aboot.mbn = 0x88e00000 offset = 0x285[/B]
00000000   05 00 00 00  03 00 00 00  00 00 00 00  [COLOR=Red]00 00 E0 88 [/COLOR] ................
00000010   10 56 14 00  10 25 14 00  10 25 F4 88  00 01 00 00  .V...%...%......
00000020   10 26 F4 88  00 30 00 00  06 00 00 EA  F0 38 00 EA  .&...0.......8..
00000030   F6 38 00 EA  FC 38 00 EA  02 39 00 EA  08 39 00 EA  .8...8...9...9..

[B] tz.mbn = 0x2a000000[/B]
00000000   19 00 00 00  03 00 00 00  00 00 00 00  [COLOR=Red]00 00 00 2A[/COLOR]  ...............*
00000010   C4 3A 03 00  C4 09 03 00  C4 09 03 2A  00 01 00 00  .:.........*....
00000020   C4 0A 03 2A  00 30 00 00  09 00 00 EA  90 F2 9F E5  ...*.0..........
00000030   90 F2 9F E5  90 F2 9F E5  90 F2 9F E5  84 F2 9F E5  ................

[B] rpm.mbn = 0x00020000[/B]
00000000   17 00 00 00  03 00 00 00  00 00 00 00 [COLOR=Red] 00 00 02 00[/COLOR]  ................
00000010   38 57 02 00  38 26 02 00  38 26 04 00  00 01 00 00  8W..8&..8&......
00000020   38 27 04 00  00 30 00 00  06 00 00 EA  1E 00 00 EA  8'...0..........
00000030   2C 00 00 EA  39 00 00 EA  46 00 00 EA  53 00 00 EA  ,...9...F...S...
    EDIT: 2/01/2014 - Updated OP to include where we're at

    2/01/2014

    1. Figuring out what Hellsdroid's method was - Unfortunately this seems unlikely as of now (figuring out what he did that is) On the other hand, @TMcGrath50 and I discussed a method we thought to be similar to his starting around here and then I learned how to use ida better as time went on and recently disassembled that I9505 S4 USB repair tool. I have not done a thorough analysis of the pseudocode yet though. But even so, this method has never been done before (as far as I know) and 
in addition to assuming the information in the pic below is true, and we can in fact reset the emmc on our devices with Secure Boot 3.0 (would this be a way of getting around having to reset the Secure Boot bit in the pbl to "0"?) I still think this idea needs to be refined a bit before its worth exploring because some questions remain in regards to if it would even work in the first place. For example, when a JTAG solution was tested previously, the VRUAMDK aboot.mbn didn't flash on a device with VRUAME7 after all the partitions were wrote over with VRUAMDK partitions via JTAG, why? @jeboo may be able to help answer that.

    Also, it was previously questioned whether or not the flash programmer (8064 hex) would need to be signed or not. As I have two S4's one thats working and one in QDL QHSUSB dload mode, in doing some recent testing through usb (S4 to S4) I was able to get some info back about my bricked S4, namely that I had sent it the wrong hex file ( see the last line here) because the dmesg and last_kmsg logs say something to the effect of "the the cpu clocks cannot start because its configured for the wrong device" and the last line from the my pastebin post says "8660" among other things as well.

    Status - Unknown - More Research Required


    pCgmFhal.png


    2. Using a Developer edition S4 to unlock a retail S4 - So here's what we know, the dev kernel (boot.img) is flashable and will work with retail S4's, but the recovery.img and aboot will not. Flashing the dev recovery.img will succeed in Odin/Heimdall, but if you try to boot into recovery it will inform you that your device is "tampered" and and will void your warranty by setting the Knox warranty bit to 0x1. Before I discuss why aboot.mbn wont flash consider this; neither the Developer edition of the GS4 nor the Developer edition of the Note 3 has every received an OTA or a factory Odin tar. This is not by random chance. Every Developer edition owner has a unique MD5 for their aboot. If you couple this with the fact that Dev edition devices have retail stickers under their dev stickers, you will probably come to the conclusion that Samsung/Verizon/AT&T haven't released updates to dev devices because they would have to do it on a 'per device' basis, that or risk handing us a method to convert retail devices into developer edition devices. If the method by which Samsung uses device specific info to sign developer edition aboot partitions were discovered this may work, or if their method to determine if a device is a developer edition or consumer retail edition is similar to what Dan R (djrbliss) took advantage of then this could be a possibility.
    3,4,5,6, coming up....updating...this will be a long post...advance warning.

    Status - Possibly - More Research Required
    View
    47
    Surge1223
    Surge1223
    Happy one year anniversary. I can't believe I wrote the OP one year ago today, I've learned so much since then, in fact im embarrassed to read the OP because reading it now I realize I didnt know much back when this thread started however ive learned a lot since then and thats mostly due to the contributions made in this thread and the people I have met here, so I just wanted to take a moment and say Thanks. :)

    #stillfightin
    View
    37
    Surge1223
    Surge1223
    RuggedHunter said:
    Any answer would just be a guess. My guess is ryanbg is feeling lonely on this project now...my hunch is that surge has moved on but the unsolved problem will bug him until it's solved, so his foot's in the door still... just a guess, I don't know either one personally. I think either one of them or any other dev is likely working on newer bootloaders... so maybe there's more effort on nc5 right now than on <mk2. Then again maybe a vulnerability is discovered for one of the older bootloaders and was patched in the newer ones.

    I'm sticking on mk2. My favorite ROM works best with the version for that bootloader, and if an unlock for a newer bootloader is ever available, I'll just upgrade at that point.
    Click to expand...
    Click to collapse

    Not moved on... just been busy and didn't have anything useful to contribute..until today anyways.

    I finally was able to re-patch the live kernel to allow insecure modules again. Meaning kexec and trustzone vulnerabilities are back on the table.

    The method I used to evoke the patch to the kernel is somewhat involved so I'll release it as a small apk or binary soon. For the time being this only effects vzw users, since I didn't check the att kernel.
    View
    36
    Surge1223
    Surge1223
    Cripes, we used to self-police well enough in here, lately thats not the case. Lets get our crap together before we lose this thread. Everyone here is smart enough to know if their post is useful or not, grow up people. We're giving this all the we've got, be patient. Other devs and I are in constant communication, not by pm but mostly through other means. Listen I know some of you may be frustrated with my lack of posting new info but just know that there are watching eyes on this thread that we don't want. Take the OYUAMDK thread I posted in original development, Samsung knows about that thread and I know that for a fact. I went to Best Buy and asked a Samsung rep (in the Samsung dept/area) how dev edition devices could get updates and the guy had no idea who I was but I started talking to him and he casually got more friendly and told me "Hey listen, I know theres no official dev stock images but check the XDA threads" then told me exactly where to check and said Samsung doesn't officially give dev device updates but knows they can be made/extracted, he said "someone already extracted it for the S4" so he essentially directed me to my own thread without knowing who I was. So theres a reason some stuff isn't posted here, please understand that. Also some of you are worried since there are no updates on kexec, I can confirm its being worked on.


    TLDR - Hold your horses

    Edit: Also we're working on some stuff today, I'll post an update tonight.
    View
    36
    Surge1223
    Surge1223
    Ok that's it. Its become apparent to me that far too many people are under the impression that the "bootloader" is a single entity, and that it is just too complex to understand. This is unacceptable to me. I had no idea what a bootloader was before I got this S4. Im going to detail the process first with a general overview, then again in more detail. Plus I dont see the current threads on this topic that include all we know, like the hexagon modem/kernel and the function of the tz and sbl2 are way over generalized. And discussion of the device cookie is completely missing. Ill post it in a new thread thread and link it here when im done.

    Sent from my SCH-I545 using XDA Premium 4 mobile app
    View

New posts