NVidia Auf die harte BIOS-Tour: manueller EEPROM-Flash einer GeForce RTX zur Umgehung der Sperre mit der Hardware-ID bei NVflash | igorsLAB

gastello hat gesagt. :
Ein solcher Code ist im read-only Speicher unveränderlich und wird als Hardware of Trust betrachtet. Es ist ein Leichtes ihn mit einer internen Kennung zu versehen, so dass das Gerät dann eben nicht validiert wird und damit auch nicht booten kann. Der Code wird durch einen Secure Prozess/Processor überwacht. Sollte die A Dices tatsächlich HPC ready sein, ist das ein effektiver Ansatz zu verhindern, sie anderweitig validieren zu können. Man kann dann nur mit seriengleichen Biosversionen arbeiten (A to A und B to B). Cut oder Pinversatz ist out und macht viel zu viel Arbeit.:)
Zum Vergrößern anklicken....

Die Frage ist, wo sich dieser Read-Only Speicher befindet. Auf dem Die kann er nicht von vorhinein hartverdrahtet sein, da erst im Nachhinein bestimmt wird was der Chip mal werden wird.

Die Vorgangsweise könnte Ähnlich sein wie hier:
hacking-nvidia-cards-into-their-professional-counterparts

Quelle: https://www.eevblog.com/forum/chat/hacking-nvidia-cards-into-their-professional-counterparts/175/

nur statt simple Widerstände (oder doch vielleicht?) wird auf dem BGA Package ein Secure Processor wie du schon erwähnt hast sitzen der im Bootvorgang die Daten validiert.

Für mögliche Workarounds muss dann aber zuerst bestimmt werden wo der sitzt.

Wenn man den Gefunden hat, könnte man sich eventuell was zurechtbasteln dass dem das originale BIOS vorgegaukelt wird, aber ein anderes geladen wird.

mögliche Holzhammermethode: 2 EEprom BIOS Chips mit einer Zeitbasierten Relaisschaltung. Quasi: Bootvorgang 0,5sec, Secureboot gibt das Booten frei, und dann wird umgeswitcht.

Keine Ahnung ob das funktionieren könnte, wahrscheinlich mache ich mich eher gerade peinlich. :D

Vielleicht regt es aber andere Ideen an. Man weiß ja nie :)
 
Wieso peinlich? Das ist höchstens die Bildqualität meiner Fotos...;)

Auf der Rückseite des PCBs sind zig Lötpunkte die scheinbar nicht benutzt sind. Theoretisch kann da auch was möglich sein... Verdammt, könnte mal bitte ein Entwicklungsingenieur von Nvidia, der hier mitliest, Klarheit schaffen? Danke! :D:D:D
 
Frank,
meinst Du ernsthaft, das macht einer der E-Ingenieure?
 
Schön wäre es... Nein, ist Wunschdenken, deshalb auch die Lachsmilies. Wenn einer mitliest, dann wird er vermutlich sehr amüsiert sein, ob der Theorien die aufgestellt werden. Dann wird er sich an seinen Arbeitsvertrag erinnern und die Finger still halten und sich seinen Teil denken.
Und die sprechende Lederjacke wird sicherlich weiterhin dafür Sorge tragen, dass wir weiter im trüben fischen... Leider! :cool:
 
Okay, ich habe auch geschmunzelt. Doch tatsächlich liest "der Feind" mit.
Igor meinte oben,
" Ich habe zudem lange daran gesessen, beide Firmware-Pakete binär zu vergleichen, auch mit anderen Extrakten aus BIOSen dieser beiden Chip-Klassen. Ich werde mich aus den Eingangs in diesem Artikel genannten Gründen jetzt auch nicht weiter darüber auslassen, welche Bereiche den OEM zur individuellen Anpassung (z.B. Vorgaben für Lüfterkurven, eigene Funktionen usw.) dienen und wo man Nvidias abgesicherte Daten vermuten könnte. Es bringt nämlich nichts, weil man für die Auswertung des Letzteren auch die verwendeten Algorithmen des Schutzes kennen müsste.

