Digital Investigation 28 (2019) 119e125

Contents lists available at ScienceDirect

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

Decrypting password-based encrypted backup data for Huawei

smartphones
Myungseo Park a, Giyoon Kim b, Younjai Park c, Insoo Lee c, Jongsung Kim a, b, *
a
Dept. of Financial Information Security, Kookmin University, 77 Jeongneung-Ro, Seongbuk-Gu, Seoul, 02707, South Korea
b
Dept. of Information Security, Cryptology and Mathematics, Kookmin University, 77 Jeongneung-Ro, Seongbuk-Gu, Seoul, 02707, South Korea
c
Digital Investigations Division, Prosecutors' Office, 157, Banpo-Daero, Seocho-Gu, Seoul, 06590, South Korea

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

Article history: Digital investigators sometimes obtain key evidence by extracting user data from the smartphones of
Received 11 December 2018 suspects. However, it is becoming more difficult to extract user data from smartphones, due to contin-
Received in revised form uous updates and the use of data encryption functions, such as Full Disk Encryption (FDE) and File Based
21 January 2019
Encryption (FBE). Backup data are usually stored in an encrypted form, in order to protect user privacy.
Accepted 22 January 2019
Available online 29 January 2019
Therefore, it is essential for digital investigators to be able to transform encrypted backup data into a
form that can be used as evidence. For this purpose, an analysis of the backup method used in a
smartphone is needed.
Keywords:
Smartphone forensics
In the research reported in this paper, we first analyze the backup process of Huawei smartphones, and
Smartphone backup then propose a method for decrypting Huawei smartphone backup data encrypted with a user-entered
Password recovery password. This process is performed by analyzing the Huawei application and PC program called
Decryption KoBackup and HiSuite, respectively. We developed a tool for user-entered password recovery and
encrypted backup data decryption. To the best of our knowledge, this is the first result analyzing all of the
backup processes available for Huawei smartphones and decrypting their backup data.
© 2019 Published by Elsevier Ltd.

Introduction Smartphones usually provide a local backup to the smartphone's

internal storage as well as a PC backup using PC backup programs,
Background such as Kies/Smart Switch (Samsung) (SmartSwitch), PC Suite/
Bridge (LG) (LG Bridge-LG), iTunes (Apple) (iTunes-Apple), HiSuite
The smartphone market is growing rapidly, and smartphones (Huawei) (HiSuite-Android Smart Dev), and others. These methods,
are now widely used. According to a survey of global smartphone provided by smartphone manufacturers, can quickly backup large
market share (Global smartphone market, 2009), Samsung amounts of data, including app and media data. However, some of
accounted for 23.4%, Apple for 15.6%, and Huawei for 11.8% in the the backup data are encrypted when stored. This feature is valuable
first quarter of 2018. However, in the second quarter of 2018, for protecting user privacy, but can impede digital investigations.
Huawei ranked second in the world, surpassing Apple's smart- Forensic investigators are ultimately required to access smartphone
phone market share for the first time ever, with a 20.9% market data in plaintext. In order to achieve this aim, we must analyze the
share for Samsung, 15.8% for Huawei, and 12.1% for Apple. There- backup process for each smartphone manufacturer, and determine
fore, the analysis of Huawei smartphones is becoming ever more how to decrypt the backup data. If the backup data are encrypted
important to digital investigators. using a user-entered value, such as a Personal Identification
Number (PIN) or a password, recovering this value should take
precedence.

* Corresponding author. Dept. of Financial Information Security, Kookmin Uni-

versity, 77 Jeongneung-Ro, Seongbuk-Gu, Seoul, 02707, South Korea. Related work
E-mail addresses: pms91@kookmin.ac.kr (M. Park), gi0412@kookmin.ac.kr
(G. Kim), park1656@spo.go.kr (Y. Park), insoo21@spo.go.kr (I. Lee), jskim@
kookmin.ac.kr (J. Kim). Studies on smartphone backup data have been conducted for
URL: http://dfnc.kookmin.ac.kr/ several years. Jaehyeok and Sangjin (2016) analyzed the Samsung

https://doi.org/10.1016/j.diin.2019.01.008
1742-2876/© 2019 Published by Elsevier Ltd.
120 M. Park et al. / Digital Investigation 28 (2019) 119e125

