Jumping Jack Flash weblog

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 1332, RFC 3241, RFC 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: , , , ,

12 comments