Das Märchen vom Killerimage

[haveaniceday]

Diese Informationen hören sich gut an.
Mal sehen ob wir gute Info's zusammenbekommen einen Entwickler dafür zu interessieren.

.) Welcher Port ist das
.) Wie wird er angesprochen
.) (gehe davon aus) Programm lebt weiter nach diesem Reset

Benötigt wird:
.) Routine zum Start und Init
.) Check wo debugflag steht. ( Wollen ja nichts kaputt schreiben..)
.) Reset
.) Umgebung "um Flag" auslesen. ( oder kann man diese Stelle alleine beschreiben )
.) DebugFlag lesen
.) Routine aus Kernel zum Flash beschreiben
.) Flag setzen und schreiben
.) sync,sync,sync, reboot ....

Zwei mini "Boot" enable/disable.

Das ganze könnte auch "Copyrightfree" sein. Kein minflsh suchen.
Jeder kann ohne Hardwareeingriff BR raus und reinspielen.
Bei Garantie hat man kein schlechtes Gewissen mehr.

Hört sich doch gut an.

[Zahni]

@haveaniceday,

jetzt musst DU nur noch einen finden, der dieses neue Programm signiert, damit der Bootloader es ausfuehrt. Wei ich schon in dem anderen Thread geschrieben habe ist minflsh signiert.

-Zahni

[hardsofty]

Hm, ich habe mal den Schaltplan gewaelzt. Tatsaechlich, der Reset am Flash ist ueber einen Prozessor-Port ansprechbar. Allerdings bin ich mir nicht so ganz im Klaren, was damit noch alles resettet wird. Andererseits ist das ja schon fast wieder egal, solange die CPU selber am Leben bleibt, sollte sie dann den Flash schreiben koennen.

Waere natuerlich schon eine interessante Option, wenn das ginge ohne zu schrauben. Fuer mich allerdings zu spaet...

Was AMD angeht: Die Methode ohne Kurzschluss scheint da ja auch zu funktionieren, daher sollte doch das gleiche Prinzip anwendbar sein, oder nicht?

Evtl. muss ja gar nicht mal eine grossartige Software geschrieben werden. Im Prinzip reicht ja ein Dreizeiler (geraten), der einfach nur kurz den Reset-Pin zieht.

Für Nokia 2xIntel:

Ja, diese Idee hatte ich nach dem Schaltplan studieren auch schon:
Es müßte an der Stelle von der Debug mode im flash.so (tuner.so) gesetzt wird auch ohne einen Hardwareeingriff (Schrauben aufschrauben, resets intern etc.) möglich sein indem man kurz den port auf low zieht und gleich wieder high.

Was mir immer noch nicht für Nokia 2xIntel klar ist:
Kann jemand FÜR DIESE BOX (relativ neu) erklären, wann welcher Bereich vom Bootloader schreibgeschützt ist bzw. den Bootvorgang genau beschreiben

Sollte wirklich nur ein 2 oder 3 Zeiler sein, ev. mit delay loop. Dann ein 10-20 Zeiler.

Falls das funktioniert ist ein Umbau bei Nokia 2xIntel ohne Aufschrauben möglich.

[Erich]

Hi hardsofty,

genau meine Ansicht. Ich meine, man koennte das alles ja einfach mal probieren, Vorraussetzung waere aber, dass man den source code fuer die flash.so kriegt. Aber den gibt es wohl nicht, oder doch?

Oder man koennte mal ein kleines Executable erzeugen, das die entsprechenden Register anspricht. Danach koennte man dann ja sehen, ob der Schreibschutz noch besteht. Allerdings weiss ich nicht, ob man unter Linux irgendwie an die Hardware direkt ran kommt.

Was den Schreibschutz angeht, kann man jedenfalls schon mal sagen, dass laut Datenblatt die Flash-Roms nach einem Reset nur den Software-setzbaren Schreibschutz gesetzt haben. Irgendwann (...) wird dann vom Bootloader der nicht ruecksetzbare Schutz gesetzt. Aber das ist offenbar nicht immer der Fall, so erklaert sich auch, warum manche Boxen ohne Eingriff in den Debug-Mode zu bringen sind.

