Az élet tele van megszakításokkal. Miután az előző posztomban jól beharangoztam a PHP deobfuscator 2. részét, sőt, el is kezdtem írni a bejegyzést, természetesen beérkezett egy nagy rakás megszakítás, amelyek közül az egyiknek egy új blogposztot kellett eredményeznie. Mivel annak a témának előbb lett vége (és konklúziója), minthogy elkészült volna az a bizonyos 2. rész, álljon most itt egy újabb vendégposzt, azaz az Égvemaradt.hu-hoz szervesen nem, csak személyemen keresztül kapcsolódó bejegyzés.
Augusztus végén négy munkatársammal hirtelen felindulásból beneveztünk a Block Harbor Cybersecurity által szervezett Automotive Capture The Flag 2024 nevű versenyre. Mindannyiunk számára ez volt az első ilyen megmérettetés, így lelkes amatőrökként csupán annyit tudtunk az egészről, hogy ez egy hackerverseny, ahol többé-kevésbé autóipari rendszerek feltöréséért kaphatunk majd pontokat.
Ez a poszt nem egy élménybeszámoló magáról a versenyről, hanem egy technikai leírás arról, hogy hogyan sikerült átverekednünk magunkat a verseny „We’ll see in the Mach-E” fejezetén. Ehhez a fejezethez egyetlen hatalmas CAN logot kaptunk, az ide tartozó feladatok mind ehhez kapcsolódtak. A log 5 különböző CAN csatorna logját tartalmazta mindenféle metaadat (például időbélyegek) nélkül, így kell elképzelni, csak sokkal hosszabban:
Mivel a Notepad++ nehezen boldogult a több mint két és félmillió soros fájllal, első lépésként külön fájlokba gyűjtöttem az egyes csatornák üzeneteit. Emiatt a továbbiakban néha több fájlban is kellett keresgélnem, de máskor meg pont előny volt, hogy egyszerre csak egy csatornát látok.
A 2-es csatornán azt vettem még észre, hogy az általam várt # helyett ## választotta el egymástól a CAN ID-kat és az adatot, illetve alaposabban megnézve az is feltűnt, hogy az adat mindig 5-tel kezdődik, és a (hagyományos) CAN-en maximálisan elképzelhető 8 helyett 8,5 bájt hosszú. Ezért azzal a feltételezéssel éltem, hogy a szeparátor igazából a ##5 string, úgyhogy azt mindenhol lecseréltem a számomra kényelmes #-ra.
Ezután már neki lehetett ugrani a feladatok megoldásának. A továbbiakban a címsorok a feladat nevét, a dőlt betűs szövegek pedig a feladatkiírást tartalmazzák.
DID Access
What negative response code was given for DID 0x4915?
Bár ezt a feladatot nem én oldottam meg, azért leírom a megoldás menetét, melyhez az UDS diagnosztika (legalább felületes) ismeretére volt szükség. Mivel a mi csoportunk munkájának szerves része az UDS használata, ez a feladat igazából gyerekjáték volt.
A feladatban szereplő DID a Data Identifier rövidítése, amelyet két UDS service használ, a Read Data By Identifier (service ID = 0x22) és a Write Data By Identifier (service ID = 0x2E). Az egyik ilyen service kérésére érkező negatív választ kerestük, ehhez pedig először meg kellett találnunk a kérést.
A 4915 bájtkombinációra rákeresve 24 találatot kaptam, a találatok között pedig azonnal ki lehetett szúrni azokat az üzeneteket, ahol a 4915-öt 22 előzte meg (2E-t nem találtam), azaz a Read Data By Identifier-eket.
Ebből kiderült, hogy a keresett UDS kérés-válasz a 3-as CAN csatornán lesz, a kérés CAN ID-ja pedig 7E4. Ezután nem volt más dolgom, mint az egyik megtalált 7E4#03224915 után keresni egy hasonló (de nem megegyező!) ID-jú üzenetet, aminek a második bájtja 7F, az jelenti ugyanis a negatív választ. Ez hamar meg is lett:
Ebben az üzenetben a 7F utáni 22 mutatja azt, hogy ez a negatív válasz a 0x22-es service kérésre érkezett, a 22 utáni 31 pedig a keresett hibakód, ez volt a feladat megoldása.
Persze lehetett volna tudományosabban is keresni, például a #..7F22 reguláris kifejezéssel; az is azonnal megmutatta volna a keresett kódot:
Az UDS üzenetek amúgy ISO-TP-be vannak csomagolva (ez a felelős az üzenetek első bájtjaiért), de ennél a feladatnál az ISO-TP részleteibe nem kellett beleásnom magam a megoldás megtalálásához, úgyhogy annak az ismertetésébe nem is megyek itt bele.
What is the VIN?
What is the VIN of the vehicle driving?
Itt a jármű alvázszámát (Vehicle Identification Number) kellett megtalálnunk. Alapesetben a DID-k kiosztása gyártóról gyártóra, ECU-ról ECU-ra változhat, de a VIN DID-ja pont szabványos, 0xF190. Viszont hiába kerestem rá, a logban nem találtam 22F190-et. Ez persze nem jelenti azt, hogy a 0xF190 DID-val nem lehet lekérni a VIN-t, csupán azt, hogy a logolt időszak alatt senki nem kérte azt le.
Abban kellett tehát bíznom, hogy van olyan ECU, amelyik kérés nélkül is broadcastolja az alvázszámot, hiszen ebben az esetben az biztosan benne van a logban. Már csak meg kellett tudni, hogy vajon hogyan találhatom meg. Saját érintettségem okán például tudom, hogy a Skodák alvázszáma TMB-vel kezdődik (fun fact: az MB Mladá Boleslavot jelöli), de más márkák konvencióit nem ismerem.
Ha a feladatcsoport neve („We’ll see in the Mach-E”) nem lett volna elég beszédes, néhány előző feladatból is kiderült, hogy a szervező Block Harbornak van legalább egy Ford Mustang Mach-E-je. Így hát adta magát a feltételezés, hogy egy ilyen autóban vették fel a logot is, úgyhogy próba-szerencse alapon elindultam ebbe az irányba.
Egy gyors Google-keresés elárulta, hogy ezeknek az autóknak 3FM-mel kezdődik az alvázszáma. Ezeknek a karaktereknek az ASCII kódjai 0x33, 0x46, 0x4D (az ASCII <-> hex konverter a verseny ideje alatt kb. végig nyitva volt), így hát rákerestem a 33464D stringre.
Bingó! A 40A üzenetek több CAN csatornára is átgatewayezve terítették a VIN-t, amelynek a következő karakterei 0x54, 0x4B, 0x34, azaz TK4 voltak (ami amúgy tökéletesen egybe is vágott az előzőleg talált VIN dekóder információival).
Igen ám, de a teljes VIN 17 karakterből áll, hol a többi? A megtalálásukhoz elég volt rákeresni az üzenetre az egyik csatornán (a 3-as épp nyitva volt, azt választottam), és a találati listában könnyen észre lehetett venni a mintát:
Úgy tűnt, hogy az első bájt, a C1 jelzi magát a VIN-t, mint valami proprietary DID. A következő bájt egy számláló gyanúját vetette fel, így az üzenetek harmadik bájtjától olvastam össze a VIN-t, amire 3FMTK4SX8MME00878 jött ki. Az utolsó üzenet utolsó bájtja FF, ami nem egy ASCII karakter (a legmagasabb ASCII karakter értéke 0x7F), úgyhogy azzal nem foglalkoztam. Az így megtalált VIN volt a feladat megoldása.
Street Names
What street names did we drive on in this log that the vehicle sent on the can bus?
Flag is list of street names without St, Dr, Ave etc and with commas between them. In the order they appear in the log. For example: Woodward,Maple,Southfield
A feladat most utcanevek keresése volt. Mivel ez egyértelműen ASCII információ, gyorsan összeraktam egy Python scriptet, ami a kapott CAN log minden sorához hozzácsapja az adatbájtokat ASCII-ként dekódolva kapott stringet. Pontosabban nem én raktam össze a scriptet, hanem a ChatGPT, én csak a végén a saját szám ízére formáltam. 🙂
Miután ezzel a scripttel átmentem egy logfájlon, ilyen kimenetet kaptam:
Ebben már azonnal látszik az előző feladatban megtalált alvázszám első néhány karaktere. (Amúgy simán lehet, hogy némi keresés után fel tudtam volna paraméterezni a candumpot úgy, hogy előállítsa ezt a kimenetet, és szinte biztos, hogy találtam volna rá másik toolt is, de egyrészt mint tudjuk, 6 órányi debuggolással simán megspórolható 5 percnyi dokumentációolvasás, másrészt pedig akinek kalapácsa van, az mindent szögnek lát.)
A következő feladat annak a kitalálása volt, hogy mire keressek. Mivel a feladatkiírás úgy szólt, hogy a megoldást St (street), Dr (drive) és Ave (avenue) nélkül kell megadni, feltételeztem, hogy legalább az egyik rövidítést meg fogom találni a logban, és hogy kis szerencsével ezek a rövid stringek nem lesznek szétvágva két CAN üzenetbe.
Az St-re 4433 találatot kaptam, de elsőre nem volt szembetűnő, hogy tényleg a street rövidítését találtam volna meg. A Dr-re már csak 109 találat jött, de az sem volt meggyőző, az Ave viszont csak 5-ször szerepelt, ráadásul mindig ugyanabban az üzenetben, az 1-es csatornán lévő 2C0-ban. Megnéztem hát alaposabban azt az üzenetet, és a következőt találtam:
Sikerült! És még csak további scriptelésre sem volt szükség, elég volt értelemszerűen összeolvasni az egymást követő utcákat: Piedmont Drive, Acacia Drive, Wheaton Avenue, Rochester Road. A megoldás tehát Piedmont,Acacia,Wheaton,Rochester volt.
Radio
What FM radio station were we listening to?
Ennél a feladatnál abból a feltételezésből indultam ki, hogy hasonlóan az utcanevekhez, a rádióadó nevét is CAN-en keresztül kapják meg a megfelelő kijelzők. Tehát megint ASCII tartalmat kerestem, de most nem állt rendelkezésemre segítség. Úgyhogy tippeltem, és rákerestem először az FM-re, de annak a találati listája (épp a VIN miatt) nagyon zajos volt.
A második tippem az MHz volt, ami viszont már érdekes találatokat adott:
Ezek alapján az 1-es csatorna 2B4 üzenetére szűrtem rá, és beigazolódott a sejtésem, hogy jó helyen járok:
Amúgy vicces látni a rádió neve helyén időről időre lefutó reklámot (Injured? Slip & Fall? FallLaw.com), ilyesmit idehaza már jó régen nem láttam. 🙂
Az üzenetekből kiderült, hogy a rádióadó frekvenciája 95.5 MHz, és egy helyen pedig Michigan állam neve is feltűnt (MICHIGAN AUTO LAW). Természetesen rápróbáltam a 95.5-re megoldásként, de azt nem fogadta el a rendszer, ezért rágugliztam a „Michigan 95.5 FM” kifejezésre, ami kidobta nekem a WKQI Wikipédia lapját. Megpróbáltam hát a WKQI-t is, de nem az volt a jó megoldás, hanem a sokadik próbálkozásra beírt 955 (a Wiki lap adta az ötletet ezzel: „[…] known as “Channel 955”, pronounced “nine-five-five””). Vagy az is lehet, hogy pont fordítva volt, már nem emlékszem pontosan, csak az maradt meg, hogy nagyon sokadik próbálkozásra találtam el a megfelelő formátumot.
When were we driving?
On what day did the drive in this can log take place? (answer in DD/MM/YYYY)
Ezzel a feladattal jó sokáig elszöszmötöltem, és végül nem is én, hanem egy csapattársam oldotta meg helyettem.
Itt ugye az volt a feladat, hogy megtaláljuk a dátumot, de ennek a módja egyáltalán nem volt triviális. A mi rendszereinkben, amelyek nagyrészt követik a J1939 szabványt, a dátum és az idő egy standardizált üzenetben utazik, a 0xFEE6 PGN-ben. Az üzenet formátuma kötött, és többé-kevésbé logikusan, egy-egy bájton ábrázolja az évet, hónapot, napot, órát, percet és másodpercet (valamint az aktuális időzóna UTC-től való eltolódását órában és percben). Az év kivételével mindegyik szám kényelmesen belefér egy bájtba, az évre pedig úgy rémlik, hogy találkoztam már 1980-as és 1985-ös eltolással, illetve persze a számítógépeknél általános 1970-es érték is szóba jöhetett. Azt feltételeztem, hogy a szervezők nem álltak neki túl korán a versenyre való felkészülésnek, ezért a log idén készülhetett, de ezen felül nem volt további információm. Ráadásul mivel ez a CAN kommunikáció nem a J1939 alapján épült fel, ezen az ágon nem tudtam továbbhaladni.
Amiből viszont ki tudtam indulni, az az idő volt, pontosabban a másodperc. Tudtam, hogy a CAN logok legalább néhány percnyi időt ölelnek fel, hiszen ennél rövidebb idő alatt valós forgalomban nehéz négy különböző utcát érinteni. Ebből kifolyólag a másodpercnek többször át kellett fordulnia 59-ről 0-ra, tehát ha egy olyan bájtpozíciót találok, ami 0-tól 59-ig növekszik, majd 0-ról indul újra, akkor jó eséllyel meglesz az időt (és minden bizonnyal a dátumot is) tartalmazó üzenet!
Írtam tehát egy (általános) számlálókereső Python scriptet, ami a következőket csinálta:
- Felparse-olta a CAN logot, minden sort csatornára, CAN ID-ra és adatbájtokra bontva
- Közben felépített egy objektumot a memóriában, ami csatornánként és ID-nként csoportosítva eltárolta az üzeneteket (opcionálisan eldobva az ismétlődőket)
- Az objektumot ezután cache-elte egy fájlba, hogy a legközelebbi futtatásnál már ne kelljen a hosszadalmas parse-olást végigvárni
- Ezután pedig minden egyes üzenetfolyamban számlálókat keresett a következőképpen:
- Az üzenet minden bájtjához hozzárendelt egy 0-ra inicializált ún. számlálóvalószínűségi változót
- Az üzenetfolyam minden üzenetére elvégezte a következőket:
- Az üzenet adatait bájtokra bontotta
- Kiszámolta az aktuális és az előző üzenet n-edik bájtjának különbségét (n = 1..8)
- Ha ez az n-edik különbség épp 1 volt, akkor megnövelte az n-edik számlálóvalószínűségi változót
- Az üzenetfolyamban talált számlálóvalószínűségi változókat az üzenetek számával normalizálta 0 és 1 közé
A számlálók valószínűségi keresésére és a normalizálásra azért volt szükség, mert ha bármilyen emelkedésre számlálónak ítéltem volna egy bájtot, akkor sok fals pozitívot kaphattam volna, ha pedig minden egyes üzenetben növekedést vártam volna el, akkor a túlcsordulások miatt a 0-ra váltásoknál valós találatokat veszítettem volna el. Így viszont előállt egy szép statisztika, ami alapján már jó eséllyel lehetett megtalálni a tényleges számlálókat:
A fenti példa azt mutatja meg, hogy a 0-s CAN csatorna 084 és 091 üzenetének és 6. bájtja jó eséllyel egy-egy számláló, míg a többi valószínűleg nem az.
Az ismétlődő üzenetek eldobását abból a megfontolásból tettem bele a scriptbe, hogy ha egy lassan változó jel (a másodperc ilyen) üzenete a változásnál gyakrabban érkezne (tehát másodpercenként többször), akkor se csökkenjen emiatt az adott bájt „számlálóvalószínűsége”.
A script kimenetében a 0.9 fölötti számokra rákeresve mindössze 28 találat érkezett, ezeket pedig már könnyű volt végignézni a logban. Hamar rá is akadtam a 084-re, ami így nézett ki:
Ez elég ígéretes! A 6. bájt ugyanis épp 0x3B, azaz 59 után fordul át 0-ra, ezzel együtt pedig az azt megelőző bájt is növekszik eggyel (miközben 60 alatt marad)! Ráadásul ezt az üzenetet több csatornán is megtaláltam, ami az időt terítő üzenet esetén logikusnak is tűnik.
Elfogadva a feltételezést, hogy ez a keresett üzenet, már csak az volt hátra, hogy megtaláljam benne a dátumot. A perc és a másodperc megvolt, az óra pedig minden bizonnyal ott volt vagy előttük, vagy mögöttük. Az első bájt 0x18-as, azaz 24-es értéke gyanúsan 2024-re emlékeztetett — lehet, hogy Fordék így kódolják az évet? Az utána következő 0x0000B2 viszont sehogy nem illett a képbe. Ha elfogadom, hogy az utolsó 0x0D az óra, akkor ebben a számban kellett benne lennie a hónapnak és a napnak. De még ha mondjuk 0-tól is kezdjük a hónapokat, és az egyik 0x00 januárt jelenti, a 0xB2 értéke akkor is 178, ami sehogyan nem lehet nap. Láttam már olyan trükköt, hogy a másodpercet és a napot 1/bit helyett 4/bit felbontással küldik, de a 178 még így is 44-et jelentett volna, ami se hónap, se nap nem lehetett.
A megoldásra majdnem egyszerre jöttünk rá egy csapattársammal, ő volt a gyorsabb. Már nem tudom, pontosan hol láttam meg azt a gondolatot, hogy az év után nem hónap és nap következik, hanem a nap sorszáma az éven belül. A 2024-es év 178. napja június 26. volt (ezt szerencsére a Google kapásból meg is mondta), és a 26/06/2024 flagre rápróbálva meg is kaptuk a pontokat.
Tényleg nem dolgoztak túlságosan előre a szervezők! 🙂
Where were we driving?
What was the latitude and longitude of our destination in degrees and minutes?
Example Flag: LatitudeDegrees.LatitudeMinutes,LongitudeDegrees.LongitudeMinutes 00.00,00.00
Koordinátákat keresni nem tűnt könnyű feladatnak, ugyanis vajmi kevés esélyt láttam arra, hogy ASCII-ként legyenek átküldve a CAN-en. Én magam lebegőpontos számokként küldeném őket, azok pedig egyáltalán nem szembeötlőek egy hatalmas bájtfolyamban.
Ezért ennél a feladatnál be is zártam a CAN logot, és inkább a Google Mapset nyitottam meg.
Az egyik előző feladatból kiderült ugyanis azoknak az utcáknak a neve, ahol a log készült. Ha az autó végig közúton haladt, akkor egymás melletti Piedmont, Acacia, Wheaton és Rochester nevű utakat kellett találnom, ami azért már elég egyedi kombinációnak tűnt ahhoz, hogy csak egy környéken legyen.
A rádiós feladat erősen utalt Michiganre, úgyhogy ott kezdtem a keresgélést. Az utcaneveket beírva láttam, hogy néhány javaslat Detroit Troy nevű városrészébe mutatott, ekkor pedig beugrott, hogy az egyik alapító adatlapján láttam már ezt a helyet, amikor egy korábbi feladathoz OSINT-et gyűjtöttem. Nemsokára meg is találtam a környéket:
Ha pontos koordinátákat kértek volna, akkor ennyiből még nem tudtam volna megadni a végpontot, de szerencsére csak szögperc pontossággal kellett válaszolni. Itt, az északi szélesség 42. foka környékén egy hosszúsági szögperc kb. 1,38 km, egy szélességi szögperc pedig kb. 1,85 km (mint akárhol máshol). Egy ekkora téglalapba pedig már könnyen bele lehetett találni próbálgatással, ha jól emlékszem, elsőre meg is lett a megfelelő megoldás, a 42.33,-83.07.
Itt amúgy annyi trükk volt még, hogy a számítástechnikában leggyakrabban használt formátumot, a tört fokokat fokba-szögpercbe kellett átváltani (általános iskolai anyag), illetve az európai szemnek szokatlan nyugati hosszúságot negatív számként kellett ábrázolni.
Steering Angle
What arbitration ID has the steering wheel angle?
A fejezet utolsó feladatának megoldásához volt szükségem a legtöbb időre. A kérdés az volt, hogy milyen CAN ID-val küldi az üzeneteit a kormányszögszenzor, ezért elsőnek megpróbáltam beazonosítani, hogy milyen alkatrészről van szó. Reménykedtem, hogy ezután találok majd további modelleket is, amelyek ugyanezt a szenzort használják, aztán pedig hátha sikerülne CAN adatbázist találni legalább az egyikhez.
Sajnos most nem volt szerencsém (vagy nem voltam elég kitartó), ezért egy idő után feladtam a keresést, és visszatértem a CAN loghoz. Összeszedtem, hogy mit tudok (vagy legalábbis sejtek) a kormányszög CAN jeléről: folytonos, viszonylag pontos jel, viszonylag hosszú középállás körüli értékkel (mert a fent megtalált utcák eléggé egyenesek) és onnan mindkét irányba való kitéréssel (mert valószínűleg jobbra és balra is kormányoztak). Ezen felül megelőlegeztem egy legalább 8 bites felbontást, de inkább jobbat, és egy jó széles értéktartományt, amit a jel valószínűleg nem használ ki (nem valószínű, hogy menet közben koppanásig tekerték volna a kormányt).
Ezek a tulajdonságok jól látszanak egy grafikonon, de a nyers CAN logban egyáltalán nem, úgyhogy azt láttam a legbiztatóbb útnak, ha grafikusan ábrázolom az adatokat. Valószínűleg átkonvertálhattam volna a logot valami olyan formátumba, amit aztán egy létező tool meg tud nyitni, de aztán valamiért mégis úgy döntöttem, hogy saját vizualizálót készítek, méghozzá HTML és Javascript alapokon, mert ezekkel tudtam a leghatékonyabban összehozni egy gyorsan alakítható, interaktív és grafikus felületet.
Az oldal betöltés után behúzza az összes CAN adatot (ugyanabból a cache fájlból, amit még a számlálókereséshez készítettem), aztán a user választhat, hogy melyik csatorna melyik üzeneteit akarja grafikonon látni. A tool az üzenet minden bájtját külön CAN jelként kezeli (itt éltem a feltételezéssel, hogy a kormányszög jele legalább bájthatárról indul), és egy közös grafikonon mutatja őket. Ezután pedig a humán intelligencia mintafelismerő képességében bízva elkezdtem az összes üzenet grafikonját az ún. guvadtszem-módszerrel átnézni.
Az elkészült grafikonok ilyenek voltak:
Listát készítettem azokról az ID-król, amelyekben találtam engem kormányszögre emlékeztető grafikonokat, majd elkezdtem flagként végigpróbálgatni őket. Végül nem is olyan üzenet lett a befutó, amelyikre legerősebben tippeltem, de azért így is sikerült megtalálni a megoldást, a 0x07E-t.
Konklúzió
A fenti leírás a megoldások menetének tömör összefoglalója; a rengeteg vargabetűt, zsákutcát, sötétben tapogatózást kihagytam belőle. Pedig ezekből állt az időnk nagy része, egy alkalommal például órákon keresztül készítettem egy Excel táblát arról, hogy melyik CAN üzenet melyik csatornákon jelenik meg — ez később teljesen feleslegesnek bizonyult.
Viszont mindannyian rengeteget tanultunk a verseny két hete alatt, jövőre pedig ezzel az új tudás birtokában, az idei tapasztalatokkal és toolokkal felvértezve állunk újra a rajtvonalhoz!
Néhány korábbi posztban (pl. 
Nem lenne korrekt nem megemlíteni a posztban a 
Ennek ellenére bolond lennék elhessegetni a segítő szándékot, ráadásul be kell látnom, hogy az igazán ütős szolgáltatások nem fognak menni további anyagi befektetés nélkül. Az első ötletem az SMS-küldés volt, de azt csak kb. 20 Ft-os darabáron tudnám megtenni, ennyi közhasznúság sajnos már nem fér bele. A másik irány, hogy inkább Push üzenetet küldök — a fogadásukra képes — felhasználóknak, azt meg tudom tenni ingyen.
