Jumping Jack Flash weblog

Hacking Icaro GSM (puntata 3)

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: , , , ,

Ancora sull’hacking della centralina GSM/GPS/GPRS Greengo Icaro / Zhidou ZD

Posted in hardware by jumpjack on 16 marzo 2019

Puntata precedente: https://jumpjack.wordpress.com/2019/03/10/esame-della-centralina-gsm-gps-greengo-icaro/

Sostituendo la SIM originale della movistar con una generica SIM Wind, sono riuscito ad ottenere l’aggancio alla rete GPRS!

Purtroppo il comando di connessione non è molto chiaro:

AT+CGDCONT=1,”IP”,”%1?….4.?..b#”

Il terzo parametro dovrebbe essere l’indirizzo IP dell’APN dell’operatore…. ma sembra scritto in codice binario invece che come stringa, quindi non si capisce a chi tenti di collegarsi.

In binario: 25 31 3F 10 10 06 04 34 07 3F 01 02 62 23

La buona notizia è che però a questo comando della MCU, e al successivo ATD*99***1# ,  il modulo GSM risponde con CONNECT, quindi l’aggancio avviene di sicuro.

…dopodichè non si capisce più niente: tutta la comunicazione passa da testuale (comandi AT) a binaria!

Leggendo come testo quello che la MCU invia al modem… si vede questo:


~?}#?!

}!}!} }4}"}&} }

 } } }%}&eglj}'}

"}(}"?m~

~?

}#?!}"}!} }2}"}&

} } } } }#}$?#}

'}"}(}"??~

~?#GPRS~?}#?!}!}#

} }.}"}&} } } }

 }'}"}(}"*?~

~?#~

~?!~?!/~

~?!~?!~?!??~

~!E?

_n?-? (?a~

~!E

?

_n?x?ls~

~!E0? ??~

~!E

}]

?

_n?4Vx?Jg~

~!En?p ??~

~!E

{

?

_n?4Vx~!

E_n???~

~!E?4Vx~

!E

_n???~

~!E?q~!E?

_n??I:~

~!E~

~!Et

?

_n?x?o.~

~!E0? ?~

Espresso in esadecimale non è che sia molto più chiaro…:
7E3F7D233F21
7D217D217D207D347D227D267D207D
207D207D207D257D2665676C6A7D277D
227D287D223F6D7E
7E3F
7D233F217D227D217D207D327D227D26
7D207D207D207D207D237D243F237D
277D227D287D223F3F7E
7E3F230102475052537E3F7D233F217D217D23
7D207D2E7D227D267D207D207D207D
207D277D227D287D222A3F7E
7E3F2301047E
7E3F2101057E3F2101062F7E
7E3F21010703067E3F2102017E3F2101083F3F7E
7E21453F04
5F6E3F16042D073F0102080928083F617E
7E2145
3F04
5F6E3F160478053F010104026C737E
7E2145303F160402203F3F7E
7E2145
7D5D
3F04
5F6E3F1604123456780204053F010104024A677E
7E21456E3F16047002203F3F7E
7E214506
7B
3F04
5F6E3F1604123456787E21
455F6E3F160404023F3F7E
7E21450B3F123456787E
214504
5F6E3F16040104023F3F7E
7E21453F717E21453F04
5F6E3F16043F01010402493A7E
7E2145047E
7E214574
3F04
5F6E3F160478053F010104026F2E7E
7E2145303F160402203F7E
Tutta roba incomprensibile, però qui c’è qualche indizio su cui investigare:
https://www.embeddedrelated.com/showthread/comp.arch.embedded/40457-1.php
Potrebbe cioè trattarsi di una comunicazione su protocollo PPP; devo quindi o studiarmi il protocollo a basso livello, o trovare un decodificare automatico.

Questo è invece quello che risponde il modem subito dopo aver risposto CONNECT:
~ÿ}#À!}!}!} }2}"}&} } } } }#}$À#}'}"}(}"Ý”~~ÿ}#À!}$}!} }*}%}&eglj`…~~ÿ}#À!}"}#} }.}"}&} } } } }'}"}(}"}4¼~~À#
In hex:

