See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/325530804

How to decrypt PIN-Based encrypted backup data of Samsung smartphones

Article  in  Digital Investigation · June 2018

DOI: 10.1016/j.diin.2018.05.006

CITATION READS

1 3,606

3 authors:

Myungseo Park Hangi Kim

Kookmin University Kookmin University
11 PUBLICATIONS   7 CITATIONS    4 PUBLICATIONS   4 CITATIONS   

SEE PROFILE SEE PROFILE

Jongsung Kim
Kookmin University
104 PUBLICATIONS   1,731 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Cryptanalysis View project

All content following this page was uploaded by Myungseo Park on 05 March 2019.

The user has requested enhancement of the downloaded file.

 Digital Investigation 26 (2018) 63e71

Contents lists available at ScienceDirect

Digital Investigation
journal homepage: www.elsevier.com/locate/diin

How to decrypt PIN-Based encrypted backup data of Samsung

smartphones
Myungseo Park a, y, Hangi Kim a, Jongsung Kim a, b, *
a
Department of Financial Information Security, Kookmin University, 77 Jeongneung-Ro, Seongbuk-Gu, Seoul, 02707, South Korea
b
Department of Information Security, Cryptology and Mathematics, Kookmin University, 77 Jeongneung-Ro, Seongbuk-Gu, Seoul, 02707, South Korea

a r t i c l e i n f o a b s t r a c t

Article history: Smartphones, which are a necessity for modern people, have become important to forensic investigators,
Received 19 April 2018 as they have a lot of user information which can be potential evidences. In order to obtain such evi-
Received in revised form dences, forensic investigators should first extract the data from the smartphone. However, if the
30 May 2018
smartphone is lost or broken, it would be difficult to collect the data from the phone itself. In this case,
Accepted 30 May 2018
Available online 2 June 2018
the backup data can be very useful because it stores almost all information that the smartphone has.
Nevertheless, since the backup data is basically encrypted by applications provided by vendors, the
encrypted backup data which acts as anti-forensic is difficult to use. Therefore, it is crucial to decrypt the
Keywords:
Smartphone forensics
acquired encrypted backup data in order to effectively use it.
Smartphone backup In this paper, we propose a method to decrypt the Samsung smartphone backup data which is
PIN-Based encryption and decryption encrypted by a user input called PIN (Personal Identification Number) and a Samsung backup program
called Smart Switch. In particular, we develop algorithms to recover the PIN and to decrypt the PIN-based
encrypted backup data as well. We have experimentally verified the PIN recovery backup data decryption
up to 9 digits of PIN. Our implementation using a precomputed PIN-table with memory 30.51 GB takes
about 11 min to recover a 9-digit PIN. To the best of our knowledge, this is the first result of decrypting
PIN-based encrypted backup data of Samsung smartphones.
© 2018 Elsevier Ltd. All rights reserved.

Introduction
Background
The smartphone market continues to grow, and smartphones
are more widely used than desktop computers. The Q3 2017 global
market share survey for smartphones (Global smartphone market
share by vendor, 2009) shows that Samsung had 22.3% global
market share, while Apple, Huawei, OPPO, and Xiaomi had 12.5%,
10.5%, 8.2%, and 7.4%, respectively. In Q4 2017, Samsung ranked
second with 18.4%, following Apple with 19.2%. Therefore, it is
important to forensic investigators to collect information on Sam-
sung or Apple smartphones that have a high share in the world.
Smartphones have a lot of personal details, such as users’ private
messages, photos, and other sensitive information. These personal
information can be also stored in PC through backup programs.
* Corresponding author. Dept. of Financial Information Security, Kookmin Uni-
versity,77 Jeongneung-Ro, Seongbuk-Gu, Seoul, 02707, South Korea.
E-mail addresses: pms91@kookmin.ac.kr (M. Park), tiontta@kookmin.ac.kr
(H. Kim), jskim@kookmin.ac.kr (J. Kim).
y
URL: http://dfnc.kookmin.ac.kr/.
Users can thus restore important data from stored backup data
when faced with smartphones lost or broken.
The most obvious method to backup smartphone data is to use a
backup program, such as Kies/Smart Switch (Samsung)
(SmartSwitch), PC Suite/Bridge (LG) (LG Bridge-LG), iTunes (Apple)
(iTunes-Apple), etc. These PC based backup programs provided by
vendors are easy to use, and can quickly backup a large amount of
data by USB connection. The backup programs basically encrypt the
backup data to ensure user data protection.
Previously, the backup data encryption was only processed by
the PC's computing power, but it is now possible and practical to
encrypt backup data using the smartphone itself as well, due to
rapidly increased smartphone's computing power. The latest
Samsung smartphone, for example, processes the backup data
encryption in the phone with a user entered PIN. It provides a
simple and effective encryption method to protect data from at-
tackers, where decrypting the backup data is hard without knowing
the PIN. However, it often acts as anti-forensic.
It is essential to forensic investigators to access smartphone
data. However, in many cases where the smartphone data cannot
be collected due to intentional deletion, destruction, etc, forensic