Es existiert auch eine physikalische Hardware-ID
Obwohl die Chips von gleichen Wafern stammen, findet man eine andere Hardware-ID vor. Das Gleiche gilt übrigens auch für die Quadro-Karten, die ja ebenfalls auf identischer Hardware basieren. Soweit unsere Informationen stimmen, löst Nvidia diese Spezifizierung in A-, S- oder eben auch Quadro mittels eines sogenannten “Hardware-Straps”, also einer kleinen zusätzlichen Komponente auf dem BGA-Platine, nicht durch eine Kennung am oder im Die. Wir sind auf der Suche danach, keine Angst."

1. Siehst Du eine Möglichkeit, die von NV verwendeten Algorithmen des Schutzes zu decodieren?
Soweit ich mich erinnere, konntest Du in den Hex. tatsächlich einiges Interessantes wie Hardware-Infos, Zertifikate und ab Hex74F etwas zu den Hardware-ID lesen.
2. Wenn der EEPROM-Chips komplett gelöscht ist und die Hardware-Straps ausgemacht worden sind, müsste man doch flashen können?
3. Wo vermutest Du die Straps am Wahrscheinlichsten?
 
1. Nein.
2. Flashen geht ja. Nur bootet nichts.
3. Selbst wenn ich es fände, würde es kaum helfen.

Im Prinzip kann man hier und jetzt erst mal abbrechen.
 
@DedSec : Also, alles was jetzt kommt ist meine persönliche Meinung!

Zu 1.: Theoretisch ja. Ist aber wie damals bei der Enigma. Man müßte eine Codesequenz kennen oder bei X verschiedenen Files identifizieren können um daraus Rückschlüsse ziehen zu können. Irre (!!!!!) aufwändig und nahezu unmöglich. Bis dahin sind wir Generationen weiter fürchte ich...
Die erwähnten Zertifikate stehen so im BIOS mit dem Klartext drinnen. Im Gegensatz zu Igor & TH.de unterliege ich keinen NDA oder ähnlichem und darf das schreiben. (Steht ja oben, ist meine Meinung oder bis Igor mir das verbietet. ;)

Zu 2.: Mit dem Programmierer kannst du die EEPROMS komplett löschen, also ALLE Speicherzellen auf FFhex setzen. Dann kann das EEPROM neu beschrieben werden. Genau so habe ich das gemacht. Die verbauten Typen verfügen NICHT über Hardware Fuses die z.B. ein Auslesen unterbinden. Auch besteht sonst kein Schutz gegen einen etwaigen Fremdzugriff. Also Modifizieren geht immer!

Zu 3.: Ehrlich?!? Keine Ahnung! Die Dies an sich werden getestet und sortiert. Dann werden sie auf den, ich glaube Interposer heisst des, montiert. Also des Dingen mit den BGA Lötkügelchen drunter um es Laienhaft zu erklären. Und DIESES Teil wird vorher auf welche Art und Weise auch immer, codiert. Und somit denke ich so gut wie nicht manipulierbar....

@Igor Wallossek : Hehe, warst schneller als ich :D
 
@BigReval

Selbst wenn manipulierbar, dachte ich bei Tegra damals auch. Zwar wird mit command und transmit ein Startup Parameter übergeben, aber letztlich wurde dann der Parameter 0 gesetzt. Beim flashen wird dir ein error write oder dead adress vermutlich nicht angezeigt, sondern successfully. Read-only wird nicht überschrieben, zudem setzen die Entwickler/Hersteller auf Fakes, damit du das nicht so einfach hast. Die antworten darauf nicht, auch im Dev Forum nicht.

Wenn der Master mit dem Code read-only versorgt ist (wo und wie nV das auch immer codiert), dann kannst du machen was du willst. Slave dann zu überschreiben bringt gar nichts. Ich vermute zur Sicherheit, damit sich nicht alle die schlechteren GPUs schrotten. Turing hat sonst die gleichen Sicherheitsmechnismen wie Volta an Board.

Die Frage ist, ob es sich bei so einer Karte überhaupt lohnt, Experiment ausgeführt, fehlgeschlagen. Macht doch nichts. Soweit ich weiß, geht es bei Asus (A to A Die). PCGH bestätigen das, weil Asus anfänglich auch auf B PCB's, A Dies verlötet haben. MSI ist vielleicht nicht der richtige Hersteller.

