Jumping Jack Flash weblog

Hacking Icaro – Centralina GSM: Man in the Middle Attack – puntata 2

Posted in auto elettriche, hacking, hardware by jumpjack on 11 luglio 2019

Una settimana di studi e teorie non sono valsi l’avere i pezzi tra le mani…

A quanto pare il passo dei due connettori non è di 2mm, ma di 1.27mm! Vale a dire 0.050″.

Quindi sia la striscia di cavi che le pin strip… sono completamente inutili, tocca ricominciare la ricerca da capo.

Per fortuna però ormai ho acquisito un po’ di esperienza nel decodificare i datasheet di questi cavi, e ci è voluto poco: quello che mi serve non è un cavo TCMD o TCSD (passo 2.0mm) , ma un cavo di una famiglia diversa: o FFMD o FFSD  (passo 1.27mm). Si tratta sempre di cavi IDC di tipo TigerEye, ma i pin hanno appunto passo 0.050″/1.27mm. “M” sta per “maschio” e “S” per socket, cioè femmina, poi per il resto la nomenclatura Samtec rimane la stessa, quindi un FFxD-25-D avrà due connettori uguali mentre un FFxD-25-T li avrà di sesso opposto; purtroppo da 2×22 pin non esistono, quindi devo prendere il numero subito superiore, 2×25. Altre famiglie sono FFTP e FMTP, che però hanno i cavi “twistati” a 2 a 2; non significa che i contatti siano “incrociati”, ma solo che i fili sono arrotolati l’uno sull’altro (credo per attenuare le interferenze elettomagnetiche), ma poi terminano da entrambi i lati nella stessa posizione.

Le sigle papabili sono quindi:

  • FFMD-25-T-xx.xx-01: maschio/femmina
  • FFMD-25-D-xx.xx-01: doppio maschio
  • FFSD-25-T-xx.xx-01: maschio/femmina
  • FFSD-25-D-xx.xx-01: doppia femmina

Twisted:

  • FFTP-25-T-xx.xx-01: twisted, maschio/femmina
  • FFTP-25-D-xx.xx-01: twisted,  doppia femmina
  • FMTP-25-T-xx.xx-01: twisted, maschio/femmina
  • FMTP-25-D-xx.xx-01: twisted, doppio maschio

Può darsi che alcune delle combinazioni maschio/femmina non esistano perchè coincidenti con altre sigle.

Purtroppo su https://www.toby.co.uk  un FFMD-25-T-08.00-01-N costa circa 32,00 sterline fra tasse e spedizione.

Su RS-components non ci sono cavi maschio/femmina in magazzino, ma ho visto che la strip-pin con passo 2.0mm che ho ordinato per sbaglio entrano senza sforzo nè gioco nel connettore-femmina della scheda GSM, quindi basterà sfilarne 22 uno per uno e infilarli in uno dei due connettori-femmina per ottenere un connettore maschio; il femmina/femmina più economico è un FFSD-25-D-04.00-01-N, cioè 2×25 pin lungo 4 pollici (10 cm) del costo di 13,54 euro, che con IVA e spedizione diventano 22,62€; prenderò questo e speriamo che stavolta i conti tornino.

 

connettore GSM nero con righello e pin

Tagged with: , ,

Hacking Icaro – Centralina GSM: Man in the Middle Attack

Posted in Diario elettrico GreenGo Icaro, GPS, hacking, hardware by jumpjack on 10 luglio 2019

Un attacco “Man in the middle” è quello che prevede che un hacker si inserisca nel canale di trasmissione tra due dispositivi per intercettare i dati, senza interromperli ma modificandoli, in modo che a entrambi gli interlocutori originali la trasmissione sembri ancora genuina, mentre in realtà qualcosa è cambiato.

E’ quello che ho deciso di fare come nuovo tentativo di “entrare nella testa” della mia Icaro. 🙂

Nella centralina GSM/GPS è infatti presente, come già detto in precedenza, un modulo GSM G600; questo modulo è saldato su un PCB che chiameremo “A”; il PCB è connesso tramite un connettore bianco a un secondo PCB che chiameremo “B”; il PCB “B” è infine connesso alla scheda madre tramite un connettore nero; ed è qui che cercherò di insinuarmi. Se infatti il connettore bianco ha pin talmente microscopici e vicini da non poter essere maneggiati con strumenti manuali, il connettore nero ha invece pin più grossi e distanziati (passo di 2mm); si tratta di un connettore a 44 pin, due dei quali sono sicuramente i TX e RX del modulo GSM, il quale ho già verificato  che comunica con l’MCU tramite semplici comandi AT testuali: è così infatti che sono riuscito a leggere quale IP la centralina cerca di contattare, che purtroppo corrisponde al sito abbandonato etheria.it; quindi, anche se la centralina funziona e tenta di inviare dati, non ricevendo risposta probabilmente non passa mai dalla modalità “handshaking” al vero e prorio invio dati. Però in compenso i server eteria.biz (senza H e con dominio .biz) pare funzionino ancora (così mi hanno detto…).

Il mio tentativo sarà quindi di interrompere fisicamente le due connessioni TX e RX, dirottarle a una mia scheda ESP32, e sostituire ogni chiamata del modem al server sbagliato con una chiamata al server giusto… e vedere cosa succede.

Per farlo, mi serviranno due connettori aggiuntivi: un maschio e una femmina che facciano da interruzione tra GSM e MCU, e al tempo stesso da “dirottatore” verso l’ESP32.

Sfortunatamente questi connettori non hanno il classico passo da 1/10 di pollice (2.54mm), ma da 2.00 mm, quindi non ho niente in “magazzino” che vada bene, dovrò comprare dei connettori specifici.