https://doi.org/10.1016/j.diin.2018.05.006
1742-2876/© 2018 Elsevier Ltd. All rights reserved.
64 M. Park et al. / Digital Investigation 26 (2018) 63e71

Table 1
Summary of decryptable backup files for Samsung smartphones.

Backup Program Backup with PIN Encrypted backup file extensions Target environment Source

Kies 2.6 X .sbu PC Gyuwon et al. (2013), Lenzen,

Armomurha
Kies 3.0 and X .spb, .ssn, .ssm, .ssc, .scl, .sme, .sal, .bk, .swp, .swi, .sls PC Jaehyeok and Sangjin (2016)
Smart Switch 4.1.16
Smart Switch 4.1.16 X .ebk, .ssca, .spba, .smea, .edb, .exml, .json, .conf, .apk PC & Smartphone Ours
O .senc, .ebk, .essca, .espba, .esmea, .edb, .ebin, .exml,
.json, .conf, .apk

investigators need to access smartphone backup data. In particular, Analysis of backup processes
the Samsung's PIN-based encrypted backup data cannot be utilized
as evidence unless the PIN is recovered. Backup program

Smart Switch is a program that manages backup for Samsung

Related work smartphone data. Samsung smartphones must support Android 4.3
or higher versions (including versions 5,6,7 and 8) to use the Smart
Kies is an old version of Samsung smartphone backup program, Switch, and PIN-based encryption has been provided since Smart
while the current version is Smart Switch. Gyuwon et al. (2013) Switch 4.1.16 (Feb. 2016).
analyzed the backup file (*.sbu) structure generated by Kies 2.6, All the Android versions x ( 4:3) are compatible with Smart
which contains contacts, SMemo, SPlanner, call log, music, photos, Switch 4.1.16 which is our attack target.1
videos, etc. They developed a tool to extract personal information
from backup data, which is better than other tools, such as SBU-
Normal and PIN-based backup processes
Extractor, SSVCardExtractor (Lenzen and Armomurha). Kies 3.0 and
Smart Switch, which were released subsequent to Kies 2.6, encrypt
The backup data of Samsung smartphones is generally trans-
and store separate backup files for each item, in contrast to Kies 2.6
ferred via USB to PC, then compressed and encrypted by Smart
that stores all details within a single backup file. Jaehyeok and Sangjin
Switch which employs AES256-CBC encryption with fixed IV
(2016) categorized backup files of Kies 3.0 and Smart Switch 4.1.16, and
(Initialize Vector) and fixed Key (Jaehyeok and Sangjin, 2016). All
analyzed the encryption method by reversing the Kies 3.0 library.
backup data is encrypted with the same IV and Key. However, since
They analyzed the backup process on the PC but do not consider the
these IV and Key can be found by reverse engineering Smart Switch,
backup process on the smartphone including the PIN-based backup.
encrypted backup data is cryptographically vulnerable in terms of
Since Smart Switch 4.1.16, the PIN-based backup data encryption is
user privacy and data protection.
supported, but it has not been analyzed until now.
To circumvent for this vulnerability, Smart Switch optionally
supports PIN-based backup data encryption since its version 4.1.16.
The backup data is first encrypted on the smartphone using a user-
Our contributions
entered PIN (this process is done with a fixed key if the user chooses
no-PIN in Smart Switch 4.1.16), and then transmitted to PC. The
In this paper, we present how to recover a user entered PIN, and
encryption algorithm processed on a PC remains the same as pre-
decrypt the PIN-based encrypted backup data of Samsung smart-
vious versions of Smart Switch where PIN is not used. Fig. 1 repre-
phones. Our contributions are summarized as follows.
sents the processes of a normal backup (no PIN chosen) and a PIN-
based backup, respectively. The difference between normal and PIN-
(1) We analyzed and reverse engineered the Samsung smart-
based backup processes is only on the encryption/decryption on the
phone's backup program, Smart Switch 4.1.16, to find PIN-
smartphone which is indicated with * in Fig. 1. For the encryption/
based encryption processes. Our analysis shows that
decryption with *, the normal backup uses a fixed key, while the
different encryption processes apply depending on file ex-
PIN-based backup does a PIN-based generated key.
tensions (Section Analysis of backup processes).
The application file that manages backup in Samsung smart-
(2) We found an authenticator in encryption processes with
phones was identified as ‘wssyncmlnps2.apk’ from the logcat logs.
which we can judge whether or not a guessed PIN is correct.
By reverse engineering this application file using (JEB Decompiler),
We then used this authenticator to develop a PIN recovery
we found the KDFs (Key Derivation Functions) and normal/PIN-
algorithm. We experimentally verified the PIN recovery from
based encryption processes of the backup data. It includes byte-
4 to 9 digits which are the most use cases. In our verification,
code, libraries, resource files, etc. The names of java object, func-
we identified that a precomputed PIN-table can significantly
tion, and variable are obfuscated in bytecode, but the function
accelerate our PIN searching (Section PIN recovery).
names called by the library were preserved.
(3) We developed a tool to decrypt PIN-based encrypted backup
Using reverse engineering, we revealed a PIN-based backup
data. Reversly different decryption algorithms apply
process, which consists of the following three stages: the MK
depending on encrypted backup file extensions (Section
(Master Key) is generated by the user-entered PIN, a number from 4
Backup data decryptions).
to 16 digits, then some of the backup files are encrypted using this
(4) We also analyzed normal encryption processes of Smart
MK on the smartphone (in this stage, a fixed key is used instead of
Switch 4.1.16 which do not use PIN, and developed their
decryption algorithms.
1
Note that our target is not “Samsung Smart Switch Mobile” application pro-
Table 1 shows a comparison of previous and our results. We vided by the Google Play, but the Samsung Smart Switch desktop version 4.1.16 and
expect that our results help forensic investigators to collect PIN- the application embedded in Samsung smartphone, named “wssyncmlnps2.apk” as
based encrypted backup data of Samsung smartphones. well.
 M. Park et al. / Digital Investigation 26 (2018) 63e71
Fig. 1. Normal/PIN-based backup processes using Smart Switch 4.1.16.
the MK for the normal backup process), and the others are not
encrypted. Next, the (encrypted) backup data is transferred to the
PC via USB and some backup data is compressed, then encrypted
using a fixed Key in Smart Switch. The remaining transferred
backup data is neither compressed nor encrypted. Each stage is
described in detail below (the normal backup process is also
explained).
PIN-based MK generation
The MK is calculated by the PBKDF2 (Password Based Key
Derivation Function 2) algorithm with HMAC-SHA1, i.e., PBKDF2-
HMAC-SHA1, which is commonly used for key stretching and
significantly increases password cracking difficulty. The PBKDF2 is a
part of PKCS#5, also published as IETF RFC 8018 (Moriarty et al.,
2017).
MK ¼ PBKDF2­HMAC­SHA1ðuser­entered PIN; DK; 1000; 32Þ:
Here, PIN is used as a Password, and DK (Default Key) used as a
cryptographic salt is a 16-byte string called from ‘libCryptionkey.so’
library in ‘wssyncmlnps2.apk’. The number of iterations for HMAC-
SHA1 is 1; 000, and the byte length of derived MK is 32. See
(Moriarty et al., 2017) for more details of PBKDF2. The number of
iterations has a large impact on our PIN recovery, as described in
Section PIN recovery.
Backup data encryption on smartphones
There are several encryption algorithms and KDFs used for
backup and they apply depending on file extensions. Files with .bin
extension containing information, such as contacts, MMS, and SMS
are changed to .ebin after encryption. The extensions of media files
are .docs, .jpg, .avi, etc. and they are changed to .senc after
encryption. The .bin files and media files are all encrypted with
AES256-ECB (see Eq. (2)).
C ¼ AES256­ECB­ENCRYPTðP; MKÞ;
C ¼ backup data:
65
Here, P is files, C is the corresponding ciphertext, and MK is the
PIN-based generated master key.
Files with .xml extension contain settings, backup file lists, and
call logs and this file extension is changed to .exml after encryption.
Files with .json, .edb, .conf, and .apk extensions retain those ex-
tensions even after encryption. In the normal backup process (no
PIN chosen) depicted in Fig. 1, these backup files except for the .apk
are encrypted using the key generated by the DK and KDF with
SHA256 (see Eq. (3)). Files with .apk extension are encrypted using
a fixed key string in the bytecode of ‘wssyncmlnps2.apk’ and KDF
with PBE (Password-Based Encryption) eSHA256 (see Eq. (4))
(Moriarty et al., 2017). In the PIN-based encryption process, these
files are encrypted using Eq. (5) or Eq. (6). These Eqs. (5) and (6) are
both based on the aforementioned MK. Among the files with .exml
extension, Manifest.exml is only created in the PIN-based backup
and used for a PIN verification. Its encryption process is Eq. (2)
unlike the other files with .exml (they use Eq. (5) or Eq. (6)).
(1)
TK ¼ SHA256ðDKÞ;
C ¼ AES128­CBC­ENCRYPTðP; TK015 ; IVÞ; (3)
IVjjC ¼ backup data:
In Eq. (3), the DK is used as the input of SHA256, and the tem-
porary key TK is its 32-byte output. The upper 16 bytes of TK are
used as the key of AES128-CBC, padded using PKCS#5-PAD. The IV
is a 16-byte random value generated by the SecureRandom API. As
in Eq. (3), this IV is prefixed to C.
TK ¼ PBE­SHA256ðFV1 ; FV2 ; 1000; 32Þ;
C ¼ AES256­CBC­ENCRYPTðP; TK; FV3 Þ; (4)
C ¼ backup data:
(2)
In Eq. (4), KDF is PBE-SHA256 and the encryption algorithm is
AES256-CBC. The key materials FV1 (Fixed Value) and FV2 are used
for generating the TK which is the encryption key of AES256-CBC.
66 M. Park et al. / Digital Investigation 26 (2018) 63e71

