1und1 Audiocenter nutzen des LCD für Rufnummeranzeige?!

[cyd0g]

Was findet man denn in der Firmware-Datei von Version 1.11, die man bei Sagem herunterladen kann?

Siehe Post 76

Sagem : SGM7021

 

[RiVen]

OK. Ich dachte, du hättest das mit dem Superscan-Tool an einem Original-Sagem-Gerät (V1.28 oder V1.35) ermittelt.

Im Ereignis-Logg der Fritz!Box taucht der Name "ONE7021" öfter 'mal auch beim Verbinden des Web-Tuners zur Fritz!Box per WLAN auf.

 

[Spielkind]

In der Sagem Firmware steht tatsächlich SGM7021.

Was mich etwas wundert, ist daß in der Sagem Firmware einmal steht:

<friendlyName>My Web Tuner 500</friendlyName>

und dann weiter unter geht es um ein ganz anderes Gerät:

<friendlyName>My DU@L RADIO 700</friendlyName>


Ansonsten hab ich mir mal diese C Progrämmchen zusammen mit der Firmwaredatei, die es zerschneiden soll, angesehen.
Es macht die Schnittpunkte in der Firmwaredatei an der Zeichenfolge 'Queen' fest. Ausserdem muss 12 Bytes später und 52 Bytes später eine Bytesequenz von 4 Bytes übereinstimmen. Der Schnittpunkt liegt dann 16 Bytes vor dem 'Queen'. Hmm, schwer zu erklähren. Ein wenig vereinfacht in VB dargestellt (ist so ganz gut lesbar):

For Pos As Integer = 0 To Size - 80
__If Data(Pos + 16) = "Q" And Data(Pos + 17) = "u" And Data(Pos + 18) = "e" And Data(Pos + 19) = "e" And Data(Pos + 20) = "n" Then
____If Data(32) = Data(72) And Data(33) = Data(73) And Data(34) = Data(74) And Data(35) = Data(75) Then
______'Schnittpunkt
____End If
__End If
Next

Wie man solche Schnittpunkte in unserer Firmware finden kann und ob sich das überhaput auf diese übertragen lässt weiss ich allerdings nicht.


P.S.: Die Seite http://www.zalip.com.tw/ ist wohl gerade nicht erreichbar. Deswegen hab ich nur in der Sagem Firmware geschaut. Ich hätte ja schon gerne mal so ne 1&1 Firmware...

 

[RiVen]

"Queen" ist ein spezielles Kennstring in der Firmware des MGB100.
Dieses WLAN-NAS-Gerät gibt es in diversen Varianten von verschiedenen Anbietern. Es stammt ursprünglich ebenfalls von AMIT, wie eben der Web Tuner auch. Das WLAN-NAS wird/wurde hierzulande u.a. von Pearl (unter der Produktbezeichnung "PE6643") vertrieben.

Hintergründe zu der Aufteilung der Firmware-Dateien findet man auch in diesem Forum: http://wl500g.info/archive/index.php/t-9513.html.

 

[hermann72pb]

Kann jemand chinesisch?
http://www.daxia.com/bibis/moredata30_1223082.shtml beschreibt nämlich den Prozessor "AMRISC 10020" zu dem angeblich relativ wenig Infos gibt. Auf dieser chinesischen Seite ist unser Tuner ziemlich genau abgebildet. Ok, zugegeben, unser hat etwas weniger auf der Platine verbaut, als auf dem Foto, aber der Aufbau sieht ziemlich identisch aus.
Auf der Seite gibt es Link zu:
http://www.daxia.com/bibis/upload/203R2886.pdf
Ich vermute, es wird behauptet, dass 10020 eine Nachmachung von RDC R2886 ist.

Ich werde gleich mit meinem Linux unter VM versuchen die Anleitung aus
http://tintuc.no-ip.com/linux/tipps/mgb100/
zu verfolgen. Mir scheint wenigstens die Info von dort:

... Die Firmwaredatei besteht meistens aus mehreren Segmenten:
    * Linux Kernel
    * Ramdisk mit Root File System
    * Partition mit HTML Files
    * Recovery Loader
    * AMIT BIOS

logisch zu klingen.
Ich berichte nachher, ob es mir gelungen ist, die Firmware zu splitten.


Edit:
1. Im c-Programm zur Splittung scheint ein Fehler gewesen zu sein bei der Ausgabe über fprintf. Wurde als Warnung beim kompilieren ausgegeben.
2. Ansonsten ist dieses c-Programm relativ ungesprächig. In unserem Fall spuckt es gar nichts aus. Ich hätte erwartet, dass es wenigstens sagt "String nicht gefunden" oder was ähnliches.
3. SGM7021 scheint in unserem Fall so eine Art Marker zu sein, wie "Queen" eben im zitierten Fall gewesen ist. Da Queen allerdings nur 5 Buchstaben hat und SGM7021 dagegen 7, muss man da genau schauen, wie man dieses C-Programm modifizieren kann. Aber grundsätzlich spricht sehr vieles dafür, dass die Chinesen da busybox wieder unter jedem Verstoß gegen GPL verwenden und versuchen es durch diverse Tricks zu vertuschen.