Dopo una settimana di ricerche sui siti più disparati (www.distrelec.it, www.farnell.it, www.mouser.it, www.tme.eu, https://it.rs-online.com), mi sono fatto una discreta cultura sui possibili modi di realizzare una connessione a 44 fili tra i due PCB; ho individuato varie possibilità:

  1. Cavo preassemblato
  2. Cavo autocostruito
  3. Connettori saldati su piastra millefori, connessi tramite fili singoli
  4. Ponticelli dupont

Ognuno ha i suoi pro e i suoi contro:

  1. il cavo preassemblato sarebbe ovviamente la scelta migliore, ma fra costi netti, tasse e spedizioni, un cavo a 40 poli finisce per costare fra i 40 e i 50 euro!
  2. il cavo autocostruito, comprando una piattina e due connettori IDC, finirebbe per costare solo 5-10 euro in meno di un cavo preassemblato.
  3. inizialmente avevo pensato di costruirmi un  “cavo” saldando due connettori maschio e femmina a due pezzi di piastra millefori, e poi collegarli tra loro tramite fili volanti, ma sarebbe un lavoro troppo approssimativo e disordinato

Alla fine ho scoperto una cosa molto interessante: oltre ai classici “ponticelli dupont” usati per prototipazione su Arduino, che hanno passo da 2.54mm, esistono anche dei ponticelli più piccoli, con passo da 2.0mm: sono molto inconsueti e poco diffusi, quindi ordinarli significherebbe doverseli per forza far spedire dalla Cina e vederli arrivare fra 3 o 4 mesi; poi però, a forza di cercare, ho trovato una soluzione al tempo stesso rapida ed economica: una spedizione Amazon Prime, di questo oggetto:

Si tratta di una sorta di cavo piatto un po’ primitivo, senza nè connettori plastici singoli nè connettori da 44 pin: sono solo 40 fili intestati con terminali femmina; l’inserzione era un po’ confusa e maltradotta, ma sperabilmente dovrebbe trattarsi di terminali da 2.0mm; sono solo 40 invece dei 44 necessari, ma in realtà non tutti i pin del connettore sulla scheda GSM sono popolati, quindi si dovrebbe riuscire ad adattare il cavo.

Adesso dall’inserzione, che includeva vari oggetti diversi, questo in particolare è sparito, quindi non resta che sperare che non mi mandino invece quest’altro oggetto, che ha la stessa foto ma è dichiarato avere passo da 2.54mm. Sennò c’è il reso gratuito Amazon.

In ogni caso, resta poi il problema che sui due PCB ho un connettore maschio e uno femmina, mentre questo cavo ha solo femmine; ho quindi aggiunto all’ordine questo strip maschio-maschio con passo da 2.0mm:

Cercando “jumper wire 2.0 mm” si troverebero varie altre alternative, ma tutte senza Prime, quindi con data di arrivo imprecisata.

Ecco uno schema di massima di come dovrebbe avvenire il collegamento “clandestino” tra modulo GSM e motherboard:

cavo intercettazione centralina GSM/GPS icaro

Cavo intercettazione centralina GSM/GPS icaro

Il cavo ideale sarebbe il TCSD-22-T-03.00-01,o l’omologo  TCMD-22-T-03.00-01 (anche se probabilmente non esistono due cavi identici con sigle diverse), ma è possibile arrangiarsi con varie altre possibilità, come descritto in figura; l’importante è che il codice non finisca con -R o con -O, che significa che il connettore finale  è capovolto (-R se sono 2 connettori, -O se sono 3 in daisy-chain, nel qual caso prima della “O” ci sarebbe anche una “Dxx”, con xx distanza tra connettore 2 e connettore 3).

Il sito https://www.toby.co.uk forse non è “fintamente inglese” comei vari mouser, farnell ecc. che in realtà spediscono dalla Cina o dall’America, quindi è possibile che ordinando qui il materiale arrivi nel giro di una settimana invece che di 3-4 mesi.

Anche il sito https://www.enrgtech.co.uk/ sembra inglese autentico.

Ecco alcuni possibili codici di cavi validi:

Nota:  essendo lo strip-pin sulla motherboard non protetto da un case, qualunque connettore femmina con più di 22 pin si può adattare, quindi per esempio anche TCSD-25-01 e successivi. Il limite ovviamente è la larghezza massima disponibile all’interno dello scatolotto della centralina. Foto del connettore maschio sulla motherboard:

connettore GSM nero con righello e pin

 

Sul sito Samtec c’è anche un configuratore 3d che permette di vedere in tempo reale come cambia il cavo al cambiare delle opzioni del suo part number, ma per ora è disponibile solo per la famiglia TCSD, non per la TCMD:

Samtec TCSD IDC 3d configurator

Samtec TCSD IDC 3d configurator

Qui di seguito riporto invece gli esiti delle mie ricerche precedenti alla decisione finale di comprare ponticell dupont.

Cavi preassemblati

Ho trovato due soli produttori per cavi piatti con connettori con passo (“pitch”) da 2.0mm e a 44 pin: Samtec e 3M; questi sono due esempi di datasheet dei loro prodotti:

La Samtec usa questa nomenclatura

xxxD-22-T-LL.LL-01-N-R

  • xxx: famiglia del cavo (v. sotto) – TCMD = maschio, TCSD = femmina
  • D: doppia fila di pin
  • 22: numero di pin per fila
  • T:  connettore di sesso opposto  all’altra estremità del cavo (invece di fili liberi); S = fili liberi, D = connettore identico all’altro
  • LL.LL: lunghezza in pollici del cavo
  • 01: numero fisso
  • N: presente solo se è presente prima la “T”, e significa “notch polarization”)
  • R: verso invertito del connettore; O = verso invertito del connettore finale se i connettori sono 3 (daisy-chain)

 

Famiglia del cavo

  • TCSD 2.00 mm  – Tigereye Cable Socket Double – IDC Ribbon Cable Assembly, Socket
  • TCMD 2.00 mm – Tigereye Cable Male Double – IDC Ribbon Cable Assembly, Terminal
  • EHT 2.00 mm Shrouded IDC Ejector Header
  • STMM 2.00 mm Shrouded Terminal Strip, Cable Mate
  • ZSTMM 2.00 mm Shrouded Variable Stack Height Terminal Strip, Cable Mate
  • ETMM 2.00 mm Shrouded Terminal Strip For Strain Relief for TCSD

(ho cancellato le famiglie non adatte al mio caso)

Qui la pagina Samtec per la ricerca visuale.

Alcune note:

  • il passo da 2.00 mm del connettore implica un passo da 1.0mm dei fili, mentre il passo tipico di 2.54mm (ad esempio per la piattina dell’hard disk) implica un passo di 1.27 mm per  i fili
  • il “passo” in inglese si chiama “pitch”
  • IDC significa “Insulation-Displacement Connector” (“connettore a spestamento di guaina”): significa che i fili non sono connessi ai pin tramite saldatura, ma grazie a delle affilate “microforcelle” presenti sul loro retro; l’apertura della forcella è poco più larga del diametro del conduttore di rame interno al filo, quindi quando si inserisce il filo nella forcella, questa taglia e sposta la guaina, andando a toccare il conduttore e garantendo un contatto elettrico stabile e addirittura a tenuta d’aria:

