[EXPLOIT][HOW-TO] BypassLKM: bypass module signature verification on TW 4.3

Search This thread
By:
Advanced…
DeadlySin9

DeadlySin9

Senior Member
Sep 2, 2012
1,475
703
Google Pixel 8 Pro
numbR7 said:
Sorry, I posted this earlier in the i9505 SHOstock-i v5.0b4 thread:

"This may be the most embarrassing question to date--but here goes. If the SHOstock-i 4.4.2 ported ROM above does not require the 4.4 bootloader and the kernal has been z-patched (fooling the MK2 bootloader) could this be a way to get a KK ROM--using SafeStrap--on the MK2 locked device?

EDIT: meant exploit BypassLKM"

I meant to post here and I meant to say your exploit BypassLKM NOT z-patched and refer over to the SHOstock ROM. I think I understand I was mixing apples and oranges. I hope it makes a tad more sense now. Anyway, I'm trying to understand the new practical options this brings to the SS locked BL user. Since you can load a different kernel in memory (the new option I can see), does that mean I could load a none TW 4.3 ROM in a slot? Are you pretty much "locked" into the 4.3 TW stuff? I believe--if this is possible--that it would be a one-off--when I changed slots--to be re-applied but would do the job? I've been cruising along flashing with a custom recovery for awhile--recently, my S4 was damaged and with the replacement I ended up in the fun new hard locked bootloader world. I will get the hang of it. I fully understand that there must be valid question in order to get and answer. I hope this is closer to the mark. Thanks...
Click to expand...
Click to collapse

This does not load a different kernel. This allows the loading of modules to the current kernel. Hashcode, the developer behind safestrap, has been working on using this on order to implement the loading of a kexec module - a module that would load a kernel over the stock kernel. If that works, then yes, non TW ROMs will be an option. For now, it's not happening though. If it were a simple process then it would have been done already.
 
  • Like
Reactions: JavaManRules-GS4, karate104, Thr33-F0ur and 2 others
numbR7

numbR7

Senior Member
Dec 1, 2011
173
73
via lactea
DeadlySin9 said:
This does not load a different kernel. This allows the loading of modules to the current kernel. Hashcode, the developer behind safestrap, has been working on using this on order to implemtheihe loading of a kexec module - a module that would load a kernel over the stock kernel. If this works, then yes, non TW ROMs will be an option. For now, it's not happening though. If it were a simple process then it would have been done already.
Click to expand...
Click to collapse

Thanks. Apparently I need to study this a little more. I need to understand the term "module" like the jfltatt-MK2-modules.zip that needs to be flashed on many of the SS ROMs. Are they the same type modules? Is thier mode and function the same? What is the goal--the pratical result? Any way, the question is--can you provide a link to some reading on this?

Thanks again...
 
DeadlySin9

DeadlySin9

Senior Member
Sep 2, 2012
1,475
703
Google Pixel 8 Pro
numbR7 said:
Thanks. Apparently I need to study this a little more. I need to understand the term "module" like the jfltatt-MK2-modules.zip that needs to be flashed on many of the SS ROMs. Are they the same type modules? Is thier mode and function the same? What is the goal--the pratical result? Any way, the question is--can you provide a link to some reading on this?

Thanks again...
Click to expand...
Click to collapse

I can't link you to any specific readings, I've just googled a few things like kexec and modules and such.

AFAIK kexec is a module just like those in the zip. They hook in to the kernel to provide some functionality (like wifi in the case of the zip). Our kernel checks the modules to make sure they're signed before using them. This exploit allows us to get around that signing however. Different modules have different functions to allow the phone different functions. It's like adding sections to a machine that let it do other different tasks along with previous ones. The goal in the case of kexec is to enable a function to boot another kernel over the current kernel. If implemented to Safestrap, it will be the next best thing to an exploit, as it will basically give us back custom kernels.

Sent from Black<3's I337 running Foxhound ROM
 
  • Like
Reactions: karate104, hankbizzo5 and numbR7
numbR7

numbR7

Senior Member
Dec 1, 2011
173
73
via lactea
DeadlySin9 said:
I can't link you to any specific readings, I've just googled a few things like kexec and modules and such.

AFAIK kexec is a module just like those in the zip. They hook in to the kernel to provide some functionality (like wifi in the case of the zip). Our kernel checks the modules to make sure they're signed before using them. This exploit allows us to get around that signing however. Different modules have different functions to allow the phone different functions. It's like adding sections to a machine that let it do other different tasks along with previous ones. The goal in the case of kexec is to enable a function to boot another kernel over the current kernel. If implemented to Safestrap, it will be the next best thing to an exploit, as it will basically give us back custom kernels.

Sent from Black<3's I337 running Foxhound ROM
Click to expand...
Click to collapse

Thanks a lot. You provided a ton of info. That's great start for me! Nice succinct lesson.
 
T

the_mentor

Senior Member
Jul 11, 2010
224
59
Would this exploit work on a galaxy s3?

I know this might be the wrong place to ask and I'm sorry if it is.
but do you think the exploit described above would also work with a verizon galaxy s3 on 4.3 ?

Thanks.
 
  • Like
Reactions: areallydumbperson
Surge1223