backup programs Kies 3.0 and Smart Switch 4.1.16 to reveal their
Backup data storage path (with password):
encryption method and backup processes (Han and Lee, 2016), - HuaweiBackup\backupFiles1\YYYY  MM  DD HH  MM 
(Han). However, their study was confined to analysis of the backup SS
program, and did not analyze the PIN-based encryption process. To
Media files (common):
address these limitations, Myungseo et al. (2018) analyzed the - Picture files: HuaweiBackup\media\photo
backup process of a smartphone, and revealed the encryption - Recording files: HuaweiBackup\media\recording
processes of the Samsung smartphone using the Smart Switch - Video files: HuaweiBackup\media\video
4.1.16 (Park et al., 2018). - Document files: HuaweiBackup\media\doc
Hashcat, an open source program dedicated to password re-
covery, provides a password recovery function for Apple smart- PC Backup. PC backup is synchronized between the Huawei
phone data (hashcat, 2018). When a password used for the Apple smartphone and HiSuite on a PC, via a USB connection. As with local
smartphone backup is revealed by Hashcat or other methods, it is backup, the backup data are encrypted with a password. However,
possible to decrypt the backup data using commercial tools, such as unlike the situation with local backup, PC backup encrypts both DB
FINALMobile Forensics (FINALMobile Forensics) or Elcomsoft Phone files and media files. It also encrypts DB files even when a password
Breaker (Elcomsoft Phone Breaker). Though backup data decryp- is not entered. Table 1 shows backup files encrypted by the local
tion for most smartphone manufacturers has been studied, the and PC backups. The backup data are stored in the same path
backup data of Huawei smartphones have not been studied to date. regardless of the use of password.
As its global smartphone market share increases, the demand for
data acquisition from Huawei smartphones will also increase, and
Backup data storage path:
thus research on the recovery of their backup data is needed. - %USERPROFILE%Documents\HiSuite\backup\

Backup folder name:
Our contributions - HUAWEI ðDevice NameÞ YYYY  MM  DD HH:MM:SS

In this paper, we analyze the entire backup process of Huawei

smartphones. We present a method to recover a user-entered
Detailed analysis of backup processes
password, and use it to decrypt the backup data of Huawei
smartphones. Our contributions are summarized as follows:
The backup processes for Huawei smartphones are performed
on a smartphone or on a PC. As stated earlier, local backup is per-
1) We analyzed and reverse engineered the Huawei smartphone
formed only on a smartphone, while PC backup is performed both
application, KoBackup, and its PC backup program, HiSuite,1 to
on a smartphone and a PC. The application file that manages
reveal both the local and PC backup processes, including
backups in smartphones is ’KoBackup.apk’. By reverse engineering
password-based encryption.
this application using the JEB Decompiler (JEB Decompiler), we
2) We identified several authenticators in the backup processes
uncovered the backup procedure as well as the Key Derivation
that can judge whether a user-entered password candidate is
Functions (KDFs) and encryption algorithms used. These were
correct or not. We developed a password recovery algorithm
identified by the bytecode, libraries, and resource files. The names
based on these authenticators.
of Java objects, functions, and variables were obfuscated in byte-
3) We developed a tool that can decrypt password-based encryp-
code, but the function names called by the library were preserved.
ted DB and media files generated during the backup process.
The backup process on the PC was revealed by reversing HiSuite
(Version : 8.0.1.303_OVE) with static and dynamic analysis using
Analysis of backup processes for Huawei smartphones
IDA pro (IDA).
Backup process on the smartphone. On the smartphone, the DB
Overview of local and PC backup methods
file encryption method depends on the value of type_attch, which
can have values of 0, 2, or 3. DB file encryption is performed only
Huawei provides options for both local backup and PC backup.
when the value of type_attch is 2 or 3. These values can be checked
Local backup starts from a smartphone, while PC backup starts from
in the “info.xml” file generated after the backup is finished.
a PC. The backup process involves the default applications and can
The DB files listed in Table 1 are encrypted through a password-
include third party applications, DB files corresponding to appli-
based encryption key DEK (DB Encryption Key). The DEK is gener-
cations, and media files such as pictures, recordings, documents,
ated by Eq. (1) (resp., Eq. (2)) when the value of type_attch is 2
and videos.
(resp., 3).
Local Backup. Local backup is backup performed on the
smartphone itself, where the backup data are stored in the internal DEK ¼ MD5ðpasswordÞ; (1)
memory, an SD card, or a USB drive. When a user enters a password,
the backup data are encrypted based on the password, but backup
C ¼ AES128  CTR  NopaddingðP; DEK; CounterÞ:
data encryption is not performed unless a password is entered. The
password can be between 4 and 32 digits long, and can include In order to generate the DEK, a password is commonly used as a
numbers, lowercase letters, uppercase letters, and special charac- parameter. In Eq. (1), the KDF used to generate the DEK is the MD5,
ters. Local backup applies encryption only to DB files. The backup and its input parameter is a user-entered password or a 32-byte
data storage path depends on whether a password is entered or not, fixed password transmitted from the PC. The former password is
although media files are created in a common path. entered by the user on a smartphone for a local backup, or on a PC
for a PC backup, while the latter password is a fixed value trans-