Die Zeiten bei denen wir mit einem Bleistift Pins verbinden, sind lange vorbei. An Pins und fehlende Widerstände allein glaube ich nicht so wirklich, aber bei den Böcken die Foxconn für nVidia gerade geschossen hat, warum nicht.;)
 
Was die EEPROMS angeht, da stimmt schon alles. Die sind nicht geschützt etc. Es gibt Typen da kann man Inhalte schützen. Die sind aber nicht verbaut. Würde mich auch wundern, sind teurer.

Was und wie geschützt ist das kennt nur Nvidia wirklich. Wir wollten es wissen und haben den Versuch gemacht. Wir haben ein Ergebnis und wissen nun Bescheid. Jeder kann mit GPU-Z das BIOS seiner Karte(n) per Mausklick auslesen. Einen Hex Editor findet man zu Hauf als Freeware. Fertig ist das Homebrew Re-Engeneering.
Logisch das Nvidia da einige Kniffe einbaut um diverse Manipulationen zu unterbinden!

War auf jeden Fall ein Experiment was Spaß gemacht hat. Auch die Zusammenarbeit mit Igor! Vielleicht ergibt sich ja mal wieder was, ich bin da zu allen Schandtaten bereit! ;)
 
Wenns der Chip ist den ihr abgebildet habt. Das ist ein IS25SWPxxx, nennt sich kurz SPI und arbeitet nach dem Master-Slave Prinzip. Der bringt ein write block protected (BP3, BP2, BP1, BP0) mit. Wenn VCC auf VWI (write inhibit voltage) fällt, werden alle write Sequenzen für die Blöcke ignoriert. ISSI halt.

Die geben diese spezifischen Blöcke mit nicht flüchtig und nur lesen an. Hat damit einen Softwareschreibschutz der durch "1" angezeigt wird. Geschützt werden die Autoboot Parameter und Register. Würde im Fall passen oder?

Ich ging von eurem Bild aus.;)
 
Zuletzt bearbeitet von einem Moderator :
Aber mal was anderes:

warum will man nochmal das BIOS vom A-Chip draufhaben? eigentlich ja nur wegen dem größeren möglichen Power Target. Wärs da nicht einfacher das non-A BIOS zu modifizieren (also höheres max. PT eintragen) und zurückzuflashen? selbst wenn dies durch nVflash fehlschlägt, mit einem Hardware EEPROM Flash geht's ja trotzdem. oder wird hier wirklich hardcore die Checksumme verglichen?
 
@gastello : Ja, hast vollkommen Recht! Man kann die EEPROMS Lese-/Schreibschützen. Aber um das zu machen müßte auch ein Pin auf LOW, hier Masse gelegt werden. Und dann die jeweiligen Bits gesetzt werden.
Ich habe das heute mal mit dem “großen“ Progger mal diverse Karten von diversen Herstellern durchprobiert. Der große kann nämlich die Config Bits Lesen und Schreiben.
Es waren keine Lock Bits Programmiert.
Abgesehen davon, wird beim löschen des EEPROMS auch die Locks gelöscht! Es sei denn der Pin... Aber das ist nicht der Fall.
Außerdem konnte ich problemlos die alten Daten schreiben und alles war schick!
Hier an der Stelle also Entwarnung.

@BlueKingMuch : Weil ichs kann... Nein, das Powertarget, die Taktfrequenzen etc. Kann man so nicht mehr ändern. Zumindest nicht ohne weiteres. Ich weiß das Boardpartner das können. Aber die Werte sind schon seit X-Generationen für Ottonormalbürger nicht mehr frei zugänglich. Es gab für ältere Karten mal so ein Tool. Heute sind, soweit ich weiß, die Daten verschlüsselt. An die Software wird keiner wirklich rankommen... Falls doch, bitte Kopie an mich! ;) Das ist des Problem!
 