Surge1223

Recognized Contributor
Nov 6, 2012
2,622
7,466
Florida
Google Pixel 6 Pro
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.

After checking your kernel source you can create or compile modules from the source direcctory. You should probably know how to compile kernels before continuing but here are a couple things you should do anyways. In terminal emulator or with adb shell type:

user@jfltevzw:/ $ su
root@jfltevzw:/ # mount -o remount, rw /system
root@jfltevzw:/ # echo 1 > /proc/sys/kernel/kptr_restrict
root@jfltevzw:/ # echo 1 > /proc/sys/kernel/dmesg_restrict
root@jfltevzw:/ # cat /proc/kallsyms >/sdcard/kallsyms
Click to expand...
Click to collapse

Next, compile your kernel from source with its defconfig. After you have successfully compiled the kernel change the .config file to allow module loading and compile a module.

Or if compiling is not for you then just to test compile a module using memory data from the kallsyms file you made earlier if the source for the module requires it. And adb push-it to /data/local/tmp. Next:

user@jfltevzw:/ $ su
root@jfltevzw:/ # mount -o remount, rw /system
root@jfltevzw:/ # cd /data/local/tmp
root@jfltevzw:/data/local/tmp # chmod 755 your_module.ko
root@jfltevzw:/data/local/tmp # ./bypasslkm
root@jfltevzw:/data/local/tmp # insmod
root@jfltevzw:/data/local/tmp # dmesg |grep TIMA
Click to expand...
Click to collapse

Then youd have to follow the directions jeboo gives in the OP and patch compile bypasslkm making sure to change all address and settings to comply with the s3.
 
Last edited:
  • Like
Reactions: Brooklynsour and jeboo
WordsworthESP

WordsworthESP

Senior Member
Jul 23, 2012
804
471
Macon
This isn't ready, so no... it won't help. As stated, this thread is for devs to post. If they ever get it working, we'll know about it.

Sent from my Hyperdriven S4
 
M

martinasa

Member
Jul 28, 2007
39
7
jeboo said:
I got this idea after reading about CVE-2013-6282 and seeing the source for it.

As we all know, anyone with MF3+ bootloaders on ATT/VZW cannot load custom kernels/recoveries. Hashcode saved the day with Safestrap, which allowed users to run custom ROMs using stock, signed boot.imgs (initramfs/kernel). Unfortunately booting a custom kernel is still not possible due to BL restrictions.

With this latest root exploit, it is possible to overwrite kernel memory and thus remove some of the restrictions of the stock kernel. Most important is the ability to insert kernel modules not signed by Samsung, specifically kexec. This module can allow one to load any custom kernel regardless of BL restrictions. Before you ask, I have never compiled nor worked with kexec!

I'm going to go over the process just for completeness, you can skip this section if you want. It's mostly for devs:

With 4.3, when you insert one of the included modules (ie, /system/lib/modules), you will see the following in dmesg:
Code: 
<4>[ 2003.009063] TIMA: lkmauth--launch the tzapp to check kernel module; module len is 3224
<4>[ 2003.009124] TIMA: lkmauth -- hdr before kreq is : e3003000
<4>[ 2003.009155] TIMA: lkmauth--send cmd (tima_lkm) cmdlen(304:320), rsplen(264:320) id 0x00050000, req (0xE511C000), rsp(0xE511C140), module_start_addr(0xE3003000) module_len 3224
<4>[ 2003.012237] TIMA: lkmauth--verification succeeded.
Though I'm not intimately familiar with the workings of lkmauth, it's obvious it's querying the trustzone (TZ) to verify the module. If we now change one insignificant byte in the module, you get:
Code: 
<4>[ 2301.298980] TIMA: lkmauth--launch the tzapp to check kernel module; module len is 3224
<4>[ 2301.299011] TIMA: lkmauth -- hdr before kreq is : e300c000
<4>[ 2301.299041] TIMA: lkmauth--send cmd (tima_lkm) cmdlen(304:320), rsplen(264:320) id 0x00050000, req (0xE511C000), rsp(0xE511C140), module_start_addr(0xE300C000) module_len 3224
<3>[ 2301.301391] TIMA: lkmauth--verification failed -1
<4>[ 2301.301544] TIMA: MSG=lkm_modified; result (TIMA_RESULT=MSG=lkm_modified;)

