Hallo Forum,
angeregt durch Projekte wie http://www.opengpstracker.org/ die
AT-Befehlsfähige Mobiltelefone einsetzen, habe ich mich gefragt, ob es
nicht möglich wäre anstelle dieser "alten" Siemens Handys oder des in
Europa nicht verfügbaren (in dem o.g. Projekt verwendeten) C168i eine
günstige und etwas modernere Alternative zu finden. Ich bin dann auf das
Motorola Motofone F3 gestoßen. Es hat eine leicht zugängliche serielle
Schnittstelle unter der Akkuabdeckung und ist teilweise für 20 EUR oder
weniger bei ebay erhältlich.
Ich habe es mal an meinen PC angeschlossen und es scheinen wirklich
viele Daten rüberzukommen. Bei jedem Knopfdruck, bei jedem Ton, bei
jeder Änderung der Beleuchtung etc. wird Etwas gesendet. Jedoch handelt
es sich dabei anscheinend um proprietären Motorola Phone Code
(hoffentlich belehrt mich Jemand eines besseren).
Nun kommt ihr ins Spiel :-)
Gebt mir einen Tipp was ich tun könnte um den Code zu analysieren.
Video zur Veranschaulichung: http://www.youtube.com/watch?v=3X2qs7vFMrk
Noch eine Anmerkung: Die empfangene Zeichenkette bei einem Tastendruck
oder Sonstigem ist nicht reproduzierbar. Sie unterscheidet sich jedes
mal in Wenigen Zeichen.
mfg Raoul
Interessant! ( Beitrag "motorola f3 serielle schnittstelle / bootloader?" )
Serial port configuration: 115200, 8, N, 1
Lass dir doch die Daten als Hex anzeigen, da sieht man evtl. mehr.
Dann systematisch vorgehen und z.B. jedes Event 10x auslösen und
aufzeichnen.
Gucken, was sich (nicht) ändert.
Hast du mal versucht, (AT) Kommandos ans Telefon zu schicken?
Da wird wohl ein Bootloader werkeln. Die Knacker flashen anscheinend 2
MB einer "offenen" Firmware:
http://forum.gsmhosting.com/vbb/showthread.php?t=649199
Vermutlich kann man die auslesen und patchen, so dass der SIM-Lock
ausgehebelt wird. Vielleicht lässt sich der Flash auch selektiv
überschreiben und dieser "Clip" patcht die Firmware direkt.
Wie dem auch sei, vielleicht könnte man auf ähnliche Weise herausfinden,
ob da AT Strings enthalten sind.
Ansonsten, wenn anhand der seriellen Message ein die anrufende Nummer
erkannt werden kann, lässt es sich ja schon verbasteln (Kaffekocher
einschalten) :-)
Hier nochmal ein Link zu raouls video, ab 0:38 wird's nämlich
interessanter:
http://www.youtube.com/watch?v=3X2qs7vFMrk#t=0m38s
"MBM 1.3"
"jumping to phone code"
Google hat zu beiden nichts.
Zum Aufschrauben braucht man Torx-5.
Seitlich sind je 2 Rastverbindungen (bei *M*otorol*A*) die man mit einem
feinen Schlitzschraubendreher vermutlich lösen kann.
Hier ein Press Release zum Displaytreiber:
http://techon.nikkeibp.co.jp/english/NEWS_EN/20071030/141570/
Und viel besser, ein Artikel von EE Times India zum Telefon:
http://www.eetindia.co.in/ART_8800498967_1800001_TA_8dbb207f.HTM
samt tieferem Einblick von Portelligent:
http://www.eetindia.co.in/ARTICLES/2007SEP/C/EEIOL_2007SEP17_EMS_NETD_TA.gif
Das Motofone basiert auf
Texas Instruments' TCS2300 LoCosto "single-chip phone"
http://focus.ti.com/general/docs/wtbu/wtbuproductcontent.tsp?templateId=6123&navigationId=12656&contentId=15408&DCMP=WTBU&HQS=Other+OT+gsm_locosto
"The LoCosto platform combines an ARM7™ general-purpose RISC processor
core with a TMS320C54x™ DSP core, both operating at 104 MHz, for high
performance with low power consumption."
"The TWL3029 analogue subsystem integrates power management and audio
circuits in a second BGA-packaged chip. Similarly, a separate 2-Mbyte
NOR flash from STMicroelectronics (M58WL016) is used for code and
user-data storage, and Skyworks' SKY77518 RF FEM provides RF power
amplification and transmit/receive switching."
"Two identical SSD1621 drivers from Solomon Systech provide the
display's electronic interface, both wirebonded to and encapsulated in
situ on the keypad/display PCB."
Aus Informationen von TI:
- SAIC and TTY support
- Hardware security (Flash content protection, ME personalization, IMEI
protection) OMTP1.0 compliant
- 2.0-MB flash
h ttp://en.wikipedia.org/wiki/Open_Mobile_Terminal_Platform
Da das ein ASIC für "high-volume applications" ist, kommt man wohl nicht
wesentlich weiter..
Softwaretools:
http://focus.ti.com/general/docs/wtbu/wtbugencontent.tsp?templateId=6123&navigationId=12744&contentId=28030&DCMP=WTBU&HQS=Other+PR+apps-suite
Aus http://focus.ti.com/pdfs/wtbu/appsecosystem.pdf:
"Partner application suites are integrated onto TI’s “LoCosto”
single-chip mobile phone solution and OMAP-VoxTM product family for a
highly customizable application solution that greatly reduces the
overall handset development cycle. Working with market-leading solutions
including Motorola AJAR, OpenPlug’s ELIPS, Sasken’s ARIA and SKY
MobileMedia’s SKY-MAPTM, TI gives its customers the flexibility to
select an application suite that can be easily adapted to the unique
needs of handset products and specific operator and consumer
requirements."
Motorola AJAR
http://www.ttpcom.com gibt einen 504
http://ajar.ukmn.com/
Flash, "download brochures" führt zu nix.
archive.org hat auch nix.
Bleibt nur raten, Flash untersuchen.
Es gibt noch einen Widerhaken zwischen SIM-Karte und Akku Kontakten. Der
hakt unter das Huckepack-PCB. Richtung Akku aushaken.
@raoul:
Hast du die Kabel angelötet oder einen Adapter gebaut?
Firmware lesen habe ich nicht getestet, da ich kein F3 habe.
Wenn die Firmware gelesen wird, musst du sie an der "seriellen"
abfangen, weil die meisten GSM Tools die Firmware in einem eigenen
kodierten Format abspeichern, damit andere Leute damit nichts anfangen.
Hallo Ihr Interessierten,
@Blödmann:
>Hast du mal versucht, (AT) Kommandos ans Telefon zu schicken?
Ja, das habe ich vergeblich versucht.
>* und # beim Anlegen der Versorgungsspannung gedrückt halten, mal gucken,>was dann über die serielle kommt!
Dann kommt folgendes:
1
MBM 1.3 <\n><\r>
2
3
Key Pressed :45<\n><\r>
4
5
MBM FLASH MODE<\n><\r>
Hier heißt die gedrückte Taste(nkombination) nun 45 und nicht 00 wie
beim Einschalten.
>Zum Aufschrauben braucht man Torx-5.
Jap.
Ich habe irgendwann auch mal ein Video gemacht wie ich das geöffnet
habe. Falls Interesse besteht könnt ich es hochladen.
>Hast du die Kabel angelötet oder einen Adapter gebaut?
Ich habe sie leider angelötet. Ich wollte nicht auf ein Adapter warten
müssen. Jedoch ist das sicherlich die bessere Methode.
@Sergey:
Ich schaue mir das Tool mal an und probiere ob es möglich ist, die
Firmware auszulesen.
--
Eine andere möglichkeit den Code zu entschlüsseln wäre vielleicht mit
einem Logic Analyzer zu versuchen, ein Protokoll zu erkennen und zu
verstehen.
Na, das Protokoll ist "asynchron seriell, 8 Datenbits ..."
Um herauszufinden, was die Bedeutung der Daten aus dem Telefon ist, muss
man's wohl erstmal systematisch aufschreiben..
"MBM FLASH MODE" klingt doch gut.
Schick da mal ein 0x3C 0x69 (0x00) als zurück.
Zum Lauschangriff auf der seriellen Schnittstelle: HHD "Free Serial Port
Monitor".
>Schick da mal ein 0x3C 0x69 (0x00) als zurück.
Dann kommt lieder nichts. Bis jetzt hab ich noch nichts senden können
auf was das Telefon antwortet.
>HHD "Free Serial Port Monitor".
Danke für den Tipp!
So jetzt habe ich mal versucht die Firmware auszulesen. Leider ohne
Erfolg.
Es läuft wie folgt ab:
Das Handy ist aus. Ich erstelle mit dem Programm einen RSA Key und
drücke "Read MEM". Ab jetzt schickt das Programm die von 'Blödmann'
geposteten "0x3C 0x69 (0x00)". Nun fordert mich das Programm auf, kurz
auf dien An/Aus Taster zu drücken, damit es erkennt, ob das Handy
antwortet. Das Programm erkennt, das Handy und schickt anscheinend ab
jetzt den Befehl zum Booten. Nach einer gewissen Zeit bricht das
Programm ab, da das Handy nicht bootet und sich auch nicht mehr meldet.
Das F3 lässt sich dann erst Einschalten, nachdem der Akku einmal
herausgenommen wurde (genau wie wenn man in den "FLASH MODE" mit der
Kombination aus * # und dem Antaster geht).
Ich guck mal was sich noch so tut...
Hab mir nun den "Phone Code" mit einem Logic Analyzer angeschaut. Jedoch
ist es leider so, dass das Signal jedes mal anders aussieht (bei
gleichem Tastendruck). Was kann das nun sein? Ob es wohl codiert ist?
Hi Raoul,
m.E. ist der Einsatz eines LA Quatsch, da die Daten ja vom HTerm
dekodiert werden. Es wird doch ein normaler UART sein.
Du siehst also nur Senden / Sendepause, nicht wirklich Daten an denen du
was erkennen könntest. Schätze ich mal :-)
>Es wird doch ein normaler UART sein.
Ja, genau das wollte ich nicht glauben, da es ein sehr schnelles Signal
war.
Aber wie es sich herausstellte (!) ist es ein UART, ein verdammt
schneller UART sogar (für meine Verhältnisse).
Also ja, ich habs! Bin so froh! :-) Erste Ergebnisse:
Man sieht hier den Einschaltvorgang.
1
21:02:45.855:
2
x
3
21:02:45.856:
4
þ€xÀ
5
21:02:45.858:
6
x>ÿÀx €x à€xàø€€
7
21:02:45.872:
8
€€x xþ
9
21:02:45.873:
10
ø
11
21:02:45.874:
12
xàx<øx<ðx
13
21:02:45.875:
14
€
15
21:02:45.876:
16
x>ð€x<øxü€xü€x<øx üx
17
21:02:45.890:
18
€€ø€ € €€x xþ
19
21:02:46.257:
20
€
21
21:02:46.258:
22
xàx>x<ÿøx
23
21:02:46.259:
24
x
25
21:02:46.260:
26
<ðøxÀøxü€x € øxüøx € x øxüøxÀøx<øx
27
21:02:46.274:
28
€ø xüøx üx<üxÀx xþ
29
21:02:46.898:
30
31
21:02:47.032:
32
RVT: Lost Message 04000006§l f SYSTPCO SYSTEM WARNING: Bigger partition allocated than requested, entity KPD, Size 100, vsi_mem.c(154)§l f SYSTPCO SYSTEM WARNING: Bigger partition allocated than requested, entity KPD, Size 104, vsi_mem.c(154)§n o SYSTPCO SYSTEM WARNING: Bigger partition allocated than requested, entity AUDIO, Size 100, vsi_mem.c(154)§l x SYSTPCO SYSTEM WARNING: Bigger partition allocated than requested, entity TTY, Size 100, vsi_mem.c(154)§l
33
21:02:47.032:
34
} SYSTPCO SYSTEM WARNING: Bigger partition allocated than requested, entity LCD, Size 100, vsi_mem.c(154)§l } SYSTPCO SYSTEM WARNING: Bigger partition allocated than requested, entity DAR, Size 100, vsi_mem.c(154)§l SYSTPCO SYSTEM WARNING: Bigger partition allocated than requested, entity RTC, Size 100, vsi_mem.c(154)
35
21:02:47.648:
36
§& Ô SYSTPCO L1:em_l1_sem_index cleared§5 Ù SYSTPCO dl dth6 dth637_EMEA_Sv 14:54:43 12/09/07§& Ù SYSTPCO DL:em_dl_sem_index cleared§& â SYSTPCO RR:em_rr_sem_index cleared
37
21:02:48.681:
38
§l SYSTPCO SYSTEM WARNING: Bigger partition allocated than requested, entity MMI, Size 228, vsi_mem.c(154)
39
21:02:48.768:
40
§k [ SYSTPCO SYSTEM WARNING: Bigger partition allocated than requested, entity MMI, Size 52, vsi_mem.c(154)
41
21:02:48.864:
42
§ Å MMI PCO %J § Å SYSTPCO TRACE ERROR in MMI
43
21:02:48.976:
44
§( 9 SYSTPCO All tasks entered main loop
45
21:02:49.083:
46
§l • SYSTPCO SYSTEM WARNING: Bigger partition allocated than requested, entity MMI, Size 228, vsi_mem.c(154)
47
21:02:49.169:
48
§k í SYSTPCO SYSTEM WARNING: Bigger partition allocated than requested, entity MMI, Size 52, vsi_mem.c(154)
49
21:02:49.313:
50
§* N MMI PCO INput UI_EtmCalRecovery --YIN
51
21:02:49.889:
52
§ ¦ MMI PCO returnValue=0--YIN
53
21:02:51.059:
54
§l L SYSTPCO SYSTEM WARNING: Bigger partition allocated than requested, entity MMI, Size 228, vsi_mem.c(154)
55
21:02:51.146:
56
§k ¤ SYSTPCO SYSTEM WARNING: Bigger partition allocated than requested, entity MMI, Size 52, vsi_mem.c(154)
Das ganze wurde bei einer Baudrate von 460892 aufgenommen. Noch nicht
perfekt, aber man kann schon eine Menge erkennen!
Ich bleib dran und hoffe, dass sich nun vielleicht auch andere das F3
kaufen und mit mir experimentieren :-) (Befehle finden, etc.)
Das sieht doch ganz gut aus. Die Funktion vsi_mem.c lässt sich googlen
und trifft einen Fork von
http://sourceforge.net/projects/plabs/
"This is the Operating System for the Vitelcom Mobile cellular phones,
by PurpleLabs.It aims (and it is) to be a full capable GSM system and
other common utilities used to be found in mobile phones, such as
agenda, and a few multimedia ones, such as mp3"
Vielleicht ist es nicht nur Zufall..
>Was hast du für eine serielle Schnittstelle? Vielleicht kann sie die>Bitrate nicht so gut einhalten:
Meinst du das jetzt, weil ich den Flash nicht auslesen konnte, oder,
weil bei dem Log oben ein paar Zeichen falsch erkannt wurden?
Ich benütze einen USB zu RS232 Wandler. Dieser hat einen IC von FTDI
drin. Hab ich extra drauf geachtet, weil ich dieses Chips für besser
halte.
Anmerkung:
Die Timestamps wurden von mir nachträglich eingefügt!
Habe keine Ahnung, wohl eher nicht. Ich habe in den Dateien nix von
"WARNING" oder irgendwas ausser einem virtuellen UART gesehen, aber
selbst wenn - im besten Fall ist es irgendeine uralte Software...
Ist TX eigentlich handyseitig oder PC-seitig gedacht?
Moin,
ist das Projekt noch aktuell ?
Der gezeigte Mitschnitt von Daten zeigt das Debug-Protokoll von den
LoCosto-Chips von Texas Instruments, was von der Firmware aus dem
NUCLEUS OS gesendet wird.
Die Datenblöcke sehen aus wie <02><11>inhalt<crc><02> .
Mit dem Rivieratracer von TI kann man sich das ganze etwas schöner
ansehen. Den gibt es an verschiedenen Stellen in Netz zum Download.
Ebenso kann man mit dem Tool "TMSH" ggf auf das LINUX-ähnliche
Dateisystem zugreifen und mit dem TI Tool CSST das ganze Telefon auch
neu flashen.
Direkte AT-Code geht bei der gleichen Baudrate wie der Trace vielleicht
auch, aber man muss in jedem Fall die Trace-Pakete abtrennen bzw.
ignorieren ...
Sieht spannend aus, ich habe gerade ein anderes LoCosto-Phone in der
Mache. Vielleicht hole ich mir auch mal ein F3 zum testen ...
Yogi
f3_pinout.jpg
(30 KB)
