Вы находитесь на странице: 1из 53


(.\fcord2017 – Chapter 18)

.bmp sent with a text message

(.\fcord2017 – Chapter 18)
• Welcome to FCORD2017 (Chapter 18)
• For new attendees FCORD is a discussion and presentation channel for persons not
present training for MTEB/IDF members; also digital and cybercrime practitioners.
• MTEB and IDF are not for profit organisations. FCORD is our focus conference. There
are numerous Chapters within FCORD e.g. Chapter 27 firearms and weapons,
Chapter 31 cloning mobile phones and so on. Statute Chapter numbers are used in
order to frame the importance of the subject and work and does not provide legal
• The title Chapter 18 comes from the original Computer Misuse Act (CMA) 1990
which makes wide provision for events associated with misuse of computer devices
and systems; CMA has been to subjected to amendments over the years, such as
The Police and Justice Act 2006 Chapter 48 amends the Computer Misuse Act, see
Part 5 sections 35-38. The new amendments came into force on October 1, 2008.
• FCORD Chapter 18 deals with computer devices and systems.
• FCORD Chapter 18 remit covers computer and computing research, discovery and
Chapter 18 [1]; Greg Smith[2]; David Wren, Managing Director [3]

[1]Institute for Digital Forensics IDF; Mobile Telephone Examination Board MTEB; London, England

[2]trewmte.blogspot.com; London, England. Email: trewmte@gmail.com

[3]PassMark Software Pty Ltd, W: www.passmark.com

E: david@passmark.com
Copyright and IP
Please note images and other materials used
throughout this and other presentations may
hold copyright and intellectual property held
by their respective owners.
Discussion Topics
Welcome to FCORD2017 (Chapter 18)

Details have been altered in terms of material

output, etc. used in this presentation in order
protect and avoid disclose of real case facts.
Seized mobile phone sent for examination:
SIO makes request and as standard requires
1 Recover all saved and deleted text messages
2 Recover any/all attachments with text messages
3 Ensure all data is visible, legible and intelligible
The SIO is not technically experienced so no
presentations of messages looking like data-salad
(combination of random ascii, hex and symbols etc.)
Mobile phone received in an Exhibit bag:

Examiner follows (simplified explanation):

A. Lab practices and procedure on received evidence
B. Conducts examination extracting and harvesting
data in a forensically sound manner.
C. Ensure all recovered data is visible, legible and
intelligible in accordance with instructions.
Results of Examination from mobile phone
(Make/Model) – text message data and attachments
originated (simplified explanation):
i. Handset – Messages 1107 (9 with attachments)
ii. SIM Card – 100 Messages (no attachments)
iii. Memory Card – 40 backed-up Messages (no
Results of Examination from mobile phone
(Make/Model) – Any other comments? (simplified
iv. Several messages found corrupted or incomplete
v. Deleted messages handset (12) SIM (4) Memory
Card (0)
vi. Handset stored messages set to delete after 60
days (principle: first in first out e.g. oldest deleted
Results of Examination from mobile phone
(Make/Model) – Request for further investigation?
(simplified explanation):
iv. Several messages suggested they were corrupted
or incomplete
The following message “Stars.bmp” stored on the
handset could be either corrupted or incomplete.
Requires further analysis to determine whether
permanently malformed or can be reinstated to
reveal the image.
Attendance time options associated with reconstruct
the .bmp:
1. Work with current data available as seen in phone
1.1 Carve from current file created by forensic suite
2. Run a second extraction and harvest this time with
JTAG and then carve?
3. Chip off & physical image and then carve?
Attendance time associated with reconstituting the
.bmp. Option 1 applied – (1. Work with current data
available as seen in text)
a) Shortest attendance time and cost.
b) Use existing data and run several tests to see what
image might reveal through viewers.
c) Quickest response time to highlight importance to
(i) The messages appears to be from the
subscriber’s mobile network operator.

(ii) Attachment appears to be included in

the body of the text message and not in
a seperate attached file.

(iii) “Stars.bmp” image could be

corrupted or incomplete.
(iv) EE sends text messages using EE as
identity but should appears as –EE–
(v) EE does not display their mobile
number as sender in text messages.
Mobile numbers and named identities
can be spoofed.
(vi) If attachment cannot be displayed
then EE informs subscriber to visit
their website using the code sent in a
text message to access the attachment
BITMAP Research Materials:
- CompuServe Incorporated: "GIF Graphics Interchange Format: A Standard defining a mechanism for
the storage and transmission of raster-based graphics information", Columbus, OH, USA, 1987.
- Compuserve Incorporated, Columbus, Ohio (1990): "Graphics Interchange Format (Version 89a)".
- IETF RFC 2083: "PNG (Portable Networks Graphics) Specification version 1.0 ", T. Boutell, et. al.,
March 1997.

Useful links:
1) https://www.cs.cmu.edu/~cil/gif87a.doc
2) http://www.martinreddy.net/gfx/2d/GIF87a.txt
3) http://www.intel-assembler.it/portale/5/Compuserve-Graphics-Interchange-
4) https://tools.ietf.org/pdf/rfc2083
Often expressed as a simple image
format not often used today; BITMAP
has a well defined format standard
and, it has been said by non-technical
individuals, convoluted structure by
those who are unaware.

There is a helpful and well researched

guides about BITMAP on Wikipedia.

Whilst station classmark
(SCM) can be use useful
(GSM04.08 UE signalling to
network) an examiner
needs to look further into
the standards for guidance
about image attachments
associated with SMS, EMS
and MMS.