Backup data storage path (without password): mitted only during PC backup without a user-entered password.
- HuaweiBackup\backupFiles\YYYY  MM  DD HH  MM  SS The DB files are encrypted using the DEK, and the encryption al-
gorithm is AES128-CTR. In Eq. (1), P represents each DB file, C is the
corresponding ciphertext, the DEK is the encryption key for
1
In our analysis, HiSuite 8.0.1.303_OVE was used, the latest version of HiSuite. AES128-CTR, and the Counter is a 16-byte string which is all 0.
 M. Park et al. / Digital Investigation 28 (2019) 119e125 121

Table 1
Backup list encrypted by the local and PC backups.

Backup Item Local backup PC backup Backup files

with password without password with password without password

DB file Alarm C P C C alarm.db

Contact C P C C contact.db
Message C P C C message.db
Call log C P C C calllog.db
Calendar C P C C calendar.db
Weather C P C C weather.db
Preferences C P C C harassment.db; HWlanucher.db
Application(db) C P C C *.db

Application(apk) P P P P *.apk

Media file Picture P P C P *.jpg;*.png; etc

Video P P C P *.mp4;*.avi; etc
Recording P P C P *.mp3;*.ogg; etc
Document P P C P *.doc;*.pdf; etc

Backup files labelled with P are stored in plaintext, and backup files labelled with C are stored in ciphertext.

Password recovery and backup data decryption for Huawei

