Ich gebe @Xander an der Stelle volkommen recht und wollte vorhin schon das gleiche schreiben. Bitte kehre mal wieder zu einem vernünftigen Diskussionston zurück!
Wenn ich als Hersteller mit closed-source Code betrügen wollte, würde ich wahrscheinlich genauso vorgehen. Ich würde den RNG bzw. die Verarbeitung so aufbauen, dass sie nicht wirklich zufällige Zahlen generieren.
Stattdessen sollten die Zahlen von mir reproduzierbar sein, wobei unterschiedliche Geräte trotzdem mit sehr hoher Wahrscheinlichkeit unterschiedliche Zahlen erzeugen müssen, damit es nicht auffällt.
Das ist sehr einfach umzusetzen, z.B. indem der gefakete „RNG“ einfach vorbereitete Zahlen liefert, die noch mit einem mir bekannten Geräte-spezifischen Salt verheiratet werden. Alternativ kann ich auch einfach auf jedem verkauften Gerät vorab eine Liste von echten, unterschiedlichen Zufallszahlen hinterlegen.
Kein Tester hätte eine Chance das herauszufinden. Trotzdem könnte ich zu beliebigen Zeitpunkten irgendwelche Wallets leerräumen; am besten nur einen winzigen Bruchteil der verkauften Wallets. Und zwar ohne dass die Geräte jemals eine Internetverbindung benötigt haben.
Das funktioniert übrigens nur, wenn der Code zur Erzeugung und der Code zur Verarbeitung der Zufallszahlen nicht open-source ist.
Wenn der Verarbeitungs-Code wie z.B. bei der Bitbox open-source ist, kann ich nachvollziehen ob alleine den RNG-Zahlen vertraut werden muss, oder ob diese noch mit Zufallszahlen anderer Elemente vermischt werden.
Beim Ledger ist der Seed niemals im Arbeitsspeicher des Microcotrollers, das ist richtig. Allerdings hat @Stadicus ja schon einiges dazu geschrieben: