da_pwner

Vabbè se intendete le iso per gli emulatori è un'altra storia visto che è l'emulatore a risolvere gli imports delle iso,io pensavo vi riferiste alle iso dei giochi psp

potreste benissimo usare gli UMD,e per problemi di spazio comprare dal psn -.-'

Si che ci sono gli exploit da cui creare un isoloader,ma non questo,per i motivi sopracitati;anche se fosse possibile,però,tutta la comunità hacker (compreso me) è decisamente contrario agli isoloader,forse i cf del futuro non avranno supporto iso cool

Mi dispiace ma le iso non andranno mai su questo exploit;per far partire una iso si necessita un exploit kernel,e vi spiego perché: Un eloader altro non è che un file binario che ne fa partire uno eseguibile (pbp,elf) risolvendone gli importa attraverso l'estimazione delle chiamate delle syscall;le syscall sono le chiamate di sistema,cioe delle funzioni non importate da questo exploit ma che possono essere chuamate,perché?Perché si trovano pur sempre nella RAM user,solo che cambiano posizione costantemente.Grazie alle syscall,l'eloader risolve gli import dell'homebrew da far partire e li confronta coi nid che gli sono stati dati dallo sviluppatore. Le iso,invece,creano altri imports visto che contengono un prx bootabile che cancella tutta la memoria già occupata dal gioco che causa l'exploit per ripartire a 0x08800000,nella memoria persa pero ci sono informazioni senza le quali un loader non potrebbe partire;tra l'altro le iso creano imports kernel,che non possono essere risolti con le syscall. Per farla breve scordatevi le iso lol

lol lol 4 ore dopo...

Invece mi permetto di contraddirti:la RAM è divisa in 3 parti: -vram:da 0x44000000 in poi,gestisce la parte grafica -user:da 0x08800000 in poi,gestisce i moduli user -kernel:da 0x88000000 in poi gestisce i moduli kernel ora,come potete ben vedere,le tre partizioni sono ben separate,il punto per il quale non ai può scrivere qualcosa sulla sulla RAM kernel (l'unica in grado di contenere il cf in quanto le altre due hanno funzioni e capacita piuttosto limitate) è sempre lo stesso,non si hanno i permessi kernel;delle volte pero (molto raramente) ci sono dei casi di overflow eccessivo nei quali una RAM scrive sull'altra:un esempio è il cuckhen:quando vedete la schermata verde dell'avvio è perché la vram,per poter mandare in overflow e portare lo stack di quest'ultimo nella RAM kernel,va a scrivere sulla RAM kernel,in questo modo abbiamo un certo numero di byte sovrascribibili con un normale indirizzo di memoria (visto che si trovano nella vram) che però andranno sulla RAM kernel per overflow eccessivo.In questo caso,la demo che causa l'exploit viene lanciata da 0x88XXXXXX e torna a 0x08800000 dove riloca i suoi nid,l'exploit pero riscrive solo la RAM user (visto che lo stack tra l'inizio della user e della vram è grosso) a questo punto diventa quasi impossibile mandare in overflow la vram visto che questa è "bloccata" dal gioco.