Fazit: Es gibt unterschiedliche Bootloader und eine generelle Aussage ist nicht moeglich.

Erich

[niemand0815]

hmmm. jetzt hab ich doch auf 2 fragen:
* wie erkenne ich nun SICHER ob der schreibschutz bei meiner box gesetzt ist?
* gibt es jetzt killerimages oder nicht? wie kann man ein solches erkennen?

[Erich]

Also erkennen sollte wie oben beschrieben gehen (habe ich aber noch nicht probiert...):

(dbox Manager starten, ...etc, also wie bei debug mode enablen...)

"-das ppcboot abbrechen und dann mit "flinfo" den zustand des flashs abfragen"

Ob es innerhalb Linux eine Moeglichkeit gibt, weiss ich nicht.

Killerimages? Also ich bin nicht ueberzeugt. Technisch sollte es moeglich sein, so ein Killerimage zu schreiben. Aber wenn es bisher die Entwickler nicht geschafft haben, den Debug-Mode ueber Software zu enablen, dann glaube ich nicht dran. Leichter ginge es natuerlich mit Boxen, die standardmaessig ungeschuetzt sind. Da sollte man aufpassen.

Was haette man aber davon? Ein Killerimage-Schreiber wuesste ja nicht mal, ob ihm irgendwer aufgesessen ist. Da koennte man sich viel besser profilieren, wenn man einen Debug-Mode-Enabler ohne Hardware-Eingriff schröbe.

Die verschiedenen Berichte, die man immer wieder liest, naja. Ob da wirklich Killerimages im Spiel waren oder jemand beim flaschen die Box irgendwie anders kaputt gemacht hat und das dann auf das angebliche Killerimage schiebt (ich vermute mal, meistens Images mit Emu), laesst sich halt nicht rausfinden.

Aber ein Restrisiko bleibt, und rigendwann ist immer einer bescheuert genug um sowas zu schreiben...

Erich

[rasc]

Da koennte man sich viel besser profilieren, wenn man einen Debug-Mode-Enabler ohne Hardware-Eingriff schröbe.


Erich

Du hast oben nicht gelesen.

Das Problem ist, dass eine signierte Software geladen wird.
Um das "debugmodeenablerwasauchimmer" auf der Box ausfuehren zu lassen, musst Du es signieren. Dazu musst du den Private Key kennen.
Den wird Betaresearch aber wohl kaum rausruecken...

Erst wenn der Debug-Mode an ist, startet die Box unsignierte Software.


Ein Killerimage hat es da dann vergleichsweise einfach, da die Box ja schon im Debug-Modus ist... der relevante Code duerfte ja auch nicht schwer aufzutreiben sein...

[hardsofty]

Da koennte man sich viel besser profilieren, wenn man einen Debug-Mode-Enabler ohne Hardware-Eingriff schröbe.


Erich

Du hast oben nicht gelesen.

Das Problem ist, dass eine signierte Software geladen wird.
Um das "debugmodeenablerwasauchimmer" auf der Box ausfuehren zu lassen, musst Du es signieren. Dazu musst du den Private Key kennen.
Den wird Betaresearch aber wohl kaum rausruecken...

Erst wenn der Debug-Mode an ist, startet die Box unsignierte Software.


Ein Killerimage hat es da dann vergleichsweise einfach, da die Box ja schon im Debug-Modus ist... der relevante Code duerfte ja auch nicht schwer aufzutreiben sein...

Stimmt, das Problem ist folgendes:
Normaler min*fl Ablauf:
1.) Signierter kernel wird gebootet.
2.) help bei rsh offen.
3.) Flash aufmachen
4.) Modifizierten Code ausführen.

Ablauf wie er funktionieren könnte?!?
1.) Signierter kernel wird gebootet.
2.) help bei rsh offen.
3.) Modifizierten Code ausführen, der einen Flash reset durchführt (geht das oder ist dieser Teil auch signiert???, flash.so, tuner.so, laut einigen Aussagen ist dierser Teil ja nicht signiert, oder ist er es doch, ohne Debug mode?)
4.) Debug enablen.
5.) Booten mit Debug enabled
6.) Files auslesen etc.