Table 2
Encryption algorithms used for backup data.

Eq. KDF (Key Derivation Function) Key materials & parameters Encryption Algorithm Parameters
Num.

(1) PBKDF2-HMAC-SHA1 (Password, Salt, Iteration, outLen) Password: user-entered PIN e e

Salt: D
KIteration: 1000
outLen: 32
(2) e e AES256-ECB(P, Key) P: File
Key: KDF output of Eq. (1)
(3) SHA256 (Input) Input: DK AES128-CBC(P, Key, IV) P: Backup file
Key: Upper 16-bytes of KDF output
IV : 16-byte random value
(4) PBE-SHA256 Password: FV1 AES256-CBC(P,Key,IV ) P: File
(Password, Salt, Iteration, outLen) Salt: FV2 Key: KDF output
Iteration: 1000 IV : FV3
outLen: 32
(5) SHA256 (Input) Input: KDF output of Eq. (1) AES128-CBC(P,Key,IV ) P: File
Key: Upper 16-byte of KDF output
IV : 16-byte random value
(6) PBKDF2-HMAC-SHA1 Password: KDF output of Eq. (1) AES256-CBC(P, Key, IV) P: File
(Password, Salt, Iteration, outLen) Salt: 16-byte random value Key: KDF output
Iteration: 1000 IV :16-byte random value
outLen: 32
(7) e e AES256-CBC(P, Key, IV) P: Compressed file
Key: FV4
IV : FV5
*
All encryption algorithms use the padding scheme as PKCS#5.

