Ich versuche das ganze nochmal ein wenig ausführlicher aufzuschreiben, du wolltest ja noch mehr dazu wissen. Ich brauche die ganzen Exploits aber garnicht, ich habe noch eine PSP-2000, deswegen ein wenig Rücksicht auf mögliche Fehler. Die Pandora Methode ist aber kein Exploit, der immer wieder gefunden werden muss, ich schreibe deshalb über die Schritte für eine PSP-3000 oder neuer auf.
Bis vor etwa 2 Jahren lief der Vorgang zum entsperren der Konsole in etwa immer gleich ab. Zuerst benötigt man einen sogenannten Userland-Exploit. Das Userland ist der Bereich, in dem alle PSP-Spiele und Sony-Programme ausgeführt werden. Meistens wird dazu ein Speicherstand eines Spiels manipuliert.
Dabei wird ausgenutzt, das die PSP den Inhalt des Speicherstandes in den Arbeitsspeicher einliest und verarbeitet. Ist das Spiel dann nicht richtig programmiert ist es möglich zum Beispiel den Namen des Spielers viel zu lang zu machen und ihn dadurch im Arbeitsspeicher über den für ihn vorgesehenen Bereich hinaus zu schreiben. Um das zu verstehen sind Kenntnisse in C oder C++ hilfreich, ansonsten such mal nach "Buffer Overflow".
Durch dieses vom Spiel und Konsole nicht gewolltes und scheinbar unkontrollierte Überschreiben ist es dann möglich den Arbeitsspeicher der PSP zu beeinflussen und im Userland-Bereich ein wenig Unheil zu treiben. Dadurch kann zum Beispiel die Rücksprungadresse beeinflusst werden, oder fremder Code eingeschleust werden. Zeigt man nun mit der Rücksprungadresse auf den Bereich, in dem der eigene, fremde Code liegt, wird er von der PSP ausgeführt! 
Wenn du dazu noch mehr wissen willst könntest du noch nach "Funktionstack" suchen, oder dich generell dazu informieren wie ein Prozessor funktioniert, auch wenn das vielleicht ein wenig über dein Zeil hinausschießt 
Jetzt hat man es also schon einmal geschafft eigenen, nicht von Sony gewollten Code auf der PSP auszuführen. In etwa so weit war auch Wololo mit der Firmware 6.20 und seinem HalfByteLoader gekommen, dem HBL. Davon hast du ja bestimmt schon gehört. Er hatte eine Möglichkeit gefunden in Patapon 2 einen Speicherüberlauf auszulösen und es so ermöglicht Homebrews auf der offiziellen Firmware abzuspielen.
In früheren Firmwares wurden häufig auch Tiff-Exploits verwendet, man musste also ein manipuliertes Bild auf seinem Memory-Stick haben. Dies hat etwa Davee benutzt, um seinem 5.03 ChickHEN zu starten. Das Verfahren ist dabei sehr ähnlich zu dem hier beschriebenen.
Um eine Custom Firmware zu installieren reicht das, was bisher geschafft wurde aber noch nicht aus. Wie ich oben schon geschrieben habe wird sämtliche Software im Userland oder User Mode ausgeführt, das Hauptmenü um VSH Mode. Beide Modi haben sehr eingeschränkte Rechte und dürfen die Hardware der PSP nicht direkt ansteuern. Auch Teile des RAMs sind nicht zugänglich. Um die fehlenden Rechte zu bekommen, um etwa in den Flash0-Speicher der PSP schreiben zu dürfen, muss man in den Kernel Mode der PSP eindringen.
Dazu wird ein zweiter Exploit benötigt. Ein solcher Kernel-Exploit ist deutlich aufwendiger als ein noch relativ einfacher Userland-Exploit und entsprechend lange dauert es bis man einen geeigeneten Kernel-Exploit gefunden hat. Häufig muss man eine Kette kleiner Fehler verbinden bis man wirklich den Kernel erreicht hat.
Ein Einfallstor in den Kernel können die sogenannten Syscalls sein, die der Kernel dem Userland bietet, um auf bestimme Funktionen zurückgreifen zu können, für die Kernel Rechte benötigt werden. Ich will das ganze hier jetzt nicht nocheinmal erklären, weil es auf Wololo.net wunderbar geschehen ist.
Hat man sich jetzt durch die verkettung der Verschiedenen Programmierfehler in Sonys Kernel und Spiel Zugriff zum Kernel erschlichen, ist es möglich den Inhalt des Arbeitsspeichers und Flash0-Speichers der PSP zu verändern. Auf bestimme Bereiche, wie die Pre-IPL, hat man trotzdem keinen Zugriff, sie sind in der Hardware codiert. Hier muss man jetzt noch unterscheiden zwischen einer PSP, die vor dem 3. Quartal 2008 produziert wurde, und denen, die danach entstanden sind.
Bis zu diesem Zeitpunkt gab es im Bootloader der PSP einen Fehler, der es uns ermöglicht, unseren eigenen Bootloader zu starten. Der Bootvorgang der PSP sieht in etwa so aus.
- Prozessor läd Pre-IPL
- Pre-IPL überprüft Signatur der IPL
- IPL wird ausgeführt
- IPL überprüft Signatur des Systems
- IPL läd System
Schlägt eine der Signaturprüfungen fehl unterbricht die PSP den Bootvorgang und kann nicht mehr gestartet werden.
Die Signatur der IPL wurde bis zum 3. Quartal mit einem leichten Fehler berechnet, der es ermöglichte durch geschickte Bearbeitung der IPL deren Signatur intakt zu lassen und der Pre-IPL so einen gültigen Sony Bootloader vorzugaukeln. Dadurch konnte die orginal IPL der Firmware ausgetauscht werden gegen eine, die die zweite Signaturprüfung unterlässt und es somit zulässt, dass wichtige Systemdateien manipuliert werden. Auf diesem System basieren fast alle fest installierten CFW, sowie der Pandora Akku, auch dabei wird eine manipulierte IPL von der PSP gestartet.
Nachdem Sony den Fehler behoben hatte war es deshalb erstmal nicht mehr möglich eine eigene Firmware in den Flashspeicher zu schreiben, man manipulierte nur noch den Arbeitsspeicher der PSP. Deshalb muss man bei ChickHEN, oder den Pro-Firmwares nach jedem Neustart den Exploit erneut ausführen, die Änderungen im Arbeitsspeicher gehen jedes mal verloren.
Erst mit dem Hack der PS3 hat sich ein wenig was an diesem vorgehen geändert. Sony hat in die PS3, um die MINIs sowohl auf PSP als auch der PS3 abspielen zu können, einen PSP-Emulator eingebaut. Er war ein gesamtes Abbild der PSP, komplett mit Kryptographie Chip, der benutzt wurde, um die Signatur der PSP-Spiele zu prüfen.
Anders als bei der PSP lag der Kryptographie Chip "Kirk" der PSP jedoch auf der PS3 nicht in Hardwareform vor, die sich fast nicht auslesen lässt, sondern als Software. Dadurch wurde nicht nur der Schlüssel verraten, den Sony zum Signieren der Spiele benutzt, sondern auch der Algorithmus, der benutzt wird. Dadurch konnte nun gezielt nach Fehler in der Signatur gesucht werden, gefunden wurde er natürlich auch. Die Hash Funktion, die die Datei überprüft, überprüft quasi nur den signierten Header der Spiels sowie dessen Größe.
Nutzt man nun also eine offizielle Demo von Sony, extrahiert daraus den Header und bringt das eigene Programm mit einer bestimmten Methode auf die selbe Größe wie die Demo war die Signatur weiterhin gültig, die Signaturprüfung der PSP für ihre Spiele war also quasi nutzlos. Das ganze funktioniert natürlich nur so lange, wie man auch eine Demo in der richtigen Größe besitzt, die Größe der eigenen Datei kann nur größer, nicht kleiner gemacht werden.
Durch diesen Fehler Sony fällt der erste Schritt sämtlicher Hacks davor weg, ein Userland-Exploit war nicht mehr nötig, man besaß diese Recht durch die Signatur automatisch. Später wurde ebenfalls noch ein Fehler in Sonys Signatur der Firmware gefunden. Der sogennante "Perma Patch" ermöglichte es, die vorher immer nur den in Arbeispeicher geschriebenen Homebrew Enabler bei jedem Start der PSP automatisch wieder aktiv werden zu lassen, die Firmware war quasi fest installiert. Dabei gab es jedoch soweit ich weiß Probleme mit dem Update der PSP auf spätere Versionen. Ab Firmware 6.30(?) wurde diese Lücke jedoch von Sony geschlossen. Das signieren von Homebrews funktioniert aber immer noch wunderbar.
Ich hoffe, dass der Text nicht so lang war, dass er dich verschreckt hat, und dass du alles soweit verstanden hast. Bei Fragen einfach fragen und Fehler bitte zurückmelden
News
Forum
Lexikon
Reviews
PS4 Spiele
Releasetermine
Marktplatz
Suche
Sonstiges
Chat
Facebook
Twitter
YouTube
RSS
PS Vita / PSP
/
Homebrew
/
Development
/
Wie funktioniert der momentane Firmwarehack der PSP?
