Das Märchen vom Killerimage

So jetzt würde mich das schon mal interessieren. Normalerweise ist mein Bootloader schreibgeschützt. Daher ja auch die Verrenkungen, um die Box in den Debug-Mode zu bringen.

Wenn es sowas wie ein Killerimage gäbe, was könnte das dann killen? Den Bootloader ja wohl kaum, oder? Bleibt noch der Rest vom Flash, mit anderen Worten, das Image selber. Nicht sehr aufregend...

Und solange ich den Bootloader noch habe, kann ich mir jederzeit ein neues Image laden, das ist ja die Idee hinter dem hardwaremässigen Schreibschutz.

Also alles Märchen. Wer hat übrigens Angst vorm schwarzen Mann?...

Erich

also als märchen würd ich das nicht gerade bezeichnen...
es gibt ne menge boxen die serienmäßig überhaupt keinen schreibschutz für den bootloader haben, und die zu killen wäre dann schon sehr leicht.
dann gibts da welche, bei denen das debugdisable mit setenv ohne weiteres durchführbar ist ohne den schreibschutz wieder aufzuheben (und dabei werden ja auch wieder die ersten 4 sektoren des flashs neu geschrieben)

Ah, interessant. Wieder was gelernt. Ts, so ein Leichtsinn! Immerhin muessten sich solche Boxen ja dann ganz ohne Hardware-Eingriff mit der minflash-Methode in den Debug-Mode bringen lassen, richtig?

Wie kann ich das denn rausfinden, ob ich den Schreibschutz drinnen habe? Ich denke beim booten kommen da bestimmte Meldungen, aber sind die zuverlaessig?

Das mit dem debugdisable kann aber wohl auch nur gehen, wenn der Schreibschutz nicht da ist oder liegt diese Variable nicht im Flash?

Koennte man denn den Schreibschutz 'nachruesten'? Dazu waere dann wohl ein Bootloader-Wechsel faellig...

Erich

-richtig
-das ppcboot abbrechen und dann mit "flinfo" den zustand des flashs abfragen
-das ist ja gerade das interessante, es geht bei vielen boxen einfach so, obwohl der bootloader schreibschutz hat
-nein, könnte höchstens mal in nen ppcboot integriert werden

Danke nochmal fuer die Info.

Jetzt habe ich nur das mit der debuginfo-Variablen nicht verstanden. Ich dachte, die liegt im Flash, sonst koennte man ja wohl damit nicht dauerhaft in den debug mode kommen. Aber wenn der Bootloader schreibgeschuetzt ist...

Ah, liegt diese Variable dann vielleicht NICHT im Bootloader-Bereich? Oder in einem ungeschuetzte Block, der an sich zum Bootloader-Bereich zaehlt?

Sorry, reine Neugier. Alles sehr faszinierend, finde ich. Ich hoer dann auch gleich auf, dumme Fragen zu stellen, ehrlich.

dochdoch,
die product? liegt im flash, und wird ja auch da geändert.
das ganze läuft etwa so ab:
box bootet,
bootloader wird abgearbeitet,
bootloader schaut im netzwerk nach was ausführbarem,
schaut im flash nach was ausführbarem,
***
setzt den schreibschutz,
startet das betriebssystem.

an der stelle *** kann man mit setenv immer noch ohne weiteres das flash neu beschreiben, auch bei boxen bei denen der bootloader schreibgeschützt ist, deshalb muß das setzen des schreibschutzes ja irgendwo kurz vorm starten des bestriebssystems erst erfolgen (wenn "lade" im display steht)

Pling! Jetzt ist es mir klar. Ich hatte angenommen, dass der Bootloader nichts wichtigeres zu tun hat als gleich seinen Schreibschutz zu setzen (Selbserhaltungstrieb).

Danke fuer die Aufklaerung!

Erich

Hallo,

gab es schon versuche diese Bootreihenfolge für ein "Debug ohne Eingriff in die Box" zu nutzen ?
Ciao,

haveaniceday

...ohne Debugmode wird aber leider nur signierte Software vom Netz gestartet.
Und die Signatur lässt sich nicht mal eben so fälschen.

Meine Idee wäre:
mini-debug-enable-only schreiben.
Finde signatur
Hänge signatur an.
Kein Hardwareeingriff.

Bin neu bei der DBOX aber generell könnte ich mir vorstellen:
mini-debug-enable-only per debug durch die "signiercheckroutine" laufen lassen.
signierwert nehmen und ans Programm anhängen.

Das ganze wird zwar aufwändig sein. Aber ein debug ohne Eingriff wäre eine schöne Sache.

haveaniceday

Naja... siehe oben:

Ah, interessant. Wieder was gelernt. Ts, so ein Leichtsinn! Immerhin muessten sich solche Boxen ja dann ganz ohne Hardware-Eingriff mit der minflash-Methode in den Debug-Mode bringen lassen, richtig?

Und die Antwort war:

-richtig

Aaber einen hab ich auch noch:

setzt den schreibschutz,
startet das betriebssystem.

In so einem Fall hat ein Killerimage auch wieder keine Chance, gell? Oder umgekehrt: Nur wenn der Bootloader komplett ungeschuetzt ist, kann ein Killerimage was ausrichten.

Erich

Hi Erich,
sorry für das Abschweifen.

Nach deinen Argumenten sollte ein Killerimage nur greifen, falls die Box im ungeschützten Modus
ist. Sonst sollte der "wichtige" Teil geschützt sein.
( Oder man hat Teile vom bootloader im ungeschützten Bereich gelassen...)

Ciao,

haveniceday

Kein Problem, das Board ist nicht mein Eigentum.

Ja, ich denke das ist die Quintessenz. Deswegen halte ich das ganze fuer Ammenmaerchen. Bzw. kann man ja nachsehen, ob fuer die eigene Box da eine Gefahr besteht.

