Magellan Maestro

Maestro 4040 Box
Image obtained from http://www.gpsmagazine.com/
2007/04/review_magellan_maestro_4040.php#2

For my introductory blog, I would like to present some information I recently learned about the Magellan Maestro 4040 Global Positioning System (GPS).  I will not be discussing how or when the items arrived on the GPS, but rather my observations and analysis of the data structures.

The GPS had been processed using several of the popular tools on the market today such as Micro Systemation's XACT/XRY and Cellebrite's UFED Physical Analyzer.  While some historical data was recovered during this initial processing, the tool-generated reports contained no dates to correlate when the subject of the investigation was at the particular points recovered from the GPS.  As a timeline was important to the client, a forensic image of the device was obtained with AccessData's FTK Imager in order to determine if dates and times could manually be parsed.

In an attempt to gain a starting point, I tried searching the Internet for articles related to Magellan GPS Forensics.  Ultimately, with the exception of several vendor sites stating support for Magellan GPS devices, I only found a single resource:  http://www.forensicswiki.org/wiki/Global_Positioning_System#Magellan.  This site was very helpful in providing a starting point listing three files in particular that I will discuss throughout this article:

• /Sys/USBTRANS/Unit_ID.dat
• /USR/TGUSERA.dat
• /USR/CITYHIST.dat

Having a starting point, I reached out to several colleagues to discuss their experience with the Magellan devices.  All of them gave me similar responses: the tools on the market supported the Magellan devices only on a limited basis due to anomalies with the file system.  What that actually means, I do not know.  Perhaps the file structure changes so significantly between models that it is not practical to support them.  While I am curious, the point is the tools we used did not obtain date/time information and now it is my turn.

The first file, Unt_ID.dat, was in plain text and, as described on the wiki, contained information about the make, model, and operating system.  It was easy to confirm the data from this file made its way into the tool-generated reports.

The second file, TGUSERA.dat, provided more of a challenge.  As pointed out on the wiki and by my colleagues, there was data available in plain text.  This easily read data is really the meat and potatoes.  While not all of the following data was available in each record, it was easy to read items such as:

• The name given to the point of interest
• The street address
• The city
• The State
• The ZIP Code
• The telephone number for the point

This is all good and well, but my task was incomplete as no dates were readily seen; additionally, I noticed I wasn't seeing coordinates as I would expect from a GPS.  Thus, my search continued.  By comparing the records to each other as well as to the XRY report, I was able to determine the data in the following tables.  While I was satisfied with the results, there were several chunks of data of which I was unable to determine the significance.  I reach out to the community to share your experience and help fill in this missing data.

Offset	Length	Description	Data
0	2	Magic Number	0x 02 00
2	2	Unknown	0x 00 00
4	4	Unknown	0x 08 00 00 00
8	4	File Size Excluding:  File Header and File Footer
12	4	Unknown	0x 04 AB 04 00

Table 1.  TGUSERA.DAT File Header

The two bytes identified as the magic number also appear to serve as the file footer as the two bytes are repeated at the offset from the header specified at offset eight of the header.  

Offset	Length	Description*	Data
0	4	Unknown	Varies
4	4	Type	[See Table 3]
8	2	Unknown	Varies  0x FF FF indicates deleted or unused record.
10	2	Unknown	Appears to be 0x 00 00 except for in unused records.  Unused records contain 0x FF FF.
12	4	Longitude	32-bit Signed Integer
16	4	Latitude	32-bit Signed Integer
20	4	Unknown	Varies
24	4	Longitude	32-bit Signed Integer
28	4	Latitude	32-bit Signed Integer
32	4	Unknown	Always 0x 00 00 00 00
36	48	Name	Name
84	64	Street	Street or Latitude in ASCII
148	48	Longitude	In ASCII
196	48	Region	City
244	48	City	State
292	20	ZIP	ZIP code
312	69	Unknown	Always all 0x 00
381	99	Work	Phone number in ASCII padded with 0x 00

* The description is based on the how the tool-generated report identified the data.

Table 2.  TGUSERA.DAT Record Format

Data (0x)	Description*
00 80 00 00	Recent
00 40 00 00	Favorite
00 08 00 00	Home
00 00 00 00	None

* The description is based on the how the tool-generated report identified the data.

Table 3.  TGUSERA.DAT Record Type

While the first four bytes are marked as unknown, they did show an interesting pattern.  The bytes appear as some sort of an offset.  While the records containing data did not show a sequential order, blank records towards the end of the file had data in these four bytes which when converted to decimal incremented by 480 bytes, the size of the observed records.

A shift was noted at record 1300.  The 480-byte increments changed to 424 bytes for the remainder of the blank records.  The reason for this shift is unknown.  As the GPS being analyzed did not have data within these records, no additional analysis was performed on this issue.

Thus far all data has been parsed, at least to the caliber of the tool-generated report.   Upon reviewing my results, I did notice that I parsed 10 records less than the tool-generated report.

These 10 additional records appear to have come from the third file, CITYHIST.dat.  Again, I compared the contents of the file to itself as well as to the tool generated report and was able to come up with the following structure.

Offset	Length	Description	Data
0	2	Magic Number	0x 99 00
2	2	Unknown	0x 00 00
4	4	Unknown	0x 02 00 00 00
8	4	File Size Excluding:  File Header and File Footer
12	4	Unknown	0x 08 E6 9A 00

Table 4.  CTYHIST.DAT File Header

Note that the header appears identical in structure to the header of TGUSERA.dat.  Again the two bytes identified as the magic number also appear to serve as the file footer as they are repeated at the offset from the header specified at offset eight of the header.  

Offset	Length	Description*	Data
0	4	Unknown	Varies 0x 00 00 00 00 was observed for all records except the first record after the header which had 0x 0A 00 00 00
4	48	City	City
52	48	Region	State
100	48	Suggestions
148	20	ZIP	ZIP code
168	4	Unknown	Either 0x 01 00 00 00 or 0x 00 00 00 00

* The description is based on the how the tool-generated report identified the data, with the exception of “Suggestions”

Table 5.  CTYHIST.DAT Record Format

Only one record in the analyzed CTYHIST.dat file contained data in the suggestion field.  It should also be noted that the record containing suggested data is the only record containing 0x 01 00 00 00 in the final four bytes of the record.  This may indicate that the last four bytes are used to indicate the presence of suggested points or the number of suggested points.  Without additional examples to analyze, this cannot be confirmed.

As you can see, there is definitely a structure present.  It can also be seen that I was unable to determine anything more than what the automated tool had already parsed for me.  Despite not finding the requested date/time information and only obtaining data that the tool already provided, I enjoyed getting into the file structure and learning what the tool was doing and from where it pulled the data.

To assist in parsing the data, I have included a WinHex template for both the TGUSERA.DAT and CTYHIST.DAT files.  Copy the text, paste it into Notepad, and save it with a .tpl file extension in your WinHex directory.  Feel free to use and/or alter as needed.  

//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

template "Magellan TGUSERA"

description "Parses TGUSERA.DAT File"

read-only

fixed_start 0x10

multiple

//Parsed the /Usr/TGUSER.DAT file from a Magellan Maestro 4040 GPS

//with results confirmed by XRY Report.

//Types:

//             0x0080  Recent

//             0x0040  Favorite

//             0x0008  Home

//             0x0000  None

//Record_Number was noted not to be distinct and therefore may not

//actually represent a record number.  0xFFFF = Deleted Record.

//Bytes which were observed as always 0x00 have been commented out

//and skipped in the template.

// header and footer appear to be 0x0200

//             hex 2      "Magic Number"

//             move 2

//             hex 4      "unknown"

// May be a record length designator?

//             hex 4      "Data Size w/o Header/Footer"

//             hex 4      "unknown"

begin

                hex 4      "unknown"

// Appears to be an offset.  Empty Records at end of file increase by 480

// bytes, the size of each record.  Shift in record size midway through

// file to 424 bytes.

                hex 2      "Type"

//             hex 2      "unknown"

                move 2

                hex 4      "unknown"

                int32       "Longitude"

                int32       "Latitude"

                hex 4      "unknown"

                int32       "Longitude"

                int32       "Latitude"

//             hex 4      "unknown"

                move 4

                char[48] "Name"

                char[64] "Street"

                char[48] "Longitude"

                char[48] "Region"

                char[48] "City"

                char[20] "Zip"

//             hex 69    "unknown"

                move 69

                char[99] "Work"

end

 //////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

template "Magellan CTYHIST"

description "Parses CTYHIST.DAT File"

read-only

fixed_start 0x14

multiple

//Parsed the /Usr/CTYHIST.DAT file from a Magellan Maestro 4040 GPS

//with results confirmed by XRY Report.

// header and footer appear to be 0x9900

//             hex 2      "Magic Number"

//             move 2

//             hex 4      "unknown"

// May be a record length designator?

//             hex 4      "Data Size w/o Header/Footer"

//             hex 4      "unknown"

begin

                hex 4      "Unknown"

                char[48] "City"

                char[48] "State"

                char[48] "Suggestions"

                char[20] "Zip"

//             hex 4      "unknown"

                move 4

end

 //////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

Still to be done:

• The above analysis used a single device for analysis.  While I was able to obtain the same data the automated tool could retrieve, having the opportunity to compare the structure with additional Magellan GPS devices would further verify the structure.

I do apologize for releasing unpolished analysis, but as the odds of me receiving another Magellan GPS for analysis in the near future are pretty slim, I thought it best to get the information out there for review in hopes that the next time someone needs to analyze a Magellan GPS, the information presented within this blog will prove helpful.

If you can fill in some of the blanks, find this data helpful, or just want to share your experience, please leave a comment below.