für die Leute, die wissen was Sie tun, hier mal eine experimentelle Soft
zum Entpacken des internen Filesystems / Resourcen grabben bzw.
Berechnen der CRC der amss.mbn und *.qapp :)
AMSS-Analyzer 1.51
Die Software benötigt Net.Framework 2.0 oder besser.
Die Soft ist Release Candidate, und Support ist noch keiner vorgesehn :mrgreen:
Möge die Soft neue Möglichkeiten eröffnen, um das EF81 besser kennenzulernen.
Btw. die Soft sollte auch mit dem SXG75/EF81C bzw. anderen Brew Modellen gehen.
Cya n have fun,
Viper BJK
P.S.: In diesem Thread gibts immer die aktuelle Version :)
Das Experimentieren mit dieser Software geschieht auf eigene Gefahr.
The software you can download here is for professional use only.
It helps to understand the structure of the Brew Amss (*.mbn / *.qapp) and is able to extract parts and to generate CRCs out of it. You may also able to use it with other BREW phones like the SXG75, EF81C, SL91.
For experimental use only.
corwin
25.10.2006, 21:45
Viper, SUPER!
Vielen Dank, genau darauf hab' ich gewartet :) :) :)
adfree, schon gesehen?
marrat
25.10.2006, 22:07
adfree sieht alles :-D
Gruß, marrat
corwin
25.10.2006, 23:49
LOL, den Eindruck hab' ich auch :)
viperbjk
26.10.2006, 01:10
So .... die Beta 2 ist draußen.
Neu :
Die Anwendungen (.c, .cpp / Binary) können jetzt auch gesucht und extrahiert
werden. Leider ist diese Funktion im Gegensatz zu den anderen sehr ungenau,
da sich für die Anwendungen keine eindeutige Header-Footer-Berechnung finden lässt. Sobald ich das passende Filesystem-Table gefunden habe wird dies natürlich korrigiert.
Cya und viel Spaß damit,
Viper BJK
corwin
26.10.2006, 09:38
Servus Viper,
wieder win Schritt näher! Sind die .c Dateien Compilat? Sind die zu dekompilieren? Kriegt jemand auch den umgekehrten Schritt bis zur fertigen AMSS.mbm wieder hin?
Bin im Besonderen an der Clamshell-schliessen-schliesst-Programme-Funktion interessiert :)
Ciao,
Corwin
Keyser Soze
26.10.2006, 09:49
Ihr seid ja krass :shock: :mrgreen:
viperbjk
26.10.2006, 12:12
Tach Corwin,
Sind die .c Dateien Compilat?
Yep, die .c Dateien sind Compilat
Sind die zu dekompilieren?
Decompilieren ist nicht, es sei denn jemand hat nen ARM-Decompiler.
Aber da die Dateien in C verfasst wurden wird da nur Schrott rauskommen.
Reines Disasm ist aber möglich.
Kriegt jemand auch den umgekehrten Schritt bis zur fertigen AMSS.mbm wieder hin?
Kaum anzunehmen. Aber wir sind dran :)
Große Sorge bereitet immer noch die Struktur ... Noch ist
nicht richtig ersichtlich, wie die Dateistruktur zusammenhängt, bzw.
welchen Aufwand es darstellt, das auseinanderzufusseln.
Ziel ist es nach wie vor die Checksummen zu finden. Denn haben wir
die erst mal gefunden, sind wir nen MEGA-Schritt weiter. Dann
kann man auch mal anfangen das Handy umzuschreiben.
Die Vermutung ist, dass die Amss.mbn aus mehreren Blöcken besteht
(ca. 3 Stück)
Cya,
Viper BJK
viperbjk
27.10.2006, 12:10
So ... die neue Beta 3 ist draußen :mrgreen:
Änderungen :
-------------
- Neues Layout
- Die Berechnung von Checksummen ist jetzt möglich
- Das Extrahieren der Magic-Table (notwendig für CRC, Verschlüsselungen)
ist nun möglich
Achtung !
Längen und Startpositionen bei CRC müssen als HEX-Werte eingetragen werden :)
Wird nichts angegeben, wird automatisch die gesamte amss.mbn genommen.
Changes :
----------
- New Layout
- Calculation of CRC is now possible
- Extraction of CRC/Encryption Magic-Table is now possible
Cya 'n' have fun,
Viper BJK
corwin
27.10.2006, 17:08
:prayer:
viperbjk
27.10.2006, 21:34
Beta 4 ist draußen .....
Änderungen :
-------------
-BugFix :
Wird der falsche Output-Pfad anzugegeben, kommt ne Fehlermeldung :)
-Feature :
Man kann jetzt die CRC-Blocklänge angeben. 0x200 bytes ist standard.
Cya,
Viper BJK
viperbjk
27.10.2006, 23:14
Beta 5 ist draußen ...
Features :
----------
Jetzt mit Support für *.qapp (Betrifft im speziellen die SXG75 User) :mrgreen:
Einfach zuerst die Datei über "Search MBN/QApp" auswählen ...
und dann die jeweiligen Funktionen auswählen.
Cya, Viper BJK
adfree
27.10.2006, 23:24
Danke viperbjk. Einfach megageiles Tool. :up:
Zum Thema SXG75. Ich würde mich freuen. Wenn Jemand den "kleinen" Fehler findet, der sich in FW26 eingeschlichen hat. Warum das 240x320 Video nicht mehr Fullscreen ist?
Jetzt lassen sich Dateien wunderbar vergleichen. Ein bissel Rumschmökern... :up:
Das wäre vielleicht mal ein Ausgangstest. :mrgreen:
MfG
viperbjk
28.10.2006, 00:24
Beta 6 ist draußen ....
Bugfix :
-------
- CRC was not calculated correctly. Serious bug fixed !
Cya,
Viper BJK :mrgreen:
viperbjk
28.10.2006, 00:38
Oki ... wenn ihr euch mal z.B. die W5V022.qapp anguggt ...
dann geht der Boot Sektor bis ca. 0x749F ... das würde auch gut ins Schema passen. bei 74A0 würde dann ne 4 byte lange crc kommen, d.h. 84670D03 => checksumme muss also 030D6784 sein. Jetzt müssen wir nur noch herausfinden mit meinem tool, welchen start, welche länge und welche blockgröße verwendet wird um auf diese checksumme zu kommen.
Es kann aber auch sein, dass dies eine längenangabe ist und keine checksumme. Fakt ist aber dass checksummen genau 32-Bit lang sind bei qualcomm, also genau 4 bytes im file sein müssen (inkl. aller 00en, nicht zu vergessen !)
Ich denke wir sollten da erst mal ansetzen. Vielleicht programmier ich noch n Automatisierungsprogramm zur automatischen Checksummenkontrolle.
Falls ihr euch fragt : Wieso das denn ?
Ganz einfach .... Ziel ist es, herauszufinden, welche Checksummen verantwortlich sind dafür, dass man die .mbm/.qapp nicht einfach so verändern kann und z.B. nen neuen Mediaplayer in die Firmware setzen kann.
Hiermit kann jeder "Forscher" hier mal loslegen ... bewaffnet mit nem Hexeditor , meinem Tool und nem Taschenrechner :)
Viel Spaß beim rumexperimentieren,
Viper BJK
P.S.: Den kleinen "Fehler" beim SXG75 finden wir sicherlich schon bald :)
adfree
28.10.2006, 01:27
Ich habe mir mal die *.C aus dem MPlayer vorgenommen.
SXG75 FW22 und 26
Erste Sichtung:
- sprechende Namen :up:
- gleiche Anzahl Dateien :up:
- gleiche Namen :up: sogar gleiche Größe
1 einzige Datei identisch, die wars also erstmal nicht. :lol:
MPlayer_MPFormStreamingVideo_OptionMenu.c die wars nicht.
Bleiben 43 von 44. Da sollten Dateinamen wie diese hilfreich sein:
MPlayer_CommonFunctions.c 85 Unterschiede
Man kann ein bissel Text erkennen...
Hilfsmittel zum Beispiel auch Total Commander, macht Dateivergleich nach Inhalt.
Vergleichen der verschiedenen FWs, nach Anzahl... Grösse... Vielleicht ist das Schema nahezu gleich? Und es werden echt nur 1 oder 2 Byte geändert?
Beim SXG75 ist es "einfacher". 2 FWs. :roll:
Beim EF81 gibts mindestens, als 3GSwup im Netz:
27,39,40,48
Genug Stoff um ein bissel Sherlock Holmes zu spielen. :mrgreen:
Wäre supi, wenn sich noch Freiwillige am Suchen beteiligen. :up:
MfG
adfree
28.10.2006, 01:54
Oki, gleiches Spielchen FW40 und FW48 beim EF81
Verzeichnis MPlayer
Diesmal sinds je 49 Dateien, also 5 mehr als beim SXG.
MPlayer_DummyForm.c :lol:
MPlayer_JavaLaunchedForm.c
MPlayer_MPFormSVG.c
MPlayer_MPFormSVG_OptionMenu.c
MPlayer_TabViewOut.c
Capt_Future
28.10.2006, 11:22
Hallo zusammen!
Prima, da scheint Euch ja was Großartiges gelungen zu sein! Könnt ihr vielleicht mal für jemanden, der sich zwar gerne mit dem SXG75 auseinandersetzt und diesbezüglich alle Threads gelesen hat, erklären, was man mit dem Proggy
machen kann?
Ist mit dem Proggy jetzt theoretisch die "selbständige" Behebung der immer noch auftretenden Bugs möglich?
Das lässt vorallem die hoffen, die dem SXG75 trotz einiger Bugs die Treue gehalten haben, sich aber mit Bits und Bytes nicht auskennen...
Wünsch euch auf jeden Fall beim weiteren experimentieren und programmieren viel Erfolg!
Gruß,
Harald
viperbjk
28.10.2006, 13:16
Natürlich ... mit dem Programm kann man primär die Firmware des Handys
analysieren um herauszufinden, wie das Handy funktioniert und welche
Features es hat, die vielleicht noch versteckt sind.
Ein selbstständiges Beheben von Bugs ist damit noch nicht möglich ...
leider fehlt hierfür noch ein Stapel an Informationen, da es momentan noch nicht möglich ist, die Firmware umzuschreiben. (Problem der Checksummen)
Was aber mögich ist, ist das Finden der Ursache der Bugs ... dazu benötigt
man aber noch zusätzliches "Werkzeug", Geduld und viel Nachdenken :)
Cya, Viper BJK
Hallo zusammen!
Prima, da scheint Euch ja was Großartiges gelungen zu sein! Könnt ihr vielleicht mal für jemanden, der sich zwar gerne mit dem SXG75 auseinandersetzt und diesbezüglich alle Threads gelesen hat, erklären, was man mit dem Proggy
machen kann?
Ist mit dem Proggy jetzt theoretisch die "selbständige" Behebung der immer noch auftretenden Bugs möglich?
Das lässt vorallem die hoffen, die dem SXG75 trotz einiger Bugs die Treue gehalten haben, sich aber mit Bits und Bytes nicht auskennen...
Wünsch euch auf jeden Fall beim weiteren experimentieren und programmieren viel Erfolg!
Gruß,
Harald
viperbjk
28.10.2006, 23:33
Ok ... wir kommen der Sache immer näher ...
die amsshdr.mbn ist eine Header Datei, in welcher
die Länge und die Stelle des Checksummenblocks der amss.mbn enthalten ist.
Die Checksumme ist am Ende der amss.mbn und scheint wohl irgendwie sowas wie ein ECC-Verfahren zu sein .... vermutlich Hamming .... näheres wird gerade analysiert. Die Blocklänge konnte immerhin auf ca. 200-210 byte festgelegt werden.
Cya, Viper BJK
lolz
31.10.2006, 22:07
can someone show me how to take the amss.mbn file from the EF81 ? :mrgreen:
thx :up:
viperbjk
01.11.2006, 16:31
Actually the only "true" possibility of getting this file is to download a
"3GSwup"-Version of the firmware. It is included in the package :)
Cya, Viper BJK
adfree
23.03.2007, 04:28
@ Viper BJK
Danke nochmal für dieses großartige Tool. :up: Es hat sehr viel Licht in das BREW-Dunkel gebracht.
MfG
onemandivision
26.03.2007, 18:58
Ich hab außer der videovollbildfunktion noch eine andere anregung für euch :D (adfree weiste noch mit meinem kommentar die firmware umzuschreiben? :D - fett jetzt gehts vielleicht wirklich)
Beim ef81 kann man im mediapool zwischen den geöffneten dateien hin und herschalten. das ist bei musik sehr praktisch weil man dann nicht jedesmal nach einem lied zum ordner zurück muss um dann das nächste lied zu starten. das macht er dann wie beim media player selber! wär cool wenn das beim sxg75 auch ginge!
Manuelc
26.03.2007, 19:23
Nee wirklich der will die Firmware umschreiben näääääääää, das gibts doch nicht, sowas das ist ja´n komischer Typ!
Mal ernsthaft, adfree kann die Firmware noch nicht umschreiben, er hat schließlich kein Tool, wie du eben richtig gesagt hast! Das hierbesprochene Tool, ist nur ein Extractor der AMSS/MBN.
Trotzdem, vielen vielen Dank an viperbjk
mfg Manuel
kraze1984
27.03.2007, 14:25
Vielen, vielen dank an viperbjk fuer das Tool. Ich hoffe das Sie werden es weiter entwickeln um die BREW gerate mehr interessant machen!
:-D :up: :up:
viperbjk
01.04.2007, 02:53
Die Software ist noch nicht tot :)
Nur momentan auf Eis gelegt, bis neue Erkenntnisse da sind.
Sobald ich neues erfahre / erforsche wird es in die Software eingearbeitet :)
Cya, Viper BJK
viperbjk
16.04.2007, 13:13
RC1 ist draußen .....
Änderungen :
-------------
-BugFix :
Kompletter Rewrite der Software, Verbesserung von Algorithmen
(Stringreference jetzt deutlich schneller)
Bugfixes im Bereich internes Filesystem
-Feature :
Neue Oberfläche, einfacher zu bedienen.
Extrahieren der CRC-Tabelle am Ende des AMSS
Neue Magic-Tables gefunden, E81C wird unterstützt.
Sonstiges :
Passwort gefunden in AMSS für sqlite ? => "KILLMENOW"
Cya,
Viper BJK
madmax
16.04.2007, 13:29
Sonstiges :
Passwort gefunden in AMSS für sqlite ? => "KILLMENOW"
*angsthab* ;)
Muss mich doch mal damit beschäftigen...
adfree
16.04.2007, 13:59
Stringreference jetzt deutlich schneller
:mrgreen:
Da hast Du ja ganz schön den Turbo eingelegt. :up:
E81C geht auch. Sehr schön.
Zu KILLMENOW. Wenn ich etwas weiter nach unten gucke. Dann fällt mir etwas auf. Die Einträge die ich durch Zufall mal auf dem Handy hatte. Siehe Bild:
http://forum.modopo.com/showpost.php?p=164365&postcount=7
Danke
viperbjk
17.04.2007, 18:53
News ...
sieht so aus, als ob die AMSS.mbn "gegluet" ist.
Die Applikationen haben keinerlei echte Referenz. Ich vermute mittlerweise, dass
die Informationen, wo welche Datei beginnt, in einer externen Datei existiert oder
in einem versteckten Sektor.
Mal guggn, was der Frühling so bringt *hehe*
Cya,
Viper BJK
viperbjk
17.04.2007, 18:54
RC1.1 ist draußen .....
Änderungen :
-------------
-BugFix :
Es können jetzt beliebige .mbn geöffnet werden (request by adfree)
Wenn die Datei benützt wird, gibts ne Fehlermeldung
Sonstige Bugfixes
Sonstiges :
Hold * key to reset & log abort
Hold # key to enter download mode
Guess what this file is for ?
=>fs:/shared/dmDelta.bin
Yes, it's OTA *grin*
Cya,
Viper BJK
viperbjk
24.04.2007, 01:55
So ... die neue RC1.2 ist draußen
Bug-Fixes :
-------------
- Falls die Speicherberechtigungen fehlen, werden Fehlermeldungen ausgegeben
- Geschwindigkeit weiter optimiert
News :
-------
Root Certificates (.cer) können extrahiert werden
Changes :
----------
- Bugfixes
- Root Certificates can be extracted
Cya 'n' have fun,
Viper BJK
P.S.: Identification module of Binary Files soon to be released :)
Dread
24.04.2007, 09:51
Only one question. how download in phone svn without bugs?
viperbjk
24.04.2007, 12:40
So ... die neue RC1.3 ist draußen
Bug-Fixes :
-------------
- Geschwindigkeit weiter optimiert
Only one question. how download in phone svn without bugs?
Please be more specific, as for me it seems to be OT.
Cya, Viper BJK
viperbjk
24.04.2007, 19:24
Mal wieder was neues ... RC1.4 ist draußen :)
Bug-Fixes :
-------------
- Interne Checks gefixt
News :
-------
CRC Sektion wird richtig extrahiert durch das Verwenden der Headerfiles
(amsshd.mbn, *.qapphd)
Changes :
----------
- Internal Checks fixed
- CRC section can be correctly expanded
Cya 'n' have fun,
Viper BJK
P.S. :
Die AMSS scheint nicht "gegluet" zu sein, sondern ist einfach nur ein Sourcecode, der compiliert wird. Somit existiert auch kein "Filetable" oder
ähnliches. Die AMSS ist die Anpassung an die Hardware und ist durch ein CRC-Feld am Ende des Files gegen unerlaubte Veränderungen geschützt.
Die Resourcen, die wir extrahieren können, sind anscheinend Resourcen, die mit in das File compiliert werden. Somit ist auch die Funktion des Header-Files endgültig geklärt. In ihm steht, wo der CRC-Block beginnt und wo er aufhört. Vielleicht auch, wieviele Blocks er beinhaltet. Mehr aber auch nicht.
adfree
24.04.2007, 19:46
Welche AMSS nimmst Du als "Referenz"?
Mir ist nur aufgefallen, das eventuell je nach Version Deines Tools und AMSS mehr oder weniger ein paar kleine Änderungen vorkommen...
Beispiel. Der Ordner CFG/Settings ist bei den neueren Versionen...
Bei RC 1.3 gab die SVN23 vom SL91 eine Fehlermeldung bei Info->MT 1
Bei RC 1.4 kommt das bei CRC
Error :System.IO.FileNotFoundException: Could not find file 'E:\MBN\AMSS\AMSSSL91\amsshd.mbn'.
File name: 'E:\MBN\AMSS\AMSSSL91\amsshd.mbn'
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy)
at System.IO.FileStream..ctor(String path, FileMode mode)
at MBN_Resourcer.Form1.magictable4CRCToolStripMenuItem_Click(Ob ject sender, EventArgs e)
Also eventuell das wir uns auf ein AMSS einigen können, als Referenz für Dein Tool, um es richtig beurteilen zu können.
Vielen Dank das Du Dir die Mühe machst. :up: :up: :up:
viperbjk
25.04.2007, 00:04
Die Fehlermeldung bei der RC 1.4 ist beabsichtigt. Der Grund : die Position des CRC wird aus der Headerdatei (beim EF81 amsshd.mbn, bei anderen Modellen wie z.B. SXG75 *.qapphd) ausgelesen. Ist diese Datei nicht vorhanden, spruckt er auch keine CRC sondern diese Fehlermeldung aus.
Zum Fehler mit der SVN23 vom SL91 .. her mit der AMSS, damit ich den Fehler reproduzieren kann :) Schließlich soll meine Soft für alle Benq ODM/Qualcomm gehen. Momentan dienen mir verschiedene AMSS von SXG75, EF81 und EF81C als Referenz.
Das mit dem Ordner CFG/Settings hab ich allerdings nicht kapiert.
Seit der ersten RC wurden alle Routinen / Algorithmen völlig überarbeitet die in der Beta noch vorhanden waren, kann also durchaus sein, dass da noch viele Bugs begraben sind. Dafür arbeitet aber das Programm jetzt deutlich zuverlässiger und vorallem deutlich schneller :)
Welche AMSS nimmst Du als "Referenz"?
Mir ist nur aufgefallen, das eventuell je nach Version Deines Tools und AMSS mehr oder weniger ein paar kleine Änderungen vorkommen...
Beispiel. Der Ordner CFG/Settings ist bei den neueren Versionen...
Bei RC 1.3 gab die SVN23 vom SL91 eine Fehlermeldung bei Info->MT 1
Bei RC 1.4 kommt das bei CRC
Error :System.IO.FileNotFoundException: Could not find file 'E:\MBN\AMSS\AMSSSL91\amsshd.mbn'.
File name: 'E:\MBN\AMSS\AMSSSL91\amsshd.mbn'
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy)
at System.IO.FileStream..ctor(String path, FileMode mode)
at MBN_Resourcer.Form1.magictable4CRCToolStripMenuItem_Click(Ob ject sender, EventArgs e)
Also eventuell das wir uns auf ein AMSS einigen können, als Referenz für Dein Tool, um es richtig beurteilen zu können.
Vielen Dank das Du Dir die Mühe machst. :up: :up: :up:
adfree
25.04.2007, 00:34
:oops: Sorry.
Ich habe nicht die Fehlermeldung gelesen und ...
Hatte doch meinen Ordner nur mit den umbenannten AMSS.MBN bestückt...
MfG
viperbjk
25.04.2007, 01:13
Die RC1.41 ist schon in Arbeit ...
vorab :
Ne menge Bugfixes in Bezug auf Kompatibilität mit EF81,EF81C,EF91 und SXG75
Grafische Analyse jetzt auch für BMP, GIF und PNG und Zertifikate :)
Endlich ! Zertifikate werden jetzt zu 100% korrekt extrahiert und können ohne Probleme am PC importiert werden.
Somit ist es demnächst möglich, auch die .sig Dateien zu extrahieren :)
Cya, Viper BJK
P.S. : adfree, denk dir nix, passiert mir auch ständig :roll:
viperbjk
03.05.2007, 15:47
News :)
Es scheint so, als ob die Checksumme per ? AES-G ? über Blöcke berechnet wird.
Die Rjindael-Tabelle findet sich genau drei Mal im AMSS, zweimal in Verbindung mit AES-Libraries. Die Checksumme hat eine WORD-Größe, also 4 bytes pro Block. Wenn ich/wir jetzt herausfinde/n, wie groß die Blöcke sind, kann die Checksumme berechnet werden ... und der Weg für Patches ist offen.
Vielleicht hat es etwas mit NAND Flash page size oder block size zu tun... Hab nix den Datasheet fuer Toshiba TH58DYG0AA2XGP5 gefunden (SXG75 NAND Memory), probier mal 512 bytes oder 2112 bytes.
For TH58NVG1S3AFT05 (2 GBit chip, ours is 1 GBit) page size is 2112 bytes
Hope this is useful...
viperbjk
06.05.2007, 15:52
Die Sache scheint jetzt doch anders zu sein.
AES-G fällt aus dem Raster, weil ein blockweises Ändern dazu führt, dass das Handy dennoch nicht startet ... dabei ist es egal, ob Werte dword, byteweise jeweils in der Zeile oder in der Spalte ausgeglichen werden.
Der Start der Checksum ist in jedem Flashfile markiert, allerdings immer an unterschiedlichen Stellen. Man kann sie jedoch finden, wenn man nach 0xFF 0xFF 0xFF 0x3F sucht. Z.B. beim EF81 :
00002E20 FF FF FF 3F 44 64 00 00 ÿÿÿ?Dd..
wobei hier die Checksumme bei der Adresse 00006444 beginnt und bis zum Ende des AMSS geht.
Blocklänge ist hierbei immer 0x200.
Mein nächstes Release wird die Checksumme des AMSS.mbn richtig berechnen. Die Frage ist allerdings, wo die Checksumme hinterlegt ist (vielleicht ist sie noch einmal gexort oder wird verschlüsselt hinterlegt)
Cya, Viper BJK
adfree
06.05.2007, 16:08
Da ich leider nur die SVN 22 vom SXG75 als FK und PK habe. :(
Wo ein einziges Byte anders ist.
Müsste es eventuell nicht eineindeutig sein. Was berechnet werden "muß"?
Versuchsanordnung wäre halt. Beide SVN 22 vom SXG75 um die letzen 256 Byte kürzen.
Du müsstest meines Erachtens dann, mit Deinem Algo entweder auf die 256 Byte vom F oder vom P kommen.
Ich glaube nicht das es mehrere Lösungsmöglichkeiten gibt...
Kenne noch Jemanden, der eventuell eine PK Version hat, wozu ich die FK habe...
Das wäre eine brauchbare Referenz. Sollte sich dort rausstellen, das auch nur ein Byte anders ist...
kraze1984
06.05.2007, 16:19
Die Frage ist allerdings, wo die Checksumme hinterlegt ist (vielleicht ist sie noch einmal gexort oder wird verschlüsselt hinterlegt)
Meinst du im AMSS.MBN oder in andere .MBN ?
adfree
06.05.2007, 16:26
Dann wäre schonmal als erster Schritt, die "Transformation" von Fieldtest Key in Production Key möglich...
Haben ja genug Fieldtest Firmware. Wo man mal ein P eintragen könnte, statt dem F. :mrgreen:
Wer weiß was sonst noch alles in die Berechnung einfließt...
viperbjk
06.05.2007, 17:14
Meinst du im AMSS.MBN oder in andere .MBN ?
egal ... ob nun amss.mbn oder andere .mbn.
Ich vermute stark, dass die letzten 256 byte mit der checksumme zu tun haben.
Im amss.mbn muss hinterlegt sein, wie die checksumme zu lesen ist.
D.h. Arm decompiler / disassembler müsste her. Den Algorithmus für die Berechung der CRC kenne ich bereits.
Übrigens .... das erste Byte im AMSS liefert den Pointer auf den CRC-Start, den ich im letzten Post angegeben habe. Mir fehlt nur noch ein kleines Teil vom Puzzle.
Adfree .... schick mir bitte nochmal die SVN mit dem einen Byte Unterschied :)
Hatte letztens einen Plattencrash :(
Cya, Viper BJK
viperbjk
06.05.2007, 17:21
Da ich leider nur die SVN 22 vom SXG75 als FK und PK habe. :(
Wo ein einziges Byte anders ist.
Müsste es eventuell nicht eineindeutig sein. Was berechnet werden "muß"?
Versuchsanordnung wäre halt. Beide SVN 22 vom SXG75 um die letzen 256 Byte kürzen.
Du müsstest meines Erachtens dann, mit Deinem Algo entweder auf die 256 Byte vom F oder vom P kommen.
Ich glaube nicht das es mehrere Lösungsmöglichkeiten gibt...
Kenne noch Jemanden, der eventuell eine PK Version hat, wozu ich die FK habe...
Das wäre eine brauchbare Referenz. Sollte sich dort rausstellen, das auch nur ein Byte anders ist...
Mein aktueller Sachstand ist folgender :
Zuerst geht das Handy an den Anfang, liest das erste Byte aus, erstellt per Algorithmus einen Pointer für den CRC-Start, der aus dem Startvektor (0x3FFFFFF) besteht und der der eigentlichen Adresse des CRC-Starts.
Dann wird die CRC bis zum Ende des Files berechnet und dann am Ende ?? des AMSS verschlüsselt per AES ?? hinterlegt. Ob das nun alle 256 Bytes sind, oder nur die letzten 4 Bytes .... mal guggn.
AES S-Key Tabellen wären hinterlegt ....
Ehrlich gesagt kenne ich keine kommerzielle Firmware die so heftig geschützt wie die des AMSS von Qualcomm :(
adfree
06.05.2007, 17:42
Also grob aus meinem Gedächtnis und mit meinem Laienwissen. Ist es komplett anders... Also keine Übereinstimmung zwischen den beiden SVN 22.
256 Byte total anders... :(
Du kannst Dir aber selbst ein Bild machen. Dauert noch nen Moment...
Nachtrag:
Also wegen dem MMTO Dingens...
Könnte es sein. Das in die Berechnung die 256 Byte der qcsbl.mbn mit einfliessen?
Dann wären es 2 Konstante. Also entweder die 256 Byte der FK oder der PK qcsbl...
Killert68i
12.05.2007, 13:30
Hi! Is there any news??? :(
Maybe we would create a team to work together on discovering firmware???
Threre are a lot of good programmers and advanced users who are working with Siemens on forum.oslik.ru and forum.allsiemens.ru and other forums...
If it is real idea, maybe we will try to interest more people on discowering FW`s... :)
P.S. I`m owner of EF81 and SXG75, both it is not stable in work. We need to improve a lot of bugs in FW to get stable work!!!
adfree
12.05.2007, 19:44
The biggest problem is, how to create the last 256 Byte of AMSS.MBN
If you compare 2 versions from same SVN and SWBuild. Main difference between Production Key and Fieldtest Key is only 1 Byte.
F or P
But the 256 Byte at the end from Amss.mbn is complete different. :(
How to create an 256 Byte key for 1 character?
What is MMTO?
Best Regards
Killert68i
12.05.2007, 23:30
At the moment I`m trying to interest people on our problem... I hope that we will succeed to make a team for futher working on firmware :)
adfree
12.05.2007, 23:43
I hope we found a few user. :up:
forum.oslik.ru seems more SX1 interests? I can't see topics without registration.
But I don't give up. :mrgreen:
Best Regards
Killert68i
15.05.2007, 19:49
And what about user firmware??? It`s selfcopying microprogram to phone memory and then phone installs it... maybe we should try some to understand how it works??? We also have internet (over the air) way to update, but it`s no more support here... :(
Killert68i
16.05.2007, 20:35
Maybe it will be interesting: http://forum.allsiemens.com/viewtopic.php?p=601900#601900
As I understand: way to work with phone when it is off
viperbjk
24.05.2007, 17:18
Unluckily, my power supply just killed some components, so I had
to rebuild my PC.
I think I can work again on the project in a few days :)
Cya,
Viper BJK
Killert68i
25.05.2007, 09:37
:prayer:
viperbjk
08.06.2007, 10:38
Ok ... a new version is soon to be released.
New features will use the Communication Port in order to read
out Memory and NVItems, furthermore Mode-Setting like Download-Mode or FTM -Mode.
Cya,
Viper BJK
kraze1984
08.06.2007, 13:50
Will it read ALL the NVItems?
viperbjk
11.06.2007, 16:29
Yes, all 65535 NV-Items. It already works under test procedures.
Cya, Viper BJK
kraze1984
11.06.2007, 20:05
You are the best :)
viperbjk
12.06.2007, 20:32
New Version 1.5 is out.
----------------------
News :
-------
Diag Mode Tool added.
Now possible to save a specific NV-Items and a specific Memory Range using
the Diagnosis Comport etc.
Have fun,
Viper BJK
P.S.:
AMSS Checksum is calculated by hash (HMAC-SHA1) and signature (RSA-2048)
Killert68i
12.06.2007, 22:54
Great work! Thanks a lot!!! You are our last hope :)
p.s. What is the next..?
viperbjk
13.06.2007, 00:50
Great work! Thanks a lot!!! You are our last hope :)
p.s. What is the next..?
Next subversions (1.51 - 1.59) will include some bug fixing for Vista.
Next higher build (1.6) will include backup and restore of SMS in NVRam.
Also I thought about a testing tool for buffer overflow exploits *yes, already found some*.(1.7 maybe)
Whilst summer I wanted to analyse CEFS. Hopefully there are a lot of interesting things :)
Cya,
Viper BJK
viperbjk
13.06.2007, 03:18
New Version 1.51 is out.
----------------------
Bugfixes :
----------
Com Port under Vista supported.
NV Items / Memory were not correctly read.
Monitoring features added.
Information :
-------------
No other program may use the Diagnosis Port (quit QPST Server !)
For usage, you must first load a amss.mbn or other amss (qapp)
You can specify where to start and where to end when using NVItem Read.
Full Range is already inserted in the boxes for full read of NVItem / Memory.
=> NVItems from 0 to max 0xFFFF
=> Memory from 0 to max. 0xFFFFFFFF
DO NOT USE HIGHER VALUES .... higher ones may crash your mobile
(Denial of Service)
NVItems and Memory reading takes a lot of time .. so wait, look at the progressbar and have a cup of tea :)
Killert68i
23.06.2007, 22:53
2 viperbjk:
How to "Read memory"??? I used almost all features (like Read NVitems) and available ports - all works... but "Read memory" gives no result :(
And how to be with readed NVitems, how to transform data from output.txt to understandable form??? :oops:
p.s. Sorry for stupid questions... just trying to know more... :)
Killert68i
24.06.2007, 15:56
And what about this (http://www.cdma-ware.com/workshop.html) program???
Some people get full "memory dump" - 128mb... also many other features available!!!
adfree
24.06.2007, 19:07
Not bad. Seems to work. :up: :up:
First result I read only 3 MB, because I can't count correct. :oops:
Now I try to read 36 MB (36000000) and then I will compare it with existing AMSS.MBN.
thanx Killert68i :up:
Killert68i
24.06.2007, 19:31
Not bad. Seems to work. :up: :up:
First result I read only 3 MB, because I can't count correct. :oops:
Now I try to read 36 MB (36000000) and then I will compare it with existing AMSS.MBN.
thanx Killert68i :up:
Our user "Sergpink" read almost all (Uncluding ROM\RAM and even MMC :-D )
He wrote this adresses: 5000:0000 (including MMC -> 1.25 GB)
Where is Viper BJK??? Want to hear his opinion about!!!
adfree
24.06.2007, 19:44
I think 128 MB would be enough to read...
Because 115 KBaud is not so fast...
After 40 Minutes I have only 63 % of 36 MB. :up:
And again Start 0 is only Amss.mbn - CEFS
We can't read Simsecure and Bootloader at real Start of Memory...
look into partition.mbn.
Correct me, if I'm wrong. :)
Paketmarke
24.06.2007, 21:28
Sorry, für die Frage - aber was macht das Programm eigentlich und für was ist es gut ?! :-\"
Killert68i
24.06.2007, 22:14
I think 128 MB would be enough to read...
Because 115 KBaud is not so fast...
After 40 Minutes I have only 63 % of 36 MB. :up:
And again Start 0 is only Amss.mbn - CEFS
We can't read Simsecure and Bootloader at real Start of Memory...
look into partition.mbn.
Correct me, if I'm wrong. :)
I`m not so experienced to assert anything about bootloader & firmware, it would better ask about this someone, more advanced people, like Viper BJK! :)
And about reading memory:
- first 128mb is ROM
- then 64mb is RAM
- at last MMC, I think this feature is not so important (size and adress depends of MMC size)!!!
All we need now is to know how work with ROM image; is it possible to write back to phone ROM and also write modified ROM...
We also must know how to work with ROM to make any changes in it correctly (patches)!!!
viperbjk
25.06.2007, 00:37
I`m not so experienced to assert anything about bootloader & firmware, it would better ask about this someone, more advanced people, like Viper BJK! :)
And about reading memory:
- first 128mb is ROM
- then 64mb is RAM
- at last MMC, I think this feature is not so important (size and adress depends of MMC size)!!!
All we need now is to know how work with ROM image; is it possible to write back to phone ROM and also write modified ROM...
We also must know how to work with ROM to make any changes in it correctly (patches)!!!
Hi there,
sorry for being away so long :)
ok ... to answer the questions ...
Memory Read and NV Items Read Function is totally experimental atm.
In fact, there were severe bugs due to difficulties in handling buffers and timeouts (thanks QC :( ). These are fixed in an actual testing version to be released soon.
But I've got to face another problem ... I was just experimenting with flashing the phone with my homebrew software as another timeout occured leaving my ef81 brain-dead (no boot loader). Good thing is, I probably found a command to set the phone in the security mode where files could be read and attributes can be changed such as nvm folder.
So I've got to wait for my phone to be hopefully repaired then testing goes on :)
To the memory read out .... the maximum of memory that can be read out is 0xFFFFFFFF (mobile says that). Memory does mean FLASH Memory and not RAM, thus it is as big as partition+amss+EFS+Bootloader, around 70-90 MB.
Don't expect too much infos from it.
Regarding NV-Items .... these are hardcoded ... so, to make it readable by QPST you need a database with structures (no common structure). My Tool just delivers binary data. So with my tool, you are able to find ALL (also hidden) NVItems as it doesn't make use of any database. Maybe I'll find the time to set up a database to make it compatible with f.e. .qcn files.
Breaking / Recalculation of checksum is nearly impossible as long as
there is no private key, as it is encrypted (signed) by RSA-2048 and hashed by HMAC-SHA1 (According to QC Presentation).
Only solution would be to patch the bootloader right now.
Hope these infos help,
Cya,
Viper BJK
viperbjk
25.06.2007, 00:38
Sorry, für die Frage - aber was macht das Programm eigentlich und für was ist es gut ?! :-\"
Tach, es dient zum Entpacken diverser Dateien aus dem AMSS, zur Analyse des AMSS und neuerdings auch zum Diag-Mode testen u.a. vom EF81.
Cya,
Viper BJK
adfree
25.06.2007, 01:13
What we can do with reading Memory (CDMA Workshop)
For instance Dumb the AMSS.MBN from Version which not found as 3GSwup.
SF71 is as Prototype without known 3GSwup... This would be possible to read the phone out. And then u can use viperbjk AMSS-Analyzer to learn more...
For me as an collector of Firmware it is an nice feature. :up: :up:
A few SXG75 Prototypes exist, with special very early "Qualcomm Firmware". Also without 3GSwup.
Regards
viperbjk
25.06.2007, 12:24
Quite sure, as soon as my EF81 is here, I'll write an phone emulator (open source) just to simulate flash procedures so that we can log everything that is sent to the phone. Next step will be to implement flashing in my soft. Maybe we can also use this emulator to see specific behaviour while reading NVItems and Memory.
Cya,
Viper BJK
kraze1984
25.06.2007, 14:41
Hmm, a bit late here :)
Also read and compared a half of my AMSS (a reboot occured on about 6 megs position (adfree, check mail, please :) ))
adfree
28.06.2007, 04:50
My Value is 36500000 (Size (bytes))
This is big enough. To Dumb AMSS.MBN from SG75,SXG75,EF81,EF82,SL91.
E81 and EF91 has bigger AMSS...
100% working without problems. Tested with:
SXG75, EF82, SL91
Next try is to read more from Memory... :mrgreen:
adfree
28.06.2007, 12:58
I removed my MMC from SXG75 and enter max. 99999999 (100 MB).
Result is 100 % Reading "something" out, without Errors or problems. :mrgreen:
Not sure, maybe 3 hours needed...
Also not sure, what I have dumbed. :lol: But it works to read in one piece.
viperbjk
28.06.2007, 16:40
Only Flash ROM will be dumped. Anyways, Diagnosis Mode allows to read out till 0xFFFFFFFF.
Just try to enter FFFFFFFF and see if it works too.
Cya,
Viper BJK
adfree
02.07.2007, 20:57
For 36 MB I need 1 hour... Tested with SXG75, EF81, EF82, SL91...
SF71, SG75, E81 would be very interessting. :mrgreen:
If someone could please confirm?
Attached is an Video, how to dumb Memory (AMSS.MBN).
adfree
02.07.2007, 23:32
Memory, without MMC or SD Card...
We have:
NAND Memory: 128 MB on an chip confirmed. :up:
SRAM Memory: (64 KB) onchip (unknown)
SDRAM Memory: Size and position (unknown)
Who knows about size and position of SRAM and SDRAM? There are onchip with MSM6250(A)?
32-bit SDRAM could be between 32 MB to 128 MB. Not sure, not confirmed...
Killert68i
03.07.2007, 00:54
Memory, without MMC or SD Card...
We have:
NAND Memory: 128 MB on an chip confirmed. :up:
SRAM Memory: (64 KB) onchip (unknown)
SDRAM Memory: Size and position (unknown)
Who knows about size and position of SRAM and SDRAM? There are onchip with MSM6250(A)?
32-bit SDRAM could be between 32 MB to 128 MB. Not sure, not confirmed...
SDRAM is 64 MB
KiRiK
03.07.2007, 09:43
Hi everyone
How can I download the proggy? I see no links to it... THX
viperbjk
03.07.2007, 09:47
You can download it by watching the first post of this topic :)
Cya, Viper BJK
KiRiK
03.07.2007, 09:51
No I can't. AMSS-Analyzer 1.51 is not a link, at least my browser thinks so (Maxthon)
adfree
03.07.2007, 09:58
@ KiRiK
Hi, maybe the Picture/Screenshot can help you.
You see Pictures in Browser?
Best Regards
KiRiK
03.07.2007, 10:06
Oh boy, it's MBN-Resourcer, isn't it? I was looking for AMSS-Analyzer -:) THX
viperbjk
03.07.2007, 11:36
Right. The old name was MBN-Resourcer. I was just lame enough not to rename it :)
Stay tuned for a new version 1.52 soon.
Cya, Viper BJK
Killert68i
04.07.2007, 21:20
2 All:
While learning strucrure of SL91 backUp I observed "SL91.qcn" in root directory... I opened it by BrewResourceEditor and found here a lot of interesting... for example list of all active\used NVitems(is it the same with SXG\EF or different???)...
Is it something like *.qcn in SXG\EF and how to get it???
2 Viperbjk:
What about monitoring memory processes of 3GSwup while we updating\refreshing FW in our phones??? This method was used for patching SX1 - we just starting the FW updater and make changes to FW when it was loaded into PC memory...
p.s. I also have some full back up of Motorola V3c... maybe it will be useful for better understanding BREW...?
viperbjk
12.07.2007, 22:15
What about monitoring memory processes of 3GSwup while we updating\refreshing FW in our phones??? This method was used for patching SX1 - we just starting the FW updater and make changes to FW when it was loaded into PC memory...
p.s. I also have some full back up of Motorola V3c... maybe it will be useful for better understanding BREW...?
Already did that ... result = dead phone :(
Bootloader checks checksum ... so no chance.
Cya,
herry potter
24.07.2007, 10:37
For 36 MB I need 1 hour... Tested with SXG75, EF81, EF82, SL91...
SF71, SG75, E81 would be very interessting. :mrgreen:
If someone could please confirm?
Attached is an Video, how to dumb Memory (AMSS.MBN).
I have seen the video.
Question : Do we have to change the value 65536 to 36500000?
Have you done to your E81?
Regards,
Herry Potter
adfree
24.07.2007, 15:34
I have test this procedure by myself with SXG75, EF81, EF82, SL91.
This Value is for the size. And if you want 36 MB+ you need to enter 36500000.
This procedure also works with SF71. One user has confirmed this. :up:
SG75 should also work...
Gehstock
24.07.2007, 16:23
Die Datei *.qvcefs lässt sich nach dem umbenennen auch öffnen und extrahieren
außerdem könntest du noch support für *.JPG und *.Jar Files Machen
hab beide Dateitypen bisher per hand entpackt was ne ziemliche arbeit ist da die dateien im File zerhackt drinliegen
aufgrund dessen wollte ich mich schon selber an ein solches programm machen bis ich dieses Thema hier gefunden hab
adfree
24.07.2007, 22:48
Das muß dann aber ein Zufallstreffer sein. Die *.qvcefs ist wirklich "zerhackt"...
Ganz kleine Dateien sind eventuell komplett, wenn sie zufällig "richtig" liegen.
Wenn Du ein Idee hast, wie die Datei aufgebaut ist?
Außerdem sind die *.qvcefs vom SG75, SXG75, EF81, EF82 "gleich". Können also auf den Handys geflasht werden...
Beim SL91 und E81 scheint das *.qvcefs anders aufgebaut. Wobei ich nicht weiß, ob das bei beiden gleich ist...
Also ich kann nicht das *.qvcefs vom SL91 auf mein SXG75 flashen.
Eventuell unterschiedliche Blockgröße?
Gehstock
24.07.2007, 23:25
Ne die hab ich wieder zusammengesetzt eigendlich will ich ja an die Midlets und Themes ran
adfree ICQ mich mal an dann können wir und ja was überlegen (ne Idee hab ich) die Dateien sind nicht willkürlich zerhackt zumindest bei den Jpeg gibts ne Regelmäßigkit
herry potter
24.07.2007, 23:45
I have test this procedure by myself with SXG75, EF81, EF82, SL91.
This Value is for the size. And if you want 36 MB+ you need to enter 36500000.
This procedure also works with SF71. One user has confirmed this. :up:
SG75 should also work...
Yes, it works for E81 also without error.
When the size set to 36500000, it reads 35,645 kB in about 1 hour.
If the size set to 50000000, it reads 48,829 kB in about 2 hours.
migraineboy
25.07.2007, 09:47
Imho, flashing SG75 *.qvcefs [W4V0_1201_IP10_2E1_de_2DBRDHandel_00_0012] to EF81 results in blank (white) screen without any action. But this is recoverable.
SG75 CEFS seems to have a different structure. :(
But I experienced that files within a CEFS are actually stored "en bloc". JAR-files and PNG files can completely be extracted: SL91 and EF82 extraction works fine with a HEX-Editor, at least for me :)
adfree
26.07.2007, 00:17
Also JPG Support vom CEFS wäre gar nicht so übel. :mrgreen:
Man könnte auf die Art seine selbstgemachten Bilder aus dem Image wieder rausprügeln:
http://forum.modopo.com/showpost.php?p=153780&postcount=1
herry potter
26.07.2007, 10:32
@adfree, Finally I can understand my current firmware E81 from AMSS.MBN
Hi,
Is it possible to extract the actual amss.mbn from a full dump of the phone's
ROM at address 0x00000000 - 0x07FFFFFF ??? Then use the extracted and
unmodified amss.mbn with 3Gswup?
I have dumped 128mb from my phone using cdma_workshop and I would like
to try writing it back to the same phone if possible (just for experiment).
Best Regards,
skiddd
adfree
30.07.2007, 21:52
Yes it is possible...
But which phone you have? And which Firmware? If 3GSwup exists you can compare. For better understanding. :-D
For flashing with 3GSwup or other Flasher... You need both.
amss.mbn
amsshd.mbn
amss.mbn is possible to extract from dumped *.bin. Simple search for 55000000C0000000 and then after next 256 Byte!
And then you need to generate amsshd.mbn. By using Brain... :lol:
WARNING!!! You need to understand, what you do...
Only these both files amss.mbn and amsshd.mbn for testing...
Or you kill your phone.
kraze1984
30.07.2007, 21:55
No problem.
The amss starts on 0000 0000 position and lasts till the pattern 55000000C0000000, those bytes including. Usually after those bytes there should be a signature of 0x100 (256) bytes. here lies the end of amss.
adfree
30.07.2007, 22:01
On older Firmware... Sometimes the last Signature of 256 Byte not exists... Then you see FFFFFFFF... after 55000000C0000000
Maybe these Version can write into Memory?
One SF71 User has such device... Maybe his SF71 can with QXDM write into Memory?
Maybe a few SL91 have also not Signature at the End?
skiddd
30.07.2007, 22:40
Thanks for the info guys!
I got 0x00000000 upto "55000000C0000000" + 256 bytes and I made an
amss.mbn out of it (about 36MB in size...)
Now how do I manually generate a header file for this? The original header
file for this firmware version contains the following 40 bytes:
Aber im Gerät werden dann halt ca. 10 Dateien in Verzeichnis kopiert. In normale Grafik und Musikdateien. Und halt eine *.bar.
Du findest die Themes also nicht als Paket wieder. Sondern mußt Dir die ca. 10 Dateien zusammensuchen...
Gehstock
31.07.2007, 00:28
Dachte ich biser auch aber die extrahierte datei(oben) enthält zumindest sämtliche bilder nach den Musikformaten such ich morgen
skiddd
31.07.2007, 03:43
@adfree
It's no secret ;-)
I am playing with a EF82 phone...
I downloaded from the internet a file named:
EF82_R13_BRDHandel-std_01_0019.rar which cotained the amss.mbn that I
used for reference. The amss.mbn is 34.5MB in size (36,202,580 bytes).
I flashed it to the phone and made a phone dump using cdma_workshop.
On my first attempt, I put 67108864 bytes to read so that I will get exactly
64MB file which is from offset 0x00000000 upto 0x03FFFFFF. I immediately
see the amss.mbn on my dump.
Now I am thinking if it is possible to use just QXDM + NPRG6250SEC.HEX +
a 128MB dump to flash the phone. I made a New Dump which is now from
0x00000000 upto 0x07FFFFFF (128MB) then I converted it into a HEX file.
I am correct to assume that it is possible to flash this kind of HEX back to
the phone using QXDM??
Best Regards,
skiddd
skiddd
31.07.2007, 06:01
I converted the amss.bin to Intel HEX32 and tried to flash it using QPST.
I put the NPRG6250SEC.HEX to the "Boot Image:" and the converted
amss.hex (97.1mb) to the "Phone Image:"
After Clicking Start, I see...
Status: The Decoding Phone Image
Then
Status: Verifying Phone Image
Then I finally got an error message...
Errors: Phone Image Verification Failed. The Stamp Hash is incorrect.
The amss file that I used came from a 3GSwup installer for EF82. It was
34.5mb before I converted it to Intel HEX32.
Does anybody have knowledge on the "Stamp Hash" ???
Best Regards,
skiddd
adfree
31.07.2007, 07:10
:lol: No risk, no fun... :lol:
Look into partition.mbn...
There is the Limit for AMSS.MBN...
Must look self... :oops: But maybe max. 38 MB for AMSS...
Warning... You can damage your phone!
BTW.: Sorry, i have no idea what you mean with convert into HEX and using QXDM... :shock:
Best Regards
adfree
01.08.2007, 07:57
Yiepie a yeah:mrgreen: :mrgreen: :mrgreen: :mrgreen:
I got it!!!!!!!!!!!!!!!!!!!!!!!
No f. 256 Signature needed. :lol:
The "secret" is the amsshd.mbn :lol: :lol: :lol:
It is so easy...
First success. I changed SVN 23 from SL91 Production Key into Fieldtest Key. :mrgreen: :mrgreen: :mrgreen: :mrgreen:
Gehstock
01.08.2007, 10:17
Und das ging genau wie?
adfree
01.08.2007, 10:41
Verdammt. Jetzt geht der nervende Kameraklick nicht mehr. :lol: Hätte den nicht mit 00 überschreiben sollen. :cool: :mrgreen:
migraineboy
01.08.2007, 10:49
Ich hätte dir das früher schreiben sollen :mrgreen:
p3t3r
01.08.2007, 12:05
Aha. adfree, scheint mir das nur so, oder kann das bedeuten, dass man demnächst auch mal beim EF81 den Camera-Click wegbekommt und vllt. - nur so rein hypothetisch - da mal an so schöne Sachen wie Shuffle, Repeat kommt?
adfree
01.08.2007, 12:20
Das Prinzip ist das Gleiche... Ist also beim EF81 auch kein Problem. :mrgreen:
Ich bin natürlich kein Programmierer, um jetzt mal locker ein BREW Aplett aus dem Ärmel zu schütteln...
Auch weiß ich nicht, ob man die extrahierten Dateien vom SL91 zum Beispiel, ohne Probleme ins EF81 AMSS prügeln kann.
Was aber definitiv kein Problem mehr ist. Production Key oder Fieldtest Key. :lol:
Und die 256 Byte Signature sind Geschichte... :cool: :up:
Wenn man sich an gewisse Regeln hält. Nur AMSS.mbn und AMSSHD.MBN ins Gerät flasht. Dürften auch Fehlversuche kein Problem sein...
Allerdings wird wieder nicht jeder rumdoktorn können.
adfree
02.08.2007, 01:59
:lol:
Da hab ich das Maul mal wieder etwas vollgenommen. :oops:
Also es geht bisher nur auf einem SL91... Dieses hat einen speziellen Zustand...
Ein Zeichen dürfte sein:
Bei Eingabe von *#0606# erscheint eine Fehlermeldung...
Es müssen aber noch mehr solcher Geräte rumschwirren... Also auch EF81 und noch mehr SL91... Ich weiß definitv, das ein SF71 auch ohne diese Signatur existiert...
Es heißt erstmal, das richtige Handy zum Rumspielen finden.
Naja. Ich hab wenigstens die SVN 23 auf dem SL91 und der Kameraton geht mir nicht mehr auf den S...
Mal sehen was ich noch dran basteln kann.
adfree
03.08.2007, 05:06
Erste Spielereien...
Ich kann die ersten 2 Einträge unter *#06# ändern...
Das ist aber nicht das was QXDM zum Beispiel ausliest... oder auch viperbjk sein cooles Tool.
Auch habe ich versucht, das Providerlogo (den Text) zu ersetzen...
Das hatte aber leider nur Auswirkungn auf das, was im Netzmenü angezeigt wird...
Vermutung: Der Text kommt echt von der SIM. :( Also müsste man den Schalter im AMSS finden...
adfree
03.08.2007, 07:32
Grins...
Jetzt verstehe ich auch, wieso beim E81 offensichtlich öfter SVN 33 dastand. Obwohl da nur eine 12 oder 10 drauf war. :lol:
Also ich werde vermutlich den richtigen Eintrag für SVN in diesem Leben nicht mehr finden...
Hab dafür erstmal was anderes gefunden. Also alle BREW Handys die ich testen konnte, hatten sich richtig mit der Bezeichnung gemeldet... Außer SL91, das gab sich als SIE-SXG75 aus. Keine Ahnung, ob Vor- oder Nachteil.
Jedenfalls der String liegt auch im AMSS.mbn.
Dread
05.08.2007, 21:51
Hi
i have 1 question: I read and save all phone memory in service mode by cdma worcshop. change in hex editor model for example (sxg75 to sxg91 twice becouse i find in memory this line twice too). now i wont write it in phone by cdma workshop or by qpst image. its kill my mobile? Tnx.
adfree
05.08.2007, 22:51
To change Entry under *#06# Product number:
Search in AMSS.mbn for asw team
Authors: ASW Team then u see SIEMENS SXG75
The other SXG75 String could be the String what u see in JAVA...
Not confirmed on SXG75. But see my changes on SL91 above...
CDMA Workshop is good for reading/dumping Firmware from SXG75 and so on... But WARNING.
With write you could damage your phone.
I would say you kill your SXG75 with certainly 99.9 %...
Better NOT try with CDMA Workshop. :mrgreen:
Dread
07.08.2007, 07:32
Hi
if u read all memory u find aws team twice. and whot about sl91? u read memory and can write it in sxg75 with out changes with rsa signature. cdma workshop not only program whot write in phone for example qpst image downloading. maybe it is way to doawnloading fullmemory.bin
tnx.
adfree
07.08.2007, 09:44
This is an misunderstanding!
You have only REAL 128 MB NAND Memory.
partition.mbn shows you all MAXIMUM and where to write all parts... the REAL sequence.
But Qualcomm generate an Security concept to masquerade the Real Addresses...
AMSS.mbn don't start at 0 in NAND Memory... You can't NEVER Dump the 128 MB in real sequence.
Again, you could damage your phone with CDMA Workshop. If you try to write back...
For writing back something "new", without 256 Byte Signature. You need an "unfrozen" phone.
Signs for unfrozen phone:
1. (NO IMEI)
2. *#0606# shows Errormessage
ttime
08.08.2007, 03:18
If I dump the memory from ef81c, and rename to AMSS.mbn, is that mean I can replace the Original AMSS.mbn in 3GSwupFU with this one, and update the phone with 3GSwupFU? Therefore I can falsh my EF81 to EF81C, isn't it?
adfree
08.08.2007, 03:31
This is nearly correct Theory... :mrgreen:
Except, you need to create the amsshd.mbn by yourself... Find the real end of AMSS.MBN...
Why you use not existing E81C 3GSwup... :mrgreen:
adfree
11.08.2007, 23:27
http://www.heise.de/newsticker/meldung/94230
... SHA-1 :mrgreen:
Other thing:
I replaced mozzies.mif with content from helloworld.mif in amss.mbn.
The other files I copied with BMC into .../mod/helloworld
Hmm. I get an Unknown Error (1). I read something about path or MIF problem...
The great white hope. :lol:
Maybe it is enough to smuggle in only *.MIF into AMSS.mbn.
Because I can't see, where or what here the *.SIG is? :oops:
All necessary files to integrate is for me at the moment impossible... :(
Helloworld SDK Example has:
helloworld.bid
helloworld.c
helloworld.dll only for PC needed
helloworld.dsp
helloworld.dsw
helloworld.mak
helloworld.mod
helloworld.sln
helloworld.vcproj
Maybe only helloworld.mod is needed also in AMSS.MBN?
Strange... If I search for mozzies.mif I can find 4 Hits:
fs:/mif/mozzies.mif
fs:/mif/mozzies.mif
fs:/mod/mozzies/mif/mozzies.mif ??
fs:/mif/mozzies.mif
Aha. It seems only for mozzies... Because other Apps have only 3 Hits for each *.mif
Dread
19.08.2007, 09:30
Hi
try to change memory adres in brew/mod/brewapp/config.txt in svn.
gl hf!
adfree
19.08.2007, 22:34
:mrgreen:
10000 thanx to NoName®
He was able to dump the whole 128 MB memory with JTAG, from an SXG75.
:up::up::up:
First Impression...
OBL.mbn and PBL.mbn are not the same like EF81, SL91...
MSM6250 and MSM6250A not 100% identical...
I found following in the dump:
File/*.mbn Start
OBL 0
PBL 00008200
partition1 0001C200
partition2 0001C400
partition3 00020200
QCSBL 00080200
OEMSBL 00140200
OEMSBL2 00200200
SIMSECURE 002C0000
AMSS 002D0000
There are some more Data...
januwar
05.09.2007, 07:49
Hi All,
can somebody tell me, how to make the amsshd.mbn after having cut the AMSS.MBN(Dump) 256 bytes after the 55000000C0000000 string?
januwar
05.09.2007, 09:05
OK, I think I got it.
As SkiDDD wrote:
02 00 00 00 -
01 00 00 00 -
B4 00 00 00 -
00 00 00 00 -
54 68 28 02 - end address of 256 bytes after "55000000C0000000"
54 67 28 02 - start address of 256 bytes after "55000000C0000000"
54 67 28 02 - start address of 256 bytes after "55000000C0000000"
00 01 00 00 -
00 00 00 00 -
00 00 00 00 -
It seems I only have to change these 3 strings. Use Hex Editor, go the these two bookmarks (start of 256 string, end of it), write down the position shown in Hec Editor and then write in in, but backwards .-)
Example:
02286854 is position of the end of 256-string. Therefore to be entered string im AMSSHD.MBN will be 54 68 28 08
Am I right?
Cheers
kraze1984
06.09.2007, 10:10
02 00 00 00 -
01 00 00 00 -
B4 00 00 00 -
00 00 00 00 -
54 68 28 02 - end address of 256 bytes after "55000000C0000000"
54 67 28 02 - start address of 256 bytes after "55000000C0000000"
54 67 28 02 - start address of 256 bytes after "55000000C0000000"
00 01 00 00 - change to 00 00 00 00
00 00 00 00 -
00 00 00 00 -
ThAt's better like this
januwar
06.09.2007, 10:43
Thanks :up:
adfree
16.09.2007, 19:58
CDMA Workshop can read more. :mrgreen:
For instance partition.mbn
This is interessting for unknown SF71... But also for some early SG75, SXG75 Prototypes...
Because Partition Override is deadly.
I dumped max. Value 99999999 (100 MB), time 3 hours...
Position is not ever exact same... For each modell type different. I found following adresses for partition.mbn.
partition.mbn
SL91
02695720
EF82
026A9C90
EF81
0269B190
SXG75
026C3D70
Simple search for qcsbl as searchstring in Dump...
Killert68i
17.09.2007, 01:26
CDMA Workshop can read more. :mrgreen:
For instance partition.mbn
This is interessting for unknown SF71... But also for some early SG75, SXG75 Prototypes...
Because Partition Override is deadly.
I dumped max. Value 99999999 (100 MB), time 3 hours...
Position is not ever exact same... For each modell type different. I found following adresses for partition.mbn.
partition.mbn
SL91
02695720
EF82
026A9C90
EF81
0269B190
SXG75
026C3D70
Simple search for qcsbl as searchstring in Dump...
SF71 available here... (http://m6n.ebay.de/__Handys_SF71_W0QQ_nkwZSF71)
migraineboy
18.09.2007, 22:37
After a bit of heavy thinking, I would like to add some lines to adfree's research of the SXG75-dump:
So, one should read out an "unfrozen" BREW-phone in order to find out how the 00003E00 to 00003F20 area looks like in those phones.
Then we would (theoretically) know, what freezes a phone and possibly also what information unfreezes it :mrgreen:
But I'm afraid that this region is write-protected... :(
adfree
18.09.2007, 23:16
I'm nearly 99,9 % sure that "frozen" means this 293 Byte OTP Block...
Yes it means One Time... it is Writeprotected.:cry:
At unfrozen Devices this Block/area is empty...
I have found these Area with CDMA Workshop. :mrgreen: :cool:
Locations:
SL91
02695B40
EF82
026AA0B0
EF81
0269B5B0
SXG75
026C4190
Strange... SL91 and EF82 have same Block... EF81 and SXG75 each different ...
migraineboy
19.09.2007, 09:38
I'm not quite sure if I understand what you mean with the location adresses... :(
[maybe I'm a bit lazy understanding it]
but the area YOU mean (starting in the 128 MB from the 0 address) is the one I was referring to in my previous post:
starting at 00003E00 in the 128MB SXG75-dump
Am I right? I'm a bit confused right now.... :mrgreen:
BTW: you mean, that this area is completely left out? "Filled" with FF? Amazing...
adfree
19.09.2007, 16:08
starting at 00003E00 is only if u dump per Hardware/JTAG
CDMA Workshop reads also more then AMSS (position is also differrent as in JTAG dump)...
Check it out. Use CDMA Workshop. :mrgreen:
adfree
21.09.2007, 21:58
I found this during my search... :-D
Dread
22.09.2007, 19:51
Where is Viperbjk missing?
DebriZ
23.09.2007, 20:38
Hi, all!
Why in 22 firmware file qcsbl.mbn is present, and in 26 firmware is absent?
Thanks for the answer.
adfree
23.09.2007, 20:47
qcsbl.mbn is an deadly useless file, for normal user. :mrgreen:
Deadly:
3GSwupFU2_manual.pdf from EF81 and so on...
Important Note: Using the Emergency Download does only work, in case the phone can manually
be set into Download Mode. In case the process was interrupted during downloading obl, pbl
or qcsbl the phone may be not recoverable.
OBL.MBN and PBL.MBN only found in special... ;)
For an safety Update you never need qcsbl.mbn (+qcsblhd_cfgdata.mbn). Because it never changed... :lol:
DebriZ
23.09.2007, 21:00
I found OBL in OTP zone where dissassembling fullflash, and OBL executes in 0xFFFF0000 address space. PBL in fullflash after OBL. It cannot be changed, as is checked in OBL.
I right?
Next. oemsbl.mbn in 26 and .qoemsbl in 22 are different after 256 byte signature. Can i add some code in to end of this files, correct oemsblhd.mbn and flash? After, change memory in QXDM for jump and execute my code. What can happen thus?
P.S. Excuse me for bad English.
adfree
23.09.2007, 21:38
At the moment.
"Main protection" is IMEI Block 293 Byte in OTP Region 0-4000.
Not eraseble by JTAG- No way find at the moment. :( :no:
OBL and PBL also in protected Area 0-4000. Unchangelable...
All "necessary" files like:
qcsbl
oemsbl
amss
Are protectected by 256 Byte Signature! No changing possible... :(
Algorithm unknown. :-?
Only devices which are unfrozen. Can execute own AMSS with changes. :mrgreen::mrgreen::mrgreen:
Go and find these devices. Most prototypes are unfrozen. To identify them check:
*#0606#
U got an Errormessage. :up:
These unfrozen devices are confirmed:
SG75, SXG75, EF81, EF82, SL91, E81, SF71
Again. No way found to remove 293 Byte IMEI Block to remove 256 Byte Signature Check.
Best Regards
DebriZ
23.09.2007, 22:20
Thanks.
Where I can find/get MSM6250 device specification? :roll:
adfree
24.09.2007, 21:59
After heavy Brainstorming in my little Brain... :lol:
One of the important Key is here:
http://forum.modopo.com/showpost.php?p=176494&postcount=140
If u concentrate your eyes and compare differences... Voilà.
1 of the lost 256 Bytes Signature. :cool:
Maybe viperbjk has now more an chance. To find an Algo to create AMSS.MBN with 256 Byte Sig.
E81, EF82, SL91 has the same Key. SXG75 has different Key. EF81 has also own Key.
SG75 unknown...
SF71 unknown...
migraineboy
25.09.2007, 15:53
a dumb question :oops: : are these 256 byte of AMSS-signature:
1) hash values (like SHA-1 or equivalent in some ways) or
2) SIGNED hash values (asymmetrically signed with some Private Key by Qualcomm)? :-k
I remember some other forum thread talking about 2).
Given the 2nd case,you'll need to find a maths-genius out there for a workaround... :(
adfree
25.09.2007, 17:11
Nothing is impossible and dreaming is allowed. :mrgreen:
Qualcomm Algos are not invulnerable... More then one solution possible...
Remamber
If like in calypso+ MCU, this 256 bytes is certificate signature and before this you have a RSA1024 originator public key (256 bytes) and manufacturer public key RSA1024 (next 256bytes) and SW signature (256bytes).
But this is not so bad... small bug exist
;)
viperbjk
26.09.2007, 01:23
a dumb question :oops: : are these 256 byte of AMSS-signature:
1) hash values (like SHA-1 or equivalent in some ways) or
2) SIGNED hash values (asymmetrically signed with some Private Key by Qualcomm)? :-k
I remember some other forum thread talking about 2).
Given the 2nd case,you'll need to find a maths-genius out there for a workaround... :(
Actually it is both.
The whole AMSS is hashed by HMAC-SHA1.
This hash is signed by RSA-2048, Private Key is Qualcomm / Siemens Property
Realgo is possible, but only as soon as we know the correct hash calculation (they were playing with hamming-ecc). Of course Realgo would take some time ... fortunately we would know the plaintext.
The "small" bug is to exploit the bootloader, same procedure as with sony mobiles. Only problem is : I am no ARM reverser :)
Cya,
Viper BJK
P.S.: My EF81 is alive again ... seems like as my Project can continue soon :)
viperbjk
26.09.2007, 01:44
Some update and thoughts ....
But Qualcomm generate an Security concept to masquerade the Real Addresses...
Nope ... no Security Concept either. It is more or less the same as you can see when reversing a normal PC program. ( same as relative virtual address / RVA to real address / RA ).
Due to stacking and memory management, memory position and file position differ.
Ok ... some thoughts .... we know now where the bootloader gets loaded into memory.
We could find an patch for the bootloader, write it to memory and flash our patched firmware. Should work as long as the battery isn't changed.
Our main goal should be to be able to write to the bootloader itself, best via JTAG to make the patch permanently. Talking about patching ... no, not 255 bytes to FF ... I'm talking about a clean one to maximum 7 bytes patch *jne to jmp or something like that*
Anyways ... I would still prefer to find an algo ... it would be easier to update existing firmware than to patch "hardware".
Cya,
Viper BJK
DebriZ
26.09.2007, 09:44
a dumb question :oops: : are these 256 byte of AMSS-signature:
1) hash values (like SHA-1 or equivalent in some ways) or
2) SIGNED hash values (asymmetrically signed with some Private Key by Qualcomm)? :-k
SHA-1 hash values encripted with RSA 2048 bit key. :(
And it is possible to change a public key in some bootloader and to sign AMSS with own private key?
Or public key in OTP?
Or some bootloader in firmware have not such strict encription?
DebriZ
26.09.2007, 09:57
The "small" bug is to exploit the bootloader, same procedure as with sony mobiles. Only problem is : I am no ARM reverser :)
I can participate, as far as possible. :up:
viperbjk
26.09.2007, 20:06
I can participate, as far as possible. :up:
Thanks ... I'm about to rewrite my whole app to make it more reliable. Actually it was programmed in C# but algos tend to be faster in C++. After rewriting and commenting the source I will publish them under GPL / Open Source License so everybody is able to append its own source :)
Actually ... I've got little time right now, but I'll keep on reversing :)
So .. after we are confident that we've got the bootloader, participation is of course very welcome.
Cya,
Viper BJK
viperbjk
26.09.2007, 20:10
SHA-1 hash values encripted with RSA 2048 bit key. :(
And it is possible to change a public key in some bootloader and to sign AMSS with own private key?
Or public key in OTP?
Or some bootloader in firmware have not such strict encription?
Attention .... not SHA-1 ... it is HMAC-SHA-1 :)
Changing the public key fitting to our own private key would be the cleanest solution, right. Yet, we do not know where the public key is attached and if the section containing it is writable. But we'll see.
Cya,
Viper BJK
DebriZ
27.09.2007, 08:51
I shall try to look. If I shall find, I shall inform.
DebriZ
30.09.2007, 14:50
So bad, what I not spec in crypto. :(
I found some binary 224 bit sequence in obl, pbl, qcsbl, NPRG6250SEC, 3GSwupFU2 and many times in amss. In oemsbl - not found. In every module It's extracted with special procedure, what in area, where are procedures such as 'GetSignature', 'SignFile', etc. And on this procedure not refered any other. Or calls is hidden, or I not found?
This sequence is: 00000000000000000123456789ABCDEFFEDCBA9876543210F0E1D2C3
What can it be? I need help! :(
Good news! Inside of the 3GSwup are libraryes for signing and encrypting from QCM! :)
viperbjk
30.09.2007, 16:52
So bad, what I not spec in crypto. :(
I found some binary 224 bit sequence in obl, pbl, qcsbl, NPRG6250SEC, 3GSwupFU2 and many times in amss. In oemsbl - not found. In every module It's extracted with special procedure, what in area, where are procedures such as 'GetSignature', 'SignFile', etc. And on this procedure not refered any other. Or calls is hidden, or I not found?
This sequence is: 00000000000000000123456789ABCDEFFEDCBA9876543210F0E1D2C3
What can it be? I need help! :(
Could be a simple magic-table for xoring.
Good news! Inside of the 3GSwup are libraryes for signing and encrypting from QCM! :)
Inside 3GWSwup ? Strange ... can you post the occuring address ?
Then I can have a look at it.
Cya, Viper BJK
adfree
30.09.2007, 17:05
3GSwup from E81 is latest Version...
http://www.benq.com.tw/products/mobile/?product=946&page=downloads&dType=A
From SG75 oldest.
:oops: This all what I know.
:mrgreen:
DebriZ
30.09.2007, 18:46
Inside 3GWSwup ? Strange ... can you post the occuring address ?
Then I can have a look at it.
User Guide
3GSwupFU2 for the Qualcomm Multi Image Boot Concept
Version 2.0.7.1
...
There are three use cases:
· 3GSwup2 for Developers - 3GSwup2
o version that use QPST Server
o version that do not use QPST Server – you have to switch off QPST Server
· 3GSwup2 for Friend Users - 3GSwupFU2
· 3GSwup2 for End Users – Internet Update
...
firmware 26 for SXG75, 3GSwup file size 1458176.
address: 0x00464F2F -> 0x00462E70
lib.procs: 0x0046230D, 0x00466090 ...
and this: 0x00500460 0x10 size data used in 0x0046239D - very interest :)
On address 0x004624CB are procedure 'OpenSignatureFile' (in WRITE_BINARY mode :) ) and "...RSA signature generating ..."
P.S. IDA used. :)
adfree
30.09.2007, 20:54
3GSwup2 for Friend Users - 3GSwupFU2
These 3GSwups we know. This what we use since month... :mrgreen:
3GSwup2 for End Users – Internet Update
I think this is what official was the Updatetool...
For example:
W5V0_IP26_fr-VF-SFRNG_26_0110_Internet_SGLPK.exe
3GSwup2 for Developers - 3GSwup2
Is maybe nothing else, as QPST Functions. Look Screenshot.
Maybe called ...
Package contains:
1. 3GSwup2.exe or 3GSwup2QPST.exe - v2.0.5
Look release info.txt from E81...
adfree
30.09.2007, 22:22
publickey.pub 820 Byte lies in Internetupdate...
Question is for what... :lol:
Taken from EF81_IP15.0.1.1_V3.22_ua-retail_52_0124_Internet_SGLPK.exe
With Help of OllyDbg.
Okidoki... If u copy the HEX part between p00= and p01
And put in HEX Editor... Then you got 256 Byte. :shock:
Remarkable coincidence. :lol:
Strange... If I remove from the rest of publickey.pub after p01=03
at the End all 20 20 20...
Then again 256 Byte... Maybe I'm paranoid. :lol:
If I compare publickey.pub with EF81_IP15.0.1_de-BRDHandel-std_48_0113_Internet_SGLPK.exe
Same for W5V0_IP26_fr-VF-SFRNG_26_0110_Internet_SGLPK.exe
Then the first part is identical... Second part of file is different.
adfree
01.10.2007, 09:05
Should the DEV Version of 3GSwup do more as Upgrade from Single Boot Concept to Multi Boot? :-k
RSA verification failed.
12345678 p01 p00
could not write signature
Authentication of the binary file successfull.
RSA signature verified by the usage of public key.
could not verify signature using public key
could not get public key
p16 p15 p14 p13 p12 p11
could not get key pair %s
could not sign using key pair %s
%d
%d
%d
Size of v_slen: %d
could not parse line %s
%lu
error processing key pair %s, unknown algorithm
error processing key pair %s
error in key id %s
RSA signature generating ...
could not open signature file %s
wb
could not read hash value from file %s
sha1 hash
Input file %s not found!
Quitting...
Taken from E81 3GSwupFU.exe 2,57 MB
DebriZ
01.10.2007, 12:35
In 3GSwupFU2 from SXG75 too most.
migraineboy
02.10.2007, 10:32
The public key from Qualcomm may even be published on their website, this doesn't matter [that's why it's called public ;)]
But it's strange it changed from SG75 to EF81, maybe the public key has a short validity period... or is a special Fieldtestkey-one for SG75 ... :-k
DebriZ
02.10.2007, 12:01
Maybe private key have not given to Benq. :lol: Therefore SG75 and SXG75 are not supported Benq.
adfree
02.10.2007, 12:30
Maybe private key have not given to Benq.
This is not really funny. Because it seems be truth...
They introduced new Key Q in AMSS and changed the Structure...
This could be the reason. Why E81 Protos are not possible to update with SVN 47, 48, 49... :-?
Only change F into Q is not enough...
In E81 is 55000000C0000000 not more the sequence to identify the END of AMSS.
Maybe self fortune from SF71. :no:
DebriZ
03.10.2007, 07:56
And *hd.mbn have remained same? With same data?
adfree
07.10.2007, 02:39
I think at this OTP position 00003E00 the "IMEI Block".
The 256 Byte is called the Root_Key.
QMSL can READ and Write "Standard" 260 Byte as Root_Key... maybe.
GSDIDIAG_ROOT_KEY_WRITE_CMD( iRootKeyLen = 260)
WARNING!!! Don't play with QMSL if u not know what key to press...
You can test some functions without attached mobile...
And *hd.mbn have remained same? With same data?
@ DebriZ
Sorry. I'm not sure what you mean... Not compared yet. But strange. Sometimes I think. Original AMSSHD.mbn without modification, sometimes not correct... Or I can't read and count. :-D
I'll try to find an example...
viperbjk
08.10.2007, 21:52
I just had an insight into the unpack routine of the internet firmware update versions ...
The publickey.pub is never loaded into memory ... for what reasons,
I do not know. Now, I'll check the MobileUpdate.exe for any switches
and if it also does include routines for signing.
3GwSup.exe does include routines for writing a signature actually ...
but the versions we have are quite useless because the functions for writing the signature and the private key is missing. I think there must be a developer version that is able to sign the amss.mbn.
We'll see.
Cya,
Viper BJK
adfree
09.10.2007, 05:16
Because I missing something... "1024 KB" for instance. :lol:
I try to search again with CDMA Workshop... OMG :shock:
"Now" I know that CDMA Workshop can seek into 4 GB area. :cry:
For dummies like me:
0xFFFF 64 KB
0xFFFFF 1 MB
0xFFFFFF 16 MB
0xFFFFFFF 256 MB
0xFFFFFFFF 4096 MB
:no:
Okay. Maybe smaller area. Not sure if SPC "opens" more.
Checked on SXG75...
0x70000000 and above Restart my SXG75...
0x65000000 short tested with Dump of 3 MB...
0x65000000 is nearly 1,7 GB (1694498816 Bytes)
To read the "complete" readable area in 99 MB steps... I need 17 attempts a 3 hours. :roll:
I need one hint, how to read and find the "1024 KB" without JTAG. :mrgreen:
Now I understand for what the Memory Scan Function is..
viperbjk
09.10.2007, 23:12
Update :
Right now, I'm reprogramming and commenting my whole prog in MFC C++. 10% of the work is done. Many improvements were made, especially the speed has dramatically increased. Hopefully, in the end, my com port function will work better and it will have nicer features than the one of CDMA Workshop.
Of course, as soon it is finished, the software will be open source. Hopefully more people will join in reversing the EF81, E81, SL91 and SXG75.
Cya,
Viper BJK
viperbjk
10.10.2007, 02:08
Letztes Update für heute ...
beim Rumspielen hab ich herausgefunden, wie die Entwickler von Benq
die CRC des AMSS beim EF91 überprüfen (vielleicht sogar erstellen ?) :
die Funktion heisst : gRemoteGetCodeCRC
und ist im XQT enthalten. Mal guggn, vielleicht ist das des Rätsels Lösung.
Cya,
Viper BJK
adfree
10.10.2007, 02:30
Du meinst den Enginner Mode? :-D
Das wäre natürlich ein fettes Ding...
viperbjk
10.10.2007, 11:30
Nö ... unter Factory API gibt es nen Tab namens "Firmware Completeness Check"
der doch tatsächlich Daten vom Handy über die QC Api abfragt.
For the english users :
Looking into the XQT for EF91, I've seen that there is a possibility to check the checksum of the firmware under "Factory API", "Firmware Completeness Check" ... and it is calculated by mobile. Maybe it can help to find a solution for amss signature.
Name is OEMSBL, begins at 0x50 and has size of 0x30.
You may wonder ... 0x30 ? strange size ... it is because it's not the size
of the OEMSBL itself, it is ONLY MEMORY ALLOCATION in MEMORY PAGES.
So ... partition.mbn is nothing more than a table HOW TO LOAD the seperate parts into the phone :)
So I looked at the fullflash extracted by JTAG .... and ... upps ...
there it is :)
Thus, I now found the section SIMSECURE *hehe*
Let's see what it is for :)
Cya, Viper BJK
P.S.: Stay tuned for new nice features of my soft .... and maybe BIG NEWS :)
This baby's got a new name "QC BS Firmware Analyzer" ... see for yourself.
Progress is 90% .... only Diagnosis-Mode and Tooltip-Function for the Graph is
missing. Soon, the beta code will be released ... maybe at sourceforge, we'll see.
Cya,
Viper BJK
P.S.: Mobiles that will work with my software so far :
EF81, E81C, SXG75, SL91
Confirmed not to work due to complete different firmware :
S81
p3t3r
12.10.2007, 15:19
Well, that sounds great! (I am only angry with myself, that I didn't start to learn programming earlier than a week ago.. it is really fascinating.)
ViperBJK, one question: Will your software be able to work on Linux?
viperbjk
12.10.2007, 15:47
ViperBJK, one question: Will your software be able to work on Linux?
As the soft will become Open Source, there should be no problem in porting it
to Linux. Also, pure MFC is used, so porting should be quite easy :)
For the non-programmers, using the exe with wine should just work fine, as no packers/protectors will be used.
Cya,
Viper BJK
viperbjk
12.10.2007, 15:58
After further research, I just found out that the crc of amss.mbn is calculated two times ....
first time : Bootloader/Flashloader (NPRG6250ASEC.HEX)
Bootloader is used to upload complete fullimage or parts of it into SRAM
=> AMSS.MBN is loaded. AMSS.MBN checks at the beginning if CRC is valid.
I still wonder, if the MSM6250A also does some checks ... for example the signature check. The Private Key I found is no RSA thinggie, it's just a magic table to generate a checksum out of the AMSS.
I could disassemble parts of AMSS.MBN, but had no success in disasm of the Bootloader (of course after converting hex to binary).
Guys, let's get rid of this damn checksum :)
Cya, Viper BJK
adfree
12.10.2007, 21:26
Maybe we try to make an collection of these 256 Byte Sigs...
And compare them? Maybe they are not "unique"? Maybe 1 Sig could pass/match for different AMSS?
But I can't compare more then 2 Files at one time. :oops:
How to compare an bunch of 256 Bytes Files at one time? To find matches...
viperbjk
12.10.2007, 22:21
Forget about these signatures ... they are generated and thus not very important.
We need to know how these are generated ... and we can get to know it by looking into the disasm.
Details, where the private key and the ref can be found will follow soon :)
Cya,
Viper BJK
adfree
13.10.2007, 06:01
SET_BY_CM
I found this on early Protos as Bootloader (oemsbl simple check *#06#)
Confirmed on early SL91, SF71...
And you can find it in AMSS...
:idea: Maybe an illustration
If readable under *#06# Bootloader ver.
Then it is unsigned oemsbl.mbn, because the name from Bootloader lies after 256 Byte signature...
viperbjk
14.10.2007, 15:07
News :
The "private key" I extracted can now be confirmed as CRC-30 keytable.
It is primary used for uploading the firmware to the phone and checking if it was flashed correctly.
Whilst uploading, the CRC, also the length of the amss is integrated into a section called Boot Information Block (when finalizing the flash).
Thus, I thought it is only to confirm that amss was flashed correctly into
the phone. Comparing other QC phones, for example the A707, I saw that they haven't included the CRC-30 keytable into amss, also having no signature.
So still ... CRC-30 must have something to do with the signature bytes at the end of the amss.
Cya, Viper BJK
viperbjk
14.10.2007, 17:37
Ok ... here it is ... second table was identified ...
very strange :)
This is the routine responsible for Signature check I assume, ripped
from AMSS FW 58 EF81 :