Idea to hack SPL(let's discuss)

Search This thread

tewilove

Senior Member
Apr 17, 2009
133
130
At the last few steps before booting the linux kernel, SPL will read the value in booting image which determines where the kernel will be loaded to.

In desire it looks like below.

Code:
RAM:8E00F5F4                 MOV     R4, boot_img_header_addr
RAM:8E00F5FC                 LDR     R0, [R4,#0xC]
RAM:8E00F600                 BL      ioremap
RAM:8E00F604                 MOV     R2, R0
RAM:8E00F608                 MOV     R0, R5
RAM:8E00F60C                 MOV     R1, R7
RAM:8E00F610                 LDR     R3, [R4,#8]
RAM:8E00F614                 BL      partition_read_some
RAM:8E00F618                 RSB     R2, R7, #0
RAM:8E00F61C                 LDR     R3, [R4,#8]
RAM:8E00F620                 SUB     R3, R3, #1
RAM:8E00F624                 ADD     R3, R3, R7
RAM:8E00F628                 AND     R3, R2, R3
RAM:8E00F62C                 ADD     R7, R3, R7
RAM:8E00F630                 LDR     R0, [R4,#0x14]
RAM:8E00F634                 BL      ioremap
RAM:8E00F638                 MOV     R2, R0
RAM:8E00F63C                 MOV     R0, R5
RAM:8E00F640                 MOV     R1, R7
RAM:8E00F644                 LDR     R3, [R4,#0x10]
RAM:8E00F648                 BL      partition_read_some
RAM:8E00F64C                 B       loc_8E00F65C

So if we can set a value which it maps just to 0x8e00f64c it will overwrite the code which is about to execute so we can patch SPL.

ioremap function I reversed is in the attachment.

Can we do this? Someone did similar thing on G2.
Refer this youself.
showthread.php?t=559806
 

Attachments

  • map.txt
    3.6 KB · Views: 42
Last edited by a moderator:

wmh

Senior Member
Dec 31, 2008
93
25
Wish i could help with this but unfortunatly i have no knowledge of these things (yet). Anyway, i looks like a promising start considering the linked topic. It's about time we get proper access to this phone, it was a big let down discovering an "open" OS soo much locked down.
 

MojUk

Senior Member
Sep 22, 2009
228
7
South West
Ultimately it is a shame that HTC make it harder and harder for dev's to gain access to the relevant areas of the phone that they need in order for us all to enjoy the baked goodness! Is a shame that android was designed to be open but the phones are become far more closed!
 

xtcislove

Senior Member
Jan 17, 2010
1,616
432
Gummersbach
Nothing Phone 2
OnePlus 12
We are able to flash kernels on the desire.

But are we not able to flash a Death-SPL with the permament recovery?

I think we can but we can not extract the SPL from Desire so we cant patch it .... =( i read something similar i think :D sorry if im wrong
 

adam235

Member
May 23, 2010
36
0
i guess because of ioremap. but we can cut the hboot.nb0 at the offset we want to patch something in. add the patch at the end of it and then we remap it to 000x8e0000 then it should patch in our changes at the offset we want.

going to try it ...

-----

i cant get it load on the offset 0x8e000000 :( its like ioremap is a protection against that.
 
Last edited:

rosebud

Senior Member
Jun 18, 2005
290
27
40
Nottingham
i guess because of ioremap. but we can cut the hboot.nb0 at the offset we want to patch something in. add the patch at the end of it and then we remap it to 000x8e0000 then it should patch in our changes at the offset we want.

going to try it ...

-----

i cant get it load on the offset 0x8e000000 :( its like ioremap is a protection against that.

Good Luck :)
edit: just realised.. you updated the post to say it wont work :(
 

adam235

Member
May 23, 2010
36
0
on the htc hero it was possible to map it to 0x8F000000 when you set the kernel base to 0x00000000. but i think htc removed the values inside the ioremap struct so thats its not possible anymore. on desire hboot the offset 0x00000000 gets remaped to 0xAE000000 and i couldnt bruteforce a usefull offset
 

adam235

Member
May 23, 2010
36
0
hm i just wanted to proof my thinking and pasted in the hero struct into the code from the first post and the result was diffrent as expected:

~/Android $ ./ioremap 00000000
00000000 af000000

which means the base 0x00000000 should also work for the htc desire but i allready tried that one and it didnt work.

thats the code im trying to patch in @ 0x8E00F634

.section ".text", #alloc, #execinstr

.align
.start:

ldr r0, newcommandset
ldr r1, dest
str r0, [r1, #0]
ldmfd sp!,{r4-r8,pc}

newcommandset:
.word 0x8E07B348
dest:
.word 0x8E0174D0

but after i boot the kernel. i see the output of a call that comes after 0x8E00F634 which means my code wasnt patched in.
 
Last edited:

tewilove

Senior Member
Apr 17, 2009
133
130
@adam
Can you try to directly call a subroutine which meant to unlock or something interesting?
Or can someone find a exploit in SPL?
 

adam235

Member
May 23, 2010
36
0
my code doesnt get executed so i cant call anything ...

like the hero radio, the desire radio got some security i cant bypass. i can send commands like AT@CID=11111111 but the radio just returns a error. the only way to bypass the checks is to patch the radio like it was done with the hero.
 

tewilove

Senior Member
Apr 17, 2009
133
130
hm i just wanted to proof my thinking and pasted in the hero struct into the code from the first post and the result was diffrent as expected:

~/Android $ ./ioremap 00000000
00000000 af000000

which means the base 0x00000000 should also work for the htc desire but i allready tried that one and it didnt work.

thats the code im trying to patch in @ 0x8E00F634



but after i boot the kernel. i see the output of a call that comes after 0x8E00F634 which means my code wasnt patched in.

Well, this code should expand oem command list and it do not change PC. And I see some co-processor instructions before jumping to kernel and I dont know what they do. So when you return, where is it going to?
 

adam235

Member
May 23, 2010
36
0
the problem is that if my code works, the jmp to the kernel entrypoint should never be reached, as my code gets executed right after my code gets copied from the boot partition to 0x8E00F634. then it should patch in the extended command va and return back to the hboot. thats why im patching in this opcode: ldmfd sp!,{r4-r8,pc}.

the co processor code you see prepares everything for the jmp to the kernel (mmu init) but i dont know any details as normaly you dont want to reach this location.