7EFF7D23C0217D217D217D207D327D227D267D207D207D207D207D237D24C0237D277D227D287D22DD947E7EFF7D23C0217D247D217D207D2A7D257D2665676C6A60857E7EFF7D23C0217D227D237D207D2E7D227D267D207D207D207D207D277D227D287D227D34BC7E7EC0230204000500AA5E7E7E8021030500
030600000000C6A17E7E8021030600
030600000000C1777E7E802101010004BB997E7E8021030700
0306
B506E685837E7E8021020800
0306
B506E68A397E

Tutto questo avviene al banco, con la centralina scollegata dalla icaro.


Alcuni link utili:
Protocollo PPP:
http://www.powerfast.net/maxtnt/~ascend/MaxTNT/admin/ppprime.htm
http://www.netfor2.com/ppp.htm
Decoder:
https://hpd.gasmi.net/  – hex decoder generico – 1
http://packetor.com/ – hex decoder generico – 2

 

Tagged with: , , , ,

Esame della centralina GSM/GPS GreenGo Icaro

Posted in hacking, hardware 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: il vano motore

Posted in Diario elettrico GreenGo Icaro, minicar elettriche by jumpjack on 24 febbraio 2018

In attesa di trovare un’assicurazione economica, non potendo usare la Icaro passo il tempo a esaminarla.

Ecco una foto commentata del vano motore:

Invece nell’abitacolo ci sono diverse “centraline”, su cui sto indagando e un riscaldatore:

Una delle centraline dovrebbe essere quella predisposta per il controllo da remoto tramite GSM dello stato delle batterie (e di chissà cos’altro…), ma mi dicono che non è stato implementato o che è stato dismesso. Quindi devo riuscire a metterci le mani dentro. 🙂

 

Nei prossimi giorni dovrò andare a far sostituire (gratuitamente) il computer di bordo che gestisce autoradio e gps perchè ha il touchscreen difettoso, come mi aveva detto il venditore. Però pare che l’abbia già sostituito due volte…

Altra cosa strana è che il navigatore chiede di inserire una SD card… ma non c’è nessuno slot SD card visibile.

Peccato perchè pare che il computer di bordo permetta anche di riprodurre musica e video!

Indagherò.

 

Intanto, questi sono i dati di motore e centralina:

Motore brushless

  • XDY Electric Manufacturing Co. Ltd
  • BLDC/6kW-3500-72
  • 6kW – potenza
  • 3500 rpm – regime potenza max
  • 72V – tensione
  • 91A – ampere continui
  • cI: F   ?
  • IP56 – grado protezione acqua/polvere
  • Conn: Y – tipo connessione bobine
  • Ph: 3 – numero di fasi

Il motore potrebbe essere uno di questi della Shandong DeYang electronic , oppure della XinDaYang, che però sembra fare solo motori per scooter, boh?

Però forse è la stessa cosa: il sito XDY dice:

Five subsidiaries

  • Taizhou XINDAYANG Electric Bike CO., Ltd
  • Taizhou XINDAYANG Mould CO., Ltd
  • Shandong XINDAYANG Mechanical & Electrical Technology Co., Ltd
  • Shandong Deyang electronics technology Co., Ltd
  • Tianjin XINDAYANG Mould Co., Ltd      

 

 

Centralina:

  • W11-2108110-00
  • 20140520/y01r03G
  • 14100172-KHB72701C

E’ nientemeno che una Kelly riprogrammabile tramite porta seriale!

http://kellycontroller.com/khb7270124-72v700aopto-bldc-controllerwith-regen-p-838.html

E supporta anche il regen. Se è abilitato o no sulla mia, devo ancora verificarlo.

 

Tagged with: , , , , ,