DEK ¼ PBKDF2  HMAC  SHA256ðpassword; salt; 5000Þ; smartphones
(2)
In this section, we describe methods for recovering a user-
entered password and exploit the recovered password to decrypt
C ¼ AES256  CTR  NopaddingðP; DEK; CounterÞ: backup data.2 Our work is aimed at decrypting all of backup data
In Eq. (2), the KDF used to generate the DEK is the Password encrypted with Huawei smartphones or HiSuite.
Based Key Derivation Function 2 (PBKDF2) algorithm with HMAC-
SHA256, i.e., PBKDF2-HMAC-SHA256, and its input parameters
are password, salt, and the number of iterations (Moriarty et al., Password recovery
2017). Here, the password is either a user-entered password or a
fixed 32-byte password transmitted from the PC. These passwords We analyzed all the backup processes for Huawei smartphones
are the same as those in Eq. (1)). The salt is a 32-byte random value, through reverse engineering. However, it is impossible to decrypt
which is different for each DB file to be encrypted, while the other password-based encrypted backup data without a user-entered
input parameters remain the same. The number of iterations is password. Therefore, it is necessary to first recover the user-
5000. The DEK used to encrypt each DB file uses a different value entered password.
because the salt is assigned a different random value for each file. In this study, we found four password recovery methods; that is,
Each DB file is encrypted using the DEK, and the encryption algo- four password authenticators. The password recovery time differs
rithm is AES256-CTR. In Eq. (2), P represents each DB file, C is the depending on the method. Each method works with a different
corresponding ciphertext, the DEK is the encryption key for environment, and thus the fastest method differs by situation.
AES256-CTR, and the Counter is a 16-byte random string that is a The first and second password authenticators are in the
different value for each file encrypted. “info.xml” file, generated in the smartphone during the backup
Backup process on the PC. Media files such as document, video, process. This file contains information such as the product model,
recording, and picture files are encrypted on the PC only when the version, and backup file encryption method. In this file, the
user enters a password. For this, media files are before transmitted “BackupFilesTypeInfo” node contains the child nodes promptMsg,
in plaintext from the smartphone to the PC. The MEK (Media checkMsg, type_attch, and type, among which checkMsg and
Encryption Key) used for their encryption is generated based on a type_attch can be used for our password recovery. Depending on
user-entered password. The encryption for the media files during the type_attch, the checkMsg value is generated. The checkMsg
the PC backup is performed as follows: value is generated from a user-entered password, and thus if we
know how to generate checkMsg, which is a fixed value in the
MEK ¼ SHA256ðuser  entered passwordÞ; (3) “BackupFileTypeInfo” node, we can verify that a user-entered
password is valid.
If type_attch is 2, the checkMsg is computed as follows:
C ¼ AES128  CTR  NopaddingðP; MEK016 ; CounterÞ:
In Eq. (3), a user-entered password is used as the input for checkMsg ¼ SHA256ðuser  entered passwordÞ: (4)
SHA256, and MEK is its 32-byte output. The upper 16 bytes of MEK
are used as the key for AES128-CTR. In Eq. (3), P is a target media Where checkMsg is the output of SHA256 with a user-entered
file, and the corresponding ciphertext is C. The Counter assigned for password input. If type_attch is 3, the checkMsg is computed as
the encryption of each media file uses a different random 16-byte follows.
value. After the file is encrypted, the extension is modified by
appending .enc to the file name.
2
Fig. 1 is a flowchart of the entire backup process for Huawei Note that our method can extract all the backup files listed in Table 1 in a
plaintext form. That is, our method can be used to decrypt the DB files encrypted
smartphones, including both local and PC backups. Table 2 sum- when a user-entered password is not used in the PC backup. Our method can also
marizes the KDFs and encryption algorithms used for the Huawei extract all the backup data which are not encrypted during the local or PC backup
backup process. process.
122 M. Park et al. / Digital Investigation 28 (2019) 119e125

Fig. 1. The entire backup process for Huawei smartphones using KoBackup and HiSuite.

Table 2
KDFs and encryption algorithms used for Huawei backup data.

Eqs. type_attch KDF Key materials & parameters Encryption Algorithm Parameters
Num.

(1) 2 MD5(password) password: a user-entered password or a fixed 32- AES128-CTR(P; Key; P: a DB file
byte password Counter) Key: KDF output
Counter: a 16-byte zero
value
(2) 3 PBKDF2-HMAC-SHA256 (password, salt, password: a user-entered password or a fixed 32- AES256-CTR(P, Key, P: a DB file
iteration)) byte password Counter) Key: KDF output
salt: a 32-byte random value Counter: a 16-byte random
iteration: 5000 value
(3) e SHA256(password) password: a user-entered password AES128-CTR(P, Key, P: a media file
Counter) Key: Upper 16-byte of KDF
output
Counter: a 16-byte random
value

The parameters in bold are different random values for each file encrypted.

possible to improve the efficiency of password recovery by using a

checkMsg031 ¼ PBKDF2  HMAC  SHA256 table that stores all checkMsgs calculated in advance, or by using a
(5)
ðuser  entered password; salt; 5000Þ: rainbow table.3 Unlike when type_attch is 2, the efficiency of the
pre-computed table is low due to the addition of a random salt to
Where checkMsg031 is the output of PBKDF2-HMAC-SHA256. Of generate checkMsg in type_attch 3.
the input parameters for PBKDF2-HMAC-SHA256, salt is a The third password authenticator is in a “backupinfo.ini” file.
randomly generated 32-byte value, which is checkMsg3263 . After backup on the PC, a “backupinfo.ini” file is created and has the
Concatenating the output of PBKDF2-HMAC-SHA256 with the salt
generates a 64-byte checkMsg.
If type_attch is 2, there is no input parameter for the checkMsg 3
A rainbow table is a precomputed chain table for reversing a cryptographic
computation other than a user-entered password. Therefore, it is hash function, usually for cracking password hashes.
 M. Park et al. / Digital Investigation 28 (2019) 119e125 123

Table 3
Time required for the recovery of the user-entered password with a brute-force search.

No.b type_attch Equation for password recovery Password digits