Table 3
Encryption methods according to extension type of backup files.

PIN-based backup in Fig. 1 Normal backup in Fig. 1 (no-PIN chosen)

Content Backup file extension Encryption Backup file Encryption

method (Eq.) extension method (Eq.)

Multimedia .senc (2) .mp3, .mp4, .m4a, .avi, Not encrypted

.png, .jpg, .hwp, .pdf, etc.
Data .edb (5) or (6) .edb (3)
Application .apk (6) .apk (4)
Setting .ebin (2) .bin Not encrypted
Setting .exml (5) or (6) .exml (3)
Setting .json (5) or (6) .json (3)
Setting .conf (5) or (6) .conf (3)
PIN test Manifest.exml (2) e e
Setting, Email, .ebk (7) .ebk (7)
Calllog, WIFI, etc.
SPlanner .essca (7) .ssca (7)
Contacts .espba (7) .spba (7)
Message .esmea (7) .smea (7)
*
Eqs. (2), (5) and (6) use PIN-based encryption processes, and the others do encryption processes with fixed key values.

The FV3 is IV , and FV1 , FV2 , FV3 , are all fixed values in the bytecode In Eq. (6), TK is a 32-byte, and used as the key of AES256-CBC.
of ‘wssyncmlnps2.apk’. The IV and Salt are 16-byte random values generated by the
SecureRandom API. As in Eq. (6), IV and Salt are prefixed to C. The
TK ¼ SHA256ðMKÞ; “backup data” indicated in Eqs. (2)(6) can be regarded as
encrypted backup files with some extensions, and the forms of
C ¼ AES128­CBC­ENCRYPTðP; TK015 ; IVÞ; (5) backup data transferred to the PC. Note that in Eqs. (2)(6), the
input parameters DK, IV , FVi (i ¼ 1  3), and Salt are all known
IVjjC ¼ backup data: values. This fact plays an important role in completing our
decryption algorithms.
In Eq. (5), TK is derived from MK. The other parameters are the Backup data transfer to PC and its encryption on Smart Switch
same as the description in Eq. (3). All the backup data is transferred to the PC, sorted, and some
backup data is subgrouped, compressed, and then encrypted by
TK ¼ PBKDF2­HMAC­SHA1ðMK; Salt; 1000; 32Þ; (6) Smart Switch (they include files with .ebk, .essca (.ssca), .espba
(.spba), and .esmea (.smea) extensions). The other transferred data
C ¼ AES256­CBC­ENCRYPTðP; TK; IVÞ; is directly stored as the final backup data in the PC (they include
files with .senc (.mp3, .mp4, .png, .pdf, etc.), .apk, .ebin (.bin), .exml
IVjjSaltjjC ¼ backup data: (.xml), .json, and .conf extensions). The equation for encrypting
backup data on the Smart Switch is as follows.
 M. Park et al. / Digital Investigation 26 (2018) 63e71 67