MfG

 

[Spielkind]

Welchen Ansatz verfolgst Du dabei? Wie erkennst Du die Punkte, an denen Du musst?
Also ich würde ja so ein Tool für Windows schreiben. Nur müsste ich wissen, wo gesplittet werden muss.

Edit:
Ja, unsere Firmware kann das Ding nicht splitten. Ich hab mal einen Screenshot für den ersten Split-Punkt, den das Tool macht angefertigt. Wenn mir einer sagt, wo ich splitten soll, schreib ich das Tool gerne auch für unsere Firmware.

Edit2:
Rot ist der Schnittpunkt,
Blau die 'Queen' Markierung,
Grün die Bytesequenzen, die verglichen werden.

 

[cyd0g]

Also mal ganz theoretisch :

wenn die Firmware aus 4 Dateien besteht, die dann zu einem *.BIN file verpackt werden, dann muss

3 mal ein Marker vorligen, der ja "höchtwarscheinlich" immer gleich aussieht, d.h. daß man

nach Strings suchen muss, die sich 3 mal wiederholen.

Bei dem MGB100 sieht der Marker lt. Docu von macsat so aus :

0000 0000 FFFF FFFF 3E00 0000 1FEC 4C69

hat also mit dem "Queen Brandig Gedöns" nichts zu tun, oder seh ich das falsch ?

 

[hermann72pb]

@Spielkind: Warum muss es gleich windoof sein und dazu noch dieses VB, was vermutlich nur du verstehst. C-Code zu dieser "QUEEN"-Geschichte war für mich persönlich verständlicher, als deine VB-Konsequenzen. Und realisieren kann man das schon irgendwie, wenn man weiß, was da zu tun ist. Sprache spielt dabei keine große Rolle. Also, das Hauptproblem ist nicht die Realisierung, sondern das rausfinden, WIE es kodiert ist.

@cyd0g: Solche große Konsequenzen, die sich ständig widerholen gibt es bei unserem SAGEM nicht. Es spricht schon sehr viel für "SGM7021" als Marker, allerdings ist die Geschichte nicht so einfach, wie im "QUEEN"-Beispiel. Auch die Chinesen lernen dazu das busybox so zu verstecken, dass es keiner wiederfindet. Abgesehen davon, dass man diese doppelten Viererbytes bei uns nicht vorfindet, gibt es noch etwas, was sehr seltsam ist. Es wird versucht, die Strings in den Binaries soweit es geht unkenntlich zu machen. Versucht euch bitte doch einige Bereiche anzuschauen, wo offensichtlich Textmessages vorkommen. Mir ist aufgefallen, dass wenigstens in diesen Bereichen alle Texte nach 8 Bytes mit einem FF zerhackt werden. Wenn das nur alleine gewesen wäre und regelmässig vorkommen würde, könnte man es leicht abfangen. Allerdings kommt es bei der Kodierung noch drauf, dass dieses FF manchmal zu FE wird, manchmal dürfen anstatt 8 Bytes plötzlich 9 nacheinander folgen. Also, es wird schwer zu erraten, was die Chinesen da alles verbaut hatten, um die Inhalte unerkenntlich zu machen.

MfG

 

[MartinH@IP]

So, ich hab mal in der Zalip FW alle ZLP7031 Strings gegen ONE7021 Stings ausgetauscht...
Ergebniss : Flashen über USB geht nicht, flashen übers Webinterface geht, Meldung :
"Update Successfull" , Box startet neu aber immer noch alte 1.28 1&1 Firmware drauf.
Da sind wohl noch irgendwelche Prüfsummen, die das Update verhindern..

Ich habe auch ein recht neues AudioCenter geliefert bekommen (Ende August 2009) und es zeigt Firmware Version "R1.35" an.
Wenn ich als "admin" das "web-interface" des AudioCenters aufrufe, kann ich da auch ohne Dateiangabe auf "Upgrade" klicken und es erscheint die Meldung "Upgrade Successfully" im web browser. Der Effekt beim AudioCenter ist ein Reboot.

Beim ersten Anmelden erscheint im IE <<Der Server "192.168.178.39" an "MAA300" erfordert einen Benutzernamen und ein Kennwort.>>

Gruß, Martin - kann ich noch mehr an der R1.35 prüfen ?

 

[cyd0g]

Hallo MartinH@IP,

du hast Recht, nach klich auf den Update Button ohne ausgewählte FW, zeigt meine Box das gleiche Verhalten