info.xml backupinfo.ini encrypted media file 4 5 6 7 8

a a a
1 2 Password recovery using Eq. (4)  7 sec.  10 min.  10 hours  34 days  7 years
O e e
a
2 3 Password recovery using Eq. (5)  38 hours.  118 days  23 years  1; 714 years  126; 843 years
O e e
a a a
3 2 or 3 Password recovery using Eq. (6)  27 sec.  35 min.  42 hours  128 days  26 years
e O e
4 2 or 3 Password recovery using Eq. (3)  10 sec.a  13 min.a  15 hoursa  49 days  10 years
e e O
a
The times are verified by our computer programming using a single CPU, and the others are estimated times.
b
Nos. 1 and 2 work both with local and PC backups, while the others apply only to the PC backup.

same role as the “info.xml” file on the smartphone. We can verify Table 3 summarizes the requirements for each password re-
the correct user-entered password using the pwdsalt_iv, pass- covery method and the time required for a brute-force search. In
word,4 and pwdsalt values stored in this file. Each value is derived Table 3, the No. 1 password recovery method is the fastest, but it is
using as follows: applicable only to type_attch 2, which is compatible only with
Huawei's old models. On the other hand, the No. 4 method applies
password ¼ Base64 encodeðHMAC  SHA256ðcheck; user regardless of the type_attch, and is more than three times faster
 entered passwordÞÞ; (6) than the Nos. 2 and 3 methods.

IMV ¼ #Base64 encodeðcheckÞ#; Backup data decryption

In this section, we describe how to decrypt backup data

pwdsalt ¼ AES256  CBC encrypted by the backup processes described in Section 2.2. As
 PKCS7PaddingðIMV; FixedKey; pwdsalt ivÞ: shown in Fig. 2, we separate our decryption process into two
phases: a user-entered password recovery phase, and an encrypted
The password is a base64 encoded value of the output of HMAC- backup file decryption phase.
SHA256 using a 32-byte random check as the HMAC message and a For the user-entered password recovery phase, we use the four
user-entered password as the HMAC key. The pwdsalt is the methods described in section 3.1, identify the requirements for uti-
ciphertext of AES256-CBC with input parameters IMV (Intermedi- lizing each password recovery method, and adopt the fastest method
ate Value), FixedKey, and pwdsalt_iv. Here, IMV is a plaintext value for the situation. For example, if type_attch is 3, the fastest method is
with the character # appended to both ends of the base64 encoded to use the No. 4 method in Table 3, but if we cannot obtain an
value of the check. The FixedKey is used as the encryption key, encrypted media file, we can use the No. 3 method. The next best
which is the same as the 32-byte fixed value transmitted from the approach is to use ‘backupinfo.ini’. If we do not have one, we can
PC in Fig. 1. The pwdsalt_iv is used as the IV (Initialize Vector) and perform a password recovery using the No. 2 method. If type_attch is
padded with PKCS7Padding. 2, it would be obviously better to use the No. 1 method.
In order to verify the user-entered password, we must first Once we finish password recovery, or know the password, we
determine the check, which is derived from pwdsalt and can perform encrypted backup file decryption. We apply the user-
pwdsalt_iv. The IMV is derived by removing the padding from the entered password obtained in the previous phase to Eqs. (1)(3).
value obtained by decrypting pwdsalt with AES256-CBC, FixedKey To decrypt the DB files, we use the information contained in the
and pwdsalt_iv. We can then obtain the check by removing the # at ‘BackupFileModuleInfo’ node of ‘info.xml’. The ‘Back-
each end and decoding the result with base64. It is therefore upFileModuleInfo’ node contains the name of the file to be
possible to verify the correct user-entered password using the decrypted, the material needed to generate the decryption key
obtained check. (¼encryption key), and the Counter used for the decryption algo-
The fourth method, which is a known plaintext attack using an rithm. In order to decrypt the media files, the .xml file containing
encrypted media file based on the user-entered password (using the backup information for each media file is used. Each ‘File’ node
Eq. (3)), was not intended by the manufacturer, but it can be used to includes the name of the file to be decrypted and IV which is used
recover the user-entered password more rapidly than the methods as the Counter. Table 4 summarizes the algorithms used to decrypt
described in Eqs. (5) and (6). Since the beginning of each media file encrypted backup data.
contains its signature information (for example, a JPEG file starts Fig. 3 shows two examples produced by our decryption tool. The
with ‘0xffd8’), it can be used as an authenticator for the known left side of Fig. 3 shows the result of decrypting an encrypted DB
plaintext attack. To exploit this recovery method, we need an file, and the right side shows the result of decrypting an encrypted
encrypted media file and the Counter used for its encryption. In picture file. Using our decryption tool, we can decrypt all the files
order to recover the user-entered password, its candidate to be contained in encrypted Huawei smartphone backup data.
tested and the corresponding Counter are substituted in Eq. (3) to
decrypt the target encrypted media file, and then we check
whether the decrypted media file includes its signature Conclusion
information.
In this paper, we described a method for decrypting (password-
based) backup data encrypted using Kobackup, a Huawei smart-
4
Note that the “password” stored in the “backupinfo.ini” file is different from a phone backup application, and HiSuite 8.0.1.303_OVE, a PC backup
“user-entered password”. program. We first analyzed the entire backup process of Huawei
124 M. Park et al. / Digital Investigation 28 (2019) 119e125

