disassemblare un file binario ecu [Archivio]

tranky

15-01-2016, 17:16

Allora per spiegare in forma "potabile" la composizione di un file binario non leggibile dobbiamo un po immedesimarsi in cio che vi sto per dire..
Facciamo conto che io e te (munro) ci telefonassimo, tra me e te c'è un "tunnel comunicativo" nel quale transitano i miei messaggi vocali e i tuoi.. se un terzo si contrappone tra noi 2 può ascoltare tranquillamente il contenuto del "tunnel comunicativo".
[io]----[te]
[io]---[impiccione]---[te]
questi sono i 2 esempi come detto sopra.
ora partiamo con [io] che invio un messaggio incapsulato dietro un algoritmo definiamolo XYZ (tanto per rimanere in tema con il sito e ecm) il quale converte il suono in un qualcosa di non comprensibile che in fase di ricezione ha 2 opzioni:
1) se il mittente ha il medesimo codice XYZ decripta il segnale e lo rende originale e "potabile"
2) se il mittente o chiunque si intrometta nella trasmissione non avrà modo di ascoltare il contenuto.
Diciamo che questo vale più che altro per le comunicazioni ma diciamo che il principio è il medesimo, basta invertire con
[io] = programmazione originale della centralina
XYZ = conversione del file da testo leggibile (in qualsiasi linguaggio sia espresso in precendenza sempre caratteri e linguaggi deve contenere)
[tu] = interprete come winols ecm ecc ecc
Allo stato attuale non saprei dirti con precisione con quale compilatore sia stato creato tale file ma esistono modi per il decompilare ma ci vuole tempo e fatica per arrivare al risultato anche perchè il file in se e per se farà parte di una suite alfa/bosch la quale avrà sicuramente il sorgente interprete.
Avendo quello hai il mondo del tuning tra le dita ;)
Spero di essere stato di aiuto e sopratutto chiaro.. contorto sicuramente ma spero chiaro
Chiedimi altro se ne hai necessità

tranky

15-01-2016, 17:28

facendo un sunto: avere XYZ equivale ad avere un driver/damos interprete del file di codifica solo che il damos/driver interpreta gli ID, l'"XYZ" interpreterebbe tutta la composizione del file.ecu

munro

15-01-2016, 18:08

ok ma se noi non abbiamo "xyz" come possiamo decifrare il contenuto di un micro o di una eprom?
mi sembra di aver letto da qualche parte che si utilizzi il linguaggio ASCII...

munro

15-01-2016, 18:22

Chiedi e ti sarà dato!
Non sono proprio un programmatore certificato ma ho coddato parecchio in vari linguaggi di programmazione.
Che devi realizzare?
l'idea e quella di implementare nel micro ed in eprom nuve funzioni non previste dal costruttore vedi ad esempio multimappa,launch control con als,sistema bang-bang,eccetera questo si potrebbe fare in teoria modificando le stringhe di codice in eprom in modo che il micro nella lettura del suo programma di routine implementi anche queste funzioni.

tranky

15-01-2016, 19:06

Si l'ASCII lo vedi infatti dal codice sull'hexdump.
Dovrei vedere qualche file di EPROM e vedere la composizione.
Appena ho tempo ci do uno sguardo.

munro

15-01-2016, 19:27

ti ringrazio...mi piace questo do..des ;))

munro

15-01-2016, 19:29

dimeticavo se hai bisogno di qualche file micro posso postarlo..

tranky

15-01-2016, 19:39

Guarda hai la mia massima collaborazione e se vuoi domenica mattina con calma postane uno e inizio a vedere la composizione e la scomposizione.
Ma di sicuro nulla di potabile visto che ogni carattere nella tabella ascii è legata ad una funzione (sia a stringa che a singolo carattere) dal programma che genera questi file ecu e con difficoltà qualcosa magari si traduce.
O magari è meno complicato di come pensiamo..
Testiamo e vediamo che succede ;)

munro

15-01-2016, 19:54

ti ringrazio molto tranky ma tu dici che sarebbe per me pressoche impossibile imparare a leggere l'ASCII??
intato però posto un piccolo promemoria in modo che anche chi e meno esperto possa capire di cosa parliamo.

La costituzione e la logica di funzionamento delle centraline elettroniche (ECU)

Voglio cercare di affrontare un argomento molto teorico e poco pratico, che può aiutare molti di noi a comprendere le logiche di funzionamento e la costituzione delle amate/odiate centraline elettroniche ECU con cui quotidianamente ci confrontiamo nelle diagnosi e nelle riparazione dei veicoli e nellla loro riprogrammazione.
Le mie sono conoscenze in materia sono piuttosto basiche: non sono un esperto e spero che chi ha più esperienza possa poi correggermi.
L' argomento se approfondito assumerebbe una piega molto teorica ed astratta che fontamentalmente serve e non serve se uno deve fare solo rimappature il discorso cambia nel caso delle riprogrammazioni di alcuni parametri del micro piu della eprom, quindi cercherò di essere più semplice possibile riassumendo le informazioni che ho al fine di capire solo come ragiona una centralina.

Come è composta una centralina?
Qualsiasi essa sia da quella motore a quella di aiuto al parcheggio, dalle prime comparse solo per l' iniezione, fino a quelle di ultima generazione, le centraline elettroniche sono formate principalmente da 5 parti fisiche :

-Alimentazione:
Comprende i positivi ed i negativi in arrivo dalla sorgente di alimentazione che, nel caso delle auto, è la batteria. La centralina ha al suo interno dei dispositivi in grado di stabilizzare le tensioni in gioco, generare altre alimentazioni come i 5V dei sensori, e filtrare il potenziale di massa isolandolo dai disturbi esterni (accensioni, spurie di radiofrequenza, interferenze elettromagnetiche, ecc..)

-Ingressi o input (I):
Una centralina deve avere degli ingressi per ricevere le informazioni dall 'esterno, siano esse "comunicazioni" (es. linea CAN) oppure segnali in arrivo dai sensori; a ****llo fisico gli ingressi devono essere composti da dispositivi che leggono dei segnali elettrici e li trasformano in informazioni digitali.

-Uscite o output (O):
Le uscite servono per convertire i comandi digitali in segnali di potenza al fine di far funzionare attuatori o spedire informazioni.

-Microprocessore:
E' il cuore operativo di tutto ed è in grado di elaborare le informazioni in arrivo dagli ingressi, accedere alla memoria e al programma di funzionamento e comandare le uscite.

-Memoria o eprom:
E' la sede dove viengono "stipate" le informazioni, le famose mappe e le istruzioni necessarie per gestire il processore.

Microprocessori "stupidi".
Il microprocessore è "stupido": non ha possibità di ragionare, ma solo di eseguire delle istruzione una alla volta; un insieme di istruzione di senso compiuto, che fanno compiere un lavoro al processore che si chiama Programma esempio:
- Leggere le informazioni di un sensore;
- Accedere alla memoria giusta;
- Confrontarle con i parametri memorizzati;
- Verificare la plausibilità del valore;
- Gestire un eventuale comando di uscita.
Questo insieme di istruzioni possono essere un vero e proprio "mini programma" quello che interessa a noi.
La particolarità di un microprocessore è la velocità con cui esegue le singole istruzioni; velocità che può raggiungere anche il migliardo di operazioni al secondo!

Come fa a gestire le informazioni?
Il Processore -di qualsiasi centralina- essendo un componente elettronico può solo ragionare con segnali elettrici: esiste quindi la necessità di convertire tutto in segnali adeguati.
Il discorso della conversione è alla base di questa mia discussione: le informazioni subiscono molte trasformazioni nel momento che raggiungono la centralina e per ora che escono, la complessità sta nel seguirle tutte.

Bit,Byte esadecimale e ASCII
Tutti questo nomi rappresentano i "formati" ed i linguaggi usati dalle centraline (e dai PC) per trattare i dati, ma cominciamo dalla base.
I bit:
L' unica cosa che sa fare un componente elettronico è quello di riconoscere delle tensioni (essere un multimetro), ecco che da qui nasce la necessità di trasformare tutto in segnali elettrici, dove una tensione bassa quasi uguale a zero verrà riconosciuta come "0", mentre una tensione più alta (esempio 5V) sarà riconosciuta come "1", questi due parametri sono i bit, ovvero le lettere dell' alfabeto elettronico.
Facendo tutte le combinazioni di 1 e 0 possiamo creare un alfabeto e quindi parole ovvero istruzioni esempio 00000001 significa "inizio del testo", bisogna pensare che un processore non ha bisogno di una quantità di parole come un essere umano, ma solo istruzioni da eseguire.
8 bit consegutivi compongono un Byte.
CODICE HEX:
Per semplificare il lavoro a chi programma e chi gestisce questa flotta di 1 e 0 hanno creato un altro linguaggio che semplifica il tutto è il "linguaggio esadecimale" o "HEX" ovvero un sistema con base 16 con il quale si trasformano i dati in byte in un codice più corto esempio 00111111 si può scrivere 1F (tradotto significa separatore oppure N°31).
Sembra difficile, ma alla fine è solo un modo diverso di rappresentare la stessa informazione, nel codice HEX compaiono anche le lettere (A B C D E F). Solitamente le centraline e i PC questo codice (HEX) viene usato per rappresentare gli indirizzi delle memorie, ovvero l' indirizzo da dove prendere o dove scrivere l' informazione, questa necessità nasce dal fatto che un processore deve sapere dove andare a cercare il dato che gli serve altrimenti non lo può trovare.
CODICE ASCII
Il codice ASCII è un ulteriore codice per trasformare i Byte in lettere o frasi compiute al fine di far capire qualche cosa a noi esseri umani sia per programmare sia per interfacciarsi ad esempio la diagnosi (P0300 significa mancate accensioni).

Riassumendo:
i programmi di gestione vengono scritti in codice ASCII, gli indirizzi in codice HEX e il tutto viene tradotto dal programma stesso in Byte (8bit) ovvero l' unica lingua che un processore può capire, al lato pratico se noi usiamo un oscilloscopio e osserviamo cosa passa sui pin del processore vediamo segnali elettrici simili ad onde quadre che rappresentano i bit 1 e 0:

Invece se con i programmi apposta ad esempio quelli di rimappatura, cerchiamo qualcosa nelle memorie usiamo gli indirizzi in HEX

Se facciamo la diagnosi o programmiamo usiamo il codice ASCII, e ragionandoci si capisce il perchè di tanti linguaggi i bit sono inleggibili, gli HEX sono complessi ed usati nelle rimappature solo da "occhi" esperti, mentre il codice ASCII è per tutti gli addetti ai lavori diciamo cosi, è un pò come se dovessimo leggere il giapponese, prima lo traduciamo in inglese e poi in italiano.

Gira che ti rigira la centralina attraverso appositi segnali elettrici (istruzioni) memorizzati nelle memorie, gestisce con altri segnali elettrici abilitando o meno le uscite, il tutto ad una velocità ininmaginabile e senza commettere errori, gli errori se ci sono, sono stati fatti da chi ha fatto i programmi.
La centralina per funzionare deve avere le giuste alimentazioni, i giusti segnali di ingresso e deve comandare in modo corretto, sempre parlando di tensioni, correnti e tempi di reazione, mentre al suo interno le memorie devono contenere i programmi ed il processore deve controllare tutto.

Chiaramente più la centralina è complessa e più operazioni deve gestire e più è difficile da analizzare da parte nostra, ma con le conoscienze basi descritte si possono affrontare qualsiasi tipo da un finestrino automatico ad una EDC17, chiaramente con le dovute proporzioni.

La rimappatura da parte degli elaboratori consiste nel variare alcuni parametri "motoristici" inseriti nelle memorie e presi da riferimento dal processore, occupano una piccola parte di tutto il programma e le protezioni anti-elaborazioni.

Spero di non aver fatto confusione, ho cercato di riassumere il tutto e renderlo il più semplice possibile al fine di aiutare a capire la logica di funzionamento di una centralina, in modo da avere meno dubbi,d'altra parte per fortuna o per sfortuna queste centraline ci sono e non ci si può fare niente, se non farcele amiche e migliorare il nostro lavoro.

tranky

15-01-2016, 20:38

Quoto in pieno quanto hai illustrato.
Non potevi essere più chiaro di così

tranky

16-01-2016, 10:43

Munro vista la tua preparazione credo che ci metti meno tu a interpretare il codice della EPROM che io a fare mappe sensate.

tranky

16-01-2016, 13:53

News
Ho fatto una ricerca lato tool per vedere eventuali disassemblatori (non decompilatori) ed ho visto che ci sono.
Ora l'incognita é sapere e capire con quale architettura (x86, arm o cos'altro) sono fatti questi file e la risposta ce la da il processore della ECU e il tipo di memoria che viene usata.
Non so se posso postare link solo per visione, mi prendo la responsabilità di eventuali richiami dell'admin ma lo posto unicamente per rendere chiaro quanto descritto nella speranza che non venga interpretato come spam (non faccio parte della unit del sito).

tranky

16-01-2016, 13:54

http://www.break-ic*****/Disassembler_software_mcu_reverse_engineer.htm

munro

16-01-2016, 14:48

molto interessante tranky mi sembra di aver capito che c'è un sw che riesce a decompilare un file direttamente dal hex o dla bin all'ASCII mi sembra che si chiami IDA pro o qualcosa del genere...io però a parte quello ostato sopra di piu non sò in merito alla compilazione/decompilazione file altrimenti non aprivo un tread tranky...
spero di imparare perche come giustamente hai detto tu sapendo fare questo si ha veramente l'elettronica in pugno.

munro

16-01-2016, 15:27

guarda un pò qui tranky cosa ho torvato:Andy Whittaker's Site | What's In My Brain (http://www.andywhittaker*****/)
vai sulla sezione dissasembler me7.1 ci sono 3 video tutorial interessanti però e tutto in inglese un pò difficile da seguire per me..

tranky

16-01-2016, 15:33

Tranquillo sto prendendo le informazioni necessarie alla ricerca dell'eventuale software o di tipologia di decodifica da fare per le ecu.
Ti anticipo che nel caso non vi siano tool e vanno fatti script appositi, al 90% bisogna passare su Linux (e li so dolori per chi non ci ha mai messo mani).
Cmq nulla di impossibile, la comodità di usare Linux sta nei compilatori ai quali affidarci per eseguire uno script di conversione con multeplici variabili e funzionalità con debug per eventuale troubleshooting del codice creato per magari migliorarlo o correggerlo.
Domani ho più tempo da dedicarci, ora debbo andare col bimbo e miglie da parenti (du palleeeee)...
Rimango a disposizione via cell come sempre ;)

tranky

16-01-2016, 15:35

tranky

16-01-2016, 16:37

Ho visto i tutorial e potrebbero esserci anche quelli del gruppo bosch.. dal video parte dalla lettera i in visuale di scelta quindi presumo ma non ne sono sicuro.
Staresa lo vedo meglio che ora debbo scappare dai parenti (serpenti).
Buona serata

Errecinque

17-01-2016, 00:14

Hey voi due .....io vi guardo dalla finestra per ora. La fame di sapere è tanta.....ma perchè non ho dato retta a mia madre e non le ho studiate a 20 anni ste cose quando avevo tempo e voglia invece di fare l'università della 3 età in corsi serali suo forum.

tranky

17-01-2016, 10:13

Ciao Errecinque, accosta la finestra che fa freddo!
Non serve un titolo di studio per queste cose.
Io lavoro da quando avevo 16anni e non ho neanche diploma.
Basta un'idea chiara e tanta voglia e tempo di imparare e vista la vostra preparazione garantisco che sarete guru in tempi brevissimi.
Più tardi inizio e posto i risultati, parto dal file della flash e vediamo cosa esce
A dopo

tranky

17-01-2016, 18:38

Eccomi qui con aggiornamenti..
Oggi ho scavato per la rete alla ricerca di software adatti allo scopo del topic iniziato da munro ed ho fatto una ventina di installazioni di software che, per la maggior parte, si sono rilevati quanto meno inutili allo scopo.
Alla fine tra vari tool il migliore e funzionale, oltre a winhex che parzialmente fa quanto cercato ma fa altamente cagare, è stato IDAPro che ho scaricato e licenziato.
Il file della flash presenta offset che vanno ad interagire nella centralina e vi mostro qualche output:
seg000:001D60C0 dd 8000800h, 0E8038403h, 0D007DC05h, 0B80BC409h, 0A00FAC0Dh
seg000:001D60C0 dd 0F4010000h, 0DC05E803h, 0C409D007h, 0AC0DB80Bh, 20h dup(0)
seg000:001D6164 dd 8000800h, 84035203h, 0DC05E803h, 0C409D007h, 0AC0DB80Bh
seg000:001D6164 dd 0E803F401h, 0D007DC05h, 0B80BC409h, 0A00FAC0Dh, 20h dup(0)
seg000:001D6208 dd 8000800h, 84035203h, 0DC05E803h, 0C409D007h, 0AC0DB80Bh
Questo è molto UNIX come metodologia di elaborazione delle memorie quindi ora dobbiamo eseguire qualche test su altre memorie.
Postate un intero backup non verginato e vediamo se dall'estrapolazione viene fuori qualche dato sensato.
Data la mia ignoranza mi viene da chiedere se aveste la possibilità di postare un backup del body o quello elabora le info unicamente tramite la ecu e fa solamente da interprete e "braccio" delle funzioni della ecu?
Tanto per curiosità che se fosse fattibile cambieremmo anche TUTTA la schermata del cruscotto personalizzandolo (scusate sè poco!)
Attendo vostro feedback e backup da mettere sotto torchio!

tranky

17-01-2016, 18:54

La programmazione del file flash è in Alllesmbly, con i file delle altre memorie si può comprendere l'eventuale correlazione delle funzioni e variabili in modo da definirne le funzioni che saranno espresse con qualche variabile ma insieme le troviamo sicuramente..
Dai ragazzi postate qualcosa di qualsiasi marca, purchè siano tutte le memorie

tranky

17-01-2016, 18:55

Alllesmbly = Assembly (errore di battitura.. sorry)
https://it.wikipedia.org/wiki/Assembly
Un bordellone ma nulla di impossibile!

munro

17-01-2016, 19:11

mamma mia che casino....tu ci capisci qualcosa? che cosa ti serve il file di un microprocessore o tutto il backup ecu cioe il contenuto di eprom,e2p e micro?

tranky

17-01-2016, 19:18

Quel "casino" che vedi sono unicamente funzioni che lui invia. Nella memoria principale ci dovrebbero essere le identificazioni di questi codici.
Siccome qui è tutto in correlazione, se riesci ad inviarmi un intero backup di una qualsiasi centralina sarebbe meglio, in modo che:
Leggo la memoria centrale e vedo gli ID e la loro identificazione sulla memoria principale
Leggo le altre memorie e vedo quali richiamano quali funzioni in confronto delle memorie.
Dopo di che cerchiamo di svelare le funzioni come sono definite e come si possono modificare.. Successivamente avremo bisogno di una cavia che carichi la ecu! :p
Mi sveli la questione del body appena hai 2 minuti? Non ho capito se ha una memoria a se o intraprende funzioni legate alla ecu ma credo abbia una qualche sua memoria da quanto penso... ma potrei sbagliare.

munro

17-01-2016, 19:31

allora ragazzo ti posto il backup completo di una edc16c39 alfa 159 mjet 150cv cosi restiamo in ambito anche per la tua ecu se vuoi posso anche qualcosadi piu semplice per iniziare perche credo che la edc16 sia molto complessa da scomporre...diciamo che queste operazione che vogliamo tentare sono ottime nel caso di ecu datate di cui non ci sono damos o non si capisce bene la logica di funzionamento...
per il quadro strumenti ..Tranky non saprei dirti io mi occupo principalemte di eleborazioni e riparazioni motoristiche su queste materie:body,abs,quadri eccetera mi affido al mio socio elettrauto...
posso provare a chiedere a lui lunedi cosi mi faccio dire il funzionamento però credo che il quadrante funzioni in entrambi i modi che ahi descritto tu...cioe possiede sia un memoria interna è riceve anche istruzioni esterne vedi il contagiri o il segnale contakm...

tranky

17-01-2016, 19:57

Grazie per il "ragazzo" ma cosi mi illudo di essere giovane.
Proviamo questa e se riesco a capirci qualcosa passiamo ad una a cui puoi caricare la EPROM per provarla.

tranky

17-01-2016, 21:18

Munro ti ho mandato una ****, rispondi come descritto appena puoi.
Ho visionato i 3 file e hanno tutti quell'offset. Ora dovrò definire la funzione di tutti gli offset e catalogarli, confrontarli e capire i riferimenti.
Datemi tempo e posto i risultati man mano che opero.
Proverò a definirli in C++ su Linux e vedere se riesco a trovare le funzioni nelle sue variabili.
Qualcuno ha operato con Meucci e sa se li vengono definite qualche operazioni del genere o meno?

sisco

17-01-2016, 21:46

Tranky mi complimento per il tuo coraggio nell'affrontare questa sfida da temerari ( oppure ne sai qualcosa di programmazione, quindi ancora complimenti), io tempo fà ho provato a utilizzare qualche software tipo ollydb oppure ws32dasm per qualche exe che non avevo il seriale e dopo i primi approcci ho pensato " qui ci divento vecchio" quindi ho lasciato perdere, anche io come errecinque vi sto seguendo e anche io ho letto che IDApro sembra il più indicato per quello che volete provare a fare, che dire buona fortuna e spero che riusciate nell'intento

tranky

17-01-2016, 23:31