Interessant währe, mit welchem Hostnamen=String sich dein Audiocenter im Fritz!Box Wlan Monitor
meldet, könntest du mal schauen ? müsste irgendwas mit ONE70** sein.

 

[MartinH@IP]

Interessant wäre, mit welchem Hostnamen=String sich dein Audiocenter im Fritz!Box Wlan Monitor meldet, könntest du mal schauen ? müsste irgendwas mit ONE70** sein.

Als WLAN Ereignis Meldung im FB webinterface erscheint für meine AudioCenter mit Firmware Version "R1.35":

WLAN-Station angemeldet. Name: WebTuner, IP-Adresse: 192.168.178.39, MAC-Adresse: 00:50:18:5D:3F:AB, Geschwindigkeit 54 MBit/s.

Meinst Du diese Angaben oder sonst noch was?

Gruß, Martin - der das AudioCenter auch mal mit LAN-Kabel betreibt.

 

[Spielkind]

Sprache spielt dabei keine große Rolle. Also, das Hauptproblem ist nicht die Realisierung, sondern das rausfinden, WIE es kodiert ist.

Mein reden. Der Programmierer des c-Programmes hat es aber auch ein wenig durcheinander gewürfelt indem er Hex- und Dezimal gemischt hat.

Eigentlich soll doch ein Teil das zu mountende root file system in gezippter Form sein. Eigentlich würde ich dann ja einen Zip-Header irgendwo finden... Tu ich aber nicht. Weder in unserer noch in der anderen Update-Datei.

 

[chriwi]

Ich weis jetzt nicht wie du auf das "in gezipter Form" kommst, wenn wenn du das irgendwo gelesen hast könnte da auch ZIP als Synonym für irgendeinen Packalgorithmus gebraucht worden sein, ZIP ist eher Windowsspezifisch bei linux werden eher andere Packer für gepackte Flashfilsysteme eingesetzt, die ich hier somit eher vermuten würde als ZIP.
.

 

[cyd0g]

Mal reingeschaut....

lt. Datasheet von RDC hat das Teil JTAG ?!

das wär doch mal SEHR von Vorteil

 

[Spielkind]

Ich weis jetzt nicht wie du auf das "in gezipter Form" kommst, wenn wenn du das irgendwo gelesen hast könnte da auch ZIP als Synonym für irgendeinen Packalgorithmus gebraucht worden sein, ZIP ist eher Windowsspezifisch bei linux werden eher andere Packer für gepackte Flashfilsysteme eingesetzt, die ich hier somit eher vermuten würde als ZIP.
.

Na, von hier: http://tintuc.no-ip.com/linux/tipps/mgb100/

# unzip the firmware
unzip "WAP-0007(R4.00b5)_2006-01-13.zip"
# we have a BIN file now, we split it
./splitamitbin "WAP-0007(R4.00b5)_2006-01-13.BIN"
...
# first make a copy of it
cp "WAP-0007(R4.00b5)_2006-01-13.BIN-0x100000" root.gz
# now unzip the root fs
gunzip root.gz
...
# mount the root fs
mount -o loop root rootfs

lt. Datasheet von RDC hat das Teil JTAG ?!

das wär doch mal SEHR von Vorteil

Schönes Foto!
Keine Ahnung was man da machen muss und was das könnte. Klingt aber interessant!
Der Speicher scheint auch erweiterbar zu sein? Und das mit dem zweiten USB klingt auch wahrscheinlich. So ein USB controller hat meine ich mindestens 2 Ports.

 

[cyd0g]

So, weiter gehts...

RDC 2886 = 150 Mhz ist baugleich mit dem
RDC 2880 = 100 Mhz

zu dem 2880 hab ich das komplette Handbuch gegoogelt ->

http://www.paradigmtools.com/docs/R2880.PDF

und siehe da - JTAG enable Pin existiert , siehe Bild

zum Thema JTAG siehe Wikipedia http://de.wikipedia.org/wiki/Joint_Test_Action_Group

 

[Spielkind]

Ja, Wikipedia hatte ich auch schon zu rate gezogen. Nur was man effektiv damit dann bewerkstelligt weiss ich nicht.

Vielleicht meinst Du:

Parallel programmierbare Speicher wie zum Beispiel Flashspeicher, die direkt an ein IC mit JTAG-Port angeschlossen sind, können deshalb im eingebauten Zustand umprogrammiert werden, weil das IC für den Speicherchip ein Programmiergerät emulieren kann. Zum Austausch solcher Programmierdaten dient oft das Serial Vector Format (SVF).

Vielleicht ja etwas womit wir die Kiste wiederbeleben können wenn wir sie zum ersten mal Kaputtgeflasht haben?
Bei der NSLU2 (Hab ich noch irgendwo im Keller) kann man das auch damit machen:
http://www.nslu2-linux.org/wiki/Info/PinoutOfJTAGPort
http://www.nslu2-linux.org/wiki/HowTo/RecoverFromABadFlashUsingJTAG
Die Frage ist, ob man dafür dann ein spezielles Flash-File benötigt.