Sollte Methode 2 nicht funktionieren? Wenn Punkt 3 geht, dann schon. Ansonsten beisst sich die Katze in den Schwanz.

[satan]

Habt hier mal hier rein geschaut? http://dbox2.elxsi.de/files/tuner.so.tar.gz

[rasc]

Habt hier mal hier rein geschaut? http://dbox2.elxsi.de/files/tuner.so.tar.gz

was soll damit sein?

[Erich]

Also zweierlei muessen wir in der Diskussion auseinanderhalten:

1. Ist die Hardware der Dbox so gebaut, dass ein Flash Reset (ueber Pin 12) ausgeloest werden kann? Ich denke die Antwort ist ja, niemand sieht das anders. Denn sonst waeren Killerimagers gar nicht moeglich.

2. Laesst sich der Debug Mode ohne Hardware-Eingriff einstellen? Das ist sicherlich die interessantere Frage. Fuer einige Nokia-Boxen geht das wohl auf jeden Fall. Das laesst sich auch in den Howtos nachlesen, einfach, weil der Schreibschutz nicht richtig gesetzt wurde.

Apropos Schreibschutz vielleicht nochmal eine Klarstellung: Es gibt zwei Stufen des Schreibschutzes. Erstmal eine softwaremaessige Verriegelung des Flash-ROMs. Diese Verriegelung laesst sich ueber Software auch wieder entriegeln. Dann gibt es noch die zweite Stufe. Das ist ein bisschen wie Tuere zusperren und den Schluessel wegschmeissen. Diese Sperre wird naemlich zwar per Software eingeschaltet, ist dann aber per Software nicht mehr zu entfernen. Nur ein Neustart = Reset des Flash-ROMs entfernt diese Sperre wieder. Offenbar wird diese Sperre bei den genannten Nokia-Boxen nicht gesetzt (haengt wahrscheinlich an der Bootloader-Version).

Um nun ohne Hardware-Eingriff den Debug Mode enablen zu koennen, muss ganz klar nicht signierte Software ausgefuehrt werden. Somit haengt alles an der Frage, ob das geht. Und ich denke die Antwort ist ja. Denn das ist doch der einzige Grund, warum man Minflash startet. Minflash ist signiert und man laesst es anschliessend die nicht-signierte tuner.so starten.

Dass tuner.so nicht signiert ist, beweisst endgueltig der Link auf tuner.so.tar.gz . Ausser wenn Hunz und tmbinc bei Beta Research arbeiten (was mich auch nicht wundern wuerde - wer weiss wie viel gefrustete oder gelangweilte Programmierer da arbeiten - oder glaubt Ihr, da sitzen lauter kleine Leos) muss es moeglich sein, ein tuner.so zu schreiben/zu modifizieren und dann logischerweise unsigniert laufen zu lassen.

Daraus folgt, dass es geht. Ich habe das Gefuehl, dass man tatsaechlich nur einen kleineren Patch in das tuner.so machen muesste, so dass es das Flash-Rom resetet, bevor es die bekannte Variable modifiziert. Es muesste sich nur einer finden, der das a) machen kann und b) keine Angst hat, seinen Bootloader zu schiessen...

(oder c ein jeweils einer davon, d.h. Experte und Sponsor...)

Erich

[chkdesign]

Also so wie ich es verstanden habe verhält sich das mit minflsh und tuner.so so:

minflsh ist ein gepatchter Betaresearch kernel. Also signiert. Die Box braucht auch nur einen signierten Kernel, alle anderen Dateien brauchen logischerweise nicht signiert sein.
Die tuner.so ist einer der ersten Treiber (Tunertreiber), der von der Betaresearch Soft geladen wird.
Das haben sich tmbinc und gillem zunutze gemacht und statt des Tunertreibers das tool zum debugenablen in die tuner.so gepackt.

So hab' ich es verstanden.