Grazie sisco,
non sono un programmatore anche perchè i programmatori al 99% sono esauriti, pazzi, mediocri e dissociati.
Al contrario io sono socievole, amichevole e sopratutto TROMBO.. quelli neanche col 3d ne vedono una (ghgh).
Scherzi a parte ti ringrazio per l'incoraggiamento che, sembra na stronzata, ma l'apprezzo più di tanti sorrisi finti.
Vi aggiorno appena ho news ma molto a rilento questa settimana causa lavoro onsite (presso cliente) per sistemazione della rete.
Ho scaricato e provato Meucci e fa il verginamento del file della e2p.. appena ho tempo lo uso in debug e vedo quali offset elabora, almeno inizio a catalogarli visto che sono un'infinità...
Vi aggiorno appena rimetto mani sul backup condiviso da munro
Buon inizio settimana a tutti ;)

munro

22-01-2016, 19:26

un pò di info sul micro edc16c39....https://en.wikipedia.org/wiki/PowerPC_5000#MPC56xx

tranky

25-01-2016, 13:27

Tra le tante cose in questo periodo sto cercando di arrivare alla soluzione di questo topic.
Le ultime news che ho è che il processore MPC56xx è il medesimo (Architettura PPC) di dispositivi mobile.
Allego un documento che spiega in forma molto complessa degli esercizi mirati a eseguire un "hello world" in funzione delle sue flags (le flags sono le operazioni che un processore può eseguire nel linguaggio di programmazione nel quale viene impiegato ed ogni linguaggio ha le sue flags compatibili.. diciamo...).
Tale processore è un elaboratore che messo in opera sul file bin postato da munro, va ad allocare operazioni in diversi settori di memoria i quali in fase di elaborazioni creano una "funzione".
Sto cercando di estrapolare tali funzioni in modo da poter riprogrammarle ma è un "bagno di sangue" non avendo in chiaro le tabelle impostate da mamma bosch.
Barcollo ma non mollo!
eccovi il file detto sopra..
10101

tranky

25-01-2016, 17:40

Sono riuscito a visualizzare le operazioni del processore per ogni ID del file (testato sul file flash ed e2p) ma gli oggetti sono cifrati come al solito e non si definisce con cosa effettua quella funzione.
(blasem..parolac..sbatti****c)
Domani vi posto il risultato ottenuto e vediamo se con più menti qualcosa si riesce a capire meglio.

munro

25-01-2016, 17:43

bravissimo tranky....ci sono cose che purtroppo non riesco a fare per via della mia estrazione meccanica diciamo..
ma grazie a te forse possiamo capire di piu di ogni singola ecu>micro>eprom...
sei un grande..

tranky

25-01-2016, 18:13

Tranquillo munro
Tu pensa a fare quel che devi in primis.
Speriamo che tra le mie conoscenze informatiche e le tue su le ECU, riusciamo a sbrogliare sta matassa e ci programmiamo le ECU senza freni (non delle ruote altrimenti facciamo crashtest).
Buona serata

munro

25-01-2016, 18:43

in pratica corregimi se sbaglio tranky l'unica cosa che manca nel hack del micro ora è il codice sorgente??

tranky

25-01-2016, 19:44

A dirla per come é queste centraline non so se elaborano codice cifrato (quindi con sorgente criptato) o solo compilato e va definito con cosa..
Nella prima ipotesi torna in vigore la storia del XYZ detto sopra mentre nella seconda é solo un interprete da definire, usare per convertire e comprendere a fondo..
Domani a lavoro visto che sto con le chiappe parcheggia senza faccende ci smanetto un'altra po e ti aggiorno.

munro

25-01-2016, 22:30

leggevo nel documento che hai postato tu che il codice di programmazione usato è il C
ora però non sappiamo se bosch o fiat hanno adottato questo direi di si ma chi meglio di te può scoprirlo..
se hai bisogon di una mano contattami...;))

tranky

25-01-2016, 22:33

Per scoprirlo ho bisogno di Linux, crosscompiler e un PC!
Appena finisco il notebook lo installo col dual-boot e devo se decompila in C o domani va VMware.. Vediamo domani

tranky

26-01-2016, 14:35

Ciao,
ecco le news del giorno (stiamo arrivando a ****lli del Messaggero, ogni giorno cronaca del giorno):
Qui 10105 è visibile il codice scomposto con tutti i fattori di allocazione delle memorie basato sul codice Assembly (ora sono certo che è assembly e non C++) che ora non posso postare totalmente in quanto lo sto usando su una macchina virtuale e appena faccio scorrere il codice, mi killa i processi per scarsa memoria. Nel codice come si può notare vi sono per ogni ID la sua "formula" di interazione sulla ECU (ovviamente codificato in linguaggio del processore) il quale interpreta il suo segnale per operare nelle sue funzionalità, quindi inviare eventuali segnali a dispositivi o correlare con sensori i quali creano roule del tipo: se il segnale ECU è X e il sensorX dice X, invia X al componente Y.. roba cosi insomma.. questo dovreste dirlo voi a me :p
Qui vi posto una breve descrizione dell'elaborazione del codice Assembly a ****llo di processore.
riguardo l'intento di integrare nuove funzionalità direi che non siamo molto lontani dal farlo, dovremmo a questo punto avere una ecu+auto test ed effettuare eventuali scopiazzamenti di codici inerenti funzioni definite nella ecu test e vedere se si integrano. Ciò non so se compromette la dimensione del file da riscrivere, lo sapremo unicamente facendo prove.
Ecco qui il documento su l'assembly (parziale ovviamente visto che saranno nmila pagine in toto)
10106
Se qualcuno ha avuto modo di leggere il codice come descritto ed ha qualche consiglio, sono bene accetti.
Ricordo che la modifica del SistemaOperativo delle ECU non è altro che un'implementazione del sistema nativo paragonabile ad uno smartphone android custom della casa al quale installiamo ad esempio cyanogenmod sopra, quindi medesime funzionalità con qualcosa in più della casa (sempre se funziona e non si blocca la ecu ma nulla che un BDM si possa risolvere col file ORI)
Al prossimo aggiornamento (work in progress)

tranky

26-01-2016, 14:45

ah dimenticavo di dire una cosa..
notate dall'img del codice che l'elaborazione è suddivisa da 2 tipologie di processore:
- 386 che sarebbe la x86 dei processori standard a 32bit
- 8086 che sarebbe una vecchissima gamma di processori (fine anni 80, primi 90)
Direi che i componenti della Ecu siano diversificati anche da 2 tipologie di processori..
Presumo ma non ho verificato sulle documentazioni online delle componenstistiche della ecu.
byebye

Errecinque

26-01-2016, 15:07

tranky

26-01-2016, 15:17