IDC connection, Torq-Tite patent

IDC connection, Torq-Tite patent

  • Nel datasheet c’è un’immagine un po’ fuorviante, che potrebbe far credere che in certi connettori i pin sono sfalsati; in realtà l’immagine di sinistra nella figura qui sotto mostra il connettore visto dal lato opposto dei pin, che invece sono disposti a griglia come mostrato a destra, in altra immagine tratta dallo stesso datahseet:

Connettore femmina da PCB

  • DS1026-05-2*22S8BV – Presa; con pioli; femmina; PIN: 44; dritto; 2mm; THT; 2×22 (codice TME.EU: ZL265-44DG)

    Datasheet: link

 

  • MMS-122-01-L-DV – Codice RS: 180-3564 – Connettore femmina per PCB Samtec serie MMS, 44 vie, 2 file, passo 2mm, foro passante RS-COMPONENTS 6,969€ x 13
  • MMS-122-01-L-DV – Codice RS-COMPONENTS: 180-3930 – Connettore femmina per PCB Samtec serie MMS, 44 vie, 2 file, passo 2mm, foro passante –   €10,10 x 1

Connettore maschio da PCB

Come maschio ci sono varie possibilità, nessuna delle quali identica al connettore che è sulla centralina:

 

DS1014-44SF1B – (2 file da 22) – TME.EU

Datasheet: link

Differenza: presa incapsulata invece che pin liberi

La sigla “DS1014-44SF1B” significa:

  • DS1014: codice prodotto
  • 44: numero contatti
  • S: montaggio di tipo V/T
  • F1: contatti in oro
  • B: colore nero

 

DS1002-02-2*25BT1F6 (2 file da 25) – TME.EU

(immagine non disponibile)

Datasheet: link

Differenza: due file da 25 pin invece che da 22.

La sigla DS1002-02-2*25BT1F6 significa:

  • DS1002-02: codice prodotto
  • 2*25: disposizione contatti
  • B: tipo di clip a “4 fingers” (???)
  • T1: placcatura pin in stagno
  • F6: placcatura clip in stagno

 

Altri:

  • 57102-F08-11ULF (2 file da 11, quindi ne servirebbero 2) – TME.EU – “Pin header; wire-board; male; Minitek; 2mm; PIN: 22; THT” – 1,46€
  • 57102-F08-25ULF (2 file da 25, da tagliare) “Pin header; wire-board; male; Minitek; 2mm; PIN: 22; THT” – TME.EU – 1,55€
  • 87831-4420 – Connettore circuito stampato serie MILLI-GRID Molex, 44 vie, 2 file, passo 2mm, 2A, Diritta – Codice RS-COMPONENTS: 670-1009 – 8,17 euro (5 pezzi)

 

  • A3-44PA-2SV(71)Codice RS 764-4622 – Connettore maschio serie A3 Hirose, 44 vie, 2 file, passo 2mm, 2A, Diritta – RS-COMPONENTS – 3,51€
  • 87758-4416 – Codice RS 670-3733 – Connettore circuito stampato serie MILLI-GRID Molex, 44 vie, 2 file, passo 2mm, 2A, Diritta – RS-COMPONENTS17,00 euro (confezione da 10)
  • 832-80-022-20-001101 – Codice RS 701-9761 – in connettore per circuito stampato, Preci-Dip, 832-80-022-20-001101, maschio, 22 vie, 2 file, 2mm foro passante – RS-COMPONENTS – 12,39 euro (confezione da 5)

Tutte le foto del modulo GSM:

connettore GSM nero con righello e pin

Connettore lato SIM con pinout marziale

connettore GSM nero con righello

Hacking Icaro GSM – puntata 3 (17/3/2019)

Posted in hacking by jumpjack on 17 marzo 2019

Trovato documento specifico del modulo G600 descrivente in dettaglio la connessione PPP: http://d1.amobbs.com/bbs_upload782111/files_35/ourdev_610405OJVGOK.pdf

PPP spiegato passo passo e campo per campo (ma in cinese): http://www.synrich.com/Download/PIML-PLUS/GPRS_TCP%20Guide.pdf

PPP spiegato in inglese con un (singolo) esempio: http://lateblt.tripod.com/bit60.txt

PPP spiegato in inglese con molti esempi: http://www.powerfast.net/maxtnt/~ascend/MaxTNT/admin/ppprime.htm

Spiegazione molto completa: http://support.huawei.com/enterprise/docinforeader!loadDocument1.action?contentId=DOC1000001581&partNo=10062#sec_vsp_fea_ppp_0007_mMcCpPsS_fig02

Incapsulamento IP/UDP/TCP: http://www.netfor2.com/contents.htm

Esempio di trasmissione reale (forum): https://os.mbed.com/forum/mbed/topic/1551/


Dati grezzi registrati in comunicazione tra microcontrollore (MCU) e modulo GSM (G600)

