FORENSIC CONFERENCE ON RESEARCH AND DEVELOPMENTS

(.\fcord2017 – Chapter 18)

.bmp sent with a text message

FORENSIC CONFERENCE ON RESEARCH AND DEVELOPMENTS
(.\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
advice.
• 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
developments.
 AUTHORS & REVIEWERS
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.
INVESTIGATION
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.
EXAMINATION
RESULTS
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
attachments)
Results of Examination from mobile phone
(Make/Model) – Any other comments? (simplified
explanation):
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
first)
Assessment
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
screen?
1.1 Carve from current file created by forensic suite
software?
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
case.
ANALYSIS
(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
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-
Format/Gif87a-Gif89a-specification-format.asp
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.

https://en.wikipedia.org/wiki/BMP_fil
e_format#File_structure
 IMAGES
SENT WITH
MESSAGES
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
codecs

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
OMA-AD-MMS-V1_3-20110913-A.pdf
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?
.BMP ASSEMBLED
 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)
Etc.
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):

424D3E070000000000003600000028000000180000001900000001001800
000000000807000000000000000000000000000000000000655A5A47155F
441850125E5B575F5B5D11574B55585F595D43154014414456515F5B5D53
1542524B4512475B1552525B5E565614425E564C115E5C5B5E4517545859
56145416195A5C42135D5857505D11504640155F4418585C555556421759
1141565747534318545C50464C46435D55125E514645565F541240515B42
17594212521441534F4C115F56474657505D11465C144643505F54414714
415E564C11465B511544525B58574551474517555E505A58501647505E5C
5614585955515D5713505C5217565E46135C5440521850125B555B525B5D
43125C461552455147574114415917515F4656464544524C1153131A575B
4718575B5F511B12345678
 .BMP
RECONSTRUCTION
For the purposes of this presentation a second
opinion was sought on validation of findings and
independently assessed by David Wren, MD.,
PassMark

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. ”
 FURTHER
ASSESSMENT
NEEDED
So what next if visual image not relevant?
ENCRYPTION
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
obtained
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:
424D3E0700000000000036000000280000001800000019000000010018000000
00000807000000000000000000000000000000000000655A5A47155F44185012
5E5B575F5B5D11574B55585F595D43154014414456515F5B5D531542524B4
512475B1552525B5E565614425E564C115E5C5B5E451754585956145416195
A5C42135D5857505D11504640155F4418585C5555564217591141565747534
42 4D Bitmap file signature Yellow hex-decimal
318545C50464C46435D55125E514645565F541240515B421759421252144153
discovered is padding

4F4C115F56474657505D11465C144643505F54414714415E564C11465B5115
44525B58574551474517555E505A58501647505E5C5614585955515D5713505
C5217565E46135C5440521850125B555B525B5D43125C46155245514757411
Decryption Key

4415917515F4656464544524C1153131A575B4718575B5F511B12345678
The real message used a basic encrypted
655A5A47155F441850125E5B575F5B5D11574B55585F595D431540144144
56515F5B5D531542524B4512475B1552525B5E565614425E564C115E5C5B
5E451754585956145416195A5C42135D5857505D11504640155F4418585C
5555564217591141565747534318545C50464C46435D55125E514645565F
541240515B4217594212521441534F4C115F56474657505D11465C144643
505F54414714415E564C11465B511544525B58574551474517555E505A58
501647505E5C5614585955515D5713505C5217565E46135C544052185012
5B555B525B5D43125C461552455147574114415917515F4656464544524C
1153131A575B4718575B5F511B

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.
CONCLUSION
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
that.

- 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.
FORENSIC CONFERENCE ON RESEARCH AND DEVELOPMENTS
(.\fcord2017 – Chapter 18)

END
FCORD2017
.bmp sent with a text message