In order to make this process a little easier, the script provides the option of generating a list of unique recipient IDs, which it will gather at the time of processing and write to a note bookmark in the root bookmark folder. The script can then be run again using those recipient IDs as sender IDs. To overcome this problem it may be necessary to run the script once in order to determine the recipient IDs of GigaTribe users to which the local user has sent messages. It should be fairly easy to identify the GigaTribe ID of the local user by examining his/her Gigatribe Registry settings and then using the script to identify messages that he/she sent, it's the identification of messages sent to the local user that is the difficult bit. The requirement to provide the sender ID may prove tricky when trying to locate messages both sent-from and received-by the local user. Without this information, the script would encounter many false hits and most likely crash whilst attempting to parse them. Taking this into account, the script needs to know the IDs of the GigaTribe users that have sent the messages that the examiner is interested in. The reason for this is that individual chat records don't have a static signature - they consist almost entirely of variable data.

Keyword searching can be used to search areas such as unallocated clusters but this is much more difficult than parsing a complete chat-file. If the examiner chooses the first option then any entry being parsed will be checked for the proper chat-log signature, which is currently the characters 'ch' followed by the value 0x0a (stored as a 4-byte Big-Endian integer value) and then the version string '1.0.1'. The script can either treat the entries being parsed as GigaTribe chat-log files alternatively it can search said entries for chat messages using a keyword search. Locates and parses chat records originating from GigaTribe V3 chat-log files.

Gigatribe id