In invio (MCU –> G600)

  1. 7E 3F 7D 23 3F 21 7D 21 7D 21 7D 20 7D 34 7D 22 7D 26 7D 20 7D 20 7D 20 7D 20 7D 25 7D 26 65 67 6C 6A 7D 27 7D 22 7D 28 7D 22 3F 6D 7E
  2. 7E 3F 7D 23 3F 21 7D 22 7D 21 7D 20 7D 32 7D 22 7D 26 7D 20 7D 20 7D 20 7D 20 7D 23 7D 24 3F 23 7D 27 7D 22 7D 28 7D 22 3F 3F 7E
  3. 7E 3F 23 01 02 47 50 52 53 7E
  4. 7E 3F 7D 23 3F 21 7D 21 7D 23 7D 20 7D 2E 7D 22 7D 26 7D 20 7D 20 7D 20 7D 20 7D 27 7D 22 7D 28 7D 22 2A 3F 7E
  5. 7E 3F 23 01 04 7E
  6. 7E 3F 21 01 05 7E
  7. 7E 3F 21 01 06 2F 7E
  8. 7E 3F 21 01 07 03 06 7E
  9. 7E 3F 21 02 01 7E
  10. 7E 3F 21 01 08 3F 3F 7E
  11. 7E 21 45 3F 04 5F 6E 3F 16 04 2D 07 3F 01 02 08 09 28 08 3F 61 7E
  12. 7E 21 45 3F 04 5F 6E 3F 16 04 78 05 3F 01 01 04 02 6C 73 7E
  13. 7E 21 45 30 3F 16 04 02 20 3F 3F 7E
  14. 7E 21 45 7D 5D 3F 04 5F 6E 3F 16 04 12 34 56 78 02 04 05 3F 01 01 04 02 4A 67 7E
  15. 7E 21 45 6E 3F 16 04 70 02 20 3F 3F 7E
  16. 7E 21 45 06 7B 3F 04 5F 6E 3F 16 04 12 34 56 78 7E
  17. 7E 21 45 5F 6E 3F 16 04 04 02 3F 3F 7E
  18. 7E 21 45 0B 3F 12 34 56 78 7E
  19. 7E 21 45 04 5F 6E 3F 16 04 01 04 02 3F 3F 7E
  20. 7E 21 45 3F 71 7E
  21. 7E 21 45 3F 04 5F 6E 3F 16 04 3F 01 01 04 02 49 3A 7E
  22. 7E 21 45 04 7E
  23. 7E 21 45 74 3F 04 5F 6E 3F 16 04 78 05 3F 01 01 04 02 6F 2E 7E
  24. 7E 21 45 30 3F 16 04 02 20 3F 7E

In ricezione (MCU <– G600)

(C021 = LCP, C023 = PAP, autenticazione, 8021 = IPCP,  02 10 = ?!?)
  1. 7E FF 7D 23 C0 21 7D 21 7D 21 7D 20 7D 32 7D 22 7D 26 7D 20 7D 20 7D 20 7D 20 7D 23 7D 24 C0 23 7D 27 7D 22 7D 28 7D 22 DD 94 7E
  2. 7E FF 7D 23 C0 21 7D 24 7D 21 7D 20 7D 2A 7D 25 7D 26 65 67 6C 6A 60 85 7E
  3. 7E FF 7D 23 C0 21 7D 22 7D 23 7D 20 7D 2E 7D 22 7D 26 7D 20 7D 20 7D 20 7D 20 7D 27 7D 22 7D 28 7D 22 7D 34 BC 7E
  4. 7E   C0 23   02 04 00 05 00   AA 5E    7E
  5. 7E   80 21   03 05  0003  06 00 00 00 00   C6 A1   7E
  6. 7E   80 21   03 06  0003  06 00 00 00 00   C1 77   7E
  7. 7E   02 10   10 10 00 4B B9 9   7E
  8. 7E  80 21   03 07  0003  06B506E6   8583   7E        
  9. 7E  80 21   02 08  0003  06B506E6   8A39   7E

 

Decodifica di un pacchetto PPP singolo

Il carattere 7d è un carattere di escape: se è presente, significa che per il byte successivo bisogna fare uno XOR con 0x20 (in pratica sottrarre 0x20) ; quindi 7d 20 diventa 00, oppure 7d 38 diventa 18, e così via.

Ricezione

7E FF 7D 23 C0 21 7D 21 7D 21 7D 20 7D 32 7D 22 7D 26 7D 20 7D 20 7D 20 7D 20 7D 23 7D 24 C0 23 7D 27 7D 22 7D 28 7D 22 DD 94 7E

Decodificato

  • 7E FF 03 C0 21 01 01 00 12 02 06 00 00 00 00 03 04 C0 23 07 02 08 02 DD 94 7E

Raggruppato per campi

  • 7E FF 03   C0 2101 01 00 12   02 06 00 00 00 00   03 04 C0 23   07 02   08 02   DD 94   7E

Commentato

  • 7E  – Inzio pacchetto PPP
  • FF – Destinatario (FF=tutti)
  • 03 –  Sempre 03 (?)
  • C0 21       –  Protocollo LCP (negoziazione iniziale)
  • 01 01 00 12   02 06 00 00 00 00   03 04 C0 23   07 02   08 02 – Contenuto del pacchetto LCP
  • DD 94   – Checksum (chiamata “FCS”)
  • 7E         – Terminatore PPP

 

Decodifica del pacchetto LCP (protocollo descritto in RFC1661)

  • 01 – Richiesta
  • 01 – Id della  richiesta (arbitrario)
  • 00 12 – Lunghezza totale della richiesta, inclusi questi 2 byte e i due precedenti (decimale 14)
  • 02 06 00 00 00 00  – Prima opzione da configurare. Decodifica:
    • 02 – xxxx
    • 06 – Lunghezza, incluso questo byte e il precedente
    • 00 00 00 00 – Payload
  • 03 04 C0 23   – Seconda opzione da configurare. Decodifica:
    • 03 – xxx
    • 04 – Lunghezza, incluso questo byte e il precedente
    • C0 23 – Payload
  • 07 02   – Terza opzione da configurare. Decodifica:
    • 07 – xxx
    • 02 – Lunghezza, incluso questo byte e il precedente; quindi il payload ha lunghezza nulla
    • Payload vuoto –> usare valore di default per questa opzione
  • 08 02 – Quarta opzione da configurare. Decodifica:
    • 08 – xxx
    • 02 – Lunghezza, incluso questo byte e il precedente; quindi il payload ha lunghezza nulla
    • Payload vuoto –> usare valore di default per questa opzione

Pacchetti decodificati

