Ahogyan egyre jobban bonyolódnak a dolgok, úgy élek majd egyre több feltételezéssel, amit a megadott helyen is igyekszem hangsúlyozni. Azonban most így külön is szeretném kiemelni, hogy a leírtakban előfordulhatnak téves információk, megállapítások vagy következtetések. Javaslatokat vagy kiigazítást a továbbiakban is örömmel veszek.
EGR bypass
A checksum számítás megoldása után nagy lendülettel folytattam a kód visszafejtését. Továbbra is az EGR felé fordítottam a figyelmemet. A biztos pont itt az EGR térkép volt, amit már korábban sikerült beazonosítani, viszont apróbb fennakadást okozott, hogy a térkép kezdetét jelző cím (A2C2) nem szerepelt sehol sem a kódban. Ezt már korábban több térkép esetben is észleltem és nem igazán tudtam reális magyarázatot találni rá. Találtam viszont egy olyan szubrutint, ahol a 1315a térkép utáni első offset címe (C365) bukkan fel:
.data:00041376 48 e7 e4 40 moveml %d0-%d2/%d5/%a1,%sp@-
.data:0004137a 08 38 00 06 8c 29 btst #6,0xffffffffffff8c29 # test condition1 to bypass EGR
.data:00041380 67 00 01 b6 beqw 0x00041538 # branch to the end of this subroutine
.data:00041384 08 38 00 00 8c 32 btst #0,0xffffffffffff8c32 # test condition2 to bypass EGR
.data:0004138a 66 00 01 ac bnew 0x00041538 # branch to the end of this subroutine
.data:0004138e 45 f9 00 00 c2 9e lea 0x0000c29e,%a2
.data:00041394 76 f8 moveq #-8,%d3
.data:00041396 4e b9 00 02 2a ec jsr 0x00022aec
.data:0004139c 42 44 clrw %d4
.data:0004139e 18 38 8c b4 moveb 0xffffffffffff8cb4,%d4
.data:000413a2 0c 04 00 e0 cmpib #-32,%d4
.data:000413a6 63 04 blss 0x000413ac
.data:000413a8 38 3c 00 e0 movew #224,%d4
.data:000413ac e9 4c lslw #4,%d4
.data:000413ae f8 39 41 00 00 00 c3 65 tblub 0x0000c365,%d4
...
A fenti nem a teljes szubrutin, mert az egész kicsit hosszú lenne és a lényeg úgyis ebben van. A TBL utasításokat kevesebb irodalom jegyzi, mint az általánosakat, de a "MOTOROLA M68000 FAMILY Programmer’s Reference Manual"-ban természetesen megtalálható: "TBLS, TBLSN, TBLU, TBLUN - Signed/Unsigned Table Lookup and Interpolate"
Az ECU a térképeken nem található értékeket a szomszédos értékek interpolációjával számolja. Tehát ez az utasítás jól illik a képbe.
Nem vagyok benne biztos, de azt gondolom, hogy a veremkezelés LIFO (Last In First Out) jellegéből adódik, hogy nem a térkép kezdete, hanem a vége szerepel a kódban. Azóta nagyon sok általam korábban megtalált térképre való hasonló (vége utáni első offset) hivatkozást találtam. Ez az oka vagy sem az biztos, hogy a továbbiakban erre figyelni kell.
Az adott szubrutin vizsgálatával sokat nem foglalkoztam, mert a tartalmánál jóval érdekesebb az, hogy hogyan lehet elkerülni a futását. Az látszik, hogy az elején rögtön két feltételt vizsgál és ezek teljesülése/nem teljesülése esetén rögtön a szubrutin végére ugrik. A feltételek címe azonban nem 0x000... hanem 0xfff... formátumú. Ez nem a programkódban, hanem a memóriában megtalálható információ. A kísérlet, hogy megtudjam mit tárol az adott memóriaterület hamar kudarcba fulladt. Sok helyen van rá hivatkozás és átláthatatlan mi mikor hova kerül. Később arra jutottam, hogy ezek nem is feltétlenül számolt értékek, hanem lehetnek akár szenzorok vagy működtető/beavatkozó egységek is. Ugyanis az már egy ideje feltűnt, hogy a rengeteg művelet között nem látok egyet sem, ami az egyes egységeket vezérelné vagy azoktól információt szerene be. Mégpedig azért, mert az M68k processzorok úgynevezett memory-mapped I/O technikát alkalmaznak, aminek az a lényege, hogy a különböző egységek egy-egy memóriaterülethez vannak társítva, és minden I/O művelet az ezekhez köthető utasításokból áll. Jelentősen megkönnyítené a dolgom, ha tudnám, hogy melyik memóriaterület melyik egységet azonosítja, de ezekből a memóriahivatkozásokból a kódban több ezer különböző szerepel. Szinte lehetetlen csak úgy próba szerencse alapon megfejteni, ezért próbáltam egy olyan logger-t keresni, amivel talán ki lehetne túrni ezt az OBD2 kommunikációból, de már a keresés sem hozott sikert.
A kódrészlet elején található két feltétel egyébként teljesen logikusan lehetne például a vízhőmérséklet (CT) vagy levegő-hőmérséklet (IAT) vizsgálat, de fogalmam sincs, hogy valóban az-e vagy sem. Ezek után már csak egyetlen esély maradt. Meg kell akadályozni a szubrutin elindulását, amibe szerencsére csak egyetlen helyről lép be a program, közvetlenül egy kódban letárolt érték (D3F3) vizsgálata után:
.data:000412b6 08 39 00 00 00 00 d3 f3 btst #0,0x0000d3f3 # EGR bypass switch
.data:000412be 66 38 bnes 0x000412f8 # branch to 0x000412f8 if 0x0000d3f3 != 0
.data:000412c0 61 00 00 b4 bsrw 0x00041376 # branch to EGR subroutine
.data:000412c4 08 39 00 00 00 00 80 1f btst #0,0x0000801f
.data:000412cc 66 2a bnes 0x000412f8
.data:000412ce 08 38 00 03 80 1d btst #3,0xffffffffffff801d
.data:000412d4 67 0e beqs 0x000412e4
.data:000412d6 08 38 00 06 89 48 btst #6,0xffffffffffff8948
.data:000412dc 67 06 beqs 0x000412e4
.data:000412de 16 38 89 49 moveb 0xffffffffffff8949,%d3
.data:000412e2 60 14 bras 0x000412f8
.data:000412e4 08 38 00 04 80 1d btst #4,0xffffffffffff801d
.data:000412ea 67 0c beqs 0x000412f8
.data:000412ec 08 38 00 06 89 4e btst #6,0xffffffffffff894e
.data:000412f2 67 04 beqs 0x000412f8
.data:000412f4 16 38 89 4f moveb 0xffffffffffff894f,%d3
.data:000412f8 08 39 00 00 00 00 d3 f3 btst #0,0x0000d3f3
.data:00041300 67 04 beqs 0x00041306
.data:00041302 16 38 8e f4 moveb 0xffffffffffff8ef4,%d3
.data:00041306 11 c3 92 5d moveb %d3,0xffffffffffff925d
A feltétel azt vizsgálja, hogy a tárolt érték 0-val egyenlő-e és ha nem, akkor egyszerűen kihagyja az EGR szubrutin futását. Ennek az lehet az előnye a térkép nullázással szemben, hogy egyrészt nem számoltatjuk az ECU-t feleslegesen a 0 értékekkel, másrészt kihagyhat egyéb korrekciós módosításokat is, harmadrészt talán végre ki lehetne szedni magát az EGR szelepet hibajelzés nélkül. Utóbbira vonatkozó reményem hamar szertefoszlott, amikor összehasonlítottam a 12594690-es szoftver verzióval, amelyben gyárilag nem működik az EGR. Abban ugyanis ugyanúgy 0, mint az én eredetimben. Sőt minden más nálam lévő binárisban is. A D3F3 címhez nem kötődik semmilyen más művelet a kódban ezért semmi nem akadályozott, hogy kipróbáljak egy módosítást. Fogtam az eredeti binárist és csak ezt az egyetlen bitet írtam át (az EGR térkép maradt gyári állapotban).
Minden a várakozások szerint alakult egyetlen kivétellel. Az EGR valóban nem mutat semmilyen aktivitást, de a csatlakozó lehúzása után jön a hibajelzés. :(
Ez a harmadik módszer (térkép, későbbi gyári ecu, bypass), amivel ki tudom iktatni az EGR működését, de úgy néz ki kell lennie legalább még egynek. Arra vonatkozólag nincs ötletem, hogy mi az eredeti célja a D3F3 helyen tárolt értéknek.
Ez a módosítás még tavaly ősszel történt, ami után egy kicsit felhagytam a további kísérletekkel, viszont azóta végig ezzel futott az autó. Ez idő alatt pedig semmilyen negatív hatást nem tapasztaltam. Ilyen hosszú és ennyire változó körülmények közt zajló teszt még semmelyik másik módosítás után nem történt. Amíg nem találok jobb módszert, addig továbbra is ezt fogom használni a térkép nullázás helyett.
A leállásomnak egyébként nem volt semmilyen rendkívüli oka, egyszerűen csak mással is kellett foglalkoznom, aztán ahogy egyre több idő telt el a lelkesedésem is alábbhagyott. Az idei év elején egyszer megpróbáltam ismét felpörgetni magam, de minden további eredmény nélkül elhalt az a próbálkozás. Sokszor éreztem, hogy nem lesz már erőm többször belefogni, mert nem csak nagyon nehéz ez az egész, hanem mérhetetlenül időigényes is. Nem beszélve arról, hogy ennyi idő alatt már sokmindent felejtettem is. Aztán jött egy szikra és most ki tudja meddig, de ismét csinálom. Egy poszt még biztosan lesz ebben a témában, mert megint találtam valami újat. :)
Nincsenek megjegyzések:
Megjegyzés küldése