Forum: Fahrzeugelektronik SRAM auslesen der von einer anderen CPU genutzt wird


von Klaus (feelfree)


Lesenswert?

Lotta  . schrieb:
> Du weißt es besser?

Ich weiß nicht mal genau was Du eigentlich erreichen willst.
Besser weiß ich nur, dass Du mit deinem nicht vorhandenen insider-Wissen 
über Automotive-Protokolle und -ECUs nicht mal den Hauch einer Chance 
haben wirst, da auch nur irgendwas zu "hacken".

: Bearbeitet durch User
von Lotta  . (mercedes)


Lesenswert?

Klaus schrieb:
> Lotta  . schrieb:
>> Du weißt es besser?
>
> Ich weiß nicht mal genau was Du eigentlich erreichen willst.
> Besser weiß ich nur, dass Du mit deinem nicht vorhandenen insider-Wissen
> über Automotive-Protokolle und -ECUs nicht mal den Hauch einer Chance
> haben wirst, da auch nur irgendwas zu "hacken".

Mm.
Du hast schon Recht.
Ich will selbst lernen und vielleicht dabei
unserem Jens bei seinem Hobby helfen, auch wenn es nur
ne klitzekleine Hilfe ist.
Was wir hier machen, ist erstmal Brainstorming.
Wenn man irgendwo rein will, geht man nicht durch die Wand,
sondern durch ein Fenster oder schlicht durch die Tür.
Die Tür währe in diesem Falle die Wartungsschnittstelle des
Steuergerätes.
Dank der Mappingkünste unseres Thomas hier können wir in den
Assemblertext des Gerätes reinschauen. Das is ne einmalige Sache,
wer kann das schon? Jens sollte mir mal schreiben
wo er den Dump des inneren EPROM wirklich her hat.
Der Prozessor ist doch auslesegeschützt, nicht wahr, Klaus?
Um wirklich ne Initialzündung zu haben ist es beim Hacken
von Protokollen üblich jeder kleinen Sache nachzuspüren, ja
sogar beim Hersteller den Müllkasten zu inspizieren. :-))

Wenn man jetzt an die Befehlsbytes und ihre Bedeutung
herankommt, etwa durch Mitlesen beim Service, wäre es möglich,
diese in den Datenstatements des Assemblerlistings aufzufinden.
Das wäre dann die Möglichkeit, die auf die Befehlsbytes referenz-
ierenden Funktionen zu ermitteln und zu benennen, und,
da die Befehle ja eventuell die gesuchten Speicherplätze bearbeiten,
so kennen wir sie dann mit Name und Adresse.  :-P

Das war eigendlich bis jetzt meine Intuition.
Bitte kannst Du uns helfen, Klaus? Gibt es mit dem derzeit
Geschafften wenigstens ne klitzekleine Chance?
Wie sieht es mit Deinen Möglichkeiten aus?

Hochachtungsvoll:
Mercedes.

von Thomas Z. (usbman)


Angehängte Dateien:

Lesenswert?

Lotta  . schrieb:
> Der Prozessor ist doch auslesegeschützt, nicht wahr, Klaus?
nein das ist er nicht. Jens hat das (wie auch immer) ausgelesen. Wäre er 
geschützt, wäre das nicht möglich. Meine Vermutung geht in Richtung 
80515. Das war die erste Variante noch in NMOS und wohl ohne 
Ausleseschutz. Deshalb habe ich nach dem Vbb Pegel(Pin37) gefragt.

Ich habe im Disassembly mal einfach nach allen Fundstellen T2EX (P1.5) 
gesucht und T2EX durch dwell_timing ersetzt. Zusätzlich hab ich mir mal 
alle Stellen mit MOVC ausgeben lassen um Referenzen auf die Tabellen zu 
bekommen.

Was ich sagen kann ist dass das alles hochkomplexer handoptimierter 
Assemblercode ist. Da kann nicht einfach mal so schnell Funktionen 
erkennen.

Lotta  . schrieb:
> da die Befehle ja eventuell die gesuchten Speicherplätze bearbeiten,
> so kennen wir sie dann mit Name und Adresse.  :-P
dann mach mal. Ich habs ja schon geschrieben durch die paged 
Adressierung wird das mit den Adressen eher nichts. Zusätzlich wird 
ausgiebig die Registerbank Umschaltung genutzt.
Um das ernsthaft anzugehen wäre es wohl sinnvoll einen spez. Bosch CPU 
Deklarationseintrag im IDA 8051 cpu file anzulegen.

Ich hab mal die AMD Version des Datenblatts angehängt.

: Bearbeitet durch User
von Lotta  . (mercedes)


Lesenswert?

Thomas ( Du hast meinen unbändigen Respekt! ) meinte:

......  siehe obrigen Post

Sowas ahnte ich bereits. Wir wissen ja noch nicht mal richtig
was der Jens überhaupt will.
Will er das, was die Serviceprogramme können oder mehr?
Wenn er die Daten nur auf dem eigenen Programm anzeigen will,
und nicht über die Schlangenöl-OLS, da würd doch ein Interpretieren
des Übertragungsprotokolls reichen.-

Mir kommt es auch langsam vor, als wenn er unsere Hilfe gar
nicht wünscht, meine Fragen und Bitten in der Mail wurden noch nicht mal
mit nem Nullpointer beantwortet sondern mit (*void), also mit NICHTS.

Wenn ich Hilfe erwarte, würde ich alles was ich von der Steuerung
weiß hier posten, Welches Programm nehm ich zum Auslesen?
Was mache ich da, damit aus den ermittelten Werten ne lütte
protokollhaeckse ein Seqenzdiagramm zeichen kann, um das 
Übertragungsprotokoll zu verstehen?
Welche Variablen möchte ich haben / auswerten? Ich würd Speicherplatz
bereitstellen, damit Datenblätter Und Testprogramme von meinen
Helfern gemeinsam genutzt werden können, wie es in ner Hackergroup
Usus ist. Sollen meine Helfer ALLES machen, und ich steck mir dann
den Button an, oder solls ne vernünftige Märchentantenfreie
Zusammenarbeit zwischen uns OM's geben?

Fragen über Fragen, alles Mist.  :-P

mfg

von Jens (jbdasky)


Angehängte Dateien:

Lesenswert?

Hallo zusammen,

das Auslesen der RAM und ROM Adressen erfolgt aktuell über einen Tester. 
D.h. das Steuergerät wird gefragt und gibt dann die Werte wieder.

Gesucht hatte ich nach einem direktem digitalem Wege des Auslesens an 
einem CHIP mit RAM. Hier wurden bereits u.a. eine Lösungen wie DUAL-RAM 
die auch in der Industrie zur Anwendung kommen, genannt.

Bei der Adressierung des ROM habe ich eine Kombination aus CPU (interner 
ROM) und EPROM (externer ROM) von 0x0000 bis 0xFFFF vermutet.

Analog vermute ich dies hier auch für den RAM.
Für den internen CPU RAM vermute ich hier die Adressen von 0x00 bis 
0xFF. Letztendlich die Endwerte für die Steuerung von u.a. Zündung und 
Einspritzung.
0x100 bis x1FF sind nicht direkt auslesbar. Ich vermute hier aber eine 
Art Spiegelung von 0x00 bis 0xFF.

Mit den Adressen von 0x200 bis 0xFFFF werden vermutlich die externen 
RAMs angesprochen die sich auf den Platinen befinden u.a. der SRAM. Ich 
vermute aber nicht nur dieser. Welche RAMs hier noch angesprochen werden 
und mit welcher Adressierung dies erfolgt weiß ich aktuell noch nicht. 
Weiß das jemand?

@ Thomas: die Spannung an PIN 37 beträgt 3,14 V
RAM 0x36 ist Batteriespannung
RAM 0x3C ist "Diagnose"-Drehzahl bis max. 2550 1/min.
und heureka.. RAM 0x3B ist Drehzahl bis max. 10200 1/min. Das passt auch 
zu den EPROM Daten. D.h. Die Hex-Werte-Adressen im RAM korrelieren mit 
denen im EPROM. Die Frequenz ist mir leider nicht bekannt.

@ Horst: Anbei noch 2 Bilder zu der Klopfplatine. Die Unterseite ist nur 
im ausgebauten Zustand gut fotografierbar. Deshalb hab ich Bilder aus 
dem WEB genommen. Die Platinennummer und Chipbestückung ist aber analog. 
Farbmarkierung gelb und rot sind die Signaleingänge + von Klopfsensor 1 
und 2.

DTAs und andere freiprogrammierbare STG werde ich mir noch bei Zeiten 
anschauen. Aktuell bin ich aber noch nicht dazu gekommen.

@ Lotta: Ich werde keinen Webspace mieten. Wenn du ebenfalls Interesse 
hast, empfehle ich dir ebenfalls dir ähnlich Hardware zuzulegen und dich 
reinzufuxen. Es handelt sich nicht um eine OBD-II Kommunikation zwischen 
MSG und Tester. Beim ABS, ZKE,EWS,SRS,CruiseControl etc. Funktioniert 
dies. Für MSG, Instrument Cluster, EGS,Board Computer etc. wird über ADS 
und K-Line (TxD) bidirektional kommuniziert und mit der L-Line (RxD) das 
jeweilige Steuergerät zu Kommunikationsbeginn einmal angefunkt.

Viele Grüße,
JB

: Bearbeitet durch User
von Thomas Z. (usbman)


Lesenswert?

Jens schrieb:
> die Spannung an PIN 37 beträgt 3,14 V

dann haben wir einen 80515 in NMOS das AMD Datenblatt passt. Die A 
Versionen gab es nicht in NMOS. Damit ist auch klar dass der Controller 
ungeschützt ist.

> RAM 0x36 ist Batteriespannung
kann es sein das 0x36 die Adresse im internen RAM ist. Ich habe Ad 
Converter Code gefunden der Kanal 1 Adwerte auf IRAM:0x36 speichert. Mit 
dem SRAM hat das nichts zu tun.
1
code:9A5F _ad_convert:                            ; 
2
code:9A5F                 setb    RAM_25.2
3
code:9A61                 mov     A, #11111000b
4
code:9A63                 anl     A, ADCON        ; Ad Channel
5
code:9A65                 orl     A, DPL          ; 0..7
6
code:9A67                 mov     ADCON, A        ; ADCON= (0xF8 & ADCON) | DPL
7
code:9A69                 mov     DAPR, #0        ; start (0..5V)
8
code:9A6C                 jb      BSY, $          ; until complete
9
code:9A6F                 mov     A, ADDAT        ; result
10
code:9A71                 jnb     RAM_25.2, _ad_convert
11
code:9A74                 ret
12
code:9A74 ; End of function _ad_convert
13
14
und der Aufrufer:
15
......
16
code:9DBF                 mov     DPTR, #0xBE01   ; 01 = channel 1
17
code:9DC2                 lcall   _ad_convert
18
code:9DC5                 mov     RAM_36, A       ;save v_battery 
19
......

: Bearbeitet durch User
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.