INVIO

  1. 7E 3F 03 3F 21 01 01 00 14 02 06 00 00 00 00 05 06 65 67 6C 6A 07 02 08 02 3F 6D 7E
  2. 7E 3F 03 3F 21 02 01 00 12 02 06 00 00 00 00 03 04 3F 23 07 02 08 02 3F 3F 7E
  3. 7E 3F 23 01 02 47 50 52 53 7E
  4. 7E 3F 03 3F 21 01 03 00 0E 02 06 00 00 00 00 07 02 08 02 2A 3F 7E
  5. 7E 3F 23 01 04 7E
  6. 7E 3F 21 01 05 7E
  7. 7E 3F 21 01 06 2F 7E
  8. 7E 3F 21 01 07 03 06 7E
  9. 7E 3F 21 02 01 7E
  10. 7E 3F 21 01 08 3F 3F 7E
  11. 7E 21 45 3F 04 5F 6E 3F 16 04 2D 07 3F 01 02 08 09 28 08 3F 61 7E
  12. 7E 21 45 3F 04 5F 6E 3F 16 04 78 05 3F 01 01 04 02 6C 73 7E
  13. 7E 21 45 30 3F 16 04 02 20 3F 3F 7E
  14. 7E 21 45 7D 3F 04 5F 6E 3F 16 04 12 34 56 78 02 04 05 3F 01 01 04 02 4A 67 7E
  15. 7E 21 45 6E 3F 16 04 70 02 20 3F 3F 7E
  16. 7E 21 45 06 7B 3F 04 5F 6E 3F 16 04 12 34 56 78 7E
  17. 7E 21 45 5F 6E 3F 16 04 04 02 3F 3F 7E
  18. 7E 21 45 0B 3F 12 34 56 78 7E
  19. 7E 21 45 04 5F 6E 3F 16 04 01 04 02 3F 3F 7E
  20. 7E 21 45 3F 71 7E
  21. 7E 21 45 3F 04 5F 6E 3F 16 04 3F 01 01 04 02 49 3A 7E
  22. 7E 21 45 04 7E
  23. 7E 21 45 74 3F 04 5F 6E 3F 16 04 78 05 3F 01 01 04 02 6F 2E 7E
  24. 7E 21 45 30 3F 16 04 02 20 3F 7E

Ricezione

  1. 7E FF 03 C0 21   01 01 00 12 02 06 00 00 00 00 03 04 C0 23 07 02 08 02   DD 94 7E
  2. 7E FF 03 C0 21   04 01 00 0A 05 06 65 67 6C 6A   60 85 7E
  3. 7E FF 03 C0 21   02 03 00 0E 02 06 00 00 00 00 07 02 08 02   14 BC 7E
  4. 7E C0 23   02 04 00 05 00   AA 5E 7E
  5. 7E 80 21   03 05 00 03 06 00 00 00 00   C6 A1 7E
  6. 7E 80 21   03 06 00 03 06 00 00 00 00   C1 77 7E
  7. 7E 02 10   10 10 00   4B B9 97
  8. 7E 80 21   03 07 00 03 06 B5 06 E6   85 83 7E
  9. 7E 80 21   02 08 00 03 06 B5 06 E6   8A 39 7E

Ulteriore decodifica

Pare che, terminata la negoziazione LCP, si possano “snellire” i pacchetti omettendo l’ “FF 03” iniziale (o 3f 03 in invio) e mettendo subito il protocollo; per qualche motivo questa centralina per i codici di protocollo usa “3f” al posto di “80”, quindi FORSE   3f21 sarebbe C021 (LCP, negoziazione iniziale) ,  3f23 sarebbe C023 (PAP, autenticazione), ma il 3f03 in riga 4 non so cosa sia, mi sa che è un errore e va tolto… quindi lo tolgo:

INVIO

  1. 3F 21   01 01 00 14      (richiesta LCP di 20 byte)
    • 02 06  00 00 00 00
    • 05 06  65 67 6C 6A
    • 07 02
    • 08 02
    • 3F 6D
    • 7E
  2. 3F 21   02 01 00 12    (risposta a richiesta LCP, 18 byte)
    • 02 06   00 00 00 00
    • 03 04   3F 23
    • 07 02
    • 08 02
    • 3F 3F
    • 7E
  3. 3F 23
    • 01 02 47 50 52 53 7E     –    Binario per “GPRS”???
  4. 3F 21   01 03 00 0E
    • 02 06 00 00 00 00
    • 07 02
    • 08 02
    • 2A 3F
    • 7E
  5. 3F 23   01 04    7E
  6. 3F 21   01 05    7E
  7. 3F 21   01 06 2F    7E
  8. 3F 21   01 07 03 06    7E
  9. 3F 21   02 01    7E
  10. 3F 21   01 08 3F 3F    7E
  11. 21 45   3F 04 5F 6E 3F 16 04 2D 07 3F 01 02 08 09 28 08 3F 61 7E
  12. 21 45   3F 04 5F 6E 3F 16 04 78 05 3F 01 01 04 02 6C 73 7E
  13. 21 45   30 3F 16 04 02 20 3F 3F 7E
  14. 21 45   7D 3F 04 5F 6E 3F 16 04 12 34 56 78 02 04 05 3F 01 01 04 02 4A 67 7E
  15. 21 45   6E 3F 16 04 70 02 20 3F 3F 7E
  16. 21 45   06 7B 3F 04 5F 6E 3F 16 04 12 34 56 78 7E
  17. 21 45   5F 6E 3F 16 04 04 02 3F 3F 7E
  18. 21 45   0B 3F 12 34 56 78 7E
  19. 21 45   04 5F 6E 3F 16 04 01 04 02 3F 3F 7E
  20. 21 45   3F 71 7E
  21. 21 45   3F 04 5F 6E 3F 16 04 3F 01 01 04 02 49 3A 7E
  22. 21 45   04 7E
  23. 21 45   74 3F 04 5F 6E 3F 16 04 78 05 3F 01 01 04 02 6F 2E 7E
  24. 21 45   30 3F 16 04 02 20 3F 7E

Ricezione

  1. 7E FF 03   C0 21   01 01 00 12    02 06 00 00 00 00     03 04 C0 23     07 02     08 02   DD 94 7E – Opzione 2: 0 0 0 0; Opzione 3 (protocollo): C0 23 (CHAP); Opzioni 7 e 8: default confermato
  2. 7E FF 03   C0 21   04 01 00 0A 05 06 65 67 6C 6A   60 85 7E
  3. 7E FF 03   C0 21   02 03 00 0E    02 06 00 00 00 00     07 02     08 02   14 BC 7E
  4. 7E   C0 23   02 04 00 05 00   AA 5E 7E
  5. 7E   80 21   03 05 00 03 06 00 00 00 00   C6 A1 7E
  6. 7E   80 21   03 06 00 03 06 00 00 00 00   C1 77 7E
  7. 7E   80 21 01 01 00 00   4B B9 97  (corretto a mano, forse mancava l’8)
  8. 7E   80 21   03 07 00 03 06 B5 06 E6   85 83 7E
  9. 7E   80 21   02 08 00 03 06 B5 06 E6   8A 39 7E

