PARSING THE CHAT LOGS FOR GIGATRIBE VERSION 3

CONTENTS
Purpose............................................................................................................................................................ 1 Tools Used ....................................................................................................................................................... 1 Chat Log Naming Convention............................................................................................................................ 1 Chat Log Locations ........................................................................................................................................... 1 The Serialisation ............................................................................................................................................... 2 Chat Log Header ........................................................................................................................................... 2 Record.......................................................................................................................................................... 3 Explanatory Notes ............................................................................................................................................ 3 Contact ............................................................................................................................................................ 4

PURPOSE
The purpose of this paper is to provide an explanation of the serialisation used by GigaTribe version 3 when writing the chat logs to file. By reversing the serialisation it is possible to reconstruct the chat log as it would appear to the user.

TOOLS USED
GigaTribe version 3.01.007. WinHex 13.8 SR-4

CHAT LOG NAMING CONVENTION

Each GigaTribe user has an ID which is assigned to them by GigaTribe. It is unique and is not to be confused with the GigaTribe user name. The user ID is always numeric, for example 123456, whereas the user name is textual, for example, BobSmith2011. The chat logs are named as follows: chathistory_<userid1>_<userid2>.dat Where: <userid1> is the user ID of the user whos account is being examining, and <userid2> is the user with whom <userid1> is chatting.

There is also a group chat log which is named as follows: chathistory_public.dat Only one of these group chat logs exists per user account as it stores the chat from all groups.

CHAT LOG LOCATIONS

The chat logs are stored on a per GigaTribe user basis. That is, if there are multiple GigaTribe users within the same Windows profile there will be a folder for each user within the GigaTribe application data folder.

Assuming that Windows has been installed to the C volume, the GigaTribe application data folder can be found in the following location: Windows XP C:\Documents and Settings\<user>\Local Settings\Application Data\Shalsoft\GigaTribe Windows Vista/7 C:\Users\<user>\AppData\Local\Shalsoft\GigaTribe

Within this folder, a folder named as the user ID will be found.

FIGURE 1: LOCATION OF USER FOLDER

Within this folder is a chat folder, in which any chat logs will be found.

FIGURE 2: LOCATION OF CHAT FOLDER

THE SERIALISATION
GigaTribe 3 is written in C++ using Qt libraries. The chat log dat files appear to be serialised Qt objects. The Qt serialisation process is well documented at the following location: http://doc.qt.nokia.com/latest/datastreamformat.html Qt serialises into big-endian by default, therefore all values are big-endian unless otherwise stated.

CHAT LOG HEADER

FIGURE 3: DAT FILE HEADER

Part A B C

Offset 0x00 0x02 0x06

Data Type byte[2] int32 string

Relevance Signature, always seen as ch. Length of version string. Appears to be a version string: 1.0.1

Parts B and C together are consistent with the serialisation of Qts QString: a uint32 indicating the number of bytes in the string that follows and then the string in big-endian UTF-16.

RECORD
Immediately following the header is a record:

...snip...

In the table below the Offset is relative to the start of the record. In this example, the record starts at 0x10. Part A B C D E F G H I J K L M Offset 0x00 0x04 0x05 0x0E 0x12 0x22 0x26 0x2A 0x2E 0x3E 0x8C 0x498 0x49C Data Type uint32 byte byte[9] uint32 QString uint32 uint32[F] uint32 QString[H] QString QString QString uint64 Relevance Message ID Boolean indicating an Offline Message Timestamp as QDateTime Senders User ID Senders User Name Number of Recipient User IDs that follow Recipient User IDs Number of Recipient User Names that follow Recipient User Names Message, formatted as GigaTribe 2 chat. Message, formatted as HTML. Supplemental Message Number of bytes just read, that is, this record.

EXPLANATORY NOTES
Part A is only used in the case of offline messages, that is, messages that were sent while the recipient was offline. When used, this value seems just to be a sequential number used to ensure offline messages are displayed in the correct order (this was a bug fixed in GigaTribe 3.1: http://www.gigatribe.com/blog/2010/02/11/gigatribe-3-1-share-with-the-world/). When an online message, this value is 0. It should be noted that in the case of an offline message, the associated timestamp is when the message was downloaded by the recipient not when sent by the sender. Part B is either 0 or 1 where a value of 1 indicates that the message is an offline message and 0, it is not. Part C is the timestamp of the message, a QDateTime object, stored as 9 bytes. As explained in the Qt documentation, the first four bytes are a uint32 representing the Julian days, the next four bytes are a uint32 representing the number of milliseconds since midnight, and the final byte is either 0 or 1, where 0 is local time and 1 is UTC.

Part F is a value indicating the number of user IDs that are about to follow. In the case of private chat, that is chat between two users, this has only ever been seen as 1 one recipient. In the case of group/public chat this can be more than one. Part G is therefore variable in length. There will be a uint32 for every recipient each recipients user ID. Part H is similar to Part F but is for the user names that follow rather than the user IDs. It should be the case that Parts F and H are identical as they map user IDs to user names. Part I is therefore also variable in length. There will be a QString for every recipient each recipients user name. Part J is the message being sent, formatted as GigaTribe 2 chat. Presumably, this allows for compatibility between GigaTribe versions 2 and 3. Part K is the message being sent, formatted as HTML. The presence of Qt CSS styles indicates the serialisation of a Qt GUI object such as QLabel. The HTML will open successfully in a web browser. Part L is a message which is generated by GigaTribe, stored as a QString. It reflects an interaction between the users that is not a typed message. For example, it tells of a bell being sent or an invitation being sent or received. If no supplemental message is sent it appears as a null, 0xFFFFFFFF. Part M is a uint64 which holds the number of characters just read, that is the length of the record, presumably as some kind of checksum. The value of the checksum does not include this uint64.

CONTACT
forensicgeekinthecorner@gmail.com