SRAM auslesen der von einer anderen CPU genutzt wird

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".

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.

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.

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

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

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

......