Eliminando quindi i marcatori di inizio e fine pacchetto, e l’FCS finale, e sostituendo il codice del protocollo col nome del protocollo, abbiamo:

  1. LCP 01 01 00 12   – Risposta a richiesta LCP:
    • 02 06   00 00 00 00 – Ok, opzione 02 va bene a 0 0 0 0
    • 03 04   C0 23 – Risposta a richiesta protocollo di autenticazione: C0 23, PAP
    • 07 02 – Ok, default accettato
    • 08 02 – Ok, default accettato
  2. LCP 04 01 00 0A – Configurazione richiesta non accettata, controproposta per opzione 5:  65 67 6C 6A
    • 05 06   65 67 6C 6A
  3. LCP 02 03 00 0E – Risposta a richiesta LCP n.03
    • 02 06 00 00 00 00
    • 07 02
    • 08 02
  4. CHAP 02 04 00 05 00
  5. IPCP  03 05 00 03 06 00 00 00 00
  6. IPCP  03 06 00 03 06 00 00 00 00
  7. IPCP  01 01 00 00
  8. IPCP   03 07 00 03 06 B5 06 E6
  9. IPCP   02 08 00 03 06 B5 06 E6

Esame di una negoziazione PPP di esempio raffrontata con quella registrata sulla centralina GSM

La MCU invia al G600 questa richiesta; il fatto che sia una richiesta si capisce dal primo “21” dopo “c0 21”, che si traduce in “01” e vuol dire appunto “richiesta”:

esempio: 7E FF 7D 23 C0 21 7D 21 7D 21 7D 20 7D 2E 7D 22 7D 26 7D 20 7D 2A 7D 20 7D 20 7D 23 7D 24 C0 23 F3 4D 7E – Config-Req

recmio:                                        7D 21 7D 21 7D 20 7D 32 7D 22 7D 26 7D 20 7D 20 7D 20 7D 20 7D 23 7D 24 C0 23 7D 27 7D 22 7D 28 7D 22 DD 94    (4 byte in più, in fatti la lunghezza è 0x32 invece che 0x2e)

Contenuto, eliminando header PPP/LCP, footer e 7D e sottraendo 0x20:

esempio: 01  01  00  0E    02  06  00  0A  00  00    03  04 C0 23 F3 4D  (lunghezza tot : 0x0e, dec 14; lunghezza 1: 6, payload = 0 0 0 0; lunghezza 2: 4, paylolad = C0 23)

recmio1:   01  01  00  12 0  2   06  00  00  00  00     03 04 C0 23   07 02   08 02   DD 94 (lunghezza tot: 0x12, dec 18; lunghezza 1: 6, payload= 0 0 0 0; lunghezza 2: 4, payload= C0 23; lunghezza 3: 2, payload vuoto (=default); lunghezza 4: 2, payload vuoto (=default))

recmio2: 04 01 00 0A 05 06 65 67 6C 6A 60 85  – Proposta rifiutata (cod. 04) e controproposta: opzione 05, payload 65 67 6C 6A

recmio3: 02 03 00 0E 02 06 00 00 00 00 07 02 08 02 14 BC – Proposta accettata, opzione 02 vale 0 0 0 0 , opzione 08 impostata a default.

 

Significato:

01 – Packet code: Configure request (direzione: uscita; la risposta ha codice 02)
01 – Packet identifier (a scelta dell’operatore)
000E – Packet length (14 caratteri)
The data field of the build request:
02 – Configuration option being configured; 02 =Asynchronous Control Character Mapping
06 – Length (02 06 00 0A 00 00)
00 0A 00 00 – Configuration value for ACCM
03– Configuration option being configured; 03=Type of authentication protocol
04 – Length (03 04 C0 23)
C023 – CHAP Certification agreement
F34D – FCS
7E – PPP Terminator Flag

 

Il G600 risponde con questo (il fatto che è una risposta è indicato dal valore “22” dopo C0 21, che va letto come  “02”):

7EFF7D23C0217D227D217D207D2E7D227D267D207D2A7D207D207D237D24C023CDCE7E LCP – Config-Ack

Senza intestazione, senza 7d e senza XOR 0x20:
02 01 00 0E 02 06 00 0A 00 00 03 04 C0 23 CD CE
Agree to the option to build a chain request.

02 – Configurazione ricevuta (e di seguito viene ripetuta)

 

MCU invia a G600:

7EFF7D23C0217D217D227D207D2A7D227D267D207D207D207D205FAD7E LCP – Config-Req

Senza intestazione, senza 7d e senza XOR 0x20:
01 02 00 0A 02 06 00 00 00 00 5F AD

CMNET’s build request.

Accettazione:

7EFF7D23C0217D227D227D207D2A7D227D267D207D207D207D2036D97E LCP – Config-Ack
Remove 7d:
02 02 00 0A 02 06 00 00 00 00 36 D9

——–

PAP (RFC1334)
PAP is a password authentication protocol, and its handshake process is consistent with the LCP protocol.
Config-Req
7E FF 03 C023 0100000D0753796E7269636800233C 7E – PAP – Config-Req
7E FF 03 C023 0200000D084C6F67696E204F4B3259 7E – PAP – Config-Ack

————-
IPCP (RFC1332)
The IPCP protocol is a process for obtaining an IP address from CMNET.

  1. Caso 1: IP dinamico
    >>>> 7E FF 03 8021  01 05  00 0A 03 06 00 00 00 00 F6 7D 37 7E – Codice 3: propongo IP 0.0.0.0, cioè chiedo un IP dinamico; la risposta è al punto 4, si riconosce dall’ID che è uguale a questo (05): il server propone un suo IP, il client lo ritrasmette per accettazione (punto 5) e il server lo re-invia per accettazione finale (punto 6).
  2. Caso 2: IP statico
    >>>> 7E FF 03 8021   01 01  00 0A 03 06 C0 C8 01 15   66 81 7E – Il client propone un suo IP prefissato (C0 C8 01 15, 192.200.1.15)
  3. <<<< 7E FF 03 8021   02 01 00 0A 03 06 C0 C8 01 7D 35 0F F5 7E – Il server accetta l’IP rispondendo con l’IP stesso, ma c’è un errore nel documento: il “15” finale è indicato col carattere di escape, quindi è diventato “7d 35”.
  4. <<<< 7E FF 03 80 21 03 05 00 0A 03 06 0A 67 CC A2 4C FF 7E – In risposta alla richiesta di IP dinamico, il server ne propone uno:  0A 67 CC A2  (10.103.204.162)
  5. >>>> 7E FF 03 80 21 01 05 00 0A 03 06 0A 67 CC A2 02 A7 7E – Il client ritrasmette l’IP in segno di accettazione.
  6. <<<< 7E FF 03 80 21 02 05 00 0A 03 06 0A 67 CC A2 6B D3 7E – Il server ri-ritrasmette l’IP per conferma finale.

 