Fig. 2. PIN recovery by a known plaintext attack.

P ¼ ‘backupinfo:xml0 jjCompressðtransferred backup dataÞ (7)

Table 4
Our experimentally verified time and memory to recover the correct PIN with brute-
force search and PIN-table based search. C ¼ AES256­CBC­ENCRYPTðP; FV4 ; FV5 Þ;
PIN digits Brute-force search PIN-table based search
Time C ¼ backup data:
Time Memory

4  13:047 sec.  0:008 sec. 320 KB The P is the concatenation of ‘backupinfo.xml’ file containing the
5  147:536 sec.  0:116 sec. 3.12 MB backup information and compressed transferred backup data. The
6  26 min.  0:761 sec. 31.25 MB Smart Switch uses a fixed 16-byte FV4 as the Key and a fixed 32-byte
7  260 min.  6:843 sec. 312.5 MB
FV5 as the IV to encrypt P. The FV4 and FV5 are fixed and known
8  2600 min.  67:078 sec. 3.05 GB
9  18 days  11 min. 30.51 GB
values in the Smart Switch. Encryption is performed in units of 256
*
bytes, and the end of each unit is padded with 16 bytes consisting of
The time columns are the time it takes to search from 4 digits to the corresponding
‘01010 … 10’. Table 2 summarizes the KDFs and encryption al-
digit.
gorithms used in the backup processes, and Table 3 summarizes
encryption methods according to file extensions. Note that the

Fig. 3. Our Smart Switch backup file decryption program and its example.
68 M. Park et al. / Digital Investigation 26 (2018) 63e71
Fig. 4. A flowchart for our normal backup data decryptions (no-PIN chosen).
backup data induced from Eq. (7) can be decrypted, and then
decompressed, whose resulting files are other files generated from
Eqs. (2)(6) in Table 3. For instance, files with .essca may have files
with .edb and .ebin after their decryption and decompression. They
can also include clear files such as .xml files.
PIN recovery and backup data decryption
In this section, we propose how to recover a user entered PIN
and exploit the recovered PIN to decrypt backup data. Our work is
done without the target Samsung smartphone, but with the PC
having backup data encrypted by Smart Switch 4.1.16.
PIN recovery
Although we have reverse engineered the Smart Switch
encryption processes, it is infeasible to decrypt PIN-based encryp-
ted backup data without a user-entered PIN. To recover the correct
PIN, we tried to find a file encrypted based on the PIN that is
suitable to predict some plaintext, i.e, some fixed and predictable
string in the file before its encryption. Since the ‘Manifest.exml’ file
is created only from PIN-based backups, we selected this file as a
target of known-plaintext attack. Our bytecode analysis of
‘wssyncmlnps2.apk’ shows that the PIN can be checked by testing
the keyword ‘Enc Level’ in the decrypted file of ‘Manifest.exml’.
Since the first string in the .xml file represents a declaration con-
taining version and encoding information, such as ‘ < ? xml
version ¼ “ 1.0 ”encoding ¼ “ utf-8 ”? > ’, this is also possible to use
as keyword. Thus the keywords can be used as an authenticator of
the PIN. Fig. 2 shows our PIN recovering attack. Besides, we can
build a known-plaintext attack using a different file. For example,
the .edb file is an encrypted file by Eq. (5) or (6). After decrypting
this file based on a guessed PIN, we can verify it by checking that
the first string of the decrypted file is ‘0  504B0304’. This string
represents the signature of the compressed file.
During the MK generation by PBKDF2, the SHA1 algorithm is
executed more than 4; 000 times as the used iteration for HMAC-
SHA1 is 1; 000 and the output length is 32 bytes. Since our PIN
recovery attack first generates a MK from a PIN candidate and then
decrypts the ‘Manifest.exml’ file to verify it, this amount of SHA1
executions is a huge obstacle. For example, if the correct PIN was a
9-digit with ‘999999999’, more than 241:02 trials of SHA1 are
required to recover the PIN if testing was in order from ‘0000’. This
PIN was recovered in about 18 days, implementing our attack in
 M. Park et al. / Digital Investigation 26 (2018) 63e71