We can use these messages to narrow down the code in the kernel. I'm using ATT MK2 as the example here:
kernel/module.c
Code: 
/* parse result */
        if (krsp->ret == 0) {
                pr_warn("TIMA: lkmauth--[B]verification succeeded[/B].\n");
                ret = 0; /* ret should already be 0 before the assignment. */
        } else {

                pr_err("TIMA: lkmauth--[B]verification failed[/B] %d\n", krsp->ret);
                ret = -1;
....

If we unpack boot.img, then decompress the zImage, we can find this code in the binary. Fire up IDA and set the base address to 0xC0008000. You should be able to resolve the above string reference to:
Code: 
ROM:C00B9C20 44 11 98 E5                 LDR             R1, [R8,#0x144]
ROM:C00B9C24 00 00 51 E3                 CMP             R1, #0
[B][COLOR="Red"]ROM:C00B9C28 02 00 00 1A                 BNE             loc_C00B9C38[/COLOR][/B]
ROM:C00B9C2C 54 01 9F E5                 LDR             R0, =a4TimaLkmauthVe ; "<4>TIMA: lkmauth--verification succeede"...
ROM:C00B9C30 CA 57 1D EB                 BL              sub_C080FB60
ROM:C00B9C34 3C 00 00 EA                 B               loc_C00B9D2C

That BNE is the target for our patch. So bypasslkm will basically overwrite that test with a NOP instruction thus forcing the authentication to succeed.

I tested inserting a modified stock module and one I compiled. Btw, if you wanna use the modules from the kernel source tree, be sure to add
-fno-pic to CFLAGS_MODULE in the Makefile.


-------------------------------------------------------------------------------------------------------------
Usage:

bypasslkm is run alone, and patches the kernel in memory. It does NOT make any changes to the filesystem, and a reboot will require re-executing the patch. Please note the patch will remain in memory until you run 'bypasslkm -r' OR reboot. THIS CAN LEAVE YOUR OS IN A VULNERABLE STATE TO MALWARE. Ideally, you would run the patch, insert your module, then run the patch with -r.

Typical usage:
adb push bypasslkm /data/local/tmp

cd /data/local/tmp
chmod 755 bypasslkm
./bypasslkm
insmod <modulename.ko>
./bypasslkm -r

Supported stock kernels: ATT MK2, VZW MK2, VZW MJ7

CREDITS
fi01 - awesome source for the CVE!
CUBE - getroot source!
djrbliss - thanks for the makefile =P

DOWNLOAD:
Get the latest from my git: https://github.com/jeboo/bypasslkm
Click to expand...
Click to collapse





I have question where i have to put this commands ?
ON CMD or some program, cuz now i have i337 Rooted 4.3 with baseband 4.4.2 and the Wifi doesnet work.

Thanks !!!
 
Bleedin_Sarge

Bleedin_Sarge

Member
Dec 21, 2013
48
6
unxthallows.com
I am trying to play around with kexec, and dont mind having to odin stock ML2 if something blows chunks all over the system.

Can this be used against either MF3 or ML2. If it could be used against MF3, Its possible to boot 4.3 with the MF3 kernel, I think thats how I used saferoot to root 4.3.

So one could downgrade their kernel to MF3 and run this against the kernel to load kexec_load.ko in, and then work on kexec itself.

For those reading this: do not try this, I am only asking for information.

:) Sent from my sgh-i537 that thinks it is an i337 :)
 
DeadlySin9

DeadlySin9

Senior Member
Sep 2, 2012
1,475
703
Google Pixel 8 Pro
Bleedin_Sarge said:
I am trying to play around with kexec, and dont mind having to odin stock ML2 if something blows chunks all over the system.

Can this be used against either MF3 or ML2. If it could be used against MF3, Its possible to boot 4.3 with the MF3 kernel, I think thats how I used saferoot to root 4.3.

So one could downgrade their kernel to MF3 and run this against the kernel to load kexec_load.ko in, and then work on kexec itself.

For those reading this: do not try this, I am only asking for information.

:) Sent from my sgh-i537 that thinks it is an i337 :)
Click to expand...
Click to collapse

This only works on MK2 kernel, not MF3. If kexec were developed it wouldn't matter what kernel it's loaded on since we'd load another over it.
 
Bleedin_Sarge

Bleedin_Sarge

Member
Dec 21, 2013
48
6
unxthallows.com
DeadlySin9 said:
This only works on MK2 kernel, not MF3. If kexec were developed it wouldn't matter what kernel it's loaded on since we'd load another over it.
Click to expand...
Click to collapse

How hard would it be to build BypassLKM against MF3? Or is it out of the question? I am willing to do a little learning and some trial and error, now that I have another phone on the way.

:) Sent from my sgh-i537 that thinks it is an i337 :)
 
DeadlySin9

DeadlySin9

Senior Member
Sep 2, 2012
1,475
703
Google Pixel 8 Pro
Bleedin_Sarge said:
How hard would it be to build BypassLKM against MF3? Or is it out of the question? I am willing to do a little learning and some trial and error, now that I have another phone on the way.

:) Sent from my sgh-i537 that thinks it is an i337 :)
Click to expand...
Click to collapse

You'll have to look at the process stated in the OP to get the exploit and see if you can recreate those steps on MF3 I believe. Also, I believe you might need to find a method to write to the kernel memory to execute it.
 
Bleedin_Sarge

Bleedin_Sarge

Member
Dec 21, 2013
48
6
unxthallows.com
DeadlySin9 said:
You'll have to look at the process stated in the OP to get the exploit and see if you can recreate those steps on MF3 I believe. Also, I believe you might need to find a method to write to the kernel memory to execute it.
Click to expand...
Click to collapse

I was able to run the bypasslkm binary on MF3, and it said it was patched. But loading a module built for another 3.4.0 phone fails with LKMauth error.
 
jeboo

jeboo

Recognized Developer
Apr 2, 2010
817
4,059
Bleedin_Sarge said:
I was able to run the bypasslkm binary on MF3, and it said it was patched. But loading a module built for another 3.4.0 phone fails with LKMauth error.
Click to expand...
Click to collapse

The MF3 kernel is vulnerable, but the patch address would have to be changed in bypasslkm.c and recompiled. I figured most people on MF3 have since upgraded to MK2. They're both vulnerable, rootable, etc..
 
1

1nstak1ll

New member
Feb 27, 2016
3
0
Dead thread

Hate to revive an old thread, but this interests me. I know this is for Jellybean, but is there an updates for it? I'd be willing to help unlock the bootloader of my i537, and whoever wants to do this can get the 1k bounty..
 
H

hubh98

Member
Dec 17, 2008
29
7
Can any senior help me compile a bypasslkm for sprint sph-l720T MK5? I have attached the boot.img.

It is only for ATT and vzw now.

Thank you a lot.
 

Attachments

  • boot_L720T_MK5.img
    8 MB · Views: 96
You must log in or register to reply here.

Similar threads

iB4STiD
|ROM|★GOLDENEYE★|►XXUHOD7 LOLLiPOP TW◄|5.1.15|★
Replies
18K
Views
2M
S
SilkRoadDog
shoman94
[RoM]&[KERNEL]&[RECOVERY][I337UCUAMK2-4.3-JB][SHOstock v3.1] [01/13/14]
Replies
2K
Views
306K
I
iamtheug
upndwn4par
  • Locked
|ROM| Graviton S4 v3.2 ★|★ TW 4.4.2 ★|★ Loki & SafeStrap |17 Sep 2014 | Final |
Replies
2K
Views
217K
stangdriver44
stangdriver44
Danvdh
[ROM]【4.4.4】Google Play Edition【JFLTE-GPE】 - Oct 5th, 2018
Replies
6K
Views
872K
Danvdh
Danvdh
Venom0642
  • Locked
[ROM]Deadly Venom v2.2.6 FINAL KitKat 4.4.2 SG5 MOD|AT&T|I9505[XXUGNH8][9/15/14]
Replies
3K
Views
205K
Venom0642
Venom0642

Top Liked Posts

24 Hours All time
  • There are no posts matching your filters.
  • 60
    jeboo
    jeboo
    I got this idea after reading about CVE-2013-6282 and seeing the source for it.

    As we all know, anyone with MF3+ bootloaders on ATT/VZW cannot load custom kernels/recoveries. Hashcode saved the day with Safestrap, which allowed users to run custom ROMs using stock, signed boot.imgs (initramfs/kernel). Unfortunately booting a custom kernel is still not possible due to BL restrictions.

    With this latest root exploit, it is possible to overwrite kernel memory and thus remove some of the restrictions of the stock kernel. Most important is the ability to insert kernel modules not signed by Samsung, specifically kexec. This module can allow one to load any custom kernel regardless of BL restrictions. Before you ask, I have never compiled nor worked with kexec!

    I'm going to go over the process just for completeness, you can skip this section if you want. It's mostly for devs:

    With 4.3, when you insert one of the included modules (ie, /system/lib/modules), you will see the following in dmesg:
    Code: 
    <4>[ 2003.009063] TIMA: lkmauth--launch the tzapp to check kernel module; module len is 3224
<4>[ 2003.009124] TIMA: lkmauth -- hdr before kreq is : e3003000
<4>[ 2003.009155] TIMA: lkmauth--send cmd (tima_lkm) cmdlen(304:320), rsplen(264:320) id 0x00050000, req (0xE511C000), rsp(0xE511C140), module_start_addr(0xE3003000) module_len 3224
<4>[ 2003.012237] TIMA: lkmauth--verification succeeded.
    Though I'm not intimately familiar with the workings of lkmauth, it's obvious it's querying the trustzone (TZ) to verify the module. If we now change one insignificant byte in the module, you get:
    Code: 
    <4>[ 2301.298980] TIMA: lkmauth--launch the tzapp to check kernel module; module len is 3224