Significato “command code” o “packet code” (v. anche link)

  • 01 Configure-Request
  • 02 Configure-Ack
  • 03 Configure-Nak
  • 04 Configure-Reject
  • 05 Terminate-Request
  • 06 Terminate-Ack
  • 07 Code-Reject
  • 08 Protocol-Reject
  • 09 Echo-Request
  • 10 Echo-Reply
  • 11 Discard-Request

Elenco protocolli (evidenziati quelli più usati)

  • 00 21 – Internet Protocol (IP)
  • C0 21 – Link Control Protocol (LCP)
  • C0 23 – Password Authentication Protocol (PAP)
  • C2 23 – Challenge Handshake Authentication Protocol (CHAP)
  • 80 21 – IP Control Protocol  (da non confondere con “IP” semplice! )
  • 80 29 – Appletalk Protocol
  • 80 2B – Novell’s Internetwork Packet Exchange (IPX)
  • 80 31 – Bridging PDU
  • 80 FD – Compression Control Protocol (CCP)

 

Scopo dei protocolli:

Link Control Protocol (LCP) checks among other things the condition of the line by sending a large (4 byte-hex) randomly chosen number (Magic Number) which needs to be returned by the receiving part.

Password Authentication Protocol (PAP) or Challenged Authentication Protocol (CHAP) checks the password either sent in clear (PAP) or encrypted (CHAP).

Internet Protocol Control Protocol (IPCP) is utilized to assign an IP address to the PC, to determine if compression will be used and to setup the configuration of the packets
encapsulated within PPP frames.

Nota: l’IPCP non è l’IP: con l’IPCP si stabilisce qual è l’indirizzo da usare per il protocollo IP.


Opzioni LCP configurabili (RFC 1661)

  • 01 – Dimensioni massime pacchetto
  • 03 – Protocollo di autenticazione (PAP oppure CHAP)
  • 04 – Link quality protocol
  • 05 – Magic number – Usato per verificare che durante la trasmissione i dati non siano alterati
  • 07 – Protocol field compression
  • 08 – Address and control field compression

Opzioni protocollo IPCP

