disassemblare un file binario ecu

[munro]

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]

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]

Ciao,
ecco le news del giorno (stiamo arrivando a ****lli del Messaggero, ogni giorno cronaca del giorno):
Qui img01.jpg è 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
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)
assembly base.rar
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]

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]

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..
Allegato 10101

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

[tranky]

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

[OT]
AHAHAHAHHAHA
Ti adoro amico.
[/OT]

[munro]

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]

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]

da nefmoto...

[tranky]

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 !