Fig. 5. A flowchart for PIN-based backup data decryptions.
Python 2.7.14 on Windows 10 Enterprise operating system, 64 GB of
RAM, intel (R) Core (TM) i7-6700.
However, the PIN recovery time can be greatly shortened using a
table of MKs derived from PINs. Although calculating and storing
the MK table requires slightly more computation than a brute-force
search for the PIN, once it is available, subsequent PIN searches are
dramatically faster. In our simulation the PIN-table based search2 is
approximately 2300 times faster than the brute-force search. See
Table 4 for our simulation results of time and memory required to
recover the PINs from 4 to 9 digits, which are the most use cases.
Our simulation results show that every single digit increase re-
quires about 10 times more computations or spaces. Therefore, we
expect that it would take about 180 days or more to recover a single
PIN for more than 9 digits in a personal computing environment. In
our estimation, recovering a PIN of 16 digits seems still unrealistic
even using the PIN-table method, because it requires 209.28 years
(¼ 11  107 min) and 195.6 PB size table. This limitation can be
2
Note that the PIN-table can be used to all the backup data regardless of Sam-
sung smartphones. For instance, even though the backup data is from different
Samsung smartphones the input parameter Salt is the same, inducing a unique MK
generated from a PIN.
69
mitigated using parallel computation and high speed imple-
mentation. See Appendix A for more details.
Backup data decryptions
As stated in Section Analysis of backup processes, different
encryption processes apply depending on file extensions. See
Table 3 for more details. Our decryption algorithms are constructed
by applying the backup data encryption processes in the backward
direction. During the decryption processes, we need to know the
actual values of several parameters, such as MK, DK, IV , FVi , and
Salt. The DK is fixed and called from library ‘libCryptionkey.so’ in
the application file ‘wssyncmlnps2.apk’, and the MK is calculated by
using the DK and the recovered PIN. The FVi ði ¼ 1  3Þ are fixed in
the bytecode of the ‘wssyncmlnps2.apk’ file and FVi ði ¼ 4; 5Þ are
fixed in the Smart Switch. The IV and Salt are fixed in encrypted
backup data. Thus, we can get to know all the values of parameters
required to decrypt backup files.
The flowcharts for our decryption processes are depicted in Figs. 4
and 5. Based on the flowcharts, we implemented a Smart Switch
backup data decryption program. Our program takes the directory of
the backup data, recovers the PIN and then uses it to decrypt the
encrypted backup data. Fig. 3 shows an example of the files we
70 M. Park et al. / Digital Investigation 26 (2018) 63e71

actually decrypted. During the normal backup data decryptions, our benchmark test results provided by hashcat (hashcat) to measure
PIN recovery process is skipped, and the decryption time is negligible. PBKDF2-HMAC-SHA1 for GPU devices. In this benchmark test, the
number of iterations of HMAC-SHA1 in PBKDF2 is 1; 000, which is
equivalent to the number of iterations used in the MK generation
Conclusion
from a user-entered PIN, and thus it can be used immediately as a
computing performance indicator. According to the test of Nvidia
In this paper, we proposed a method for decrypting PIN-based
GTX 1080 Ti in the right Fig. A.6, one of the GPUs, PBKDF2-HMAC-
encrypted backup data of Samsung smartphones via Smart
SHA1 with a single GPU is run at a speed of about 4; 520:05kH=s on
Switch 4.1.16. We first analyzed the PIN-based backup process and
average (4; 520:05 kiloHash per second, i.e, 4; 520; 050 PBKDF2-
derived its employed encryption processes in detail. We then
HMAC-SHA1 computations per second), and thus x ð 2Þ GPU
developed a tool based on these details to recover the PIN used for
connections can run PBKDF2-HMAC-SHA1 at approximately
encryptions and to decrypt backup data.
ð4; 520:05  xÞ kH=s. Applying 8 GPU computing power to brute-
One of the promising countermeasures to our PIN recovery and
force search, it takes about 8.54 h to recover the 12 digit PIN, but
backup data decryption is to increase the iteration level used in the
the 16 digit PIN recovery takes about 9.74 years and is still unre-
PIN-based MK generation. The iteration level in PBKDF2 used for key
alistic. However, if we connect more GPUs or use a high-end GPU, it
stretching purpose is currently 1; 000 (¼Iteration). This iteration level
can be further improved. See Table A.5 for more details of hashcat
is relatively weak compared to those in other systems. Some guides
implementations.
(OWASP (Steven et al., 2018), NIST (Grassi et al., 2017)) recommend

Fig. A.6. PBKDF2-HMAC-SHA1 performance of 4x Nvidia GTX 1070 and 4x Nvidia GTX 1080 Ti with hashcat benchmark mode.

Table A.5
Estimated time to recover the correct PIN with a GPU-based brute-force search.

PIN digits GTX 1070 4x GTX 1070 GTX 1080 Ti 4x GTX 1080 Ti 8x GTX 1080 Ti

