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 who’s 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 Offset Data Type Relevance A 0x00 byte[2] Signature, always seen as ch. B 0x02 int32 Length of version string. C 0x06 string Appears to be a version string: 1.0.1

Parts B and C together are consistent with the serialisation of Qt’s 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 Offset Data Type Relevance A 0x00 uint32 Message ID B 0x04 byte Boolean indicating an Offline Message C 0x05 byte[9] Timestamp as QDateTime D 0x0E uint32 Sender’s User ID E 0x12 QString Sender’s User Name F 0x22 uint32 Number of Recipient User IDs that follow G 0x26 uint32[F] Recipient User IDs H 0x2A uint32 Number of Recipient User Names that follow I 0x2E QString[H] Recipient User Names J 0x3E QString Message, formatted as GigaTribe 2 chat. K 0x8C QString Message, formatted as HTML. L 0x498 QString Supplemental Message M 0x49C uint64 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 recipient’s 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 recipient’s 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