0x03: Negoziazione indirizzo IP  (http://www.uniroma2.it/didattica/netsec/deposito/1_ppp.pdf , pag. 38)

Statico: client comunica il suo IP e server conferma

Dinamico: client invia IP 0.0.0.0 e server invia rifiuto (nack) e propone IP; client allora invia richiesta con l’IP appena ricevuto, e server accetta (ack).

Tutte:

1 IP-Addresses (deprecated). RFC 1332
2 >= 14 IP-Compression-Protocol. RFC 1332RFC 3241RFC 3544
3 6 IP-Address. RFC 1332
4 6 Mobile-IPv4. RFC 2290
129 6 Primary DNS Server Address. RFC 1877
130 6 Primary NBNS Server Address. RFC 1877
131 6 Secondary DNS Server Address. RFC 1877
132 6 Secondary NBNS Server Address. RFC 1877
Tagged with: , , , ,

Hacking Icaro: centralina GSM/GPS – puntata 1 (3/3/2019)

Posted in hacking, hardware, minicar elettriche by jumpjack on 10 marzo 2019

L’anno scorso ho provato a smontare ed esaminare la centralina GPS/GSM che rende(va) la Icaro (o meglio i.car.0) una “interconnected car”, inviando a una centrale di monitoraggio remoto decine e decine di telemetrie, come descritto in questo thread:

https://www.forumelettrico.it/forum/centralina-gsm-gps-t2437.html

Alcune foto della centralina.

Qui si vede il contenitore dell SIM card e un connettore a pettine a 12 pin:

Questo è il modulo GPS, un “GA71 V4.0 SiRF star III” a 20 canali:

 

Alcune marcature utili per l’identificazione:

Visione d’insieme; in alto la batteria-tampone ricaricabile al NiMH da 3.6V:

Questi pin, apparentemente interessanti… si sono rivelati completamente muti e inutili:

 

 

Quelli che invece si sono rivelati molto interessanti sono quelli dello strip maschio a 12 pin: collegandolo a un adattatore TTL/seriale per il PC, sono riuscito a dare una sniffata, scoprendo questo:

Per il momento non sono riuscito ad agganciare la rete, nemmeno togliendo la SIM originale e mettendo la mia, ma farò ovviamente altre prove.

Probabilmente, infatti, solo una volta che la scheda riesce ad agganciare la rete fa un tentativo di agganciarsi ai server remoti che un tempo leggevano queste telemetrie; bisogna vedere poi:

  • se la scheda aspetta una risposta dal server prima di inviare dati, o se li invia “a fondo perduto”
  • se è possibile riprogrammare a mano l’indirizzo a cui la scheda tenta di collegarsi
  • varie ed eventuali

Comandi AT:

Diario elettrico GreenGo Icaro – La manopola del volume

Posted in Diario elettrico GreenGo Icaro, hacking, hardware, minicar elettriche, Uncategorized by jumpjack on 26 gennaio 2019

Primo prototipo: gennaio 2019

Ho finalmente applicato una nuova modifica per migliorare la sicurezza dell’auto: lo spostamento dei comandi dell’autoradio.

In origine la manopola di accensione e del volume si trova tra i pulsanti del cambio; il che vuol dire che si rischia di mettere in folle mentre si guida, tentando di alzare il volume… Un’assurdità.

Così ho comprato un encoder per pochi euro, una manopola per ancora meno euro, ci ho attaccato 4 fili et voila. 🙂

In questa foto apparentemente non si vede niente… ma solo perchè la modifica è molto pulita: semplicemente, al posto della terza manopola, che nel mio modello A1 è finta perchè non è presente l’aria condizionata, ho messo una manopola vera, che dietro è collegata a un encoder con interruttore, avvitato a una tavoletta di compensato che a sua volta è avvitata al cruscotto:

Poi basta allungare i fili che normalmente vanno alla manopola originale, e farli arrivare invece a questa…

Spiegazione morsetti dell’encoder: http://henrysbench.capnfatz.com/henrys-bench/arduino-sensors-and-input/keyes-ky-040-arduino-rotary-encoder-user-manual/

Fin qui si tratta del primo prototipo, realizzato a gennaio; funzionava abbastanza  bene, ma con due difetti minori:

  1. La manopola era un po’ “ballerina”, perchè il perno del decoder era troppo corto per spuntare dalla plastica, quindi ho dovuto fargli una prolunga stampata in 3d, che non è molto precisa, quindi la manopola ha un po’ di gioco.
  2. Per qualche strano motivo, in certe situazioni imprecisate quando alzo il volume, si sente un “bip” e il tablet cambia schermata! Altre volte la radio inizia ad aumentare di volume in modo incontrollabile senza che io tocchi niente.

Il secondo problema mi ha costretto ad aspettare “tempi migliori” prima di pubblicare ufficialmente questo post, per aver tempo di individuare il problema. Poi l’auto è stata in officina per 3 mesi e mezzo… e tra una cosa e l’altra siamo arrivati a giugno.

Versione 2: giugno 2019

In base a quanto descritto nel punto due qui sopra, ho pensato che ci fosse un problema di falso contatto, che in termini elettronici si traduce in resistenza spuria. Ma in teoria un encoder non dovrebbe contenere nessuna resistenza, essendo composto semplicemente di 3 interruttori: due che servono a determinare il verso di rotazione, e un terzo è collegato alla pressione dell’alberino rotante. Comunque ho deciso di fare alcune prove collegando resistenze di valori diversi ai PIN a cui è collegato l’encoder, iniziando dal quello collegato all’interruttore a pressione, e in effetti ho avuto conferma dei miei sospetti. Ecco infatti la lista degli effetti che ho rilevato sul tablet collegando ai due PIN diversi valori di resistenza; tutti i valori sono espressi in kOhm:

  1. 0-0.3 (0-300 ohm): on/off
  2. 0.5-0.9 (500-900 ohm): Home page
  3. 1.9-2.0: Radio giù
  4. 2.0-3.9: Radio su
  5. 3.5-4.5: Cambio banda AM/FM
  6. 4.8-6.5: modalità (musica, film, aux)
  7. 6.8-8.4:  mute
  8. 8.4-17: funzioni non chiare
  9. 17-20: volume su
  10. 22-28: volume giù
  11. 40-70: Navigatore
  12. 100: Telefono

Ovviamente non si tratta di valori precisi ma di intervalli di valori, all’interno dei quali deve cadere la resistenza di valore standard che si utilizza. I valori sono i seguenti:

In base a questa tabella, i valori da usare per attivare le funzioni sopra descritte sono:

  1. On/off: nessuna resistenza
  2. Home page: 560/680/820 ohm
  3. Radio giù: 1.8 K
  4. Radio su: 2.2 K
  5. Cambio banda AM/FM: 3.9 K
  6. Modalità (musica, film, aux): 5.6 K
  7. Mute: 8.2 K
  8. 8.4-17: funzioni non chiare
  9. Volume su: 15 K
  10. Volume giù: 22/27 K
  11. Navigatore: 47/56/68 K
  12. Telefono: 100 K

Sono poi andato a esaminare più da vicino l’encoder e mi sono accorto di una grossa svista: non si tratta di un encoder semplice; è invece collegato ad alcune resistenze di polarizzazione da 1 kOhm:

Quindi erano queste che probabilmente facevano scattare in certe posizioni della manopola le funzioni del tablet; così ho rimosso del tutto l’encoder dal suo PCB e l’ho collegato direttamente al tablet. Per predisporre il lavoro a modifiche successive ho collegato, piuttosto che dei fili volanti, una serie di morsetti; al tablet ho collegato un morsetto femmina a 4 pin, in modo che sia più facile fare le prove successive con resistenze provvisorie volanti; ho poi collegato un morsetto maschio all’encoder, dopodichè ho praticato dei fori negli spazi vuoti della pulsantiera degli specchietti, per implementare le nuove funzioni:

 

 

Come connettori ho usato quelli che ho imparato a conoscere sull’Ecojumbo: impermeabili e a prova di  disconnessione, grazie  a un  sistema  di  aggancio  a molla:

Ho collocato i due nuovi pulsanti in una zona libera della pulsantiera degli specchietti:


I due pulsanti rossi servono ad alzare ed abbassare la frequenza di sintonia; il pulsante quadrato nero al momento, giusto per prova, attiva il navigatore, che però non è molto utile se lo schermo non funziona perchè non posso impostare la destinazione; vorrei invece fare in modo che attivasse direttamente la telecamera di retromarcia che ho installato e che normalmente richiede diversi clicchi sul touch screen per essere attivata. Se invece potessi attivarla al volo con un pulsante sarebbe molto più comodo.

La manopola questa volta l’ho fissata in modo diverso e più stabile: usando un piastrino di plexglass abbastanza sottile da entrare nell’incavo della plastica, rendendo così non necessaria la prolunga stampata in 3d; per tenerlo in posizione ho aggiunto due viti. Il lavoro resta comunque abbastanza pulito:


“Pulito” finchè non metto i fili; una volta saldati al decoder, la faccenda si fa più complessa…

 

Sul tablet c’è anche una schermata che permetterebbe di assegnare delle funzioni ai pulsanti al volante… anche se di pulsanti al volante nella Icaro non ce ne sono. Comunque la schermata del tablet è questa:

Come si vede, molte delle funzioni che ho scoperto sono proprio elencate in questa schermata; purtroppo aggiungere dei pulsanti al volante non è possibile perché l’unico filo che arriva dentro al volante è quello del clacson, e per portare altri fili l’unico modo sarebbe usare un particolare interruttore a strisciamento che permette al volante di girare senza interrompere i contatti; c’è già un meccanismo di questo tipo sulla Icaro, ma soltanto uno dei 5 pin è popolato, e aggiungere nuovi fili sarebbe un lavorone perché dovrei smontare lo sterzo e quindi non se ne parla. Però Se riesco effettivamente a trovare altre funzioni attivabili senza touchscreen potrei comunque realizzare un tastierino esterno per attivarle.

 

Di seguito  le altre foto che ho fatto lavorando al progetto: