CZECH LAND ROVER FORUM

Ahoj,
Norim do oblasti CAN Bus hackingu. Neresil to tu nahodou nekdo?
Potrebuju sehnat LandRoveri kody, kterymi se mezi sebou dorozumivaji ridici jednotky v aute.

Bacha, neni to zadne ODB II, ani takove ty ELM27 do odb portu. Proste nativni komunikace na High-speed sbernici.

Ted trochu spanelske vesnice:
Na HS-CAN jsem pripojil CAN analyzator (Pouzivam analyzator a "hacking" tooly od https://rs.canlab.cz)
CAN data traffic ukazuje behem 1 minuty ca 30 ruznych extended ID, vetsinou po 8 bytech. Standarni CAN ramce, vse extended ID's.

Je v tom zakodovano vicemene vse, po cem patram. Pro zacatek mi staci rychlost vozidla. Pozdeji budu zkoumat provozni stavy jednotlivych jednotek (haha, treba vzduchoveho perovani, napriklad )

Resil nekdo, jak tuhle vec rozkodovat? Predpokladam, ze to asi resili pouze vyrobci diagnostik, popisy typu zprav vubec neni verejna informace, takze je to spis mission impossible.
No na druhou stranu v CZ stale plati "to das"

Diky, Honza

Provadej logovani a zaznamenavej zmeny stavu bytu. Pri zmacknuti tlacitka. Pri vypnuti komresoru atd. atd atd.....aspon milionkrat[emoji2957] Kdyz budes mit dostatecne mnozstvi popsanych logu tak dokazes vyseparovat ty ktere te zajimaji a potom se uz pustis pouze do dekodovani logiky stavu jednotlivych bitu v bytu. Nemyslim ze tam bude pouzity nejaky algoritmus kodovani. To nema zadny smysl.

Edit: jeste me napadlo uplne jednoduche urychleni. Kdyz budu hledat byte kde je sprava o teplote kompresoru tak ji najdu rychle tak, ze zaloguju dotaz diagnostiky na zpravu o teplote. To znamena: rozdil komunikace bez a s teplotou v live datech = retezec -> tohle je dotaz na teplotu.
Sent from my iPhone using Tapatalk

No zase zajímavé téma.
Nebudu tu popisovat celí princip CAN atd. Jenom nějaké základy. ID je označení typu informace nebo spíše jaká jednotka tento kód vypustila. Jedna jednotka může mět více ID. proto jich je v D3 skoro 30. Záleží ještě na jaké CAN v D3 loguješ D3 má myslím že 2 a SUBMOST. (vím že HS-CAN) Celý systém je naprogramován tak že každá jednotka má svoji prioritu a vypouští do sítě svoje informace naopak si ze sítě bere informace které potřebuje. Jenom v případě dotazu na chyby vypustí jednorázově log chyb a zase si jede to svoje.
Z toho plyne že je třeba si zjistit jaké ID má jednotka ABS a začít logovat jenom informace z konkrétním ID co má ABS protože ta se domnívám že vypouští do sítě právě rychost vozidla. Pak postavit CAN simulátor jednotky ABS a začít rozkódování jednotlivích informací pomocí diagnostiky. Až zjistíš které byty to jsou.

To jak popisuje Kokešek je u KKL komunikace u CAN to tak nefunguje. OPRAVA v diganostickém režimu se to mění.
Takhle to znám já ale klidně je to jinak.

Ale nepochopil jsem rozdil toho co sem napsal ja a co ty Huberte? To ze id je na zacatku zpravy je jasne ale my potrebujeme vedet ktera jednotka je ktera. A prave ze budes sledovat ktera zprava se vytvori prvni v poradi nova, tak mi odhali prave id abs. Treba kdyz odpojim senzor abs nebo zatocim kolem. Pokud zatocim kolem tak budu hned vedet na ktere pozici je ulozeno v bytu teto zpravy ono kolo. A dohledam dalsi. Vsak neni problem si do obd hodit elm nebo neco jineho a koukat na stavy spolu s can analyzerem. A zacnes mit predstavu o tom co ktera zprava rika.


Sent from my iPhone using Tapatalk

Ahoj sry za delsi prispevek.

Napred bych upresnil par faktu - "cetl" jsem schema. Opravte me jestli se mylim.
- V D3/4 je Medium speed canbus, High speed canbus (obe vyvedene na ODB diag. konektor). Dale jeden privatni can bus nikam nevyvedeny. A pak opticky MOST na audio/video/handsfree.
- Gateway mezi High a Medium speed canbusem dela pristrojovka.
- Gateway mezi MOST a HS canbus dela radio. (mozna je tam i MS canbus, nevim)
- Souhlas, detaily obecneho fungovani CANbusu zde nerozebirejme, na to je Wiki https://en.wikipedia.org/wiki/CAN_bus, neni to uplne trivialni.

Ke komunikaci HS-CANu: kompletne exteded-id (29.bitu) datove ramce. Zadny "normalni 11. bit-id neni videt. Nize je screenshot prvniho "poslechu".

Hubert ma pravdu, ze jedna jednotka muze mit vice (i hodne vice) IDcek - klidne separe ID na kazdy typ provozni zpravy (proc ne) - bez firemni dokumentace detektivka.
Kokesku rozumim, hledani je detektivka, hodne casu, trochu stesti a intuice. Plus potreba dobry can-analyzator software.

Ta jednodussi cast:
na HS-CANu je dlouhodobe ~30 IDcek (screenshoot), dohromady ca 240bajtu informaci, ktere stale dokola "broadcastuji" vsechny jednotky pripojene na HS-CAN. Ok, tohle by se s trouchou stesti dalo reverse-engeneerovat. Budu doufat, ze provozni data, ktera shanim, jsou zde jinak je to blby (pac se musi do canu "zapisovat")

To slozitejsi - na urovni fyzicke vrstvy CANu)
Muzou (a urcite budou) tam byt informace typu dotaz-odpoved. Na to ma CAN specialni paket Remote transmission request (RTR) - kdokoliv posle IDcko s priznakem RTR a cilove IDcko odpovi. Tahle komunikace muze byt zcela neviditelna, dokud ji nekdo nevyvola. Tohle jde odpposlouchat pouze mam-li neco, co prislusny dotaz posle. Navic uz to znamena, ze nelze pouze pasivne poslouchat, ale neco do site aktivne poslat (=hezka prilezitost pro problemy).

A aby to bylo jeste slozitejsi - ODB II)
Mame tu ODB standard (opet na Wiki), kdy diagnostika ala ELM27 posila datove CAN ramce (asi na HS-CAN) na definovane "ODB" IDcka, s definovanym obsahem (PID) - tedy dohodnuty "ODB" format paketu. Nektera z jednotek v aute (pristrojovka?) na ne pak asi odpovida, opet v dohodnutem ODB formatu. Me to ODB moc nezajima, to co potrebuju tam nebude.

No a zatreti a to uz vubec nemam paru, prepokladam, ze jednotky maji vlastni proprietarni protokol na aplikacni vrstve slouzici pro slozitejsi diagnosticke ukoly (update firmware, prenosy CCF souboru). Prepokladam ze firware jednotky ma nejaky vyssi komunikacni protokol, k tomu je protikus v podobe software v notebooku. Tohle odposlouchat uz je velmi obtizne, nastesti me to nezajima.

Ja potrebuju pouze rychlost a teplotu a nechci nic do CANu posilat. Zajimave je, ze kdyz jsem si pripojil svyho nanocoma a nechal ho zobrazovat "live" data ze systemu, tak se na HS-CANu objevili 2 nova IDčka ktere cile po celou dobu zobrazovani prenaseli data. Tj. vede me to k domence, ze nektera provozni "live" data na canbusu v klidovem stavu nejsou, ale je potreba si o ne aktivne "zazadat". To je to, co popisuje kokesek. Teoreticky nekde v techhle 2 Idckach (=max. 16 bajtu) je to, co hledam. Teoreticky. Ale musel bych zapisovat.