Und es fragt sich halt auch, wieviele Boxen ohne Schreibschutz es ueberhaupt gibt. Wenn man dem Howto bei digixp.de glauben darf, dann sind das eh nur bestimmte Nokia-Boxen.

Ich habe den Verdacht, dass da hin und wieder einer seine Box schiesst und dann ein bisschen Aberglaube ins Spiel kommt. Moeglicherweise gibt es auch Leute, die ihn dann gerne in dem Glauben lassen... Aber das geht mich nix an.

Und wer böses denkt, kann auch meinen jemand mit Signaturmöglichkeit schreibt solche
images....

Naja, wenn das ginge, dann koennte man auch komplett auf den Debug Mode verzichten. Das waere dann sozusagen der Stein der Weisen fuer die D-Box.

Wenn man wuesste, was dazu fuer ein Algo verwendet wird...

Falls es anstaendig gemacht wurde, dann ist es sicherlich was assymetrisches und damit so gut wie unknackbar. Aber wo nicht (z.B. CRC berechnung oder so), koennte man somit einen Haufen Boxen vor dem Kurzschluss-Infarkt bewaren.

Hab mich noch nicht soviel mit so etwas beschäftigt.
Meine (hoffentlich funktionierende) einfache Idee wäre:

.) geht debugger z.B. gdb
.) Bootloader ins Ram laden
.) Bootloader mit "enable-debug" füttern.
.) Stelle suchen wo "Mecker" kommt. + break ( Ist ein vergleich von 2 Werten...)
.) gesuchten Wert an das enable-debug hängen.

Wäre ne Assemblersache + viel Geduld..

Habe das Thema mal unter Vorschläge gebracht.

Ciao,

haveaniceday

Na, wie gesagt, wenn ein einfaches Verfahren verwendet wuerde, wie z.B. eine Pruefsumme, dann geht das. Aber wenn ein Verfahren wie z.B. bei PGP benutzt wird, dann wird das alles ziemlich schnell aussichtslos...

@Erich:

In so einem Fall hat ein Killerimage auch wieder keine Chance, gell? Oder umgekehrt: Nur wenn der Bootloader komplett ungeschuetzt ist, kann ein Killerimage was ausrichten.

doch kann es, soweit ich das bisher hier mitlesen konnte killen die besagten images nach nem reset der box, und da ist der kasus knaktus:
nach nem reset ist erstmal der bootloader ungeschützt, und wenn mit dem laufenden image der resetvektor des prozessors verbogen wird auf ne routine die den bootloader löschen soll, dann ist das leicht machbar.
ich denke das prinzip sieht so aus: normalerweise ist beim MPC823 nach nem reset die adresse 0100 aus dem flash die startadresse. wenn man nun diese startadresse während des betriebs mit dem image auf ne andere adresse setzt, dann wird nach nem reset nicht der bootloader an der adresse 0100 gestartet sondern irgendwas ganz anderes. würde man nicht resetten sondern den netzstecker ziehen, dann würde wieder die normale startadresse 0100 angesprungen werden

Wäre das nicht auch eine Möglichkeit ohne "Hardwareeingriff" in den Debugmode zu kommen.
=> an der Stelle wo "help" oder das "enabledebug" script aufgerufen wird.
=> Programm schreibt seine Adresse "debug enable" in den Resetpointer
=> Kein "Pin x" verbinden, sondern "reset" über die Tastenkombination
Oder Programm macht selber reset...
Bingo... äh Debug

Also das ist zwar reine Mutmassung, aber bei den Prozessoren, die ich kenne, laesst sich der Reset-Vektor nicht verbiegen. Normalerweise ist der doch fest, eben um definierte Einschalt-Verhaeltnisse zu haben. Das koennte also nur klappen, wenn nach dem Einsprung in den gescheutzten Bootloader dort wieder aus dem geschuetzten Bereich rausgesprungen wuerde, bevor der Schreibschutz gesetzt ist.

Ich sollte mir mal das Datenblatt anschauen, bevor ich sowas behaupte...

Aber ich denke, haveaniceday hat da einen guten Punkt. Wenn es irgendwie meoglich ist, mittels eines Killerimages den Bootloader zu aendern, dann ist das doch DIE Methode, um den Debug-Mode zu disablen, oder?

Das Killerimage kann Boxen mit Intel flash ganz leicht killen inklusive Bootloader in dem es eine Flashreset ausführt und denn das Flash mit müll beschreibt weil das intel flash nach einem Reset z.B. bei Starten der Box von Bootloader sofort den Befehl bekommt geschützt zu sein der dann auch nur noch per Hardware aufgehoben werden kann nur das killer image macht nen Flash reset und löscht es denn gleich also es wird kein befehl für den Schreibschutz gegeben und es ist den Flash egal ob die Hardware schreibschutz gesetzt ist oder nicht, ohne befehl ist das intelflash nicht geschützt warum das so ist weis ich auch net. AMD Flash habe das nicht wenn dort der Hardware schreibschutz gesetz ist sind die geschützt.
Denn gibt es auch noch boxen z.B. alte nokia die eine Fehler in der Schaltung haben wo der Schreibschutz deshalb immer aus ist.

Was würde dann ein "debug-enable" daran hindern ein flashreset zu machen und
nicht zu löschen, sondern nur "debug enable" zu schreiben ?

Ciao,

haveaniceday

Ja das würde für Intelboxen gehen wenn man das ins miniflash einbaut nur dafür muss das erstmal einer machen und ich kann den Processor der box leider nicht programmieren.

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.

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

bitte nicht "Kurzschluß"-methode mit dem Schreibschutz disablen verwechseln, das sind zwei grundlegend verschiedene vorgänge