Fig. 2. A flowchart for our user-entered password recovery and backup data decryption.

Table 4
Decryption algorithms used for backup data.

Eq. type_attch KDF Key materials & parameters Decryption Algorithm Parameters
Num.

(1) 2 MD5(password) password: Acquired password AES256-CTR1(C, Key, C: an encrypted DB file

Counter) Key: KDF output
Counter: 16-byte zero value
(2) 3 PBKDF2-HMAC-SHA256 (password, password: Acquired password salt: Upper 32- AES256-CTR1(C, Key, C: an encrypted DB file
salt, iteration)) byte of encMsgV3 Counter) Key: KDF output
iteration: 5000 Counter: Lower 16-byte of
encMsgV3
(3) e SHA256(password) password: Acquired password AES128-CTR1(C, Key, C: an encrypted DB file
Counter) Key: Upper 16-byte of KDF output
Counter: 16-byte IV of xml file by
media type

The parameters in bold are different random values for each file encrypted.-
 M. Park et al. / Digital Investigation 28 (2019) 119e125 125

Fig. 3. Examples: file decryption results using our decryption tool.

smartphones, and then uncovered the detailed encryption method Global smartphone market share by vendor 2009-2018, https://www.statista.com/
statistics/271496/global-market-share-held-by-smartphone-vendors-since-
used in their backup processes. Based on our analysis, we devel-
4th-quarter-2009/, accessed: 2018-10-15.
oped a tool for user-entered password recovery and decryption of J. Han, Smartphone-Backup-Data-Extractor, https://github.com/JaehyeokHan/
encrypted backup data. Our work is the first on Huawei smart- Smartphone-Backup-Data-Extractor.
phone backup data decryption, and we believe that it will have a Han, J., Lee, S., 2016. A practical approach to analyze smartphone backup data as a
digital evidence. In: DFRWS USA, p. 2016.
significant practical impact for forensic investigations. hashcat, advanced password recovery, https://hashcat.net/hashcat/, accessed: 2018-
02-21.
Acknowledgement HiSuite-Android Smart Device Manager, https://consumer.huawei.com/minisite/
HiSuite_en/.
IDA, https://www.hex-rays.com/products/ida/index.shtml.
This work was supported as part of Military Crypto Research iTunes-Apple, https://www.apple.com/kr/itunes.
Center (UD170109ED) funded by Defense Acquisition Program LG Bridge-LG, http://www.lge.co.kr/lgekor/download-center/downloadCenterList.
do.
Administration and Agency for Defense Development. Moriarty, K., Kaliski, B., Rusch, A., January 2017. PKCS5: Password-Based Cryptog-
raphy Specification Version 2.1, RFC 8018.
References FINALMobile Forensics, http://finaldata.com/mobile/.
Park, M., Kim, H., Kim, J., 2018. How to decrypt PIN-Based encrypted backup data of
Samsung smartphones. Digit. Invest. 26, 63e71.
JEB Decompiler by PNF Software, https://www.pnfsoftware.com.
SmartSwitch, http://www.samsung.com/sec/support/smartswitch.
Elcomsoft Phone Breaker, https://www.elcomsoft.com/eppb.html.