<4>[ 2301.299011] TIMA: lkmauth -- hdr before kreq is : e300c000
<4>[ 2301.299041] TIMA: lkmauth--send cmd (tima_lkm) cmdlen(304:320), rsplen(264:320) id 0x00050000, req (0xE511C000), rsp(0xE511C140), module_start_addr(0xE300C000) module_len 3224
<3>[ 2301.301391] TIMA: lkmauth--verification failed -1
<4>[ 2301.301544] TIMA: MSG=lkm_modified; result (TIMA_RESULT=MSG=lkm_modified;)

    We can use these messages to narrow down the code in the kernel. I'm using ATT MK2 as the example here:
    kernel/module.c
    Code: 
    /* parse result */
        if (krsp->ret == 0) {
                pr_warn("TIMA: lkmauth--[B]verification succeeded[/B].\n");
                ret = 0; /* ret should already be 0 before the assignment. */
        } else {

                pr_err("TIMA: lkmauth--[B]verification failed[/B] %d\n", krsp->ret);
                ret = -1;
....

    If we unpack boot.img, then decompress the zImage, we can find this code in the binary. Fire up IDA and set the base address to 0xC0008000. You should be able to resolve the above string reference to:
    Code: 
    ROM:C00B9C20 44 11 98 E5                 LDR             R1, [R8,#0x144]
ROM:C00B9C24 00 00 51 E3                 CMP             R1, #0
[B][COLOR="Red"]ROM:C00B9C28 02 00 00 1A                 BNE             loc_C00B9C38[/COLOR][/B]
ROM:C00B9C2C 54 01 9F E5                 LDR             R0, =a4TimaLkmauthVe ; "<4>TIMA: lkmauth--verification succeede"...
ROM:C00B9C30 CA 57 1D EB                 BL              sub_C080FB60
ROM:C00B9C34 3C 00 00 EA                 B               loc_C00B9D2C

    That BNE is the target for our patch. So bypasslkm will basically overwrite that test with a NOP instruction thus forcing the authentication to succeed.

    I tested inserting a modified stock module and one I compiled. Btw, if you wanna use the modules from the kernel source tree, be sure to add
    -fno-pic to CFLAGS_MODULE in the Makefile.


    -------------------------------------------------------------------------------------------------------------
    Usage:

    bypasslkm is run alone, and patches the kernel in memory. It does NOT make any changes to the filesystem, and a reboot will require re-executing the patch. Please note the patch will remain in memory until you run 'bypasslkm -r' OR reboot. THIS CAN LEAVE YOUR OS IN A VULNERABLE STATE TO MALWARE. Ideally, you would run the patch, insert your module, then run the patch with -r.

    Typical usage:
    adb push bypasslkm /data/local/tmp

    cd /data/local/tmp
    chmod 755 bypasslkm
    ./bypasslkm
    insmod <modulename.ko>
    ./bypasslkm -r

    Supported stock kernels: ATT MK2, VZW MK2, VZW MJ7

    CREDITS
    fi01 - awesome source for the CVE!
    CUBE - getroot source!
    djrbliss - thanks for the makefile =P

    DOWNLOAD:
    Get the latest from my git: https://github.com/jeboo/bypasslkm
    View
    39
    Hashcode
    Hashcode
    Hello @jeboo and community,

    I deciding to open this up a bit and at least give everyone an update on where I'm at with the kexec process on the S4.

    These instructions are based on my test device: JFLTEVZW running MJ7. The future is: if we get this working, I'll update and rebase against the MK# kernel sources as well as have other testers on other devices.

    Current bootlog of the kexec attempt:
    Code: 
    [    3.806488] Running Safestrap hijack
[    4.306549] [mdnie lite] is negative Mode On = 0
[    4.306549] [mdnie lite] negative off when resume, tuning again!
[    4.306549] [mdnie lite] mDNIe_Set_Mode start , mode(0), background(1)
[    4.306549] [mdnie lite]  = UI MODE =
[    4.306579] [mdnie lite]  = STANDARD MODE =
[    4.306579] [mdnie lite]  send tuning cmd!!
[    4.339782] [mdnie lite] mDNIe_Set_Mode end , mode(0), background(1)
[    5.489624] [TouchKey]press=1, code=0
[    5.666046] [TouchKey]press=0, code=0
[    8.833953] Running bypasslkm jfltevzw JSS15J.I545VRUEMJ7
[    8.837127] 
[    8.837127] BypassLKM patch by Jeboo
[    8.837127] usage: -r will restore kernel to original
[    8.837127] Big thanks to fi01 & CUBE for their awesome CVE-2013-6282 exploit source!
[    8.837127] 
[    8.837127] Found devicename=jfltevzw
[    8.837158] Found buildid=JSS15J.I545VRUEMJ7
[    8.837158] 
[    8.837158] Patching kernel @ 0xC00C9D58: Done.
[   10.396148] pid 1's current affinity list: 0-3
[   10.396148] pid 1's new affinity list: 0
[   11.244873] synaptics_rmi4_i2c 3-0020: synaptics_ta_cb: device is in suspend state or reflash.
[   11.422241] init: /init.rc: 75: invalid command 'powerctl'
[   11.424194] init: cannot find '/sbin/healthd', disabling 'healthd'
[   11.425720] init: invalid uid 'fm_radio'
[   11.425964] init: invalid uid 'fm_radio'
[   11.663604] power_supply sec-fuelgauge: driver failed to report `status' property: 4294967274
[   11.667419] power_supply sec-charger: driver failed to report `power_now' property: 4294967274
[   11.688232] init: Unable to open persistent property directory /data/property errno: 2
[   11.688751] init: untracked pid 163 exited
[   11.688873] init: untracked pid 164 exited
[   11.688964] init: untracked pid 268 exited
[   12.436737] [mdnie lite] is negative Mode On = 0
[   12.437072] [mdnie lite] negative off when resume, tuning again!
[   12.437286] [mdnie lite] mDNIe_Set_Mode start , mode(0), background(1)
[   12.437622] [mdnie lite]  = UI MODE =
[   12.437805] [mdnie lite]  = STANDARD MODE =
[   12.438140] [mdnie lite]  send tuning cmd!!
[   12.486511] [mdnie lite] mDNIe_Set_Mode end , mode(0), background(1)
[   40.014373] [TouchKey]press=1, code=1
[   40.093597] [TouchKey]press=0, code=1
[   81.530334] kexec: KEXEC_IOC_LOAD
[   83.554534] kexec: KEXEC_IOC_CHECK_LOADED (1)
[   83.556427] kexec: KEXEC_IOC_REBOOT
[   83.556640] KEXEC: preempt_disable
[   83.556823] KEXEC: disable interrupts
[   83.557159] KEXEC: kernel_restart_prepare_ptr
[   83.557342] set_dload_mode <0> ( c007b340 )
[   83.557708] (sec_debug_set_upload_magic) 0
[   83.565917] BUG: scheduling while atomic: kexec/511/0x00000003
[   83.568267] BUG: scheduling while atomic: kexec/511/0x00000003
[   83.600341] BUG: scheduling while atomic: kexec/511/0x00000003
[   83.619934] BUG: scheduling while atomic: kexec/511/0x00000003
[   83.639984] BUG: scheduling while atomic: kexec/511/0x00000003
[   83.660186] BUG: scheduling while atomic: kexec/511/0x00000003
[   83.679931] BUG: scheduling while atomic: kexec/511/0x00000003
[   83.699951] BUG: scheduling while atomic: kexec/511/0x00000003
[   83.719909] BUG: scheduling while atomic: kexec/511/0x00000003
[   83.739898] BUG: scheduling while atomic: kexec/511/0x00000003
[   83.759979] BUG: scheduling while atomic: kexec/511/0x00000003
[   83.760650] BUG: scheduling while atomic: kexec/511/0x00000003
[   83.779907] BUG: scheduling while atomic: kexec/511/0x00000003
[   83.830535] BUG: scheduling while atomic: kexec/511/0x00000003
[   83.830596] qup_i2c qup_i2c.2: QUP: I2C status flags :0x1300c8, irq:228
[   83.879791] qup_i2c qup_i2c.2: I2C slave addr:0x26 not connected
[   83.879974] BUG: scheduling while atomic: kexec/511/0x00000003
[   83.899810] BUG: scheduling while atomic: kexec/511/0x00000003
[   83.901123] BUG: scheduling while atomic: kexec/511/0x00000003
[   83.903015] mdm_power_down_common: MDM2AP_STATUS went low successfully.
[   83.903320] KEXEC: machine_shutdown
[   83.903930] MKEXEC: found gic_raise_softirq: c002c590
[   83.903961] MKEXEC: waiting for CPUs ...(1000000)
[   83.904083] KEXEC: machine_kexec
[   83.904113] MKEXEC: va: dd7a9000
[   83.904174] MKEXEC: pa: 9eba9000
[   83.904235] MKEXEC: kexec_start_address: 80208000
[   83.904327] MKEXEC: kexec_indirection_page: 9ebab000
[   83.904388] MKEXEC: kexec_mach_type: 00000f6d
[   83.904479] MKEXEC: kexec_boot_atags: 80201000
[   83.904541] MKEXEC: copy relocate code: addr=0xdd7a9000, len==164
[   83.904632] MKEXEC: flush_icache_range
[   83.904693] MKEXEC: kexec_reinit
[   83.904754] MKEXEC: soft_restart
[   83.904815] MKEXEC: outer_flush_all
[   83.904907] MKEXEC: outer_disable
[   83.904968] MKEXEC: kexec_identity_mapping_add
[   83.905181] MKEXEC: end mappings end==0xbf000000: 0xbf000000
[   83.905273] MKEXEC: kexec_setup_mm_for_reboot
[   83.905944] MKEXEC: kexec_call_with_stack (kexec_call_with_stack=0xbf004578, __soft_reset=0xbf00400c, addr=0x9eba9000, stack=0xbf004db8)

    And then it just hangs there. (I've disabled the msm_watchdog so that I have all the time I need to jump kernels without it triggering a reboot.)
    I'm obviously not killing off mmu correctly or leaving something up which is hanging the process inside the kernel remapping code.

    The kernel/kernel modules git I'm working from:
    https://github.com/Hashcode/android_kernel_samsung-jf-common

    I have a set of working files for the JFLTEVZW MJ7 release in the "build" dir.

    To build the kexec binary:
    check out: https://github.com/Hashcode/kexec-tools (master branch)

    To build the kexec modules:
    check out: https://github.com/Hashcode/android_kernel_samsung-jf-common

    Code: 
    cd <kernel git location>
export PATH=$PATH:~/android/<your android basedir>/prebuilts/gcc/linux-x86/arm/arm-eabi-4.6/bin
export JAVA_HOME=/usr/lib/jvm/java-6-sun
export CROSS_COMPILE=arm-eabi-
export KERNEL_DIR=`pwd`
export KERNELDIR=$KERNEL_DIR
make ARCH=arm VARIANT_DEFCONFIG=jf_vzw_defconfig SELINUX_DEFCONFIG=jfselinux_defconfig SELINUX_LOG_DEFCONFIG=jfselinux_log_defconfig jf_defconfig
make -j8 ARCH=arm zImage
make -j8 ARCH=arm modules

    Currently, I'm using the stock boot.img split back into zImage and ramdisk.gz for kexec testing.

    I have a special version of Safestrap 3.71 which includes the bypass code so that modules can be loaded in recovery:
    JFLTEVZW: http://hosting.crackflasher.com/get...rap/Safestrap-JFLTEVZW-3.71-KEXEC-TESTING.apk
    JFLTEATT: @jeboo if you want, I'll run a build for you in a bit

    (Note: there is NOTHING special about this Safestrap other than:
    1. It loads the module bypass prior to entering recovery
    2. It mounts /firmware so that when insmod is used the tz firmware can be found by the kernel
    -- no need for the every day user to "try it out")

    Here's my testing process (after installing the "special" version of Safestrap above):
    Once I'm in recovery, I run the following commands via PC:
    Code: 
    # push kexec binary, kexec modules, zImage, recovery.gz and 2 scripts to /datamedia/local/tmp
adb push <kerneldir>build /datamedia/local/tmp
# run the "push.sh" script which copies the files to the rootfs and sets perms
adb shell "/datamedia/local/tmp/push.sh"
# run the "setup.sh" script which unmounts the 
adb shell "/setup.sh"

    Eventually the screen will either fade to white or black and the device is not responsive.
    Unplug USB
    Hold power button while quickly sliding the contact of the battery out and back in.

    On the reset: re-enter safestrap recovery and you'll have a /proc/last_kmsg to look at (similar to the above).

    NEXT STEPS:
    The goal would be to find a small bit of machine code that I can execute directly inside the kernel remapping code that is insignificant but will show a "sign of life".. Such items are writing to the serial port (which I'm currently trying to work out), setting off a vibrator pulse, etc).
    View
    30
    Hashcode
    Hashcode
    Thank you @jeboo. I'll see what I can do with this :)

    Sent from my XT926 using Tapatalk
    View
    29
    jeboo
    jeboo
    z-patch

    Well, I'm back again with another essay on removing the annoying module authentication that Sammy uses across the S4 phones. This tutorial will focus on those phones with either loki-vulnerable BLs (MDB, MDL, etc) or unlocked BLs (i9505).

    It seems with the last few releases, Sammy has started tying the kernel modules to the BLs, instituting a TZ-based authentication system. We will focus on bypassing this "protection" by modifying the kernel binary itself. This is useful when we dont have source yet to build our own versions, as is the current case with KK. This also allows us to use newer stock kernels without having to update the BLs to match.

    *** This is strictly intended for developers, do NOT try any of the below for fear of bricking! ***

    1. Confirm modules are being rejected by BL-based authentication.
    Simple, try to turn on WiFi and keep on eye on dmesg/logcat. You should see some module-related errors (dmesg | grep 'tzapp').

    2. How to extract the kernel binary
    In post #1, I mention this but figure it's worth detailing for future use! To deconstruct boot.img is pretty trivial, I use the Adi_Pat package and simply run 'extract.sh boot.img' (you may need to update some of the binaries in that package). This will separate out zImage and ramdisk (expanded) into their respective folders.

    zImage is composed of some important loader code and the gzip compressed kernel binary. We need to extract the kernel and then decompress it.

    This is a snippet of a script Entropy512 used for s2 unpacking..
    Code: 
    pos=`grep -P -a -b -m 1 --only-matching '\x1F\x8B\x08' zImage | cut -f 1 -d :`
echo "Extracting gzip'd kernel image from file: zImage (start = $pos)"

if [ ! -z $pos ]; then
	echo "Dumping compressed image"
        dd if=zImage of=zImage_unpacked.gz bs=1 skip=$pos 2>/dev/null >/dev/null
	echo "Unzipping compressed image"
        gunzip -qf zImage_unpacked.gz
fi

    3. Analyze the unpacked kernel binary.
    Now load up zImage_unpacked into IDA, set to ARM CPU and base address 0xc0008000. Post #1 pretty much details how to isolate the exact ARM code to be patched. I patched things a little differently this time (this is MLD ATT KK leak):
    Code: 
    ROM:C00C91C8 00 50 E0 E3     MOV           R5, 0xFFFFFFFF  ; <<<< [COLOR="Red"]This returns -1, indicating authentication failed[/COLOR]
    The patch is trivial, we simply change R5 to equal 0 and the function will always return successful.

    4. Patch and restore zImage, or not?
    While the patch is easy, recompressing the kernel and popping it back into zImage is not. The zImage structure is very finicky, so I thought of a better way. Since we know the kernel binary in zImage is decompressed before the kernel is jumped to, why not inject a little patch after realtime decompression. This way we avoid having to decompress, patch, recompress to size, etc..So what we need to do is load up zImage (which has the loader code) in IDA and find the relevant code/injection point.

    I will just tell you that arch/arm/boot/compressed/head.S from the kernel src pretty much lays it out for us.
    Code: 
    		mov	r1, sp			@ malloc space above stack
		add	r2, sp, #0x10000	@ 64k max
		mov	r3, r7
		[COLOR="Red"]bl	decompress_kernel[/COLOR]
		bl	cache_clean_flush
		bl	cache_off
		mov	r0, #0			@ must be zero
		mov	r1, r7			@ restore architecture number
		mov	r2, r8			@ restore atags pointer
 ARM(		mov	pc, r4	)		@ call kernel	<<<< [COLOR="red"]Remember R4 here![/COLOR]
 THUMB(		bx	r4	)		@ entry point is always ARM

    in misc.c
    Code: 
    void
decompress_kernel(unsigned long output_start, unsigned long free_mem_ptr_p,
		unsigned long free_mem_ptr_end_p,
		int arch_id)
{
	int ret;

	output_data		= (unsigned char *)output_start;
	free_mem_ptr		= free_mem_ptr_p;
	free_mem_end_ptr	= free_mem_ptr_end_p;
	__machine_arch_type	= arch_id;

	arch_decomp_setup();

	putstr("Uncompressing Linux...");
	ret = do_decompress(input_data, input_data_end - input_data,
			    output_data, error);
	if (ret)
		error("decompressor returned an error");
	else
		putstr(" done, booting the kernel.\n");
}

    So we need a little codespace for our patch, I see 2 log messages that really serve no meaningful purpose. Let's look at the ARM of decompress_kernel in zImage:
    Code: 
    ROM:00000928 00 00 8F E0                 ADD             R0, PC, R0 ; "Uncompressing Linux..."
ROM:0000092C 00 20 81 E5                 STR             R2, [R1]
ROM:00000930 68 20 9F E5                 LDR             R2, =0x1C
ROM:00000934 02 20 94 E7                 LDR             R2, [R4,R2]
ROM:00000938 00 30 82 E5                 STR             R3, [R2]
ROM:0000093C D7 FF FF EB                 BL              sub_8A0
ROM:00000940 5C 30 9F E5                 LDR             R3, =8
ROM:00000944 05 20 A0 E1                 MOV             R2, R5
ROM:00000948 03 00 94 E7                 LDR             R0, [R4,R3]
ROM:0000094C 54 30 9F E5                 LDR             R3, =0
ROM:00000950 03 10 94 E7                 LDR             R1, [R4,R3]
ROM:00000954 50 30 9F E5                 LDR             R3, =0x14
ROM:00000958 01 10 60 E0                 RSB             R1, R0, R1
ROM:0000095C 03 30 94 E7                 LDR             R3, [R4,R3]
ROM:00000960 A5 08 00 EB                 BL              sub_2BFC	; <<<< decompress_kernel
ROM:00000964 00 00 50 E3                 CMP             R0, #0		; all code below is essentially replaceable
ROM:00000968 03 00 00 0A                 BEQ             loc_97C
ROM:0000096C 3C 00 9F E5                 LDR             R0, =(aDecompressorRe - 0x978)
ROM:00000970 00 00 8F E0                 ADD             R0, PC, R0 ; "decompressor returned an error"
ROM:00000974 38 40 BD E8                 LDMFD           SP!, {R3-R5,LR}; <<<< this is important, as it restores R4 which has our kernel base address
ROM:00000978 CC FF FF EA                 B               sub_8B0
ROM:0000097C             ; ---------------------------------------------------------------------------
ROM:0000097C             loc_97C                                 ; CODE XREF: sub_8F4+74j
ROM:0000097C 30 00 9F E5                 LDR             R0, =(aDoneBootingThe - 0x988)
ROM:00000980 00 00 8F E0                 ADD             R0, PC, R0 ; " done, booting the kernel.\n"
ROM:00000984 38 40 BD E8                 LDMFD           SP!, {R3-R5,LR}
ROM:00000988 C4 FF FF EA                 B               sub_8A0
ROM:00000988             ; End of function sub_8F4


    5. With our patch points figured out in zImage and the unpacked kernel, we need to generate our new ARM code and make the changes!
    - With R4 representing our kernel base address, we need to calculate a relative offset to patch: C00C91C8 - C0008000 = 0xC11C8
    - To generate ARM code, you can write it up in a simple, unformatted .s file and compile with arm-as.
    - So our patch @964 in zImage above will be the following:
    Code: 
    ROM:00000960 A5 08 00 EB    BL              sub_8020ABFC        ; decompress_kernel
ROM:00000964 38 40 BD E8    LDMFD           SP!, {R3-R5,LR} 	; restore registers, most impt R4
ROM:00000968 0C 00 9F E5    LDR             R0, loc_0000097C	; our relative offset, 0xC118C
ROM:0000096C 00 10 84 E0    ADD             R1, R4, R0		; base address + offset
ROM:00000970 A0 00 A0 E3    MOV             R0, #0xA0 		; this one byte fixes the R5 instruction mentioned above
ROM:00000974 02 00 C1 E5    STRB            R0, [R1,#2]         ; actual patch!
ROM:00000978 1E FF 2F E1    BX              LR      		; leave
ROM:0000097C C8 11 0C 00

    And that's it, hex edit that code starting @0x964 into the zImage, repack the zImage+ramdisk into boot.img/lok and we're done! I call it z-patching for lack of a better name :)
    I was verbose with this post since it can be applied to pretty much any kernel downstream of an unlocked/compromised BL.
    View
    16
    jeboo
    jeboo
    Hashcode said:
    Hello @jeboo and community,

    I deciding to open this up a bit and at least give everyone an update on where I'm at with the kexec process on the S4.
    Click to expand...
    Click to collapse

    NICE work so far man! I get back home this weekend, I will definitely start debugging things so we can make progress on this project. :)
    View

New posts