Tohle bude docela slozite. To muze sezrat hodne casu a vysledek je stejne nejisty.

Hele nevenuje se tomuhle tematu nekdo profesionalne?
Nedaji se ty informace komercne koupit?
Neni tu nadsenec, ktery by se do toho chtel pustit (klidne za $$$) - kdyztak se mi ozvete SZ.

A kdyz si sledoval dva nove id po pripojeni nanocomu tak sis urcite zatocil kolem u auta bez nastartovaneho motoru. A potom si musel i videt co se deje v onech bytech. Nechtej to zdolat a prekonat, zamer se jen na to co jde videt a dokazes osefovat. Ja bych ti vedel pomoct. Jen ses daleko a ja porad neco resim na dilne. Tohle je na akce v noci. Zadny zakaznik zadny telefon. Zeptam se kamarada co je vice teoretik v tomto ohledu.


Sent from my iPhone using Tapatalk

HST píše: 26 led 2020 20:56 Ahoj sry za delsi prispevek.

nie vsetky jednotky komunikuju v aute na HS-CAN, su to predovsetkym jednotky powertrainu, motor, prevodovka, abs, atd - v manualoch je to popisane pekne.

je to tema na dlhsie a je to velmi specificke pre znacku/architekturu auta.

V zasade CAN funguje pre signaly nasledovne (priklad rychlost v km/h):
- na aplikacnej vrstve mas urcity signal, ktory RJ pouziva v urcitej kvantifikacii (e.g. 1bit = 0.001km/h)
- signal je nasledne mapnuty na nejake CAN-ID na buse, ktore ma zase vlastnu kvantifikaciu (e.g. 1bit = 0.1km/h)
- to potom Sender-ECU posiela na celom buse
- kto chce, potom frame spracuje a poskytne aplikacnej vrstve

Potom je este kopec frameov vyssich protokolov (e.g. UDS, OBD), pripadne multiplexovane Frames, kedy Frame obsahuje viac signalov (e.g. byte0-2 rychlost v km/h, byte3-4 teplotu v C).

V zasade plati, ze nie vsetky framy su posielane v kazdom stave vozidla (cast zacne pri T15=ON, potom dalsie pri otackach motora, dalsie pri rychlost > 0km/h, pripadne dalsie pri zakroku DSC, ...). Toto sa vsetko tyka cyklickych frameov, teda tych ktore maju nejaky cyklus posielania. bezne sa pouzivaju aj event-triggered frames - hlavne diagnostika, Request-Response medzi RJ, etc. Ale tie vacsinou neobsahuju ziadne dolezite informacie, kedze sa velmi zlozito diagnostikuju.

Niektore framy obsahuju aj alive-counter a CRC (vacsinou po jeden byte), pripadne mozu byt osetrene nejakym Autosar E2E protection (co v pripade D3 skoro urcite nebude;-)).

Treba si este uvedomit jednu vec, vela signalov je na buse v raw forme, t.j. rychlost auta kludne moze byt rozdelena na samostatne rychlosti kazdeho kolesa zvlast. Napriklad pre stabilizacne systemy je dolezite rozlisovat rychlost taziska auta a rychlost v priamom smere.

Reverse engineering jednotlivych IDs:
- zisti si, aky signal potrebujes (napriklad rychlost)
- stimuluj auto tak, aby signal dosahoval urcite definovane hodnoty (chod 5km/h, 10km/h, 50km/h, 100km/h)
- v logoch hladaj udaje ktore sa menia podla stimulov

Pre niektore znacky najdes specifikaciu datovych busov na forach (VW, BMW, etc.). Mozno najdes podobne aj pre Land Rover. Taktiez plati, ze urcite signaly su medzi roznymi modelmi jednej znacky rovnake, aby bola zachovana ako taka architektura.

edit: este dodam, ze novsie auta uz nemaju iba HS-CAN, ale aj novsi CAN-FD s vacsimi frameami.