Vielleicht noch als Gedankengang (nerven will ich nicht), auf dem Chip ist noch Platz (man reserviert meist Blöcke für spätere Updates, wäre blöd wenns dann am verfügbaren Speicherplatz scheitert, so ist es bei dem IS25WSP auch). Heisst, wenn du das Bios neubeschreibst, lässt die Software den read-only Bereich unberührt. Sie beschreibt Blockweise den freien Bereich, nach und nach. Soweit ich weiß wird der gesperrte Bereich durch einen Kondensator gespeist, der entwender die Spannung hebt oder senkt (VCC zu VWI), um ein write command ausführen zu können. NV Flash liegt ja auch in einer gemoddeten Version vor, die Schutzmechanismen aushebelt, sonst könnte man auch die A to A Tour nicht durchführen.

Wenn du blockweise beschrieben hast, findet der I2C Driver den benötigten Autoboot nicht, weil einfach der alte Master abgerufen wird. Daher kann man wohl auch A to A und B to B flashen. Gibt vermutlich Unterschiede zwischen A und B.
 
BigReval hat gesagt. :
Nein, das Powertarget, die Taktfrequenzen etc. Kann man so nicht mehr ändern. Zumindest nicht ohne weiteres. Ich weiß das Boardpartner das können. Aber die Werte sind schon seit X-Generationen für Ottonormalbürger nicht mehr frei zugänglich. Es gab für ältere Karten mal so ein Tool. Heute sind, soweit ich weiß, die Daten verschlüsselt. An die Software wird keiner wirklich rankommen... Falls doch, bitte Kopie an mich! ;) Das ist des Problem!
Zum Vergrößern anklicken....

Schade, hätt ja sein können :) hab bevor ich auf die Vega64 gewechselt bin bei meiner ehemaligen Maxwell 980ti noch selbst mit GPU-Z das vBIOS extrahiert und mit dem BIOS-Editor einfach das Powertarget von max. 109% auf max. 140% ziehen können, ist jetzt auch nur 2 Generationen her...
 
@gastello : Nein, du nervst nicht. Im Gegenteil, sind alles berechtigte Einwände. Nun kommt aber das ABER... Denn das EEPROM hat ja sogar OTP Bereiche etc. Ich habe es nach dem Auslesen erst mal verifiziert. Das wäre ins Aus gelaufen wenn der Schutz aktiviert wäre. Das Read / Verify sind nur zwei Klicks. Das war erfolgreich. Daraufhin habe ich die Fuses mit dem “dicken“ ausgelesen. Es ging ja bei dem Artikel darum, ob das mit 10€ Hardware, also was, was jeder mal testen kann oder nur mit teuren speziellen Geräten geht wo teilweise ein Studium ratsam ist. Zurück, also KEINE Fuses aktiv, 00hex und gut ist. Anders wäre Nvflash ja auch nicht in der Lage zu schreiben. Und beim Lesen käm nur Blödsinn raus. Also ist der Schreibschutzpin nicht aktiv oder über z.B. eine Transistorschaltung beschaltet. Braucht Nvidia auch nicht. Das BIOS selbst ist geschützt.
Was du meinst, so verstehe ich das, wäre wenn ich z.B. Atmel und Pic hätte. Also zwei verschiedene Typen die verschiedenen Code brauchen. Es sind aber die gleichen Chips, die den selben Code brauchen. Also in der Theorie läuft die Software auf BEIDEN.
Nvidia hat aber den EEPROM Inhalt schon verschlüsselt und braucht deshalb keinen weiteren Schutz. Scheinbar hat jede GPU ihren eigenen Schlüssel zum entschlüsseln. Und dann passt der Code zwar aber nach dem entschlüsseln kommt nur Murks und die GPU hängt.... Soviel Soft passt ja locker in die GPU um das zu realisieren.
Also haben wir da wahrscheinlich mit ganz anderen Problemen zu kämpfen als mit gesetzten Schutz-Bits, die nach dem Lösch Befehl genullt werden.

@BlueKingMuch : Das ging an mir vorbei, zu der Zeit war ich noch aktiv und habe mich mit den Sachen nicht so beschäftigen können. Meine Info war, das es noch länger nicht ging.
Heute ist aber damit schluss. Leider. Sonst könnte man das BIOS ja so ändern und die Werte der OC Karte hinterlegen. Schon wäre alles schick. Geht aber leider nicht....
 
Um antworten zu können musst du eingeloggt sein.
Oben Unten