PS2 Fortuna. ALL PS2s (incl. TV) HACKABLE! Another discless exploit!

Arrrrr... Technically not possible with the OpenTuna or not implemented?

Well, maybe there are more vulnerabilities, but I can edit that part.
 
TnA said:
Arrrrr... Technically not possible with the OpenTuna or not implemented?

Well, maybe there are more vulnerabilities, but I can edit that part.
Click to expand...
As of today... it is impossible...

Alex tried his best to make it possible (me too).
We believe the source of this issue is that 1.00 and 1.01 boot roms are the only ones wich have non compressed OSDSYS programs...

although... i wonder... if we suceed on making this happen... we will have another issue:

How the F*CK will we stick the kernel patches inside OpenTuna????????? they fix (amongst other things) a bug on LoadExecPS2()
 
Oh, I did not even think about the Protokernel-fixes, but I think it is possible. We are currently rather stack-smacking the return-value on the stack, but I think we can write in a more coordinated fashion and locations.

The initial issue of no-RLE is indeed a big one it seems.
I think we can STILL use an "icon", but it can't use RLE as an Exploit able vulneraility on those.
 
Yeah and I replied... What don't you get about it?

The initial vulnerability seems like a bigger issue than patching other offsets...
 
TnA said:
Yeah and I replied... What don't you get about it?

The initial vulnerability seems like a bigger issue than patching other offsets...
Click to expand...
Big issue is that we need to increase the payload size to make an icon Wich can hack into the ProtoKernels...

The kernel patches also have an embedded EELOAD module, so they will result on a ~6kb - 16kb increase.

And they have two variants, so we have to embed both...

edit: the behaviour of the kernel patches is EXACTLY the same between 1.00 and 1.01 so the diff must be on the EELOAD replacement...

edit2: indeed, EELOAD is the only diff...


Code: 
isra@DESKTOP-6J4JFIF:/mnt/d/isr/isr_git/OSD-Initialization-Libraries/kpatch$ diff --color ./patch0100/EELOAD/EELOAD.c ./patch0101/EELOAD/EELOAD.c
4c4
<     Date:        2013/04/25
---
>     Date:        2013/10/13
26c26
< // 0x00083e80
---
> // 0x00084080
30c30
< // 0x00083e88
---
> // 0x00084088
33,34c33,34
< // 0x00083ea0 - the patch that solves the problem with the browser being unable to pass arguments to the update.
< // The same as the v1.01 OSDSYS patch, except for the addresses.
---
> // 0x000840a0 - the patch that solves the problem with the browser being unable to pass arguments to the update.
> // The same as the v1.00 OSDSYS patch, except for the addresses.
48c48
<     0x8d4ad280, // lw t2, $d280(t2)
---
>     0x8d4ad800, // lw t2, $d800(t2)
59c59
<     0x34e7d288, // ori a3, a3, $d288
---
>     0x34e7d808, // ori a3, a3, $d808
72c72
<     0x24030006, // addiu v1, zero, $0006
---
>     0x24030006, // add    iu v1, zero, $0006
82c82
< /* 0x000820e8*/
---
> /* 0x000820e8 */
90,95c90,93
<     // Copy the patch.
<     strcpy((char *)0x0028b9b0, "DVD�v���[���[���N���ł��܂���ł����B"); // Don't know why they need to patch this as the original message is exactly the same. D:
<     // Originally, these lines made the OSD use osd110.elf instead. But since FMCB's v1.10 update only causes the v1.01 OSD to use osd130.elf, do the same thing here. The v1.20 update is the first update that doesn't require patching.
<     strcpy((char *)0x0028b770, "/BIEXEC-SYSTEM/osd130.elf");
<     strcpy((char *)0x0028b790, "-x mc%d:/BIEXEC-SYSTEM/osd130.elf");
<     strcpy((char *)0x0028b8a0, "osd130.elf");
---
>     // These lines weren't originally here, but I would like the kernel to use the update for v1.20 instead to save space (Since it's the first update that doesn't involve kernel patching).
>     strcpy((char *)0x0028bd00, "/BIEXEC-SYSTEM/osd130.elf");
>     strcpy((char *)0x0028bca8, "-x mc0:/BIEXEC-SYSTEM/osd130.elf");
>     strcpy((char *)0x0028be08, "osd130.elf");
97c95,96
<     *(volatile unsigned int *)0x00204ad0 = ((*(volatile unsigned int *)0x00204ad0) & 0xFC000000) | 0x0013c000; // jal 0x004f0000
---
>     // Copy the patch.
>     *(volatile unsigned int *)0x00204b28 = ((*(volatile unsigned int *)0x00204b28) & 0xFC000000) | 0x0013c000; // jal 0x004f0000
110c109
< /* 0x000821d0 */
---
> /* 0x00082180 */
126c125
< /* 0x00082258 */
---
> /* 0x00082208 */
133c132
< /* 0x00082298 */
---
> /* 0x00082248 */
142c141
< /* 0x000822c8 */
---
> /* 0x00082278 */
160c159
< /* 0x00082368
---
> /* 0x00082300
176c175
< /* 0x000823a8 */
---
> /* 0x00082340 */
185c184
< /* 0x00082400 */
---
> /* 0x00082398 */
198c197
< /* 0x00082440 */
---
> // 0x000823d8
213d211
<         /* 0x000824b8 */
 
Last edited:
Move/Copy&Delete-Icons were implemented on those OSDSYS-Versions?

We can probably use one of those as storage for patches, because we can predict the RAM-Offsets of the icons.
 
You must log in or register to reply here.

Similar threads

Back
Top