ALC 5000 Mobile firmware hack

[Alex S. (thor368)]

Tach allerseits,

juhu, mal wieder ein leicht seltsames hacking Projekt in diesem board.
Ich habe die Tage einen ALC 500 Mobile bekommen, den ich nun umbauen
werde. Der gesammte Leistungsteil wird rausgeschmissen. Ich benutze nur
den aktiven Kühler weiter(auf dem Foto schon ausgebaut). Da die
Frontplatte recht hübsch ist, ist mein Ansinnen die senkrecht stehende
interface Platine weiter zu verwenden.

Problem: Das display wird von einem µC angesteuert, den ich nicht kenne.
Wäre es ein simpler LCD controller gewesen oder ein AVR gäbe es diesen
thread nicht.

Aufgabe: So muss ich nun den bus zwischen den controllern knacken.

Forsetzung mit genauerer Hardwarebeschreibung folgt.

[Alex S. (thor368)]

Das Gerät besteht aus zwei boards. Interface und Leistungsteil. Beide 
haben einen controller. Controller 1. ist ein Samsung S3C72M9. Ein 
extrem simpler 4bit controller mit fettem LCD treiber. Der Leistungteil 
wird von einem mega128 angesteuert.

Die beiden sind über einen 20pin Pfosenstecker verbunden. Der relevante 
Teil der Pinbelegung ist wie folgt:

    C72    mega128
1   P3.0   PD4
3   P3.1   PD5
5   P3.2   PD6
7   P3.3   PD7
9   P4.0   PF0
11  P4.1   PF1
13  P4.2   PF2

Der mega ist, wie nicht anders zu erwarten war, gelockt.

Ansätze:
1) Logicanalyser bauen und per Hand das Protokoll sniffen. Ich werde 
sowieso bald einen Testaufbau bauen müssen um mit dem controller zu 
kommunizieren.
2) Firmware disassemblieren. Hat natürlich jeweils einen Stolperstein: 
Der mega ist gelockt und ich habe keinen JTAG programmer für den C72.

Fortsetzung mit bissherigen Ergebnissen folgt.

[elevant (Gast)]

ELV Akku-Lade-Center ALC 5000

[Alex S. (thor368)]

Ansatz 1 ist bisher nicht sehr weit gekommen:

Erstmal ein overview von allen 7 pins. Die einzelnen Kanäle sind nicht 
gleichzeitig aufgenommen worden sondern zusammen geschnitten(2ch oszi). 
4ms/div. Wie ich grade gesehen habe ist 13 zu 9 bis auf kleine spikes 
invers. Siehe Foto.

Bei Ansatz 2 hat sich alles was mit dem C72 zu tun hat schnell im Sande 
verlaufen, weil der mega mehr Angriffsfläche bietet: An die firmware 
kommen wir zwar nicht per ISP ran ABER das Teil hat eine update 
Funktion. Es gibt eine Reihe files names "updateALC5xxx_V2_0x.enc". Es 
sind ASCII bassierte hex files:

0112408C8AB8AC1239631AACDDCE3C97D260D22A5DAD864032F9881D2D3FA48C0A563682 
231
AA2E1B812C460DD2FBB5C063EBE99C38AC4AE0F6613B14AEB115EE228EBEAF747B09D8AB 
48C
09D4B2B05BEF3D5648AAAA9FC4781C17D7AB3ADC5F319529CB7361CD58802A8AD8E37FED 
66E
B0E59C66D90A8588DC4F33CE5F63A65BF16D52864169C2C2DC6D4701D962F52D625AEB97 
65C
504963F8F87ADDAE1AF71EFA60C322AE4230B097A43D16F335C542A57AAA41621096FE72 
033
3A538E5DFB4845F45E692B3ABE5FF3AADC9DDB2A51C8E0622EB80F2FA6820F59B35CE6CC 
62B
64047D269971879DA806B52C94471F3F1D984B624D11FCD75A6E447F658A2417C8A7CA07 
6CA
775B3DC6C9B2869672DAB3B61B700127230F384B9B87D60A1D396EA542046E8974801126 
153
A291D532E00F6191F6FFCF139B2858AE242B1DFDF70A40C81A5509F873E6CF36DBBB80F7 
D57
388F12D7373EC1E17B6A6E660DCBEC67459EDF1631B932644F817E002D1A521BE9E5F5D3 
79B
81C1EBF18BFAE9E8F374D4FF345CEC559B13C202936ADBF9680EE499336AF3AD7701D6A9 
D53
487B1ED34932E4844F76F5B9E1D33080816636C303FA5A98B101DC785B06CD2BD0C00A82 
4E0
49AADA35E0192FCF2AC08F5031477CCD724525A2DE4AB0C09696A80A6D1D2B050FAA42CB 
0DA
053392860E8798EEAC281A2C0ADB2F1F862774127FA1D83E93C4227EE23E1E0C4E8A4102 
33C
8A8CFDFF036729DD8321A759DD71FF4762FED8C65EF02A9096C120F2F54A92D28621CFE7 
7C4
418EF4F5CADAB6FA65F

Der Ausschnitt ist nicht zufällig gewählt. Es fällt auf, dass es 
scheinbar zwei Blocktypen gibt. Einer fängt mit 01h 12h an und es folgen 
274 byte. Der andere fängt mit 00h 12h an und es folgen 18 byte. Die 
beiden Blöcke wächseln sich bis auf einen kleinen Teil am Ende des files 
immer ab. Es gibt in der neuesten Revision 329 01h 12h und 324 00h 12h 
Blöcke.

Durch das mitschneiden des update Vorgangs ist ersichtlich, dass diese 
Blöcke auch tatsächlich getrennt übertragen werden. Zuerst wird der 01h 
12h Block gesendet. Es folgt eine Pause von einigen 10ms und die Antwort 
11h. Danach kommt der Block 00h 12h mit nur wenigen µs späterer 11h 
Antwort. Wohlgemerkt ist das Systemzeit. Die Daten gehen unverändert zur 
Schnittstelle raus. Sollte das weiter encryptet sein wird erst im mega 
decryptet.

Fragen:
1) Falls jemand diesen Dateityp kennt, eventuell ist das ein wenig 
bekannter Standart, bitte schreiben.
2) Auch wenn wem was in der Strucktur der files auffällt.
2) Ideen zum Bus sind gefragt.
3) Auch Erfahrungen mit dem C72 wären gut. Ich muss wissen ob ich im 
Notfall die Firmware für diesen controller neu schreibe/auslese.

So das war's erstmal. Wem sonst noch was hilfreiches auf-/einfällt oder 
wer noch Fragen hat, ich bin latent bei der Sache und werde euch nicht 
warten lassen;)

Thor

[Alex S. (thor368)]

@elevant
Das Teil wird bei weitem nicht nur von ELV vertrieben.

[Alex S. (thor368)]

Ich habe rausgekriegt, dass das ein AES bootloader Format von Atmel 
ist(appnote AVR231).

Wenn man Kapitel 3.5.5 durch hat wird einem das schnell klar: 112h ist 
die Framelänge(274byte). Gleichzeitig sind die Frames auch genau so 
aufgebaut das das für eine 256byte flash page passt. Es wurde aber auf 
einige features die Atmel anbietet verzichtet. Als erstes enthält der 
frame immer nur einen Record und keine signatur. Die kleinen Bölcke 
müssen dann EEPROM pages sein. Es gibt noch eine Reihe von 
Steuerbefehlen und die Frames werden auf 16 aufgerundet aber sie sind 
viel zu passig eine page + overhead groß als das was anderes sein 
könnte.

Wie ich das sehe gibt es zwei Schwachstellen.
Nummer eins ist, die Konfiguration vom Entwickler. Es erlaubt, dass man 
am Anfang jedes Frames mindestens 6byte erraten kann. Außerdem kann man 
alle dieser 6byte header erraten und finden. Das sind über 2KB Daten 
inkl. Position deren plaintext man kennt. Außerdem hat der bootloader 
Schwachstellen. Es wurde zwar daran gedacht, keine Auskunft über den 
Schlüssel zu geben(sowohl bei erfogreicher als auch bei gescheiterter 
Dekodierung wird ein OK als return geliefert) aber man kann ja einen 
page write code schicken und nachsehen WANN das OK zurück kommt. Ist es 
zu schnell da wurde der frame geskipt.

Thor

[Janez J. (janez_j)]

Hi,

I wasn't trying to hack ALC5000 firmware but load new one. Why?
When the device is wrong calibrated you haven't be able to calibrate it 
again (FW pre 2.06). And I've got such a device then I was start playing 
with ISP programmer but I've accidentally erased flash. I was trying to 
buy programmed atmega128 but you can't buy it in ELV shop or elsewhere. 
I contacted also support and trying to get controller from them. The 
reply from support was that I have to send ALC to reparature service. 
Unfortunately the post costs are more then 100E so it is beter to buy 
new ALC. So I've decided to play with firmware update. When I saw that 
the firmware is somehow cripted I've given up with those enc files. But 
on Conrad side I've found another firmware for ALC5000 v. 2.01 made for 
galep4 programmer which are not cripted.
But this files are for Galep32 soft ver.1.17.29 which is not compatible 
whith other versions of Galep32. Actually the different versions of 
galep32 are not compatible with each other!
Anyhow playing with different glp files I've found out where are 
different parts of programm (bootloader, main, EEprom). Now ALC is able 
charging I can also connect device to PC and see everything but I can't 
uprade firmware to let say ver 2.06. So something is still missing and 
the answer is in ALC5000M_Firmware_ELV06547_V2_01_SPI_080408cfg1.gpf 
file. This file is for SPI programming but there is also for parallel 
programming.
If you need info what I've found out just send me PM.

Janez