Nur, wie kommen wir in das Linux, wenn den eines drauf läuft?

 

[hermann72pb]

JTAG ist meistens relativ aufwendig und wird gebraucht tatsächlich um mit dem Prozessor "auf du" zu reden. Und das wird oft dazu verwendet, um die Firmware auf "zerschossene" Geräte zu flashen. "Aufwendig", weil JTAG nicht immer JTAG ist und weil man meistens einen (nicht immer billigen) JTAG-Adapter + zugehörige Software braucht. Für gängige Controller und Prozessoren mag es zutreffen, dass sehr viel Vorarbeit geleistet ist und man relativ billig und schnell dadran kommt, etwas mit JTAG zu machen. In unserem Fall sehe ich es aber eher schwarz. Bin auch kein JTAG-Experte und mag sein, dass ich mich diesbezüglich irre.
Zum GZIP (so soll es korrekt heißen). Es ist tatsächlich so, dass im Image wenigstens busybox als gz-Datei zu erwarten wäre. Ich war gestern auch auf dem Tripp, die passende Konsequenz (so genannte Magic-Bytes) für unsere gz-Datei zu finden. Leider konnte ich im Netz nichts passendes finden, wie der Header einer gz-Datei aussehen soll. Wenn jemand dazu was findet, bitte her damit. Ansonsten hatte ich, wie gesagt, die Passende Konsequenz "SGM7021....Li" gefunden, weiß allerdings nicht, wo ich genau die Schnittpunkte setzen muss. Enden tun die Abschnitte exakt ein Byte vor "SGM7021". Aber wo sie genau anfangen, darüber rätsele ich noch.
Zum C-Programm. Zugegeben, es ist etwas chaotisch. hab ich auch oben gesagt. Aber ich habe es halbwegs am laufen, dass es mir die Abschnitte nach meinem Marker nun findet. Mit dem schneiden selbst geht es irgendwie noch in die Hose. Muss ich noch debugen, warum.
Zum Bild. Vergleicht mal doch bitte mit dem Bild aus http://www.daxia.com/bibis/moredata30_1223082.shtml (hatte ich oben bereits zitiert). Das ist die Version mit dem bestückten FM-Tuner usw. Auf unserer Platine kann man die Beschriftungen übrigens auch lesen.

MfG

 

[Spielkind]

Ich war gestern auch auf dem Tripp, die passende Konsequenz (so genannte Magic-Bytes) für unsere gz-Datei zu finden. Leider konnte ich im Netz nichts passendes finden, wie der Header einer gz-Datei aussehen soll. Wenn jemand dazu was findet, bitte her damit. Ansonsten hatte ich, wie gesagt, die Passende Konsequenz "SGM7021....Li" gefunden, weiß allerdings nicht, wo ich genau die Schnittpunkte setzen muss. Enden tun die Abschnitte exakt ein Byte vor "SGM7021". Aber wo sie genau anfangen, darüber rätsele ich noch.

Du meinst bestimmt 'Sequenz'... schau mal hier:
http://www.garykessler.net/library/file_sigs.html
1F 8B 08

 

[hermann72pb]

@Spielkind: So weit bin ich inzwischen auch. Ich hatte da sogar andere "magic Bytes" für gz in Google ausfindig gemacht. Wie du aber selbst berichtet hast, sind diese Bytes in unserem Image nicht vorzufinden.
Inzwischen hatte ich unter
http://www.macsat.com/macsat/component/option,com_openwiki/Itemid,66/id,dangerous_stuff/
etwas mehr zu uns passendes gefunden. Dort werden die header relativ ausführlich beschrieben. In der Beschreibung findet man die Realisierung von diesem C-Programmchen zu splitten der Bin-Datei wieder. Bzw. es ist dort etwas verständlicher beschrieben, als im Programmchen selbst. Und ganz unten findet man diesen zweiten header mit dem "Li", welcher in unserem Image mehr oder weniger vorkommt.
Leider entspricht weder dieser Li-Header, noch der globale Header für einzelne Abschnitte dem, was wir in unserem Image vorfinden. Ich hatte mir gestern alle gefundenen Header (5 Stück) untereinander aufgeschrieben, um die Unterschiede zu erkennen. Leider finde ich dort nicht so viele sich unterscheidenden Bereiche, die die Adressierung darstellen sollten (4. Byte für Anfangsadresse, 4. Byte für Länge, etc.). Im gesamten Header (zwischen SGM7021 und Li) konnte ich jeweils Unterschiede lediglich in 3 Bytes feststellen. Damit kann man aber nur bedingt Addresbereiche definieren, wo es hin soll.

MfG