TrustZoneHax für 2.x, 3.x und 4.x

  • Würde es nicht tragisch finden, wenn es mal einer leakt. Dann kommt alles noch ein bischen mehr Schwung und alle bekommen das was sie eigentlich wollen ^^
    Außerdem hat ein Leak den Vorteil das Nintendo es fixen kann. Wenn das deren Ziel ist.


    Kann kaum glauben das die Switch schon über 1 Jahr hier rumliegt. Die Zeit vergeht echt wie im Flug. Aber maximal noch 1 Jahr und wir haben das ganze gute Zeug und nicht nur simple Emulatoren die ja alle so unbedingt wollen *hust*


  • Ich habe schon gedacht 'sieht aus als hätten die schon Hardwarebeschleunigung am laufen', bevor ich die letzten 10 Sekunden gesehen habe.


    Allerdings bin ich mir fast sicher, dass das auch noch (teilweise) via Software-Rendering geht, also wäre da doch noch ein wenig Aufklärung nötig. ;)


    Naja, da die hausgemachte Schwachstelle in den Nvidia-Grafiktreibern, die von potenziellen Coder als Einfallstor für den Bootrom-Exploit genutzt werden,


    Treiber-Exploit? Ich bin verwirrt... auf welchen der Exploits beziehst du das? Die hausgemachte Backdoor hat ja eher weniger mit dem Treiber, zu tun und ist hardware-näher, sonst könnte man es leicht mit einem Treiber-Update fixen.

  • @Plastic
    Sorry, ich beziehe mich natürlich auf den Bootrom-Exploit....um dies zu konkretisieren, wollte ich eigentlich nur schreiben: Dass der Weg die Sicherheitsmechanismen im Tegra X1 auszuhebeln schon in der Dokumentation zum Tegra X1 »Bypass the SMMU« detailliert zu finden ist, das wäre auch das Einfallstor.
    Aber ist die Aufgabe eines Treibers nicht, das Bereitstellen von hardwarenahen Funktionen durch die Hardwareabstraktionsschicht.
    Erfordert dies auch nicht „rein hypothetisch“ eine Hardware-Revision, wenn man den Graffik-Treiber aktualisiert oder ist das auch aus Nintendo Sicht per Software-Update behebbar?

  • Also ich bin jetzt nicht sicher, ob BootROM-Exploit und der Tegra/SMMU-Exploit der gleiche sind. Falls es nicht einer sondern 2 sind, sind aber beide nur durch eine neue Hardware-Revision zu fixen.


    ...und zum Grafiktreiber, der wiederrum nicht viel mit dem Exploit an sich zu tun hat, denn der Tegra ist nicht nur eine GPU... (Zumindest wenn man seinen eigenen Systemprozess erstellen kann, braucht man auch keinen Fehler in einer Abstraktionsschicht näher mehr suchen. Das geht ja dann mit Kernel-Rechten.)


    Informiere dich nochmal genauer, wie ein Treiber funktioniert und was er macht. An sich (teilweise) richtig (dein Satz), aber unzureichend.


    Aber selbst von der Funktionsweise eines Treibers mal abgesehen... Wenn der Fehler 'nur' darin wäre, könnte man einfach den Treiber per Software/FW-Update mit updaten und somit wäre der Exploit weg! Das bringt nur beim SMMU-Exploit nichts, da der nicht in einem Treiber, oder einer Abstraktionsschicht (softwareseitig) sitzt, sondern direkt im Chip und das wodurch der da drin ist, kann man NICHT per Software updaten. :D



    Eine Auflistung aller Exploits wäre interessant und vor Allem, was davon nun 'das Gleiche' (oder eben auch nicht) ist.


    SMMU-Exploit, BootROM-Exploit, nvhax, TrustedZoneHack, etc.
    Sicher ist nur das da mehrere Exploits dabei sind.


    TZ-Hack und SMMU-Exploit können zusammenhängen, aber das der TZ-Hack FW-Abhängig ist lässt darauf schließen, dass da noch eine Software-Komponente im Spiel ist (Im Gegensatz zum reinen SMMU-Exploit, der das Ausführen von eigenem Programmcode AUF DER NIEDRIGSTEN SYSTEMEBENE [trotzdem 'in' der 'TrustedZone-HardwareSandbox'] ermöglicht, scheint der '[TZ]Hack' auf den die sich beziehen die Erlangung der Rechte zu sein, der dass triggern des SMMU-Exploit von Software-Seite aus erst ermöglicht [und ist somit wieder etwas Eigenes, praktisch das Paket vom Kernel-Exploit, bis Software-Setup, welches es ermöglicht alles auszuführen]!)


    Der BootROM-Exploit ist wahrscheinlich etwas Anderes, da es ja ein Coldboot-Exploit ist und somit nicht mit der Code-Ausführung, sondern dem Startverhalten und dem/den Bootloader/-n und/oder Systemdateien zu tun hat.


    Selbst die Art wie man zur pid 0 'wird', ist ein Exploit.



    Selbst wenn neue Hardware-Revisionen rauskommen, wird man sicher sehr schnell auch bei denen viel machen können (denke ich).


    @BiBo1994: Wenn dich Exploits (auch außerhalb vom Switch-Beispiel) interessieren, such halt mal einerseits nach einfachen 'Buffer Overflow Exploits' (welche mehr eigenen Code benötigen) und nach 'return to libc Exploits' (die etwas schwieriger aufzubauen sind). Die sind beide von der Funktionsweise unterschiedlich und geben einen guten Einblick! Der 'pid 0 hack' ist da da schon wieder einfach (einen Teil der Initialisierung weglassen). ;)



    ...und zu den Fehlern der Vergangenheit. Sollte logisch sein, dass die (auch aus ihren) Fehlern lernen... Die waren damals ja auch mittendrin, statt nur dabei! ^^



    ...und zu Hardware-Revision und Treiber generell... (abgesehen vom Rest): Eine neue Hardware-Revision kann einen neuen Treiber BENÖTIGEN, muss es aber nicht.
    Eine alte Hardware-Revision kann einen neuen Treiber als Update BEKOMMEN, muss es aber nicht.


    ...und da der Exploit soweit ich weiß Hardware-basierend ist, könnten die mit einem neuen Treiber nur den Zugriff auf diesen beschränken (was umgangen werden kann durch andere 'ausnutzbare Fehler [in Software]'/Exploits) und das könnten die auch nur, wenn der Fehler/Bug der genutzt wird wirklich im Grafiktreiber liegt.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!