Research Pre GSM Modem Protocol - Revision history

Morphis: Add more information about the frame header and first implementation of the protocol

2009-11-11T21:03:26Z

Add more information about the frame header and first implementation of the protocol

2009-11-10T22:08:44Z

Escaping

2009-11-10T22:08:00Z

2009-11-10T22:07:13Z

2009-11-09T05:23:26Z

A short mention of GPS functionality over the same protocol

2009-11-09T05:13:07Z

Added what seems to be the PIN entry sequence

2009-10-24T09:30:50Z

Add HDLC+PPP usage

2009-10-21T18:25:55Z

2009-10-21T18:12:39Z

Add assume about 0xfa as non-starting-flag

2009-10-20T22:57:57Z

Checksum

@@ Line 2: / Line 2: @@
 What we are doing to get used to the protocol is to strace the different applications that talk to the modem and log everything that goes over /dev/modemuart to the actual modem. From this wire protocol traces we are working backwards to the actual protocol and packet format.
 === Packet Start ===
@@ Line 19: / Line 26: @@
 === Header ===
-No informations about the header format have been gathered yet.
+Header consists of 3 bytes. The first byte seems to be an adress or something like that, cause it's everytime the same byte '''0xFA'''.
 === Payload ===
@@ Line 34: / Line 54: @@
 http://tools.ietf.org/html/rfc1662
 === Identified byte sequences ===

@@ Line 15: / Line 15: @@
 === Escaping ===
-For the packet end marker there is an escaping sequence inside the packet. It is used '''0x7D 0x5E''' instead. Therefor '''0x7D''' is escaped as '''0x7D  0x5D''' as well.
+For the packet end marker there is an escaping sequence inside the packet. It is used '''0x7D 0x5E''' instead. Therefore '''0x7D''' is escaped as '''0x7D  0x5D''' as well.
 === Header ===

← Older revision		Revision as of 22:08, 10 November 2009
Line 1:		Line 1:
−	Here we are collecting informations about the modem protocol. At the moment all the research is done on the european UMTS version of the Palm Pre. The ~~CDM~~ version is likely to be pretty similar to the UMTS variant with regards to the protocol.	+	Here we are collecting informations about the modem protocol. At the moment all the research is done on the european UMTS version of the Palm Pre. The CDMA version is likely to be pretty similar to the UMTS variant with regards to the protocol.

	What we are doing to get used to the protocol is to strace the different applications that talk to the modem and log everything that goes over /dev/modemuart to the actual modem. From this wire protocol traces we are working backwards to the actual protocol and packet format.		What we are doing to get used to the protocol is to strace the different applications that talk to the modem and log everything that goes over /dev/modemuart to the actual modem. From this wire protocol traces we are working backwards to the actual protocol and packet format.

← Older revision		Revision as of 22:07, 10 November 2009
Line 1:		Line 1:
−	Here we are collecting informations about the modem protocol. At the moment all the research is ~~don~~ on the european UMTS version of the Palm Pre. The CDM version is likely to be pretty similar to the UMTS variant with regards to the protocol.	+	Here we are collecting informations about the modem protocol. At the moment all the research is done on the european UMTS version of the Palm Pre. The CDM version is likely to be pretty similar to the UMTS variant with regards to the protocol.

	What we are doing to get used to the protocol is to strace the different applications that talk to the modem and log everything that goes over /dev/modemuart to the actual modem. From this wire protocol traces we are working backwards to the actual protocol and packet format.		What we are doing to get used to the protocol is to strace the different applications that talk to the modem and log everything that goes over /dev/modemuart to the actual modem. From this wire protocol traces we are working backwards to the actual protocol and packet format.

← Older revision		Revision as of 05:23, 9 November 2009
Line 44:		Line 44:
	* SIM PIN on startup is sent with: 0xfa 0x60 0xe3 0x0f 0x0e 0x00 0x13 0x00 0x00 0x00 0x00 <4 ASCII digits> 0x00 0x00 0x00 0x00 0x00		* SIM PIN on startup is sent with: 0xfa 0x60 0xe3 0x0f 0x0e 0x00 0x13 0x00 0x00 0x00 0x00 <4 ASCII digits> 0x00 0x00 0x00 0x00 0x00
	* SIM PIN acknowledgement from modem: 0xfa 0x50 0x0f		* SIM PIN acknowledgement from modem: 0xfa 0x50 0x0f
		+
		+	=== GPS ===
		+	The [[GPS]] receiver is part of the modem in Palm Pre and all data received and sent related to location goes over the same port using the same frame coding as GSM. GPS functionality can not be enabled (at least not using the Palm-provided drivers) until modem radio is enabled and seemingly until the modem successfully registers to the network.
		+
		+	Tracing the data sent over /dev/modemuart the following hostnames can be seen being sent from the OS to the modem chip:
		+	xtra1.gpsonextra.net, xtra2.gpsonextra.net, xtra3.gpsonextra.net
		+
		+	They point to the RX Network's company website (rxnetwork.ca) that claims to provide better geolocation by combining GPS, wifi signals, GSM CellID and live reports downloaded over GPRS. The modem downloads the following files:
		+	http://xtra1.gpsonextra.net/xtra.bin, http://xtra2.gpsonextra.net/xtra.bin, http://xtra3.gpsonextra.net/xtra.bin

← Older revision		Revision as of 05:13, 9 November 2009
Line 42:		Line 42:
	* Configuration Response Message: 0xfa 0x40 0x0		* Configuration Response Message: 0xfa 0x40 0x0
	* Acknowledge Message: 0xfa 0x50 0x0		* Acknowledge Message: 0xfa 0x50 0x0
		+	* SIM PIN on startup is sent with: 0xfa 0x60 0xe3 0x0f 0x0e 0x00 0x13 0x00 0x00 0x00 0x00 <4 ASCII digits> 0x00 0x00 0x00 0x00 0x00
		+	* SIM PIN acknowledgement from modem: 0xfa 0x50 0x0f

@@ Line 31: / Line 31: @@
 === Similarity to RFC1662 ===
-The usage of CRC-16-FCS but even more the frame boundary packet as well as the escaping for it looks similar to what we found about this protocol.
+The usage of CRC-16-FCS but even more the frame boundary packet as well as the escaping for it looks similar to what we found about this protocol. Even a grep -i HDLC over the binary firmware image reports the usage of PPP and HDLC as communication protocol format. So we can be almost sureley that HDLC+PPP is used.
 http://tools.ietf.org/html/rfc1662

← Older revision		Revision as of 18:25, 21 October 2009
Line 34:		Line 34:

	http://tools.ietf.org/html/rfc1662		http://tools.ietf.org/html/rfc1662
		+
		+	=== Identified byte sequences ===
		+	* Sync Message: 0xfa 0x10 0x0
		+	* Sync Response Message: 0xfa 0x30 0x0
		+	* Configuration Message: 0xfa 0x30 0x00 0x1
		+	* Empty Configuration Message: 0xfa 0x40 0x0
		+	* Configuration Response Message: 0xfa 0x40 0x0
		+	* Acknowledge Message: 0xfa 0x50 0x0

@@ Line 5: / Line 5: @@
 === Packet Start ===
-A new packet starts with: '''0xFA''' (This may be an address instead as rfc1662 uses only one flag for frame separation)
+A new packet starts with: '''0xFA''' (This may be an address instead as rfc1662 uses only one flag for frame separation).
 === Packet End ===

@@ Line 25: / Line 25: @@
 === Checksum ===
-The last two(?) bytes before the packet ending marker seem to be a CRC16 checksum. For now we think it is the CRC-16-CCITT variant.
+The last two bytes before the packet ending marker are a CRC16-FCS checksum. (See rfc1662 for polynom and table)
 === Similarity to RFC1662 ===