No scusa piccolo OT, ma teeee maneggi queste cose (ho visto quante pagine ha il doc allegato l'ho salvato e messo da parte per la pensione) e ti aggrovigli su dei BP che un asino come me ha capito? Hai ragione... tu TROMBI troppo....fine OT

AHAHAHAHHAHA
Ti adoro amico.

munro

26-01-2016, 15:41

allora tranky...ci siamo quasi mi pare...nell jpg che hai postato(che si vede davvero male) mi pare di vedere le funzioni ecu in codice ora secondo me manca un ultimo passaggio per estrapolare da quella catasta di lettere è numeri senza senso una qualcosa di leggibile...
in pratica noi vediamo questo
sub_FFA60:
FFA60 mov r4, word_8E40
FFA64 mov r9, word_BE80
FFA68 cmp r9, r4
FFA6A jmpr cc_ULE, loc_FFA7C
FFA6C mov r4, word_F87A
FFA70 mov r9, word_BE82
FFA74 cmp r4, r9
FFA76 jmpr cc_ULE, loc_FFA7C
FFA78 movb byte_8DAC, ZEROS
FFA7C
FFA7C loc_FFA7C:
FFA7C
FFA7C extp #0E1h, #1
FFA80 mov r4, 0CFF2h
FFA84 jnb r4.2, loc_FFA9A
FFA88 jnb word_FD48.9, loc_FFA94
FFA8C extp #0E1h, #1
FFA90 mov 0CFF2h, ZEROS
FFA94
FFA94 loc_FFA94:
FFA94 movb rl4, byte_8AF3
FFA98 rets
FFA9A ; ---------------------------------------------------------------------------
FFA9A
FFA9A loc_FFA9A:
FFA9A extp #0E1h, #1
FFA9E mov r4, 0CFF0h
FFAA2 mov r9, word_BE7E
FFAA6 cmp r9, r4
FFAA8 jmpr cc_ULE, loc_FFABE
FFAAA movb byte_8DAC, CC2IC
FFAAE addb rl4, #1
FFAB0 extp #0E1h, #1
FFAB4 movb 0CFF0h, rl4
FFAB8 movb rl4, byte_8AF3
FFABC rets
FFABE ; ---------------------------------------------------------------------------
FFABE
FFABE loc_FFABE:
FFABE jb word_FD48.9, loc_FFACE
FFAC2 extp #0E1h, #2
FFAC6 mov 0CFF0h, ZEROS
FFACA mov 0CFF2h, ONES
FFACE
FFACE loc_FFACE:
FFACE movb rl4, byte_8AF3
FFAD2 rets
FFAD2 ; End of function sub_FFA60

ma per comprendere il tutto ed implementare nuove funzioni dovremmo vedere questo

function_8FFA60()
{
// Anti-Lag
if (vehicleSpeed < ThresholdSpeed && engineRpm > ThresholdRpm)
{
closingTime = 0; // Interrupt ignition
}

// No-Lift-Shift
if (! noLiftShift_active)
{
// NoLiftShift is inactive
if (cond_clutchPressed)
{
noLiftShift_active = TRUE;
}
}
else
{
// NoLiftShift is active
if (counter_NoLiftShift < ThresholdCounter)
{
closingTime = 0; // Interrupt ignition
counter_NoLiftShift++;
}
else
{
if (! cond_clutchPressed)
{
counter_NoLiftShift = 0;
noLiftShift_active = FALSE;
}
}
}
}

function_antilag_noliftshift()
{
// Anti-Lag
if (B_kuppl && vfil_w < SpeedThreshold && nmot_w > LaunchRPM)
{
tsrldyn = 0; // Interrupt ignition
return;
}

// No-Lift-Shift
if (B_kuppl)
{
if (! B_brems && nmot_w > RPMThreshold && wped > AccPedalThreshold)
{
// NoLiftShift is active
if (counter_NoLiftShift < IgnitionCutDuration)
{
tsrldyn = 0; // Interrupt ignition
counter_NoLiftShift++;
}
}
else
{
// Other conditions not true, don't allow ignition interruption
// until clutch is released and pressed again
counter_NoLiftShift = 0xFFFF;
}
}
else
{
// Clutch released -> re-arm NLS
counter_NoLiftShift = 0;
}
}

qui amico mio entri di nuovo in gioco tu sul come fare...
P.S: erre ha ragione scopa di meno se capisci queste cose i bp e cazzatine varie sono una fumata di sigaretta.

tranky

26-01-2016, 15:59

Dove hai estrapolato quell'output?
Riguardo il trombare parlate con mia moglie, non ho voce in capitolo.. la donna ha il "bastone" del comando!

munro

26-01-2016, 16:17

da nefmoto...

tranky

26-01-2016, 16:27

ok quindi tunerpro.. ora iniziamo a capire la direzione da prendere anche se non ho capito come funziona con i file xdf..
imparo imparo imparo...
work in progresex !

munro

26-01-2016, 16:36

è progresex sia...:cool:

munro

26-01-2016, 17:27

azzarola...demeticavo..i file xdf sono dei driver come quelli di ecm ma creati dall'utente in tunerpro stesso in pratica credo che sul Sw esista una funzione di disassembly direttamente dal file in hex attraverso cui ti puoi creare i tuoi driver o xdf in funzione del file stesso.una volta fatto questo in tunerpro si carica prima il file ori della eprom da modificare e succesivamente il file di settaggio xdf fatto dal file ori stesso una volta caricati tutte è due nel menu a tendina del sw appaiono tutte le mappe create in xdf
è una cosa facile a dirsi ma molto difficile a farsi io ci ho provato in quanto tunerpro è un sw open source ma ci ho rinunciato perche secondo me è piu una cosa da programmatori che sanno benissimo il codice esadecimale e sanno farsi i calcoli in esadecimale.
procurarsi questi file non è difficile qualcosa in giro c'è solo che essendo creati da utenti sconosciuti la loro attendibilità fà un pò desiderare.

tranky

26-01-2016, 17:39

tranky

28-01-2016, 13:12

Aggiornamento
oggi ho chiesto ad un programmatore della mia azienda di vedere un secondo quel file e mi ha rifilato delle illustrazioni riguardo il codice che se diceva che non era capace faceva più bella figura..
Continuo gli studi con la mia bella III media in pancia alla faccia di chi muore dietro un libro per diventare celebroleso

vi aggiorno appena ho news che sto testando altri 4 tool per la conversione su mpc56xx in attesa che qualcosa riesco a vedere...

munro

28-01-2016, 14:20

sei un genio...

tranky

07-02-2016, 20:31

aggiornamento.
Sono passato a linux per effettuare la procedura di conversione e compilazione ma.. tutte le variabili sono indefinite e non visibili.. quindi a questo punto partono le biastime.
Il file è parzialmente decompilato ma senza quel famoso fattore XYZ non vedremo 'na sega..
Attendiamo news che nell'eventualità esca pubblicato ne integro il modulo per la decompilazione.
Fino ad ora quindi: Bosch 1 - tuner 0 (maledetti!)

munro

28-08-2016, 13:14

ragazzi salve eccomi di nuovo qui...scusatemi tutti per le mie assenze prolungate sul forum ma ultimamente stò avendo parecchi problemi di salute che non mi permetono di seguire tutto come vorrei...
comunque il progetto di hacherare lle auto procede anche se a lento passo...
volevo rendervi partecipi degli ultimi sviluppi di studioin materia e riporto qui perchi fosse interessato all'argomento una importante pagina che ho pescato in rete al quale ho aggiunto e/o eliminato alcune parti.
l'autore della presente illustrazione mi voglia perdonare per la "scopiazzatura".
Quindi in questo post voglio riferire le mie esperienze e studi su elettronica del veicolo in merito all"hacheraggio" dell'auto".
Avvertenze: ho trovato che le informazioni generalmente disponibili su questo argomento su internet sono piuttosto scarsa e non molto chiaro. Mentre sto cercando di fare del mio meglio nella verifica, degli errori potrebbero essere presenti.
Sentitevi liberi di aggiungere i vostri commenti e/o le vostre critiche.
Questo sta per essere un progetto a lungo termine, in modo da questa pagina sarà migliorata nel corso del tempo*****e ben saprete le automobili sono complessi,sempre complessi.
Elettronica in auto è davvero sofisticato, e le auto attuali auto in commercio hanno decine di unità di controllo per dispositivi di gestione, sensori,ecc..
Questa premessa è d'obbligo per quello che stò cercando di fare quindi riporto un promemoria delle varie componenti e particolarita dei sistemi interessati in questo studio.
ECU: Unità di controllo Elecronic,tutti noi sappiamo cosa sono ma la coniscenza in merito è davvero superficiale perche ci si limita a capire solo un minima parte di queste complesse unita.
c'è da sapere per chi non lo sapesse che queste ecu(o almeno da un certo periodo in poi,e lo vedremo piu avanti)"parlano" su reti locali, dei veicoli che sono simili a un comune computer in linea LAN, ma basate su protocolli diversi.
ECU, Engine Control Unit, sono stati i primi ad essere collegato alla rete di veicoli, presto seguito da altri centraline (generica unità di controllo elettronico).
questo per poter ridurre la quantità di cavi di segnale tra i molti componenti elettrici di una vettura moderna, sono stati introdotti protocolli di comunicazione digitale e interfacce digitali elettroniche tra ogni dispositivo elettrico e collegate tra loro appunto come computer in linea con una infrastruttura di comunicazione.
La centralina più importante è l'unità di controllo del motore.
come BOSCH (Esempio: EDC16), MAGNETI MARELLI (esempio: 95160), SAGEM (esempio: 95080), SIEMENS (esempio: TMS374)ecc...

Standard di comunicazione:un terribile mal di testa
Ci sono molte norme che definiscono i protocolli, di direzione,autodiagnosi e intercomunicazione deelle elettroniche in auto.
Ecco un elenco incompleto e probabilmente forse sbagliato
SAE e ISO sono i quadri standard e documenti più comuni, ma ci sono molti altri
SAE è la Society of Automotive Engineers.
SAE definisce comunicazione standard utilizzato nei veicoli On-Off-Road e terrestri. In questo schema 3 classi di dispositivi di comunicazione sono spiegati:

Classe A: fino a 10Kbit / sec, multiuso, asincrono, utilizzato per la non-tempo reale(tenete a mente questa frase perche il mio progetto nasce proprio da qui,ma lo spieghero in seguito), sensori intelligenti, la riduzione dei cavi a bordo vettura come dicevamo.
Classe B: nella gamma 10Kbit / sec fino a 125Kbit / sec, utilizzato per il trasferimento dei dati e il controllo intermodulo non in tempo reale. SAE J1850 è un protocollo CLASSE B, attualmente utilizzata per la connettività a basso costo tra i nodi come strumentazione e dispositivi diagnostici.
CLASSE C: critica, ad alta velocità, le comunicazioni in tempo reale tra i dispositivi. Per queste esigenze, CAN ad alta velocità è attualmente utilizzato (fino a 1 Mbit / sec), ma ci sono anche alternative più veloci, come Flexray (fino a 10Mbit / sec, in primo luogo implementato in BMW X6 nel 2008 ad esempio ).

SAE J1850 descrive due diversi protocolli: Protocollo di un VPW singolo cavo a bassa velocità (Variable Pulse Width) in esecuzione a 10.4Kbit / sec e un protocollo più veloce a due fili differenziale PWM (Pulse Width Modulation) in esecuzione a 41.6Kbit / sec. Questo è non può né è compatibile con CAN.
VPW è classicamente utilizzato da General Motors (GM) i veicoli.
PWM è classicamente utilizzato da veicoli Ford.

ISO_9141-2 non è un protocollo di segnalazione, ma un'interfaccia diagnostica per verificare la funzionalità dei componenti del veicolo. È un'interfaccia seriale che funziona a 9.6Kbit / sec. Spesso è disponibile in connettore OBD-2.

ISO_11992 è un bus CAN utilizzato negli autocarri per le comunicazioni tra il trattore e rimorchi.

SAE_J1939 è un insieme di specifiche sulla base di una infrastruttura CAN sottostante, lavorando con identificatori LATTA 29bit e di solito con un bit rate di 250kbit / sec. Questo è normalmente utilizzato per autocarri e veicoli industriali. Si tratta di un prerequisito per la FMS (vedi avanti) sistema per funzionare. ui . Altre informazioni J1939 si possono trovare su wikipedia,inoltre secondo wiki SAE_J1939 sostituisce SAE_J1708 e SAE_J1587.

Ecco un elenco dei bus di dati Automotive.

Reti di veicoli
In realtà ci sono molte reti del veicolo, eventualmente sulla base di standard diversi, diverse criticità, diversi protocolli, e le diverse velocità di comunicazione. Attualmente queste reti stanno convergendo allo standard CAN, ma ci sono molti altri. Dal momento che CAN è ormai lo standard de-facto per il networking di veicoli, a volte è anche identificato come VDB (bus dati del veicolo).
Nonostante la sua popolarità, CAN bus non è l'unica rete all'interno di qualsiasi veicolo moderno, e in un solo veicolo di solito ci sono diverse reti (multipli possono reti e non-CAN reti).

CAN sta per Controller Area Network. È stato originariamente sviluppato da Bosch, a partire dal 1983. CAN è utilizzato in molti ambienti di automazione e non solo nell'industria automobilistica.

In un bus CAN tutti i dispositivi di comunicazione sono collegati agli stessi due fili, etichettati CAN-alta e CAN-Low. Tutti i dispositivi devono utilizzare il bus alla stessa velocità. A ciascuna estremità, i due fili sono collegati con una resistenza da 120 ohm sulle terminazioni.
Non è necessario avere un segnale di terra comune tra i dispositivi di comunicazione. lunghezza massima del bus dipende dalla velocità operativa, e ad 1Mb / s è di circa 40metri. velocità del bus rete di bordo sono di solito al di sotto 500kBit / sec.(e come se in un solo secondo riusciamo a scrivere o leggere mezza mappa da un mb per capirci,e questo è molto interessante per quello che voliamo ottenere)l' implementazione veicolo bus ad alta velocità spesso adotta doppi cavi intrecciati.
In una situazione normale, i due fili portano un segnale a due ****lli, perfettamente speculare, e quando uno è alto l'altro è basso.

I diversi valori logici dei segnali possono essere letti, e qui ogni segnale ha una durata di circa 1V.Un trasferimento completo può pacchetto è visibile. Il tempo complessivo di trasferimento dei pacchetti è di circa 200ms (320-120).

munro

28-08-2016, 13:19

questa è solo una parte in seguito posterò altro in materia..

Errecinque

28-08-2016, 14:49

Bentornato Munro spero nulla di troppo serio, ci domandavamo proprio che fine avevi fatto con un altro utente. Meglio così

munro

28-08-2016, 17:10

Ciao erre grazie di tutto purtroppo ripeto i problemi che ho non mi permettono di seguire tutto come vorrei ma spero di riuscire a ristabilirmi al più presto...

munro

28-08-2016, 18:01

di seguito riporto altre info riguardo la linea can in quanto sostanzialmente la mia idea è di riuscire a riprogrammare le varie ecu usando non la classica porta obd ma implementando il pc con il tool di riprogrammazione adeguamente conformato per poter seguire in real time sia il lavoro ecu,quindi micro,ram e flash,e di conseguenza implementare spezzoni di codici per la ricalibrazione degli stessi purtroppo come potrete vedere in seguito la cosa è fattibile ma particolarmente difficile perche appunto ogni frame di dati canbus presenta un codice indentificatore e uno di priorita che attraverso i vari nodi can viene di volta volta processato.

Il protocollo CAN
Attualmente ci sono due versioni principali del protocollo CAN
standard: 2.0A con 11bit identificatori
standard CAN estesa: 2.0B con 29bits identificatori
CAN è definito in ISO_11519 e ISO_11898.

ISO 11898-2 definisce l'alta velocità CAN, fino a 1Mbit / sec

ISO 11898-2 ad alta velocità

ISO 11898-2 è lo standard di ****llo fisico più usato per reti CAN. Esso descrive l'unità di accesso al bus (implementato come transceiver CAN ad alta velocità) funzioni, così come alcune caratteristiche dell'interfaccia di media-dipendente.
In questo standard la velocità dei dati è definito fino a 1 Mbit / s con una teoricamente possibile lunghezza del bus di 40 m a 1 Mbit / s. Lo standard ad alta velocità specifica un bus differenziale a due fili per cui il numero di nodi è limitato dal busload elettrica. L'impedenza di linea caratteristica è di 120 Ohm, la tensione di modo comune varia da -2 V sul CAN_L a +7 V CAN_H. La nominale specifica ritardo di propagazione della linea bus a due fili è specificato a 5 ns / m. Tutte queste figure sono valide solo per un / velocità di trasferimento 1 Mbit s ed una lunghezza di rete massima di 40 m.
Per ottenere la compatibilità fisico tutti i nodi della rete devono utilizzare lo stesso o un simile bit di temporizzazione. Per le applicazioni automotive la SAE ha pubblicato le specifiche SAE J2284. Per le applicazioni non-automotive industriali e di altro il progettista del sistema può utilizzare la raccomandazione CiA 102. Questa specifica definisce il bit-timing per i tassi di 10 kbit / s a 1 Mbit / s. Esso fornisce inoltre raccomandazioni per le linee di bus e per i connettori e assegnazione dei pin.

ISO 11.898-3 (aka ISO 11.519-2) definisce il fault tolerant (e velocità inferiore) possono, fino a 125Kbit / sec

ISO 11.898-3 fault-tolerant

Una forma alternativa di interfacciamento del bus e la disposizione di linee di autobus è specificato nella norma ISO 11.898-3 (fault-tolerant CAN). Questo standard è utilizzato principalmente per l'elettronica del corpo nel settore automobilistico. Dato che per questa specifica è ipotizzato un circuito breve, il problema della riflessione segnale non è così importante come per le linee di bus lunghi. Ciò rende l'uso di una linea bus aperto possibile.
Questo significa driver a bassa bus possono essere utilizzati per reti con un consumo energetico molto basso e la topologia bus non è limitata ad una struttura lineare. È possibile trasmettere dati asimmetricamente su una sola linea bus in caso di guasto elettrico di una delle linee di bus.
ISO 11.898-3 definisce velocità di trasferimento dati fino a 125 kbit / s con la lunghezza massima del bus a seconda della velocità di trasmissione dati utilizzato e la marea. Sono specificati fino a 32 nodi per rete. La tensione di modo comune è compresa tra -2 V e +7 V. L'alimentatore è definito a 5 V.
Chip ricetrasmettitore, che supportano questo standard, sono disponibili da diverse società. I ricetrasmettitori fault-tolerant supportano la gestione degli errori completa compresa l'individuazione di errori del bus e commutazione automatica per la trasmissione del segnale asimmetrica.

****lli di tensione ISO 11898-2 (CAN ad alta velocità)

Segnale stato recessivo stato dominante
min nominale max min nominale max
CAN-alta 2.0 2.5 3.0 2,75 3.5 4.5 Volt
CAN-Low 2.0 2.5 3.0 0.5 1.5 2.25 Volt

Si noti che per lo stato recessivo, tensione nominale per i due fili è la stessa. Questo diminuisce la potenza assorbita dai nodi attraverso i resistori di terminazione. Queste resistenze sono 120ohm e si trovano su ciascuna estremità dei fili. Alcune persone hanno giocato con l'utilizzo di resistori di terminazione centrali (vale a dire, la loro messa in un posto sul bus). Questo non è raccomandato, poiché tale configurazione non impedirà problemi di riflessione.

ISO 11519 ****lli di tensione (CAN a bassa velocità)

Segnale stato recessivo stato dominante
min nominale max min nominale max
CAN-alta 1.6 1.75 1.9 3.85 4.0 5.0 Volt
CAN-Low 3.1 3.25 3.4 0 1.0 1.15 Volt

ISO 11519 non richiede resistori di terminazione. Essi non sono necessari perché i tassi po 'limitato (massimo 125 kb / s) rende il bus insensibile alle riflessioni. Il ****llo di tensione sul bus CAN è recessivo quando il bus è inattivo.

lunghezze di bus
La lunghezza massima del bus di una rete CAN dipende dalla velocità di bit utilizzata. È necessario che il fronte d'onda del segnale di bit ha tempo di viaggiare al nodo più remota e viceversa prima viene campionato il bit. Ciò significa che se la lunghezza del bus è vicino al massimo per il bit rate utilizzato, si dovrebbe
scegliere il punto di campionamento con la massima cura - un altro canto, si dovrebbe sempre farlo!
Di seguito una tabella di diverse lunghezze di autobus e le velocità di trasmissione massime corrispondenti.

lunghezza del bus (m) Massima velocità di bit (bit / s)
40 1 Mbit / s
100 500 kbit / s
200 250 KPIT / s
500 125 kbit / s
6 km 10 kbit / s

cavi
Secondo lo standard ISO 11898, l'impedenza del cavo deve essere di 120 + - 12 ohm. Si deve essere attorcigliato coppia, schermati o non schermati. Il lavoro è in corso sullo standard single-wire SAE J2411.

munro

28-08-2016, 18:13

CAN frames
Ecco alcune informazioni su frame di dati CAN
il seguente quadro è da http://www.jcelectronica*****/articles/CAN%20bus%20tutorial_2.htm
Lo Standard e cornici estese sono mostrati, e la diversa lunghezza del campo indirizzo può essere visto.

CAN affidabilità
CAN comunicazioni del bus sono generalmente molto affidabili, piuttosto insensibile ai disturbi esterni (dal interferenze esterne influenzano analogamente entrambi i fili, la differenza tra le tensioni rimane invariato), e al singolo guasto centralina. I dispositivi possono spesso lavorare anche in caso di bus essere gravemente collegato male (un cavo cortocircuitato a terra o a Vcc). Non c'è bisogno di una terra comune aumenta la robustezza. Questa affidabilità è tra le proprietà che lo hanno reso lo standard attuale in ambienti difficili, con un'ampia gamma di temperature, e molto diverse situazioni ambientali.

Rilevamento CAN
Poiché ci sono molti fili, non è facile individuare quelli appropriati.
segnali 0.CAN di solito non sono presenti se la chiave non è acceso per alimentare il cruscotto. (Normalmente non è necessario che il motore è alimentato).
fili 1.can di solito sono intrecciati.
2.Checking segnale CAN presenza senza l'uso di un oscilloscopio: Un semplice test per vedere se il bus funziona correttamente è usare un multimetro e misurare la tensione tra i due fili. In situazioni "perfetto", se il bus è attivo e funzionante mostrerà un 2,5V o 0,5V stabile (in assenza di variazioni del segnale), o un veloce alternanza tra il 0,5 e 2,5V. Se non funziona, sarà 0V come uno dei controller CAN sulla rete sta tirando il bus bassa (noto come Bus Off).
3. Operando con un oscilloscopio a due canali, e utilizzando la funzione di sottrarre tra i due segnali CAN-H e CAN-L, si dovrebbe ottenere una costante (perché i due segnali hanno fasi opposte). Oscilloscopio può anche aiutare a rilevare la velocità dei segnali CAN bus. (Aggiungerà dettagli qui).
4. Un indicatore presenza può indiretto potrebbe essere il test per la terminazione corretta. La corretta terminazione di un bus CAN può essere facilmente testato con un multimetro: quando il bus non è utilizzato, una resistenza di 60ohm deve essere misurata tra le due cavi (due 120 ohm terminatori in parallelo ai lati invia una resistenza globale di 120 / 2 = 60 ohm).
5. Come uno strumento utile per il rilevamento possibile controllare la Würth CANfinder dispositivo .
6. segnali CAN non potevano essere presenti dove dovrebbero essere (cioè nel connettore OBD2) se una corretta impostazione non viene eseguita sul dispositivo gateway.
prorpio sul gateway vorrei soffermarmi perche proprio questa "porta can bus" è oggetto di studio in quanto sembra essere presente su diverse vetture,in realta esistono delle interfaccie appositamente sviluupate con tanto di sw che permettono gia di implementare un pc in linea can rendendolo di fatto un ulteriore nodo o modulo al pari della ecu in quanto se ci pensate la ecu si comporta un pò come un pc con tanto di hard disk(la eprom flash).Inoltre come vedremo ci sono svariati altri hardware in grado di interfacciarsi alla rete can.

Interfacciamento con CAN
In termini di circuiti, ogni dispositivo di connessione al bus CAN di solito si interfaccia tramite un controller CAN, che a sua volta acceses bus tramite un driver linea CAN (in realtà un ricetrasmettitore).

Il controller può effettivamente parlare con il dispositivo in qualche modo (per esempio tramite un'interfaccia seriale RS232) e sulle altre Molti produttori di produrre circuiti integrati del driver linea CAN, per esempio Dallas Semiconductors / MAXIM MAX13050 o Microchip MCP2551 .o Philips PCA82C250 . o Philips / NXP TJA1054

La corretta terminazione bus deve essere presente ad ogni estremità del bus per smorzare la riflessione del segnale elettrico (echi). Inoltre è importante minimizzare la lunghezza del collegamento tra il bus e il ricetrasmettitore di ciascun dispositivo collegato (per minimizzare effetti indesiderati eco).

I moduli sono insiemi di ECU
In un veicolo, un modulo di solito identifica un insieme di due o più centraline elettroniche.
Il controllo del motore è il primo e più critico, le corrispondenti unità di controllo sono le più complesse. Engine Control Unit (ECU) è supportata da unità di controllo della trasmissione (TCU) ed i due sono a volte indicato come modulo di controllo Powertrain (PCM). Transmission Control Unit, tra le altre cose, si prende cura di cambio marcia.

Le unità di controllo elettronico relativi utenti sono spesso indicati nel suo complesso con il termine modulo di body computer o BCM.

munro

28-08-2016, 18:15

diverse reti
La diversa criticità della segnalazione tra i dispositivi elettronici del veicolo, ha creato una spinta per isolare le reti di diversi moduli, per esigenze di sicurezza, ma anche per diverse interfacce di apparecchiature essendo a velocità diverse.
Queste reti diverse sono raggruppati in 3 classi principali:

Telaio Corpo, che richiedono velocità fino a 10Kbps (vetri elettrici, porte, ecc,) [come esempio di BCM vedi riferimenti successivi a Peugeot BSI Built-in System Interface]
strumentazione del cruscotto, che richiede gamma di velocità 50-125Kbps (strumentazione, aria condizionata, ecc)
Motore e trasmissione, richiedendo ad alta velocità (fino a 1Mbps)

Alcune di queste reti veicolo può anche essere non-CAN. Ci sono altri standard utilizzati nelle reti dei veicoli, come LIN (utilizzato per il basso costo, a bassa velocità, uso non critico, vedi anche qui ), FlexRay (usato per l'alta velocità, le esigenze critiche, in BMW SUV), MOST (Media Oriented System Transport ) per il multimedia e infotainment.

Separazione Bus

Controllo Motore, Airbag, sottosistema di frenata, controllo della velocità e ABS, sono i sistemi più critici per la sicurezza, richiedono ad alta velocità, e quindi di solito sono tenuti separati dai sistemi meno critici.

La separazione tra i diversi autobus può permettere molto di più capacità di recupero dei sistemi critici nel caso di una unità di controllo non critica fallisce (il motore dell'auto si avvia ancora se si dispone di un problema nel lettore CD o nelle luci della cabina).

I gateway tra reti diverse
Nella maggior parte dei veicoli, molte reti CAN sono lì, operante a velocità diversa, e che vi sono gateway consentono dati trasferiti tra i vari bus.
La presenza di questi gateway consentono filtrato trasferimento di informazioni, insieme con eventuale cambio di velocità. Un gateway potrebbe agire come un firewall consentendo solo la propagazione dei pacchetti specifici. Gateway sono in realtà dispositivi elettronici collegati a più bus, e possono essere programmati per consentire il filtraggio dei pacchetti.
Vi è una specifica interessante chiamato Pass-Through SAE J2534-1 che è stato progettato per consentire una sorta di protocollo comune (!! fornitore e marchio indipendente !!) per l'attraversamento in-tra i gateway bus (può o non può). Questo standard deve essere supportato su tutti i veicoli prodotti dopo il 2004. specifica pass-through è rivolto a riprogrammazione e ri-lampeggio delle singole centraline elettroniche, ma permette anche di leggere e scrivere I / O, e messaggi periodici definizione. Vi è anche un insieme di API definite (Application alle interfacce per programmi), attraverso il quale il dialogo può essere implementato.

Ecco la descrizione del documento raccomandazione SAE J2534-1, come preso da J2534/1: Recommended Practice for Pass-Thru Vehicle Programming - SAE International (http://standards.sae.org/j2534/1_200412/) il 22 settembre 2011.

"Questa pratica suggerita SAE fornisce il quadro per consentire alle applicazioni software di riprogrammazione da ogni Casa automobilistica la possibilità di lavorare con più strumenti di interfaccia di collegamento dati del veicolo da più fornitori di utensili. Questo sistema permette ad ogni costruttore del veicolo per controllare la sequenza di programmazione per unità di controllo elettronica (ECU ) nei loro veicoli, ma consente un unico insieme di hardware interfaccia di programmazione e veicoli da utilizzare per moduli di programma per tutti i costruttori di veicoli. Questo documento non limita le possibilità hardware per la connessione tra il PC utilizzato per l'applicazione software e l'utensile ( ad esempio, RS-232, RS-485, USB, Ethernet ...). fornitori di utensili sono liberi di scegliere l'interfaccia hardware appropriato per il loro strumento. l'obiettivo di questo documento è quello di garantire che il software di riprogrammazione da qualsiasi costruttore del veicolo è compatibile con hardware fornito da qualsiasi produttore di utensili. l'agenzia statunitense Environmental Protection (EPA) e il California Air Resources Board (ARB) hanno proposto i requisiti per la riprogrammazione veicoli per tutti i produttori da parte del settore aftermarket riparazione. Il presente documento ha lo scopo di soddisfare tali requisiti proposti per i veicoli di anno di modello del 2004. Requisiti aggiuntivi per l'anno modello 2005 possono richiedere la revisione di questo documento, in particolare l'inclusione di SAE J1939 per alcuni veicoli pesanti. Questo documento sarà rivisto per un'eventuale revisione dopo quei regolamenti sono finalizzate e requisiti sono meglio compresi. Eventuali revisioni includono software specifico SAE J1939 e un connettore veicolo alternativo, ma si prevede l'hardware di base di un dispositivo di interfaccia SAE J2534 rimanere invariata ".

Controllare anche questo articolo di Dan Demaggio da Drew Technologies : http://www.drewtech*****/support/j2534/intro.html per la storia dello sviluppo di questa raccomandazione SAE.

Ecco un esempio di un dispositivo gateway doppia interfaccia CAN bus: CAN / CAN Gateway CG-ARM7, prodotto da EMS Dr. Thomas Wünsche: http://www.ems-wuensche*****/?menu=_prod&cont=datasheets/html / cgarm7_e

Tale dispositivo è infatti un firewall con un sofisticato filtro del contenuto dei pacchetti e la capacità di riscrittura.
Ecco un documento che descrive un dispositivo può ingresso in una macchina Volkswagen Golf
I due paragrafi seguenti sono tratte da http://www.my-gti*****/2296

Il ruolo del Gateway (noto anche come il bus dati J533 interfaccia diagnostica) è lo scambio di dati tra i sistemi di bus dati CAN ( 'Powertrain CAN bus dati', 'convenienza CAN bus dati' e 'autobus infotainment CAN dati') e la conversione dei dati diagnostici dai sistemi bus di dati CAN a K-cavo e viceversa in modo che i dati possono essere utilizzati per la diagnosi dei veicoli, sistemi di informazione e di sperimentazione, come gli strumenti rivenditore VAS e Vagcom / VCD.

Per vari motivi, tra cui problemi di consumo di energia con unità di testa di terza generazione o l'aggiunta di nuovi moduli non supportati il gateway bus CAN deve essere aggiornato a una nuova versione. Questa guida copre la sostituzione del gateway bus CAN in un 2005 MY06 Volkswagen Golf GTI. L'aggiornamento sostituisce il 1K0 907 530 E (1K0907530E) con una 1K0 907 530 AA (1K0907530AA).

Ecco una foto della Volkswagen / Audi gateway (parte no: 1K0907530AA), tratto da http://www.my-gti*****/1101

Questo gateway in termini di Volkswagen si chiama "bus dati interfaccia diagnostica J533". E 'utilizzato in molti modelli di auto da questo fornitore. Ho trovato un documento tecnico di Audi (Audi A5 gruppo proprietari sito Audi_A5 _-_ Networking_en_2.pdf ) che descrive la versione 4 diversa di questo componente gateway (differenze sono in termini di interfacce), per i diversi modelli di auto. È collegato a molti autobus differenti (diverse lattine, Lin, la maggior parte). Il documento afferma che la "modalità di trasporto" può essere attivato su richiesta. Credo che questo modo di trasporto potrebbe consentire il flusso di informazioni tra i diversi autobus attraverso il gateway stesso (che in questa modalità si comporta un po 'come un router).

munro

28-08-2016, 18:27

parlaimo un pò della porta obd ovvero la porta seriale che consente la riprogrammazione dei parametri ecu(non su tutte dipende,ma questo è un altro argomento)che poi è quello che interessa tutti noi.
il motivo di tutto questo chilometrico post di cui mi vorrei scusare un pò ripeto è l'implementazione di nuove funzioni anche non impengnando fisicamente tale porta.vediamo un po come funziona.

OBD: On Board Diagnostic
A causa della progressiva diffusione di dispositivi elettronici nel settore dei veicoli, anche procedure diagnostiche hanno iniziato a fare affidamento su interrogazione questi diversi pezzi di elettronica, per la risoluzione dei problemi, e messa a punto dei parametri.
Gli standard diagnostico di bordo (OBD) definiscono come queste diagnosi può essere eseguita. Ogni unità di controllo dispone di una serie di codici di difficoltà diagnostici (DTC) che possono aiutare a identificare il proprio stato o eventuali guasti.
diagnosi effettiva viene eseguita da un tecnico collegamento di un dispositivo di ispezione ad una spina specifico all'interno del veicolo, e l'analisi eseguendo.
In molti veicoli, il connettore OBD (attualmente in genere conforme alla OBD-2 standard) è a portata di mano dal sedile di guida e consente l'accesso ad almeno uno dei veicolo può autobus.

Nel corso degli anni, molte versioni differenti dello standard OBD apparvero, e quella attuale è etichettato OBD-2 o OBD-II, che utilizza un 16 pin (2x8) Connettore femmina SAE J1962 sul veicolo. configurazioni specifiche di gateway potrebbero essere necessari in modo da consentire specifica unità elettroniche di controllo del traffico (filtraggio) sia disponibile sul OBD-2 interfaccia CAN. Inoltre, a seconda del produttore e il modello, la disponibilità bus CAN sul connettore OBD-2 potrebbe essere necessaria una configurazione specifica altrove (forse ponticelli nel pannello dell'interruttore).
Essere presenti in molti veicoli, il connettore OBD-2 di solito consente l'accesso a molti segnali diagnostici. A volte più di un bus CAN è reso disponibile sul connettore, su diversi sulla mappa.

Ecco la piedinatura del connettore FIAT OBD-2: http://pinoutsguide*****/CarElectronics/fiat_car_obd_ii_pinout.shtml

Alcune "regole" circa il connettore OBD-2
(informazioni da http://www.auterraweb*****/obdiipinout.html e 404 - Beitrag nicht gefunden (http://www.obd-ii.de/tech_conn.html) )
Se il perno 5,6,14,16 sono collegati, i pin 6 e 14 sono CAN-HI / LOW (ISO_15765-4 / SAE_J2284), mentre il pin 5 è a terra ed il pin 16 è 12Vcc
Se sono collegati i pin 5,7,16 e facoltativamente 15, il connettore supporta l'accesso ai ISO_9141-2 (aka KWP): pin 5 è a terra, il pin 16 è 12Vcc, pin 7 è ISO-dati (aka ISO_K-line), come così come il perno opzionale 15, che è più vecchio ISO_9141-2 (aka ISO_L-line).
Se sono collegati i pin 2,5,16, il connettore supporta l'accesso ai VPW_J1850: pin 5 è a terra, il pin 16 è 12 Vcc, e il pin 2 è VPW-dati

Se sono collegati i pin 2,5,10,16, il connettore supporta l'accesso ai PWM_J1850: pin 5 è a terra, il pin 16 è 12 Vcc, e il pin 2 e 10 sono PWM-dati

Connettore Pins 1,3,8,9,11,12,13 (se collegato) vengono utilizzati in modo diverso da diversi costruttori di veicoli, e lo standard OBD-2 non definisce il loro ruolo.

Utilizzo di contatto di alcuni produttori (tavolo da 404 - Beitrag nicht gefunden (http://www.obd-ii.de/tech_conn.html) ):
perno SAE J1979,
ISO 15031 GM Fiat Opel Saab Isuzu GM-FI
da 5,2002
1 Produttore mandato secondo UART ABS, freni, K-Line riservato Saab Instruments (+) SIR (GM8192 Prot.) SW-LS-CAN (33kb)
o
DW-FT-CAN (+) (<125KB)
2 J1850 (+) PWM / VPW J1850 (+) VPW DW-FT-CAN (+) n / a n / a n / a n / a
3 Produttore mandato Comfort Airbag K-Line, K2, TCM, Tetto apribile, CDL, Multi-Timer n / a ABS (KW81-Prot.) MS-CAN (+) (95kb)
4 terra del telaio terra del telaio terra del telaio terra del telaio terra del telaio terra del telaio terra del telaio
5 massa del segnale massa del segnale massa del segnale massa del segnale massa del segnale massa del segnale massa del segnale
6 ISO 15765 HS-CAN (+) PCM ISO 15765 HS-CAN (+) Blinkcode Blinkcode TCM ISO 15765 HS-CAN (+) (500kB)
7 ISO 9141 K-Line n / a ISO 9141 K-Line (motore) K-Line, K1 (motore) K-Line, K1 (motore) K-Linie, K1 (motore) n / a
8 Produttore mandato CCM n / a K-Line, K4 K-Line (Saab 9000/1, KW81 / 82 Prot.) n / a riservato
9 Produttore mandato prima UART corpo ECU reserviert Saab Instruments (-) ECM / TCM (GM8192 Prot.) DW-FT-CAN (-) (<125KB)
10 J1850 (-) PWM n / a DW-FT-CAN (-) n / a n / a n / a n / a
11 Produttore mandato controller EVA (Sistema antifurto) riservato Posti di memoria L-Line SIGNORE MS-CAN (-) (95kb)
12 Produttore mandato addominali vano motore K-Line, K3, ABS, TC, sterzo, RTD, OW n / a addominali K-Line (KW82 Prot.)
13 Produttore mandato SIGNORE Compartimento bagagli f riservato. K-Line, K5 n / a ECM riservato
14 ISO 15765 HS-CAN (-) E & C ISO 15765 HS-CAN (-) riservato n / a n / a ISO 15765 HS-CAN (-) (500kB)
15 ISO 9141 L-Line n / a n / a n / a n / a n / a n / a
16 Batteria più, non commutata Batteria più, non commutata Batteria più, non commutata Batteria più, non commutata Batteria più, non commutata Batteria più, non commutata Batteria più, non commutata

Accesso ai bus CAN in auto
Quando CAN bus non è disponibile nella spina OBD2 o non è possibile per la connessione nella porta seriale, o se il gateway non è "pubblico" I segnali sulla porta OBD2,o via bus si potrebbe avere la possibilità do collegarsi ai suoi fili.
Ma è necessario un disclaimer:
Nella maggior parte dei casi, i produttori di automobili non sono idonei a rivelare le specifiche dei loro sistemi diagnostici e non ci sono approcci semplici che sono coerente tra le diverse marche. Anche se si è in grado di accedere segnali CAN, non sarà un compito facile per decodificare e comprendere il significato dei pacchetti di dati. Qui è una guida (preparato dalla società britannica Racelogic ) a trovare i cavi giusti in diversi veicoli. Dispositivi come il suddetto Würth canfinder possono anche essere utili.

Su auto Volkswagen Golf, i seguenti codici di colore filo applicano (da http://www.my-gti*****/991/performing-repairs-on-can-bus-wiring ). Tutte le tre reti possibile utilizzare coppie di cavi, e ogni coppia possono essere identificati dal colore del filo CAN-HIGH, essendo tutti i fili CAN-LOW dello stesso colore.

Una linea non schermato bifilare (1) e (2) con una sezione trasversale di 0,35 mm² o 0,5 mm² viene utilizzato per il cablaggio CAN bus.
I codici colore del cablaggio CAN bus sono:
Powertrain CAN ad alta filo arancione / nero
Convenienza CAN ad alta filo arancione / verde
Infotainment CAN ad alta arancione / viola
CAN bassa del filo, (tutti) arancio / marrone

Su FIAT Punto diesel, abbiamo trovato un segnale CAN nel connettore dietro la radio. I fili possono in questa vettura sono rosa-nero e bianco-rosa.
il seguente collegamento descrive un progetto per interfacciare un bus CAN macchina a una rete Wi-Fi:
http://www2.cs.uidaho.edu/~oman/RTCS/Wood-Chroninger-project.pptx

Per Peugeot (/ PSA e probabilmente per cytroen) automobili, controllare questo sito: http://peugeot.mainspot.net/ dove si possono trovare informazioni precise e Schema di collegamento completa per Peugeot307 , insieme alle informazioni su BSI (Body Control: B uilt -In S istema I nterface)
Peugeot BSI è collegato e "accoppiato" per unità di controllo del motore, e ci sono le protezioni per evitare manomissioni da parte di rivenditori non ufficiali o tecnici di auto-riparazione. Qui ci sono una serie di avvisi relativi alla manutenzione Peugeot BSI-ECU: http://www.liontamer.net/forums/index.php/topic,3.0.html
Qui è una foto di una Peugeot BSI.
Peugeot / PSA utilizzati per implementare la propria versione di bus CAN, chiamato VAN (Dati del veicolo Area Network Comfort VAN autobus bus / corpo Data Control). Ho trovato alcuni ragazzi intelligenti che hanno fatto un po 'di lavoro impressionante nella raccolta di informazioni su Van: Graham Auld, e Alessandro Zummo. Controllare http://graham.auld.me.uk/projects/vanbus/index.html e http://code.***********/p/van-bus/ ho avuto modo di questi siti tramite questa pagina web.

munro

28-08-2016, 18:33

Accesso CAN in camion
In particolare per i camion, non vi è un altro standard, di avere un accesso uniforme ai dati del veicolo, e mirato per le esigenze di guida di dispositivi di monitoraggio.

http://www.fms-standard*****/
Questo standard FMS (Fleet Management System) è molto importante per consentire l'accesso alle informazioni specifiche camion come il tachimetro e contachilometri, che sono necessari per essere letti nei dispositivi per controllare l'attività del conducente (tachigrafi digitali). FMS richiede un SAE J1939 CAN 29 bit 250kbit / sec sottostante standard.

Per tachigrafi digitali europei, controllare http
://www.dtco.vdo*****
Al fine di essere compatibile con FMS serie, produttori di veicoli industriali implementano una specifica centralina di gateway che legge le informazioni richieste dal principio da tutti i luoghi adatti e attraverso tutti gli standard richiesti, rispettando protocolli interni specifici del veicolo-marchio, e rende tutti questi informazioni disponibili attraverso uno specifico bus CAN a cui è collegato il dispositivo contagiri.
In questo modo, un FMS dispositivi contagiri digitale compatibili possono essere facilmente collegati a qualsiasi FMS camion compatibile.

Diversi cavi di collegamento
(Questa sezione ha bisogno di lavoro ed è parzialmente superata da quello che ho scritto nella sezione del connettore OBD-2)

Un certo numero di diversi cavi pronti esiste per accedere diagnostica per auto, di solito tramite il suddetto connettore di ODB-2
ecco un elenco dei loro nomi, ma sono lontani dal comprendere le loro differenze

SAE J1850 (può essere un doppio differenziale filo di 41,6 Kbit / s PWM -pulse Larghezza Modulation-, o un 10.4Kbit / s VPW Singlewire Pulse Width -Variable). vedere questo documento Intel.
SAE J2534 (questo è un protocollo PWM utilizzato in Ford, Lincoln, Mercury, veicoli Mazda)

K-LINE e L-LINE (ISO 9141-2) (da spiegare: ho bisogno di studiare)
ISO 14230-4 (noto anche come KWP)

PWM può
HS-CAN (ISO 15765)

VAG-COM non è un cavo, ma un prodotto da Ross-Tech. Si tratta di un software di Windows diagnostica per Volkswagen / Audi. Alcuni cavi da utilizzare con questo software sono etichettati VAG-COM

ELM 32x sono circuiti integrati, (qui è elm327 descrizione), venduto da elmelectronics***** e basata su Microchip Technology Inc . Dispositivi prime. Questi chip ELM agiscono come decodificatori ODB2 generici e sono in grado di identificare e decodificare molti dei diversi segnali disponibili sulla spina ODB2, convertendoli in RS232, per collegamento a un PC. Molti software di diagnostica diversi PC sono in grado di interfacciarsi con l'elettronica per auto tramite un adattatore ELM base, come questa

Arduino e CAN
E 'possibile interfacciare un Arduino 2009 bordo con bus CAN, tramite una specifica stringa di codice
si può usare SkPang Arduino CAN-Bus Shield , per la connessione a una Audi A6 (2003) e si è in grado (mediante l'applicazione di esempio fornito) per leggere correttamente RPM (giri al minuto) i dati dal motore utilizzando un meccanismo di polling.

Questo scudo utilizza un MCP2515 CAN controller e un MCP2551 CAN Line Driver.

Sk-Pang scudo utilizza una libreria preso dal codice Fabien Greif (qui è il sito principale: http://www.kreatives-chaos*****/artikel/universelle-can -bibliothek )

OBDuino
Si tratta di un progetto, avviato nel 2009, di utilizzare una scheda Arduino, come consuetudine per interfacciarsi con auto CAN-Bus e costruire una
Il progetto è descritto in questa pagina Wikipedia: OBDuino - Wikipedia, the free encyclopedia (http://en.wikipedia.org/wiki/OBDuino) e il codice repository, insieme ad alcune immagini di prototipi, si trova in una pagina di ******-code, qui: http: // codice. ***********/p/opengauge/wiki/OBDuinoInterface

MPGuino
Questo progetto è mirato a costruire un computer di misurazione del carburante, con un Arduino come il dispositivo, analizzando gli impulsi agli iniettori di carburante, e con le tabelle per il calcolo del combustibile iniettato specifica basandosi sulla durata dell'impulso. I segnali devono essere direttamente lettura / presa dai principali collegamenti del motore ECU gli iniettori. I dati appare estremamente accurata. Ecco il link: http://ecomodder*****/wiki/index.php/MPGuino

Teltonika FM4200
Si tratta di un dispositivo appositamente progettato per interfacciarsi con FMS interfaccia CAN in camion.
che utilizza un microcontrollore NXP LPC2368 che è (per inciso) la stessa UC utilizzato dal mbed progetto. Ecco alcune informazioni circa il microcontrollore che include un controller CAN (ma non un ricetrasmettitore CAN). I circuiti FM4200 utilizza un Texas Instruments SN65HVD234D CAN ricetrasmettitore 3.3V.

CAN bus dati reverse engineering:
Per una vettura Toyota Prius, da Attila Vass: The new 2004 Toyota Prius : My CAN Project (http://www.vassfamily.net/ToyotaPrius/CAN/cindex.html)
Per una vettura SAAB da Tomi Liljemark: http://pikkupossu.1g.fi/tomi/projects/i-bus/i-bus.html

Riferimenti generali e link
Il grande sito CAN-CIA: http://www.can-cia.org/ che è probabilmente il miglior sito e più affidabile di riferimento disponibile.
Il dizionario può : contiene una definizione della maggior parte degli acronimi e abbreviazioni.

Grande pagina su CAN di Staffan Nilsson: http://www.staffannilsson.eu/developer/CAN.htm
Bosch CAN 2.0 specifiche .
Pagine Mike J Schofield: (URL non funzionante: http://www.mjschofield*****/~~number=plural - c'è uno specchio in sito Staffan Nilsson)
http://www.ixxat*****/can-controller-area-network-introduction_en.html
http://www.jcelectronica*****/articles/CAN%20bus%20tutorial.htm

CAN fornitori di analisi e attrezzature
http://www.vector-group.net
http://www.kvaser*****
http://www.ems-wuensche***** : Ho comprato un EMS-Wuensche CPC-USB / ARM7 con optoisolamento galvanica e transceiver a bassa velocità (TJA1054) per il settore automobilistico. Ricevuto l'oggetto (2010.dec.10), e la prima impressione è buona: sembra molto ben costruito e affidabile. Presto testarlo sul campo.
http://www.lawicel*****/
http://www.peak-system*****/

munro

28-08-2016, 18:44

CAN bus in moto
Naturalmente,anche le moto utilizzano elettronica con protocolli digitali.
ed anche qui riuscire ad hacherare la can bus e con essa il modulo ecu ha applicazioni vastissime non solo sulla mappatura in tempo reale ma su tutta una serie di sistemi che sono integrati sulle moderne motociclette
come traction controll drive by wire ecc..gli eventuali sviluppi su tali sitemi permetterebbero di cucirsi addosso la moto e non solo ovviamente questa come un abito basta avere fantasia.di seguito posto un sw molto conosciuto che stò usando nei momenti liberi per lo studio degli stati logici can bus.
Software
FreeDiag: Freediag - Vehicle Diagnostic Suite (http://freediag.sourceforge.net/)
*********** è un software per l'analisi di auto italiane fatte (fiat / alfa / Lancia di marca). Disponibile in versione gratuita e in versione a pagamento, con caratteristiche diverse. Http://***********.net . Ecco una lista dei veicoli supportati dalla versione corrente della ***********.

Ricapitolando di primo acchitto sembrebbe impossibile riuscire nello scopo Ma questa impossibilità non è normalmente a causa di ragioni fisiche. Ogni produttore ECU utilizza il proprio insieme di regole e codici di pacchetti di dati sulle loro reti veicoli. Queste informazioni e formati di dati non sono facilmente disponibili, e non ci sono regole condivise seguita da diversi produttori.

FM4200 che citavo prima ad esempio è progettato per essere in grado di decodificare FMS CAN, che è una rappresentazione formato di dati standard accettati e condivisi da tutti i veicoli industriali (camion). L'obiettivo è quello di consentire di interconnessione contagiri con cruscotto del veicolo.

Tachimetri sono dispositivi che in molti paesi deve essere installato sul camion in modo da monitorare il comportamento del conducente e attività lavorative. Dal momento che ci sono molti dispositivi contagiri, che sono costruiti e installati da molti paesi fornitori certificati, era necessario uno standard, in modo da FMS è nato. L'accesso non professionale per la connessione dati del tachimetro è generalmente vietato.

Attraverso bus dati inverso dell'automobile di tecniche di ingegneria, per lo più sulla base di prove ed errori e / o informazioni trapelate, è teoricamente possibile mappare alcuni dei pacchetti di dati possibile per il loro significato. Generalmente solo leggere approccio è sicuro. Ma i problemi potrebbero sorgere quando la manutenzione del software del veicolo viene effettuata, in quanto significato pacchetto di dati potrebbe cambiare, e produttori attuali non sono tenuti a rivelare apertamente questi dettagli.

Accesso in scrittura alla trasmissione e il motore del bus è da considerarsi critica ed è generalmente esplicitamente vietato o fortemente sconsigliato anche se noi tutti ben sappiamo che se stessimo a dar retta hai veti imposti da qualche burocrate di turno saremmo rimasti forse ancora all'età della pietra.

Di sicuro però potrebbe essere grande se tutti i dati fossero comprensibile e accessibile, ma ci sono importanti implicazioni per la sicurezza se la gente irresponsabile manomettere queste cose. Sicurezza del veicolo, la copertura assicurativa e la sicurezza stradale potrebbero venire influenzati.
spero di non aver annoiato nessun con questo lungo trattato sull'argomento e mi raccomando:

Studiate sempre, imparate e capite prima di "giocare"con questa roba.
E se volete condividte responsabilmente le vostre scoperte.

Munro

ugoboss

28-08-2016, 21:54

bel lavoro , grazie, e auguri per la salute.

frenk85

29-08-2016, 19:15

Grande lavoro! Non sai che piacere averti letto qui sul forum! Ben tornato e un augurio per tutto!

munro

29-08-2016, 20:29

Grazie a voi ragazzi per tutto

tranky

24-10-2016, 21:47

munro

25-10-2016, 15:49

Non voglio frenare le speranze di qualcuno, ma quello che volete fare è quasi impossibile, e chi programma un pò ve lo può confermare.

Intanto non soffermatevi su quello che c'è nella eeprom, ma su quello che c'è nella flash; nella eeprom ci sono solo dati variabili, nella flash c'è il vero sistema operativo della ecu, che sarebbe quello da disassemblare e interpretare.

Bisogna fare delle precisazioni, ogni tipologia di ecu ha un micro con un'architettura diversa; nel caso della edc16c39 c'è un motorola con architettura arm.

I progettisti quando creano una ecu, scrivono il programma che deve svolgere e lo scrivono in un linguaggio di alto ****llo (C++ o similari), poi lo compilano utilizzando i tool messi a disposizione dalle stesse aziende che creano i microcontrollori, facendolo diventare un file binario che viene caricato o direttamente della memoria del micro, o in una memoria esterna.

Un file binario o hex non può in nessun modo e con nessun software restituire il listato sorgente originale, ma può solo essere disassemlato con gli stessi tool utilizzati per compilarlo, ottenendo un file in linguaggio macchina o assembly, ma ovviamente privo di ogni nome di variabile e info varie.

In sostanza, io riesco a leggere il contenuto di una ecu, riesco a disassemblarlo, ma il file assembly che ottengo è quasi inutile poichè ottengo solo pagine e pagine di codice sorgente scritto in linguaggio macchina senza nomi e appunti, umanamente impossibile da interpretare.

Se io voglio realmente creare qualcosa ho bisogno dei sorgenti originali di quella ecu, scritti non in linguaggio macchina, ma in un linguaggio di alto ****llo più umanamente interpretabile.
mi associo a quanto diceva tranky cioè una volta che si riesce a decompilare tutto il codice sia che esso si trovi nel micro o nella ram in teoria sarebbe possibile risalire alle locazioni di memoria delle varie routine e sub-routine che il codice stesso fa eseguire alla "macchina" certo nessuno qui a detto che sia una cosa che facile che si fa in due minuti ma c'è gente che lo fa già attualmente è non solo a hackerato il codice sorgente senza "la chiave" di lettura del listato ma riesce ad implementare stringhe di proprio codice da fareseguire come nuove istruzioni alla "macchina" quindi quello che dico io è se ci sono riuscit altri persone perche non ci si può riuscire anche noi..

munro

25-10-2016, 15:55

Parzialmente vero ciò che dici ma se programmi e presumo di si visto che ne parli a modo, sai che un reverse con de compilazione fatta con la architettura nativa ti restituisce il code nativo.
Poi se é C++ oltre alle variabili definite dal costruttore si possono interpretare le roule (regole/istruzioni) e con logica modificarle.
Quindi impossibile non direi, ho fatto di peggio.. ;) ma sicuramente un gran lavoro e bisogna avere una buona potenza di calcolo per fare il revert del codice.
esatto tranky reversando il codice macchina con assembly o C oppure C++ il programma di decompilazione stesso ti restituice il codice sorgente..è un pò un cane che si morde la coda se vogliamo metterla cosi..certo poi il difficile è capire tutte le istruction set nelle varie locazione con tutte i diagrammi delle routine e sub-routine e li che viene il bello..
diciamo che con l'ida-pro una volta individuato il micro esatto da dargli in pasto la decompilazioneè abastanza semplice il difficile viene appunto dopo per capire il resto..

Backgroop

26-10-2016, 11:18

Backgroop

26-10-2016, 11:20

naturalmente essendo processore 32 bit non si può usare il software su pc 64bit

munro

26-10-2016, 15:21

Ciao Ragazzi Da tanto che non ci si sente vero?
Non ho potuto fare ammeno di leggere la vostra conversazione molto interessante..
vi voglio indirizzare nella strada giusta, allora:
Tutti i microcontrollori sviluppati dalla freescale motorola quali

MPC533: 32-bit Microcontrollers
MPC534: 32-bit Microcontrollers
MPC535: 32-bit Microcontrollers
MPC555: 32-bit Microcontrollers
MPC561: 32-bit Microcontrollers
MPC562: 32-bit Microcontrollers
MPC563: 32-bit Microcontrollers
MPC564: 32-bit Microcontrollers
MPC565: 32 Bit Microcontroller

sono programmati con un development software chiamato codewarrior che include al suo interno un optimizing compiler c e c++ (naturalmete ha bisogno di librerie esterne quindi vanno installati i due compilatori della borland)
l'optimizin compiler facilita il lavoro in quanto l'asseble motorola 32bit complesso viene convertito in linguaggio multiparadigma semplice.
ho usato questo software circa 2 anni fa e posso dire che qualcosa si potrebbe fare ma ci vuole molto studio.
la maggiorparte dei dati contenuti nel controllore sono per la gestione delle comunicazioni I/O e per la logica interna.
bisogna conoscere gli indirizzi di memoria interni e come vengono gestiti quindi vi occcorrera un user manual del mpc5xx
Ciao Backgroup il sw Ida pro che si sta usando fa tutto quello che hai scritto tu sia su un PC da 32 che da 64bit e senza bisogno di librerie o user manuale in quanto supporta molti micro basta selezionare quello che interessa reversare dargli in "pasto" il file è il sw restituisce i diagrammi con le locazioni contenenti le routine e subroutine del caso sia per gli stati logici sia per le istruction set il problema è che come scriveva Matteo SR
Il tutto viene tradotto il linguaggio di ****llo superiore è non avendo molta familiarità con questo decifrare tutto richiede tempo e fatica inoltre la versione di Ida pro che utilizziamo non è ufficiale e mancano parecchi plugin in quanto una versione ufficiale e con tutti i plugin del sw viene sui 5000 euro... direi che per noi dilettanti a ****llo amatoriale di questa roba è decisamente troppo