Sonstige Zugriff mit yaffs2-utils auf RAZR2 V8 und ROKR Z6

ich komme auf "nur" 2kbit

 

Ich habe mir das vorhin noch einmal angesehen. Als ich den PoL umgebaut habe auf LP0039B. Ich hab einmal das LP0039B vom 2GB V8 und einmal das vom 512er V8 genommen. Wo ich nun gerade dabei war, hatte ich beide verglichen. Die Signatur ist bis auf die besagten 128 Byte identisch. Gibt es irgendeinen Algorythmus der 128 byte lange Checksummen erstellt? Oder sind es 2x 64 Byte lange Prüfsummen irgendeines eventuell sogar bekannten Algos?

 

soweit ich weiss ist der mechniasmus unerreichbar fern im irom der cpu geschrieben und damit definitv RO!

Ich schlage vor dem kind einen namen zu geben: z.B: Sig-Checker, oder RSA-Blocker

Wenn die signierten CGs nit die gleiche Länge haben, dann muss dieser mechanismus irgendwie die informationen der .hmg beachten um CGs mit ihren Signaturen auffindig zu machen: er liesst .hmg oder beim flash-scan stellt er selber fest wo die CGs mit ihren Sigs liegen

@MeinerEiner: wie gross schätzt du den Code-SpeicherBedarf für für das identifizieren von CGs und Sigs ein?

woher weiss der mechanismus welche CGs signiert sind und zu rüfen sind?

der Code muss in das irom passen. dieser ist nur wenige KB gross, teuer und knapp.
je mehr knowhow im irom stehen um so teurer und unflexibler wirds und umgekehrt.


RSA ist als Prinzip auch mit größeren Zahlen möglich! Es wäre dann nur nicht standarisiert! Aber das stört der Mathematik nicht!

 

Also 128 Bytes sind doch schon recht gross, wenn man bedenkt das ein AES Schlüssel gerade mal 128Bit hat.

 

Sorry gorgoyle,
Aber manchmal weiß ich echt nicht wovon du sprichst.

Aber zu

Die Sig hat wie gesagt, eine ganz bestimmte Länge. Und zwar 1106 Byte.

In der Sig stehen diverse Infos. z.b. welche CG es ist, wo di Sig steht, .... und eben 128 Byte mit infos von denen unbekannt ist wofür.

 

Die 128 Byte werden sicherlich der Public Key vom RSA sein. Um aber diesen zu erstellen braucht man den Privat Key und den wird uns Moto wohl kaum offen legen. :D

 

Den Privatekey hat nicht mal Motorola.

Den wird irgendeine Maschine erstellt haben

 

Also hat ihn doch Motorola die Maschine wird wohl denen gehören.

 

Ok, das ist zwar korrekt, aber Motorola KENNT den Privatekey nicht.

Ich glaube allerdings auch kaum das es sowas wie einen Masterkey gibt. Falls doch, dann kennt ihn zumindest Motorola

Aber bei einer Verschlüsselung bzw Signatur einen Masterkey?

Ich weiss...klingt vielleicht komisch, aber WÄRE es denn möglich? Ist zwar normalerweise ein Sicherheitsrisiko, aber die Daten sind ja nicht Verschlüsselt, sondern nur Signiert.

 

ich erkläre es nochmal hoffentlich besser.

wenn es für eine signierte CG mehrere Versionen gibt, die unterschiedliche Größen besitzt, können die CGs nicht genau in einer konstanten Weise im Flash "positioniert" werden.

Wenn sich die Lage einer CG ändern kann muss die Position und Größe der CG dynamisch bestimmt werde. Vll. benutzt der Mechanismus die Werte aus der .hmg!

Wenn ja, liesse sich vll. da etwas tricksen.

Wenn nicht muss der Mechanismus den Speicher nach CGs scannen und irgendwie entscheiden, ob eine CG signiert ist oder sein sollte.

Je mehr der Mechanismus machen muss um so größer ist seine Code-Größe.
Der Mechanismus steht im irom, einen kleinen Speicher in der CPU.
Er ist nicht veränderbar.

Dies ist Ausgangslage meiner Überlegungen.

Weiterführende Fragen sind:
In wie weit steht der Code für den Mechanismus nicht im irom?
Wird der Inhalt der hmg vom Mechanismus benutzt um CGs "aufzusuchen"?
Oder wird der Speicher gescannt nach CGs?

Wie gross ist das irom?
Wie gross wäre der hypothetische Code für die eine oder anderer Methode bzw. würde eine hypothetische Methode in den irom passen?
etc.

Es scheint erreichbar ein Programm zu schreiben und auszuführen, dass den Inhalt und Größe des irom ausgibt!

Das reverse-engineering des irom dagegen erscheint mir dagegen als schwere arbeit.


Die Größe des irom allein zu wissen ist schon hilfreich für weitere Überlegungen über den Mechanismus.

 

Es gibt aber wie gesagt nur eine Version.

Auch die lage einer CG kann man nicht ändern.

 

Also die .hmg hat damit nichts zu tun. Zumindest nicht so. Diese Datei wird NICHT ins Handy geflasht, sondern ist eine Parametertabelle für das Flashprogramm selber. Dort ist sie aber extrem wichtig - der kleinste Fehler darin kann den Tod des Handys bedeuten (also Reparatur nur noch durch Platinentausch).

Nur das, was .smg heißt, kommt ins Handy. Die Größe dieser .smg kann durchaus variabel sein. Oder sagen wir so: Eine maximale Größe. Kleiner dagegen ist möglich.
Übrigens - Recalc prüft beim Flasherstellen die Überschreitung der max. Zulässigen Größe.

Mit anderen Worten: Nur die CG's selber sind entscheidend (im Handy). Die Zusammenhänge sind sehr komplex, da sich die CG's selber überprüfen.

 

Dem muss ich wiedersprechen. ME weiß jetzt worum es geht.
Es gibt CGs deren Lage man getrost verschieben kann um diese CGs in anderen Modellen zu verwenden. Hier jetzt allerdings nur Synergy.

 

dass es für CGs (individuelle!?!) Maximal-Größen gibt deutet auf eine fest position der CGs hin mit begrenzt variabler Länge.

vll. kann man den mechanismus austricksen, indem man eine signierte mini-cg voranstellt welche die signature-prüfung befriedigt und dahinter eine unsignierte tatsächlich verwendetet CG.


*edit*

Fa. Aleph One hat Interesse bekundet an unyaffs(2)-programmen.
Diese wurden in den Projekt-Queue an zweiter Stelle die Erschaffung von unyaffs(2) gestellt!
Damit wird der Inhalt der yaffs(2) ohne Umweg über den mount möglich!!! :D