4  0:0046 sec.  0:0011 sec.  0:0023 sec.  0:0006 sec.  0:0003 sec.
5  0:046 sec.  0:011 sec.  0:023 sec.  0:006 sec.  0:003 sec.
6  0:46 sec.  0:11 sec.  0:23 sec.  0:06 sec.  0:03 sec.
7  4:58 sec.  1:15 sec.  2:38 sec.  0:61 sec.  0:31 sec.
8  45:81 sec.  11:57 sec.  23:89 sec.  6:14 sec.  3:07 sec.
9  458:09 sec.  115:69 sec.  238:90 sec.  61:45 sec.  30:73 sec.
10  4580:96 sec.  1156:95 sec.  2389:02 sec.  614:54 sec.  307:27 sec.
11  763:5 min.  192:8 min.  398:2 min.  102:4 min.  51:21 min.
12  127:3 hours  32:1 hours.  66:4 hours  17:1 hours  8:54 hours
13  53 days  13:4 days  27:7 days  7:1 days  3:56 days
14  530 days  134 days  277 days  71 days  35:56 days
15  14:5 years  3:67 years  7:6 years  1:9 years  355:64 days
16  145 years  36:7 years  76 years  19 years  9:74 years

Iteration > 10; 000. It is obvious that increasing the iteration level
makes the PIN recovery more time consuming. We believe that our
analysis will be of practical assistance to forensic investigations.
Acknowledgement
This work was supported by Institute for Information & com-
munications Technology Promotion (IITP) grant funded by the
Korea government (MSIT) (No.2017-0-00344, Deciphering and
forensic analysis of recent mobile devices).
Appendix A. GPU-based bruteforce implementation
The PIN searching can be accelerated by using GPGPU (General-
Purpose computing on Graphics Processing Units), which is based
on parallel implementation (Hashcat Benchmarks). shows some
References
Armomurha, SSVCardExtractor, https://forum.xda-developers.com/attachment.
php?attachmentid¼644065&d¼1309648829.
JEB Decompiler by PNF Software, https://www.pnfsoftware.com.
Global smartphone market share by vendor 2009e2017, https://www.statista.com/
statistics/271496/global-market-share-held-by-smartphone-vendors-since-
4th-quarter-2009/, accessed: 2018-02-12.
Grassi, P.A., Fenton, J.L., Newton, E.M., Perlner, R.A., Regenscheid, A.R., Burr, W.E.,
Richer, J.P., June 2017. Digital Identity Guidelines-authentication and Lifecycle
Management, SP 800e863B, NIST.
Gyuwon, L., Hyunuk, H., Kibom, K., Taejoo, C., 2013. Analysis scheme on backup files
of Samsung smartphone available in forensic. KIPS Transactions on Computer
and Communication Systems 2 (8), 349e356.
hashcat, advanced password recovery, https://hashcat.net/hashcat/, accessed: 2018-
02-21.
Hashcat Benchmarks for Nvidia GTX 1080Ti and GTX 1070, https://www.
blackhillsinfosec.com/hashcat-benchmarks-nvidia-gtx-1080ti-gtx-1070-
hashcat-benchmarks/, accessed: 2017-07-20.
iTunes-Apple, https://www.apple.com/kr/itunes.
 M. Park et al. / Digital Investigation 26 (2018) 63e71 71

Jaehyeok, H., Sangjin, L., 2016. A practical approach to analyze smartphone backup
data as a digital evidence. In: DFRWS USA, p. 2016.
A. Lenzen, SBU-Extractor, https://github.com/Luncher91/SBU-Extractor.
LG Bridge-LG, http://www.lge.co.kr/lgekor/download-center/downloadCenterList.do.
Moriarty, K., Kaliski, B., Rusch, A., January 2017. PKCS5: Password-based Cryptog-
raphy Specification Version 2.1, RFC 8018.
SmartSwitch, http://www.samsung.com/sec/support/smartswitch.
Steven, J., Manico, J., Righetto, D., February 2018. Password Storage Cheat Sheet,
Tech. rep., OWASP accessed: 2018-02-19. https://www.owasp.org/index.php/
Password_Storage_Cheat_Sheet/.

View publication stats