hab mich mal ein wenig mi der blöden signatr beschäftigt, da mich das nicht in ruhe lässt und hier auch findeige programierer anwesend sind.
auf der folgenden seite wird z.b. beschireben wie eine NK.bin signiert wird.
http://www.microsoft.com/germany/msdn/library/mobility/windowsce/ErstellenEinesSicherenWindowsCEGeraets.mspx?mfr=true
ich denke das MS in dem punkt das rad nciht neu erfunden hat und bei dem alten system verblieben ist, daher hoffe ich mal das heir der eine oder andere mir zustimmt, das wenn wir wissen wie die signatur erstellt wird man mittels selbst erstellten tool den privat udn puplic key zurück gewinnen können um unsere NK.bin und auch Tv2client etc.pp signieren könnten. weil MS gibt uns heir die nötigen programme zum erstellen einer solchen Signatur also soltle es doch theoretisch möglich sein anhand vorhandener datein ein gegen program zu entwikeln, welches die signatur aus dem file ausliest.
es ist reine theorie aber möglich wäre es, man kann z.b. passwörer aus rarfiles auslesen wenn man weiss an welcher stelle es leigt also sollte es nicht fern sein dies hier zu entschlüsseln da es einen SAH algo verwendet. wobei hier nun festzusellen ist SAH1 oder sogar nen SAH-256 oder SAH-512 das ist die frage.
daher hoffe ich mal das heir der eine oder andere mir zustimmt, das wenn wir wissen wie die signatur erstellt wird man mittels selbst erstellten tool den privat udn puplic key zurück gewinnen können
Ich bin zwar kein Kryptoexperte, aber wenn das möglich wäre wären digitale Signaturen komplett wertlos. Die sind ja gerade so gemacht, dass man sie nicht "nachmachen" kann...
Generell hat sich hier noch keiner so richtig mit der Signatur auseinandergesetzt.
Da sollte man erstmal schauen was geht und was nicht.
Vielleicht hat ja M$ ja einige Fehler gemacht die man gezielt ausnutzen kann.
ich bin berufsbedingt Security- und Kryptographieexperte, daher bilde ich mir ein das ich mir ein Urteil erlauben kann :)
wir müssen hier zwei Fälle unterschieden:
1. bootloader Signatur: damit hat Microsoft gar nichts zu tun. Es ist ein rein SMP863x spezifischer Vorgang damit nur Code des OEMs auf seiner Hardware läuft. Das ganze läuft intern im Security CoProzessor des SMP ab...
2. die content Signatur: das hat Mircosoft zusammengebaut um den Inhalt der Festplatte abzusichern. Von allen Dateien wird der SHA1 Hash berechnet und dieser wird mit den Werten aus der Boot.sig Datei verglichen. die boot.sig Datei selbst ist signiert und die wird natürlich vorher geprüft.
zu den Fehlern in der RSA Implementierung... das wird in beiden Fällen alles in Hardware auf dem Security Prozessor gemacht. Ohne den programmcode der
RSA+SHA1 Implementierung zu sehen, ist es sehr unwahrscheinlich einen Fehler zu finden.
was das zurückberechnen der Private Keys angeht.... das ist mathematisch unmöglich... aber mit dem Beweis will ich euch nicht langweilen, glaubts mir einfach :)
Was machbar ist, ist ein Bruteforceansatz... da gibt es inzwischen schon recht interessante Ansätze mit denen man die Ergebnismenge gut reduzieren kann, so das der Zeitaufwand deutlich sinkt.
ich habe bei einem anderen Projekt vor zwei Jahren mitgeholfen einen RSA 512bit key mittels "general number field sieve" zu hacken.
Dafür hatten wir in etwa 500 Core2Duo Rechner per Internet zusammengeschaltet... die haben dann nur 14 Tage gebraucht um den Privatekey
zu finden (was mich wirklich überrascht hat)
Aber jetzt nur keine Hoffnung machen, denn mit jedem zusätzlichen bit bei der Keylänge steigt der Zeitaufwand überproportional.
im Fall von der x300t sind alle RSA Schlüssel 2048bit lang... also optimistisch geschätzt liegt der Zeitaufwand mindestens bei mehreren 1000 Jahren, wenn wir sehr sehr viele Rechner auftreiben könnten.
nur zum Vergleich... der bisher längste gehackte RSA key ist 640bit lang !! dafür wurden mehr als 5 Monate gebraucht.
Theoretisch könnte man natürlich beim ersten probierten Key schon den richtigen getroffen haben... aber bevor das passiert hab ich sicherlich eher zwei mal hintereinander 6 Richtige im Lotto
ach ja... ein Speicherproblem würde es auch noch geben, denn im letzten Schritt muss eine monströse Matrix ausgerechnet werden.
in meinem 512bit hack Projekt hat das schon mehr als 4GB Speicher geschluckt... bei 2048bit braucht man auf jeden Fall wesentlich mehr als man in einen normalen PC reinstecken kann.
Mist dann kann man den Sighack auch vergessen !
Da bleibt nur noch heraus zu bekommen was die übrigen Pins der CPU für Funktionen haben.
Vielleicht gibt es ja Pins die ein Direktzugriff auf das interne CPUflash ermöglichen.
Einige sind ja schon bekannt. (Jtag und Serialport)
Die Signaturen der content.sig und custom.sig sind RSASSA-PKCS1 v1.5 (http://rfc.net/rfc2437.html#s8.1) mit SHA1-Hash, zumindest lässt sich das so aus dem Code entnehmen, ich gehe mal von aus das es bei der boot.sig genauso ist. Ich sehe keinen Grund Zeit an den Signaturen an sich zu verlieren, wir haben doch eine funktionierende JTAGlösung. Lottospielen wäre sowieso erfolgreicher als da auf gut Glück jahrelang herumzuraten um den privaten Schlüssel zu finden.
Interessant ist jedoch : Bei einer 386 Zeichen (bzw 193 bit) langen Signatur in der boot.sig wird diese Signatur von der originalen BooterCE.exe nicht überprüft ("Skipping validation because of old-style signature"), was macht der Bootloader dann ? Meine Hoffnung ist natürlich nicht besonders groß, aber wer weiss...
ja diese Überprüfung hatte ich auch mit grosser Hoffnung untersucht, aber leider kommt man da auch nicht weiter.
wenn ich mich recht erinnere, dann wird alles gelöscht was nicht vom signaturcheck geprüft wurde.
wenn also die Signaturprüfung übersprungen wird, dann wird keine Datei als "ok" geflaggt und somit wird alles gelöscht.
Was passiert wenn man diese Löschfunktion außer kraft setzt ?
Sofern das möglich ist.
bin ich jetzt nicht sicher ob es da einen Fehler gibt, falls das Löschen nicht klappt... also im besten Fall bleiben dann alle Dateien auf der Platte und die Anwendung wird normal gestartet.
das bringt bei der Aktuellen Version aber auch nicht so viel, weil die Anwendung nicht mehr auf der Festplatte ist... daher könnte man nur am GUI rumbasteln.
mir gings hier bei mehr um die 301 user, die 300er sind einfacher zu patchen aus dem einfachen grund der internet ok meldugn die kommt bei der X301 nicht, der versucht solange eine internet verbndung herzustellen bis es nicht mehr geht. die 300 fragt nunmal ob internet ok ist dies wird mittels ok ja bestätigt, udn da ist ja der punkt an dem der patch ansetzt so viel ich das bisher raus bekommen habe. daher ist es für die 301 serie ein wenig schwerer.
icch hbe ja 2 301er die sich itentisch verhalten und nein am eingelöteten chip liegt das problem nicht weil auf lgeiche art in eine 300er eingebaut funktioniert er ja auch, 50 - 60 boot vorgänge sidn da normal ehe der patch greift bei der 301. kann aber auch daran ligen das ich ne Rev C habe, auf jeden fall ist das zum brechen, ich bin schon her gegangen habe beim patch wait time viele optionen aus probiert bin hoch und runter geganen im sekunden takt im halben secunden takt also bei der 301 ist das ein wenig schwerer. die reagiert nicht so wie die 300er
der signaturcheck wäre nen guter ansatz gewesen, aber so wie es ausschaut fast ünmöglich wobei unmöglich gibts nicht das haben schon viele behauptet siehe sat verschlüsselungen die angeblich unhackbar waren udn doch gehackt wurden. von daher sag ich auch unmöglich gibts nicht.
was mich irritert z.b. in der boot sig ist in der ersten zeile nen ellen langer schlüssel, in wie weit der überhaupt ne auswirkung hat etc.pp
also für diesen langen schlüssel habe ich noch keie verwendung wärend die SHA-1 quersummendie für die jeweilige datei drinne ist auch passen.
problem wird bei der neuen 300er box ohne DVB-T nen bekannter hat eine geliefert bekommen der hat auch REV-C, board layout weiss ich nicht, da ich die box nicht in der hand hatte. aber wird denke ich mal der 301 ähnlich sein nur ohne DVB-T.
x301t ist nur eine umbenennung... es gibt auch x300t die genau wie die x301t sind, nur mit 80gb platte.
also wenn schon dann sollte man von der hardware-revision sprechen ... das sagt mehr aus als x300t oder x301t ...
wenn ich von x300t spreche dann meine ich normalerweise alle t-home boxen, wie immer die auch gerade heissen mögen (marketing nervt)
wie auch immer, es ist problemlos möglich den bootloader der x301t downzugraden... aber soweit ich weiss hängt das Verhalten
des bootloaders von der boot.prv datei ab...dort ist auch ein flag vorhanden "wait on network" ... ich meine das sollte sich so
einstellen lassen, dass die x301t sich genauso verhält wie die x300t.
die frage ist aber wieder in wie weit die boot.prv von sigcheck abhängt. aber wäre eine interresante lösung.
aber soweit ich weiss hängt das Verhalten
des bootloaders von der boot.prv datei ab...dort ist auch ein flag vorhanden "wait on network" ... ich meine das sollte sich so
einstellen lassen, dass die x301t sich genauso verhält wie die x300t.
Irgendwo hattest du doch mal eine boot.prv von dir gepostet wo das Flag gesetzt war, hab die auch mit dem x301t benutzt, aber das Ding hat definitiv nicht gewartet, ich gehe also mal von aus das die x301t generell nicht wartet.
ich hab die verschiedenen bootloader in diesem thema nicht so genau untersucht... wär natürlich denkbar das der neue bootloader das flag komplett ignoriert.
wie auch immer, es ist problemlos möglich den bootloader der x301t downzugraden... aber soweit ich weiss hängt das Verhalten
des bootloaders von der boot.prv datei ab...dort ist auch ein flag vorhanden "wait on network" ... ich meine das sollte sich so
einstellen lassen, dass die x301t sich genauso verhält wie die x300t.
Das Flag steckt im NV-Bereich des Bootloaders (Offset 0xE7FE5), wo man auch die MAC-Adresse, Zertifikate, den Modellnamen und den Discovery-Servernamen findet. In diesem ist der Wert mit dem Identifier 0x000F, Länge 0x0001, Inhalt "1" oder "0" enthalten. Die Funktion IPTV_HAL_Cfg_GetRequestNWAccessBeforeDRA(int *result) holt sich diesen Wert, wandelt ihn per atoi() in einen Zahlenwert um, und gibt entsprechend 1 oder 0 zurück.
Wenn dieser NV-Bereich des Bootloaders ebenfalls verschlüsselt im Flash-ROM liegt, dann könnte man das Flag nur permanent setzen, indem man den FlashInhalt - also inklusive MAC-Adresse und Zertifikaten - durch einen mit auf "1" gesetzten Wert ersetzt...
dieser Bereich ist nicht verschlüsselt. das jtag tool könnte man relativ leicht anpassen, so dass all diese parameter und flags geändert werden können ;)
vielleicht bau ich da mal was zusammen, wenn ich mit dem NK.BIN erstellen fertig bin.
dieser Bereich ist nicht verschlüsselt. das jtag tool könnte man relativ leicht anpassen, so dass all diese parameter und flags geändert werden können ;)
Wow, tatsächlich!?? Dann müsste man sich ja glatt noch einmal anschauen, ob sich bei diesen Parametern nicht vielleicht doch irgendwo einer findet, mit dem man irgendwie die Signaturchecks permanent aushebeln könnte...
es kann auch sein das es flags sowohl in dem verschlüsselten als auch verschlüsselten Bereich gibt. Da bin ich jetzt nicht sicher,
allerdings bin ich 100% sicher da am Ende des Flashs diverse Informationen unverschlüsselt gespeichert sind.
Wie soll sich der Sig Check denn damit aushebeln lassen?
Es sind ja nur die Zertifikate in diesem Bereich und nicht die Schluessel oder sehe ich das falsch?
Wie soll sich der Sig Check denn damit aushebeln lassen?
Wenn es z.B. einen Wert dort gibt, der den Bootloader in einen "Debug Mode" versetzt... Da gibt es ja immer noch dieses komische Flag, welches den Signaturcheck überspringen lässt. Vielleicht haben wir ja bislang nur die Stelle nicht gefunden, an welcher dieses gesetzt wird - vielleicht durch einen Wert im OEM-Konfigurationsblock, der bisher nicht gesetzt ist...?!?
Da gibt es ja immer noch dieses komische Flag, welches den Signaturcheck überspringen lässt.
Echt? Wo denn? Den Thread muss ich verpasst haben :)
Da gibt es ja immer noch dieses komische Flag, welches den Signaturcheck überspringen lässt.
Echt? Wo denn? Den Thread muss ich verpasst haben :)
An Speicheradresse 0x937E1728.
na ich glaub das sieht ganz vielversprechend aus...
Bootloader 1051:
KMM3210-DE-A discovery.iptv.t-online.de 1 1 1
Bootloader 1053:
KMM3210-DE-A discovery.iptv.t-online.de 1 1 0
ich hab jetzt noch nicht nachgesehen welche funktion diese drei flags am ende haben, aber mein Bauch sagt
das letzte Flag ist das "wait on network"
ist natürlich interessant was die anderen beiden machen.
ich glaub zwar nicht das man dort den signatur-check ausschalten kann, aber vielleicht trotzdem was hilfreiches ?
ist natürlich interessant was die anderen beiden machen.
DefaultLanguage und DefaultVideoFormat - also nichts hilfreiches.
da muss es aber denke ich noch irgend wo ne funktion geben, die z.b. verursacht das wenn die Nk binnicht vorhanden ist nen reset durch geführt wird. oder irre ich mich da?!?
auf jeden fall findet man innerhalb der FW die diversen infos Internet ok Keine verbindung, Debug Modus usw. also müsste es innerhalb der FW irgend wo was geben.
auf jeden ist diese BL geshcichte sehr kompiziert von siggnatur udn vershclüsselungs verstädniss hab mir mal das in der libery von MSDN mal angeschaut das teil ist duch gut ausgeknopelt.
wenn ich mir das hier
http://msdn.microsoft.com/en-us/library/bb643805.aspx
und das hier so anschaue
http://msdn.microsoft.com/en-us/library/bb201900.aspx