SMS - TS 23.040
MMS - TS 22.140,
TS 23.140, TS 26,140,
TS 26.141
The relevant standards to review are:
3GPP TS 22.140 - Multimedia Messaging Service (MMS); Stage 1
3GPP TS 23.140 - Multimedia Messaging Service (MMS); Functional description;
Stage 2
3GPP TS 26,140 - Multimedia Messaging Service (MMS); Media formats and

MMS - http://www.3gpp.org/specifications/79-specification-numbering

OMA - http://www.openmobilealliance.org/release/MMS

SMIL - http://www.w3.org/TR/smil20/
Open Mobile Alliance
SMIL (Synchronized Multimedia Integration Language)
MMS SMIL - SMIL subset defined for MMS interoperability purposes
SMIL used for the presentation of multimedia messages on mobile terminals. Window size can be
severely limited by the resolution and appearance of the receiving terminal display. Layout may not fit
into the display of the receiving mobile terminal. MMS SMIL can handle this exchange possibly by
changing the relative position of the different elements. Could this cause the corrupted or incomplete
state of message in this case?
Considered graphics file formats
Standard bitmap file formats Nonstandard graphics file formats
Graphic Interchange Format (.gif) Targa (.tga)
Joint Photographic Experts Group (.jpeg, Raster Transfer Language (.rtl)
.jpg) Adobe Photoshop (.psd) and
Tagged Image File Format (.tiff, .tif) Illustrator (.ai)
Window Bitmap (.bmp) Freehand (.fh9)
Standard vector file formats Scalable Vector Graphics (.svg)
Hewlett Packard Graphics Language Paintbrush (.pcx)
(.hpgl) Etc.
Autocad (.dxf)
Various graphics file viewers were used
- Windows Photo Viewer
- Paintbrush
- IrvanView
- XnView
- Opanda Professional
- Etc.

None of the viewers revealed a full or partial image.

“Stars.bmp” data found in text message is corrupted or incomplete does
not display through various viewers (see examples in following slides):

For the purposes of this presentation a second
opinion was sought on validation of findings and
independently assessed by David Wren, MD.,

PassMark have submitted their .bmp reconstruction

for this presentation.
David’s initial analysis:
The number of bytes in Stars.bmp dump is 311.
The expected file size is 1843.
To understand the content of Stars.bmp to add
padding to the original data to complete the correct
byte size..
“So the randomness
implies it is either
corruption, compression
or encryption. None of
which are normal for a
BMP. ”
So what next if visual image not relevant?
In this case, a bit of luck emerged. Examination of
home laptop revealed (associated with the user of
the work smartphone) a stored file containing:

- Key for decryption

- Encryption utility
- Weblink where .bmp file signature and padding
If it was encrypted data then,
1) Why include the decryption key with the message? This is pretty silly security.
2) Even if the decryption key was included, then this isn't of much help unless you have a
lot of time on your hands to work out the encryption algorithm or tool that was used. e.g.
AES, ROT13, Elliptic curve, Twofish, etc..
3) If this was a real life example, the key would be less contrived. So it wouldn't be obvious
it was the last few characters (or even how long it was), without some brute forcing.
4) Nobody sends BMP files via SMS. No one does anything with a BMP nowadays. So if you
wanted security why use a method which draws attention to itself? An encrypted message
in steganography in a JPG would be better (without the encryption key)
5) There are lots of apps for secure messaging. Why not use one of them?
From an examiner’s perspective, whatever the motives of the creator of the
.bmp, the investigation must go on (objectively/dispassionately).

- There is still the work involved to identify which part of the data is padding
and which is the encryption content (trial and error)

- There is still the work to discover what encryption algorithm involved and
whether program created by user or sourced online, etc.

- There is still the work necessary to discover relevance to a case

- Etc.
A peek inside a working copy of Encryption.exe revealed the encryption capability.
For reference visit: https://en.wikipedia.org/wiki/XOR_cipher
“Stars.bmp” - .bmp file signature:
42 4D Bitmap file signature Yellow hex-decimal
discovered is padding

Decryption Key

The real message used a basic encrypted

This is in fact a decryption key 12345678

Below is a fake message for this presentation. The real
message concerned unauthorised distribution of company
financial information.
Data discovered in the SMS text message appears a as Trompe-
l'œil (a lie to the eye)

Painting: Escaping Criticism by Pere Borrell del Caso, 1874

- This case affords us a potential to learn from a scenario that on the face of it
appears random and the perpetrator appears quite naïve and silly.

- Of those issues that experienced examiners could observe as actions ‘easily

found out’; to the uninitiated the text message labelled Stars.bmp is most
likely to be ignored from **researching opinions.

- **20 people from a range of backgrounds (private, civil and non-technical)

were asked to view and comment on the text message. All dismissed the
message as either corrupted message and/or the handset was not
compatible to read the message and would ignore the message completely.
So where to from here:

- Where examination laboratories are harvesting tens of ‘000 texts and other
messages it may be a message like that might not be seen as relevant.

- It is unrealistic to expect forensics software suites to make assessment about

each piece of evidence it recovers; that requires human intervention to do

- Hopefully, this presentation may assist examiners/investigators etc. as a

reminder/refresher (should a similar incident arise in an investigation) and
hopefully help reduce attendance time researching and analysing.
(.\fcord2017 – Chapter 18)

.bmp sent with a text message