Thursday, March 19, 2015

Emotion Icons

From a recent discussion about knowledge/skills and experience and operators of forensics tools having a range of training, contributors comments varied as to exactly where the demarcation line lay regarding 'competence'. That is how far should an examiner go to valid the extracted and harvested data from a mobile phone. Bits and Bytes levels, carving out etc. brought some responses suggesting these were not seen as paramount to know, which seemed to me to suggest, at any rate, reliance on the forensic tool to get it right.

A couple of observations I raised were these:

Some examples of required technical competence

(c) Good example of checking the tool's output can be seen when cross-checking the output on the physical mobile handset device. Take the standard Smart Messaging which can contain images. The tool extracts and the output is harvested. The image shown by the tool is not always the same as shown on the mobile phone. Why? Proprietary applications that reside on the handset are not the same as on the tool? A smart messaging image can be interpreted differently by another make/model of handsets? Or did the tech / examiner incorrectly perform the extract and harvesting properly? So where would blame lay in a situation like this?

I have added an example for a Phillips Savvy mobile phone 1999 (from 15 years ago) when it was known makes/models handle emotion icons (emoticons) differently.



 (d) Remaining with SMS text you may know about 7-bit, 8-bit and 16-bit encoding for SMS text messages. But how about variations such as Fernschreiber 5-bit encoding that can be used in SMS PDU mode allowing one single message to contain 244 characters. A user may send one text but with 7-bit encoding (244 characters) but the mobile phone sends this as a GSM concatenated text message e.g. in say 2 messages (concatenation of messages can be up to max: 255 messages). Does the tech / examiner immediately mistake the 5-bit 244 character message as a concatenated message?

I choose these observations because they highlight how deceptive recovered data can be when viewed through the GUI of the tool used to extract and harvest data. Viewing recovered data can be a trompe l'oiel (a lie to the eye) if as examiners we merely accept on the face of it what the tool tells us. Additionally, a tool cannot encompass all a mobile's features or its interpretation libraries associated with particular data.

The emotion icons discussion interested me because on first blush emoticons may be perceived as simple smiley faces and different Unicode characters etc. However, with Emotion Icons and Emoji widely in use on mobile devices Emoji can also e.g. be used for encrypting messages; which takes these icons into a completely different ball park when it comes to evidence. Another example for the potential for mistaken identity about the meaning of the data.

https://itunes.apple.com/us/app/hidemessage-pro-send-private/id648699383?mt=8

http://www.quora.com/Some-mobile-apps-allow-you-to-encrypt-text-messages-in-emojis-I-need-to-decipher-a-long-sequence-of-seemingly-random-black-white-red-and-blue-circles-Is-it-likely-that-this-message-is-encrypted-in-emojis-If-it-is-how-should-I-go-about-trying-to-decrypt-this-and-other-emoji-encrypted-messages

http://www.appszoom.com/iphone-apps/business/hidemessage-encrypt-secret-private-messages-into-emoticons-for-chat_ghosb.html

No comments: