🔥 PoC https://github.com/sinsinology/CVE-2023-20887 for CVE-2023-20887 VMWare Aria Operations for Networks (vRealize Network Insight) unauthenticated RCE This vulnerability allows a remote unauthenticated attacker to execute arbitrary commands on the underlying operating system as the root user. The RPC interface is protected by a reverse proxy which can be bypassed.
ACTION NOTICE: Impacted ESG appliances must be immediately replaced regardless of patch version level. If you have not replaced your appliance after receiving notice in your UI, contact support now (support@barracuda.com).
Barracuda’s remediation recommendation at this time is full replacement of the impacted ESG.
JUNE 1st, 2023:
Preliminary Summary of Key Findings
Document History
Version/Date
Notes
1.0: May 30, 2023
Initial Document
1.1 : June 1, 2023
Additional IOCs and rules included
Barracuda Networks’ priorities throughout this incident have been transparency and to use this as an opportunity to strengthen our policies, practices, and technology to further protect against future attacks. Although our investigation is ongoing, the purpose of this document is to share preliminary findings, provide the known Indicators of Compromise (IOCs), and share YARA rules to aid our customers in their investigations, including with respect to their own environments.
Timeline
On May 18, 2023, Barracuda was alerted to anomalous traffic originating from Barracuda Email Security Gateway (ESG) appliances.
On May 18, 2023, Barracuda engaged Mandiant, leading global cyber security experts, to assist in the investigation.
On May 19, 2023, Barracuda identified a vulnerability (CVE-2023-28681) in our Email Security Gateway appliance (ESG).
On May 20, 2023, a security patch to remediate the vulnerability was applied to all ESG appliances worldwide.
On May 21, 2023, a script was deployed to all impacted appliances to contain the incident and counter unauthorized access methods.
A series of security patches are being deployed to all appliances in furtherance of our containment strategy.
Key Findings
While the investigation is still on-going, Barracuda has concluded the following:
The vulnerability existed in a module which initially screens the attachments of incoming emails. No other Barracuda products, including our SaaS email security services, were subject to the vulnerability identified.
Earliest identified evidence of exploitation of CVE-2023-2868 is currently October 2022.
Barracuda identified that CVE-2023-2868 was utilized to obtain unauthorized access to a subset of ESG appliances.
Malware was identified on a subset of appliances allowing for persistent backdoor access.
Evidence of data exfiltration was identified on a subset of impacted appliances..
Users whose appliances we believe were impacted have been notified via the ESG user interface of actions to take. Barracuda has also reached out to these specific customers. Additional customers may be identified in the course of the investigation.
CVE-2023-2868
On May 19, 2023, Barracuda Networks identified a remote command injection vulnerability (CVE-2023-2868) present in the Barracuda Email Security Gateway (appliance form factor only) versions 5.1.3.001-9.2.0.006. The vulnerability stemmed from incomplete input validation of user supplied .tar files as it pertains to the names of the files contained within the archive. Consequently, a remote attacker could format file names in a particular manner that would result in remotely executing a system command through Perl’s qx operator with the privileges of the Email Security Gateway product.
Barracuda’s investigation to date has determined that a third party utilized the technique described above to gain unauthorized access to a subset of ESG appliances.
Malware
This section details the malware that has been identified to date, and to assist in tracking, codenames for the malware have been assigned.
SALTWATER
SALTWATER is a trojanized module for the Barracuda SMTP daemon (bsmtpd) that contains backdoor functionality. The capabilities of SALTWATER include the ability to upload or download arbitrary files, execute commands, as well as proxy and tunneling capabilities.
Identified at path: /home/product/code/firmware/current/lib/smtp/modules on a subset of ESG appliances.
The backdoor is implemented using hooks on the send, recv, close syscalls and amounts to five components, most of which are referred to as “Channels” within the binary. In addition to providing proxying capabilities, these components exhibit backdoor functionality. The five (5) channels can be seen in the list below.
DownloadChannel
UploadChannel
ProxyChannel
ShellChannel
TunnelArgs
Mandiant is still analyzing SALTWATER to determine if it overlaps with any other known malware families.
Table 1 below provides the file metadata related to a SALTWATER variant.
SEASPY is an x64 ELF persistence backdoor that poses as a legitimate Barracuda Networks service and establishes itself as a PCAP filter, specifically monitoring traffic on port 25 (SMTP) and port 587. SEASPY contains backdoor functionality that is activated by a «magic packet».
Identified at path: /sbin/ on a subset of ESG appliances.
Mandiant analysis has identified code overlap between SEASPY and cd00r, a publicly available backdoor.
Table 2 below provides the file metadata related to a SEASPY variant.
SEASIDE is a Lua based module for the Barracuda SMTP daemon (bsmtpd) that monitors SMTP HELO/EHLO commands to receive a command and control (C2) IP address and port which it passes as arguments to an external binary that establishes a reverse shell.
Table 3 below provides the file metadata related to a SEASIDE.
Ensure your ESG appliance is receiving and applying updates, definitions, and security patches from Barracuda. Contact Barracuda support (support@barracuda.com) to validate if the appliance is up to date.
Discontinue the use of the compromised ESG appliance and contact Barracuda support (support@barracuda.com) to obtain a new ESG virtual or hardware appliance.
Rotate any applicable credentials connected to the ESG appliance: o Any connected LDAP/AD o Barracuda Cloud Control o FTP Server o SMB o Any private TLS certificates
Review your network logs for any of the IOCs listed below and any unknown IPs. Contact compliance@barracuda.com if any are identified.
To support customers in the investigations of their environments, we are providing a list of all endpoint and network indicators observed over the course of the investigation to date. We have also developed a series of YARA rules that can be found in the section below.
Endpoint IOCs
Table 4 lists the endpoint IOCs, including malware and utilities, attributed to attacker activity during the investigation.
File Name
MD5 Hash
Type
1
appcheck.sh
N/A
Bash script
2
aacore.sh
N/A
Bash script
3
1.sh
N/A
Bash script
4
mod_udp.so
827d507aa3bde0ef903ca5dec60cdec8
SALTWATER Variant
5
intent
N/A
N/A
6
install_helo.tar
2ccb9759800154de817bf779a52d48f8
TAR Package
7
intent_helo
f5ab04a920302931a8bd063f27b745cc
Bash script
8
pd
177add288b289d43236d2dba33e65956
Reverse Shell
9
update_v31.sh
881b7846f8384c12c7481b23011d8e45
Bash script
10
mod_require_helo.lua
cd2813f0260d63ad5adf0446253c2172
SEASIDE
11
BarracudaMailService
82eaf69de710abdc5dea7cd5cb56cf04
SEASPY
12
BarracudaMailService
e80a85250263d58cc1a1dc39d6cf3942
SEASPY
13
BarracudaMailService
5d6cba7909980a7b424b133fbac634ac
SEASPY
14
BarracudaMailService
1bbb32610599d70397adfdaf56109ff3
SEASPY
15
BarracudaMailService
4b511567cfa8dbaa32e11baf3268f074
SEASPY
16
BarracudaMailService
a08a99e5224e1baf569fda816c991045
SEASPY
17
BarracudaMailService
19ebfe05040a8508467f9415c8378f32
SEASPY
18
mod_udp.so
1fea55b7c9d13d822a64b2370d015da7
SALTWATER Variant
19
mod_udp.so
64c690f175a2d2fe38d3d7c0d0ddbb6e
SALTWATER Variant
20
mod_udp.so
4cd0f3219e98ac2e9021b06af70ed643
SALTWATER Variant
Table 4: Endpoint IOCs
Network IOCs
Table 5 lists the network IOCs, including IP addresses and domain names, attributed to attacker activity during the investigation.
Indicator
ASN
Location
1
xxl17z.dnslog.cn
N/A
N/A
2
mx01.bestfindthetruth.com
N/A
N/A
3
64.176.7.59
AS-CHOOPA
US
4
64.176.4.234
AS-CHOOPA
US
5
52.23.241.105
AMAZON-AES
US
6
23.224.42.5
CloudRadium L.L.C
US
7
192.74.254.229
PEG TECH INC
US
8
192.74.226.142
PEG TECH INC
US
9
155.94.160.72
QuadraNet Enterprises LLC
US
10
139.84.227.9
AS-CHOOPA
US
11
137.175.60.253
PEG TECH INC
US
12
137.175.53.170
PEG TECH INC
US
13
137.175.51.147
PEG TECH INC
US
14
137.175.30.36
PEG TECH INC
US
15
137.175.28.251
PEG TECH INC
US
16
137.175.19.25
PEG TECH INC
US
17
107.148.219.227
PEG TECH INC
US
18
107.148.219.55
PEG TECH INC
US
19
107.148.219.54
PEG TECH INC
US
20
107.148.219.53
PEG TECH INC
US
21
107.148.219.227
PEG TECH INC
US
22
107.148.149.156
PEG TECH INC
US
23
104.223.20.222
QuadraNet Enterprises LLC
US
24
103.93.78.142
EDGENAP LTD
JP
25
103.27.108.62
TOPWAY GLOBAL LIMITED
HK
26
137.175.30.86
PEGTECHINC
US
27
199.247.23.80
AS-CHOOPA
DE
28
38.54.1.82
KAOPU CLOUD HK LIMITED
SG
29
107.148.223.196
PEGTECHINC
US
30
23.224.42.29
CNSERVERS
US
31
137.175.53.17
PEGTECHINC
US
32
103.146.179.101
GIGABITBANK GLOBAL
HK
Table 5: Network IOCs
YARA Rules
CVE-2023-2868
The following three (3) YARA rules can be used to hunt for the malicious TAR file which exploits CVE-2023-2868:
rule M_Hunting_Exploit_Archive_2
{
meta:
description = "Looks for TAR archive with /tmp/ base64 encoded being part of filename of enclosed files"
date_created = "2023-05-26"
date_modified = "2023-05-26"
md5 = "0d67f50a0bf7a3a017784146ac41ada0"
version = "1.0"
strings:
$ustar = { 75 73 74 61 72 }
$b64_tmp = "/tmp/" base64
condition:
filesize < 1MB and
$ustar at 257 and
for any i in (0 .. #ustar) : (
$b64_tmp in (i * 512 .. i * 512 + 250)
)
}
rule M_Hunting_Exploit_Archive_3
{
meta:
description = "Looks for TAR archive with openssl base64 encoded being part of filename of enclosed files"
date_created = "2023-05-26"
date_modified = "2023-05-26"
md5 = "0d67f50a0bf7a3a017784146ac41ada0"
version = "1.0"
strings:
$ustar = { 75 73 74 61 72 }
$b64_openssl = "openssl" base64
condition:
filesize < 1MB and
$ustar at 257 and
for any i in (0 .. #ustar) : (
$b64_openssl in (i * 512 .. i * 512 + 250)
)
}
rule M_Hunting_Exploit_Archive_CVE_2023_2868
{
meta:
description = "Looks for TAR archive with single quote/backtick as start of filename of enclosed files. CVE-2023-2868"
date_created = "2023-05-26"
date_modified = "2023-05-26"
md5 = "0d67f50a0bf7a3a017784146ac41ada0"
version = "1.0"
strings:
$ustar = { 75 73 74 61 72 }
$qb = "'`"
condition:
filesize < 1MB and
$ustar at 257 and
for any i in (0 .. #ustar) : (
$qb at (@ustar[i] + 255)
)
}
SALTWATER
The following three (3) YARA rule can be used to hunt for SALTWATER:
rule M_Hunting_Linux_Funchook
{
strings:
$f = "funchook_"
$s1 = "Enter funchook_create()"
$s2 = "Leave funchook_create() => %p"
$s3 = "Enter funchook_prepare(%p, %p, %p)"
$s4 = "Leave funchook_prepare(..., [%p->%p],...) => %d"
$s5 = "Enter funchook_install(%p, 0x%x)"
$s6 = "Leave funchook_install() => %d"
$s7 = "Enter funchook_uninstall(%p, 0x%x)"
$s8 = "Leave funchook_uninstall() => %d"
$s9 = "Enter funchook_destroy(%p)"
$s10 = "Leave funchook_destroy() => %d"
$s11 = "Could not modify already-installed funchook handle."
$s12 = " change %s address from %p to %p"
$s13 = " link_map addr=%p, name=%s"
$s14 = " ELF type is neither ET_EXEC nor ET_DYN."
$s15 = " not a valid ELF module %s."
$s16 = "Failed to protect memory %p (size=%"
$s17 = " protect memory %p (size=%"
$s18 = "Failed to unprotect memory %p (size=%"
$s19 = " unprotect memory %p (size=%"
$s20 = "Failed to unprotect page %p (size=%"
$s21 = " unprotect page %p (size=%"
$s22 = "Failed to protect page %p (size=%"
$s23 = " protect page %p (size=%"
$s24 = "Failed to deallocate page %p (size=%"
$s25 = " deallocate page %p (size=%"
$s26 = " allocate page %p (size=%"
$s27 = " try to allocate %p but %p (size=%"
$s28 = " allocate page %p (size=%"
$s29 = "Could not find a free region near %p"
$s30 = " -- Use address %p or %p for function %p"
condition:
filesize < 15MB and uint32(0) == 0x464c457f and (#f > 5 or 4 of ($s*))
}
rule M_Hunting_Linux_SALTWATER_1
{
strings:
$s1 = { 71 75 69 74 0D 0A 00 00 00 33 8C 25 3D 9C 17 70 08 F9 0C 1A 41 71 55 36 1A 5C 4B 8D 29 7E 0D 78 }
$s2 = { 00 8B D5 AD 93 B7 54 D5 00 33 8C 25 3D 9C 17 70 08 F9 0C 1A 41 71 55 36 1A 5C 4B 8D 29 7E 0D 78 }
condition:
filesize < 15MB and uint32(0) == 0x464c457f and any of them
}
rule M_Hunting_Linux_SALTWATER_2
{
strings:
$c1 = "TunnelArgs"
$c2 = "DownloadChannel"
$c3 = "UploadChannel"
$c4 = "ProxyChannel"
$c5 = "ShellChannel"
$c6 = "MyWriteAll"
$c7 = "MyReadAll"
$c8 = "Connected2Vps"
$c9 = "CheckRemoteIp"
$c10 = "GetFileSize"
$s1 = "[-] error: popen failed"
$s2 = "/home/product/code/config/ssl_engine_cert.pem"
$s3 = "libbindshell.so"
condition:
filesize < 15MB and uint32(0) == 0x464c457f and (2 of ($s*) or 4 of ($c*))
}
The following SNORT rule can be used to hunt for SEASPY magic packets:
alert tcp any any -> any [25,587] (msg:»M_Backdoor_SEASPY»; flags:S; dsize:>9; content:»oXmp»; offset:0; depth:4; threshold:type limit,track by_src,count 1,seconds 3600; sid:1000000; rev:1;)
The following SNORT rules require Suricata 5.0.4 or newer and can be used to hunt for SEASPY magic packets:
alert tcp any any -> any [25,587] (msg:»M_Backdoor_SEASPY_1358″; flags:S; tcp.hdr; content:»|05 4e|»; offset:22; depth:2; threshold:type limit,track by_src,count 1,seconds 3600; sid:1000001; rev:1;)
alert tcp any any -> any [25,587] (msg:»M_Backdoor_SEASPY_58928″; flags:S; tcp.hdr; content:»|e6 30|»; offset:28; depth:2; byte_test:4,>,16777216,0,big,relative; threshold:type limit,track by_src,count 1,seconds 3600; sid:1000002; rev:1;)
alert tcp any any -> any [25,587] (msg:»M_Backdoor_SEASPY_58930″; flags:S; tcp.hdr; content:»|e6 32|»; offset:28; depth:2; byte_test:4,>,16777216,0,big,relative; byte_test:2,>,0,0,big,relative; threshold:type limit,track by_src,count 1,seconds 3600; sid:1000003; rev:1;)
MAY 30th, 2023:
Preliminary Summary of Key Findings
Barracuda Networks priorities throughout this incident have been transparency and to use this as an opportunity to strengthen our policies, practices, and technology to further protect against future attacks. Although our investigation is ongoing, the purpose of this document is to share preliminary findings, provide the known Indicators of Compromise (IOCs), and share YARA rules to aid our customers in their investigations, including with respect to their own environments.
Timeline
On May 18, 2023, Barracuda was alerted to anomalous traffic originating from Barracuda Email Security Gateway (ESG) appliances.
On May 18, 2023, Barracuda engaged Mandiant, leading global cyber security experts, to assist in the investigation.
On May 19, 2023, Barracuda identified a vulnerability (CVE-2023-28681) in our Email Security Gateway appliance (ESG).
On May 20, 2023, a security patch to remediate the vulnerability was applied to all ESG appliances worldwide.
On May 21, 2023, a script was deployed to all impacted appliances to contain the incident and counter unauthorized access methods.
A series of security patches are being deployed to all appliances in furtherance of our containment strategy.
Key Findings
While the investigation is still on-going, Barracuda has concluded the following:
The vulnerability existed in a module which initially screens the attachments of incoming emails. No other Barracuda products, including our SaaS email security services, were subject to the vulnerability identified.
Earliest identified evidence of exploitation of CVE-2023-2868 is currently October 2022.
Barracuda identified that CVE-2023-2868 was utilized to obtain unauthorized access to a subset of ESG appliances.
Malware was identified on a subset of appliances allowing for persistent backdoor access.
Evidence of data exfiltration was identified on a subset of impacted appliances.
Users whose appliances we believe were impacted have been notified via the ESG user interface of actions to take. Barracuda has also reached out to these specific customers. Additional customers may be identified in the course of the investigation.
CVE-2023-2868
On May 19, 2023, Barracuda Networks identified a remote command injection vulnerability (CVE-2023-2868) present in the Barracuda Email Security Gateway (appliance form factor only) versions 5.1.3.001-9.2.0.006. The vulnerability stemmed from incomplete input validation of user supplied .tar files as it pertains to the names of the files contained within the archive. Consequently, a remote attacker could format file names in a particular manner that would result in remotely executing a system command through Perl’s qx operator with the privileges of the Email Security Gateway product.
Barracuda’s investigation to date has determined that a third party utilized the technique described above to gain unauthorized access to a subset of ESG appliances.
Malware
This section details the malware that has been identified to date.
SALTWATER
SALTWATER is a trojanized module for the Barracuda SMTP daemon (bsmtpd) that contains backdoor functionality. The capabilities of SALTWATER include the ability to upload or download arbitrary files, execute commands, as well as proxy and tunneling capabilities.
Identified at path: /home/product/code/firmware/current/lib/smtp/modules on a subset of ESG appliances.
The backdoor is implemented using hooks on the send, recv, close syscalls and amounts to five components, most of which are referred to as “Channels” within the binary. In addition to providing backdoor and proxying capabilities, these components exhibit classic backdoor functionality. The five (5) channels can be seen in the list below.
DownloadChannel
UploadChannel
ProxyChannel
ShellChannel
TunnelArgs
Mandiant is still analyzing SALTWATER to determine if it overlaps with any other known malware families. Table 1 below provides the file metadata related to a SALTWATER variant.
Table 1 below provides the file metadata related to a SALTWATER variant.
SEASPY is an x64 ELF persistence backdoor that poses as a legitimate Barracuda Networks service and establishes itself as a PCAP filter, specifically monitoring traffic on port 25 (SMTP). SEASPY also contains backdoor functionality that is activated by a «magic packet».
Identified at path: /sbin/ on a subset of ESG appliances.
Mandiant analysis has identified code overlap between SEASPY and cd00r, a publicly available backdoor.
Table 2 below provides the file metadata related to a SEASPY variant.
SEASIDE is a Lua based module for the Barracuda SMTP daemon (bsmtpd) that monitors SMTP HELO/EHLO commands to receive a command and control (C2) IP address and port which it passes as arguments to an external binary that establishes a reverse shell.
Table 3 below provides the file metadata related to a SEASIDE.
Ensure your ESG appliance is receiving and applying updates, definitions, and security patches from Barracuda. Contact Barracuda support (support@barracuda.com) to validate if the appliance is up to date.
Discontinue the use of the compromised ESG appliance and contact Barracuda support (support@barracuda.com) to obtain a new ESG virtual or hardware appliance.
Rotate any applicable credentials connected to the ESG appliance: o Any connected LDAP/AD o Barracuda Cloud Control o FTP Server o SMB o Any private TLS certificates
Review your network logs for any of the IOCs listed below and any unknown IPs. Contact compliance@barracuda.com if any are identified.
To support customers in the investigations of their environments, we are providing a list of all endpoint and network indicators observed over the course of the investigation to date. We have also developed a series of YARA rules that can be found in the section below.
Endpoint IOCs
Table 4 lists the endpoint IOCs, including malware and utilities, attributed to attacker activity during the investigation.
File Name
MD5 Hash
Type
1
appcheck.sh
N/A
Bash script
2
aacore.sh
N/A
Bash script
3
1.sh
N/A
Bash script
4
mod_udp.so
827d507aa3bde0ef903ca5dec60cdec8
SALTWATER Variant
5
intent
N/A
N/A
6
install_helo.tar
2ccb9759800154de817bf779a52d48f8
TAR Package
7
intent_helo
f5ab04a920302931a8bd063f27b745cc
Bash script
8
pd
177add288b289d43236d2dba33e65956
Reverse Shell
9
update_v31.sh
881b7846f8384c12c7481b23011d8e45
Bash script
10
mod_require_helo.lua
cd2813f0260d63ad5adf0446253c2172
SEASIDE
11
BarracudaMailService
82eaf69de710abdc5dea7cd5cb56cf04
SEASPY
12
BarracudaMailService
e80a85250263d58cc1a1dc39d6cf3942
SEASPY
13
BarracudaMailService
5d6cba7909980a7b424b133fbac634ac
SEASPY
14
BarracudaMailService
1bbb32610599d70397adfdaf56109ff3
SEASPY
15
BarracudaMailService
4b511567cfa8dbaa32e11baf3268f074
SEASPY
16
BarracudaMailService
a08a99e5224e1baf569fda816c991045
SEASPY
17
BarracudaMailService
19ebfe05040a8508467f9415c8378f32
SEASPY
18
mod_udp.so
1fea55b7c9d13d822a64b2370d015da7
SALTWATER Variant
19
mod_udp.so
64c690f175a2d2fe38d3d7c0d0ddbb6e
SALTWATER Variant
20
mod_udp.so
4cd0f3219e98ac2e9021b06af70ed643
SALTWATER Variant
Table 4: Endpoint IOCs
Network IOCs
Table 5 lists the network IOCs, including IP addresses and domain names, attributed to attacker activity during the investigation.
Indicator
ASN
Location
1
xxl17z.dnslog.cn
N/A
N/A
2
mx01.bestfindthetruth.com
N/A
N/A
3
64.176.7.59
AS-CHOOPA
US
4
64.176.4.234
AS-CHOOPA
US
5
52.23.241.105
AMAZON-AES
US
6
23.224.42.5
CloudRadium L.L.C
US
7
192.74.254.229
PEG TECH INC
US
8
192.74.226.142
PEG TECH INC
US
9
155.94.160.72
QuadraNet Enterprises LLC
US
10
139.84.227.9
AS-CHOOPA
US
11
137.175.60.253
PEG TECH INC
US
12
137.175.53.170
PEG TECH INC
US
13
137.175.51.147
PEG TECH INC
US
14
137.175.30.36
PEG TECH INC
US
15
137.175.28.251
PEG TECH INC
US
16
137.175.19.25
PEG TECH INC
US
17
107.148.219.227
PEG TECH INC
US
18
107.148.219.55
PEG TECH INC
US
19
107.148.219.54
PEG TECH INC
US
20
107.148.219.53
PEG TECH INC
US
21
107.148.219.227
PEG TECH INC
US
22
107.148.149.156
PEG TECH INC
US
23
104.223.20.222
QuadraNet Enterprises LLC
US
24
103.93.78.142
EDGENAP LTD
JP
25
103.27.108.62
TOPWAY GLOBAL LIMITED
HK
Table 5: Network IOCs
YARA Rules
CVE-2023-2868
The following three (3) YARA rules can be used to hunt for the malicious TAR file which exploits CVE-2023-2868:
rule M_Hunting_Exploit_Archive_2
{
meta:
description = "Looks for TAR archive with /tmp/ base64 encoded being part of filename of enclosed files"
date_created = "2023-05-26"
date_modified = "2023-05-26"
md5 = "0d67f50a0bf7a3a017784146ac41ada0"
version = "1.0"
strings:
$ustar = { 75 73 74 61 72 }
$b64_tmp = "/tmp/" base64
condition:
filesize < 1MB and
$ustar at 257 and
for any i in (0 .. #ustar) : (
$b64_tmp in (i * 512 .. i * 512 + 250)
)
}
rule M_Hunting_Exploit_Archive_3
{
meta:
description = "Looks for TAR archive with openssl base64 encoded being part of filename of enclosed files"
date_created = "2023-05-26"
date_modified = "2023-05-26"
md5 = "0d67f50a0bf7a3a017784146ac41ada0"
version = "1.0"
strings:
$ustar = { 75 73 74 61 72 }
$b64_openssl = "openssl" base64
condition:
filesize < 1MB and
$ustar at 257 and
for any i in (0 .. #ustar) : (
$b64_openssl in (i * 512 .. i * 512 + 250)
)
}
rule M_Hunting_Exploit_Archive_CVE_2023_2868
{
meta:
description = "Looks for TAR archive with single quote/backtick as start of filename of enclosed files. CVE-2023-2868"
date_created = "2023-05-26"
date_modified = "2023-05-26"
md5 = "0d67f50a0bf7a3a017784146ac41ada0"
version = "1.0"
strings:
$ustar = { 75 73 74 61 72 }
$qb = "'`"
condition:
filesize < 1MB and
$ustar at 257 and
for any i in (0 .. #ustar) : (
$qb at (@ustar[i] + 255)
)
}
SALTWATER
The following three (3) YARA rule can be used to hunt for SALTWATER:
rule M_Hunting_Linux_Funchook
{
strings:
$f = "funchook_"
$s1 = "Enter funchook_create()"
$s2 = "Leave funchook_create() => %p"
$s3 = "Enter funchook_prepare(%p, %p, %p)"
$s4 = "Leave funchook_prepare(..., [%p->%p],...) => %d"
$s5 = "Enter funchook_install(%p, 0x%x)"
$s6 = "Leave funchook_install() => %d"
$s7 = "Enter funchook_uninstall(%p, 0x%x)"
$s8 = "Leave funchook_uninstall() => %d"
$s9 = "Enter funchook_destroy(%p)"
$s10 = "Leave funchook_destroy() => %d"
$s11 = "Could not modify already-installed funchook handle."
$s12 = " change %s address from %p to %p"
$s13 = " link_map addr=%p, name=%s"
$s14 = " ELF type is neither ET_EXEC nor ET_DYN."
$s15 = " not a valid ELF module %s."
$s16 = "Failed to protect memory %p (size=%"
$s17 = " protect memory %p (size=%"
$s18 = "Failed to unprotect memory %p (size=%"
$s19 = " unprotect memory %p (size=%"
$s20 = "Failed to unprotect page %p (size=%"
$s21 = " unprotect page %p (size=%"
$s22 = "Failed to protect page %p (size=%"
$s23 = " protect page %p (size=%"
$s24 = "Failed to deallocate page %p (size=%"
$s25 = " deallocate page %p (size=%"
$s26 = " allocate page %p (size=%"
$s27 = " try to allocate %p but %p (size=%"
$s28 = " allocate page %p (size=%"
$s29 = "Could not find a free region near %p"
$s30 = " -- Use address %p or %p for function %p"
condition:
filesize < 15MB and uint32(0) == 0x464c457f and (#f > 5 or 4 of ($s*))
}
rule M_Hunting_Linux_SALTWATER_1
{
strings:
$s1 = { 71 75 69 74 0D 0A 00 00 00 33 8C 25 3D 9C 17 70 08 F9 0C 1A 41 71 55 36 1A 5C 4B 8D 29 7E 0D 78 }
$s2 = { 00 8B D5 AD 93 B7 54 D5 00 33 8C 25 3D 9C 17 70 08 F9 0C 1A 41 71 55 36 1A 5C 4B 8D 29 7E 0D 78 }
condition:
filesize < 15MB and uint32(0) == 0x464c457f and any of them
}
rule M_Hunting_Linux_SALTWATER_2
{
strings:
$c1 = "TunnelArgs"
$c2 = "DownloadChannel"
$c3 = "UploadChannel"
$c4 = "ProxyChannel"
$c5 = "ShellChannel"
$c6 = "MyWriteAll"
$c7 = "MyReadAll"
$c8 = "Connected2Vps"
$c9 = "CheckRemoteIp"
$c10 = "GetFileSize"
$s1 = "[-] error: popen failed"
$s2 = "/home/product/code/config/ssl_engine_cert.pem"
$s3 = "libbindshell.so"
condition:
filesize < 15MB and uint32(0) == 0x464c457f and (2 of ($s*) or 4 of ($c*))
}
MAY 23rd, 2023:
Barracuda identified a vulnerability (CVE-2023-2868) in our Email Security Gateway appliance (ESG) on May 19, 2023. A security patch to eliminate the vulnerability was applied to all ESG appliances worldwide on Saturday, May 20, 2023. The vulnerability existed in a module which initially screens the attachments of incoming emails. No other Barracuda products, including our SaaS email security services, were subject to this vulnerability.
We took immediate steps to investigate this vulnerability. Based on our investigation to date, we’ve identified that the vulnerability resulted in unauthorized access to a subset of email gateway appliances. As part of our containment strategy, all ESG appliances have received a second patch on May 21, 2023. Users whose appliances we believe were impacted have been notified via the ESG user interface of actions to take. Barracuda has also reached out to these specific customers.
We will continue actively monitoring this situation, and we will be transparent in sharing details on what actions we are taking. Information gathering is ongoing as part of the investigation. We want to ensure we only share validated information with actionable steps for you to take. As we have information to share, we will provide updates via this product status page (https://status.barracuda.com) and direct outreach to impacted customers. Updates are also located on Barracuda’s Trust Center (https://www.barracuda.com/company/legal).
Barracuda’s investigation was limited to the ESG product, and not the customer’s specific environment. Therefore, impacted customers should review their environments and determine any additional actions they want to take.
Your trust is important to us. We thank you for your understanding and support as we work through this issue and sincerely apologize for any inconvenience it may cause. If you have any questions, please reach out to support@barracuda.com.
Welcome back to our introduction to hardware hacking series! In this post we will be covering embedded MultiMediaCard (eMMC) flash chips and the standard protocol they use. eMMC is a form of managed flash storage typically used in phones, tablets, and many IoT devices because of its low power consumption and high performance. If you haven’t already, make sure to check out our other intro to hardware hacking posts on our blog.
We’ll also be tearing down an Amazon Echo to show how to use logic traces to identify a pinout for an eMMC chip. Lastly, we’ll walk through options for dumping the contents of the chip while it’s still on the board, as well as when it’s lifted off.
MMC & eMMC Background
MultiMediaCard (MMC) is a form of solid-state storage originally created for use with portable devices, such as cameras. It features a low pin count, along with a simple parallel interface for communicating with it. This standard was later improved upon as the Secure Digital (SD) standard, which had much better performance while keeping the same simple interface. Often you’ll see that SD cards contain two primary components: a NAND flash chip, and a flash controller. NAND flash is a type of flash memory used in many embedded devices, typically seen in TSOP-48 or BGA-63 packages. Other types of flash memory include NOR flash and Vertical NAND flash. The NAND flash is the non-volatile storage where all of the data on the SD card is stored, while the flash controller provides an interface to the NAND flash in the form of the data pins on the SD card.
To read and write to the NAND chip, the host only needs to communicate with the flash controller, which will internally manage all interactions with the NAND chip. With this setup, the controller can contain algorithms to handle many of the complexities of using NAND flash without the host needing to do any additional work. Some of these include:
Error correction code (ECC) handling
Wear leveling
NAND whitening
As the name implies, eMMC combines all of the components used for MMC into a single die and places it into a package that can be used in embedded devices, typically into a single ball grid array (BGA) chip. These chips will expose the same interface seen in MMC/SD cards, so a host will be able to follow the same protocol for communicating with them.
Some manufacturers opt to create a configuration that is essentially an SD card built into a larger board, consisting of a separate NAND flash chip and SD controller. As shown in the above diagrams, the interface for this setup is the same as a single eMMC chip, so everything detailed in this post will apply to these as well.
eMMC Bus Signals
The eMMC protocol is capable of operating in 1-bit, 4-bit, or 8-bit parallel I/O depending on the number of data lines being used. A command signal is used for initializing the eMMC chip and sending read/write commands. A single clock signal is used to synchronize all command and data lines, where they can be sampled on either the rising edge only, or both rising and falling edges for faster performance. These signals and additional pins are detailed in the table below:
eMMC Pinout Table
Pin
Description
CLK
Clock line used to synchronize CMD and all DAT lines
CMD
Bidirectional line used for sending commands and responses to/from the chip. This is used during initialization to determine the number of data lines that should be enabled, the desired clock speed, and any other operating conditions.
DAT0
Bidirectional data line, used in 1-bit, 4-bit, 8-bit modes
DAT1
Bidirectional data line, used in 4-bit, 8-bit modes
DAT2
Bidirectional data line, used in 4-bit, 8-bit modes
DAT3
Bidirectional data line, used in 4-bit, 8-bit modes
DAT4
Bidirectional data line, used in 8-bit mode
DAT5
Bidirectional data line, used in 8-bit mode
DAT6
Bidirectional data line, used in 8-bit mode
DAT7
Bidirectional data line, used in 8-bit mode
VCC
Input voltage for flash storage, usually +3.3V
VCCQ
Input voltage for flash controller, usually +1.8V or +3.3V
VSS / VSSQ
GND for flash storage and flash controller
Command Structure
The commands sent on the CMD line follow a fairly simple structure, and knowing how these look will help in identifying CMD in a logic trace. Commands are encoded in the following 48-bit structure:
Name
Length (Bits)
Description
Start bit
1
Start of a command, always ‘0’
Transmission bit
1
Indicates the direction of the command. 1: Host->Card 0: Card->Host
Command index
6
Value between 0-63 indicating the command type
Command argument
32
Value to be used by the command, e.g. an address
CRC
7
Checksum to validate the data was read correctly
End bit
1
End of a command, always ‘1’
Hands On
Now let’s take a look at a first generation Amazon Echo to show how to identify a pinout for an eMMC chip. Knowing this pinout, it may be possible to dump the contents of the chip without removing it from the PCB. However, in cases where that doesn’t work, we’ll cover a simple alternative once the chip is already lifted.
Here’s the device we’ll be working with:
Materials
The following materials are needed to follow along with this tutorial. You can pick these or other products that serve the same purpose. Links are included for your convenience (but note that we don’t endorse any of these vendors or products):
The first step in taking apart the Amazon Echo starts at the bottom of the device. There’s a rubber cover lightly glued in place. Pulling up from the side is enough to pull it off.
Next, there are 4 T10 screws that need to be removed in order to remove the bottom plate and access the first PCB.
Carefully lift the bottom plate out, and you’ll see speaker plugs and a ribbon cable still attached to the PCB. Pull the speaker plugs out, and disconnect the ribbon cable by lifting the dark brown lever away from the board.
Now the next plate covering the speaker can be lifted out. There are holes in this plate for the speaker cables and ribbon cable to pass through.
Then, the outer casing can be pulled off.
Next, peel off the felt paper wrapped around the device. There are a few glue strips holding it in place, so peeling these off the plastic as you go will allow the felt to come off cleanly.
To remove the main PCB, there are 4 more T10 screws that need to be removed and 2 ribbon cables that need to be disconnected. The top cable (J21) is glued to the plastic with another glue strip. We’ll need this to power the main PCB later, so carefully peel off and remove the ribbon cable.
With the main PCB off, now we can take a look at all the components on it. These have been labeled in the image below:
Amazon Echo: Logic Analyzer Setup
For now we only want to focus on the eMMC chip, which on this unit is a KIOXIA THGBMBG5D1KBAIT 4GB eMMC. Lucky for us, this board has as a number of test points on the other side of the board, directly opposite the eMMC chip.
The plan is to attach jumper wires to all of these pads and capture traces on the logic analyzer. From these, we should be able to identify a few of the main pins necessary to read an eMMC chip. The bare minimum we need is 3 pins to operate in 1-bit mode: CMD, CLK, and DAT0, along with a way to power the chip.
For this, I made some jumper wires with 30awg wire. Having a thin gauge wire like this is always very useful when soldering to any small components or pads like the ones on this board. Solder them all to the pads so we can take logic analyzer captures.
We also need a ground reference for the logic analyzer. On the same side of the board, the copper pad at P2 can be used for this. You can confirm this is ground by checking continuity between this and the shielding pads on the other side (the “dashed lines” of pads surrounding the chips).
To power the board, we need the ribbon cable and bottom plate of the echo we removed earlier. We can connect all of these together and plug in the power supply, and that will power the main PCB so we can capture traces. Here’s what the setup should look like:
You’ll need more than one capture to account for all the pads being tested here. In each case, start a capture and power on the device, and you should see traces similar to the images below:
Capture 1
Capture 2
NOTE: Pin 1 is not connected
Trace Breakdown: Identifying Pins
It turns out that the first capture here has all the pins that we’re interested in. The first, and most obvious, is the CLK pin. This is Channel 1 in the example trace above, easy to identify by its fixed rate oscillation.
Next, we can try to identify CMD. This will be a line that’s active along with the CLK, and follows the structure covered above. We can use the Logic software to help identify this by adding an analyzer for parallel I/O. This is the “Simple Parallel” option:
In the next menu, set the clock to the channel we already identified as CLK (Channel 1), and set D0 to a channel we want to analyze further. In this case, let’s look at ‘Channel 0’. Set all the other channels to ‘None’ (Tab + N is your friend here) and click ‘Save’.
Now if you zoom in at a point where both channels are showing activity, the analyzer we just added will show the parsed binary values found by sampling all the rising edges on the clock. Here is an example Host->Card command:
Followed immediately by a Card->Host response:
You can match both of these commands up with the structure we covered before.
In the first image, we see a start bit, 0, followed by 1 to indicate this is a Host->Card command, and the last bit is a 1.
The second image starts with 0, 0, indicating this is a Card->Host response, and once again ends in a 1.
We can see many commands following this same structure throughout the capture, so we can be fairly confident this is the CMD line.
Finally, we want to identify the DAT0 line. When initializing an eMMC chip, DAT0 is the only active data line since every host is capable of 1-bit communication. During the initialization phase the host and card will agree on the total number of data lines to be used, but by default it is always only 1. So, all we need to do is go to the beginning of the capture and see which data line shows activity first after CLK and CMD start up.
Here we can clearly see that after the first series of commands are sent, Channel 7 is the first to respond, so this likely DAT0.
Now looking back at the board, you should have identified the following pinout:
“Alexa, give me a flash dump”
Depending on the device you’re working with, it may be possible at this point to dump the eMMC flash just by connecting to the pins that have been identified. Since this is the same MMC protocol used by SD cards, there are various adapters that can be used to connect to these pins and read them with any SD card reader. There are some pre-made examples, such as this Sparkfun SD Sniffer, where you can solder headers to the board and connect the pins to them directly.
There’s also a similar microSD version made by exploitee.rs that only uses one data pin:
If you don’t have any of these but have a microSD to SD adapter, you can even turn that into a reader by breaking out all the pins inside:
Attempting to dump the chip while on the board may run into a few common issues. When powering on the board normally, the CPU is going to initialize and access the eMMC chip. Attempting to read the chip on another computer while this is happening will likely result in failing to detect it at all. One option around this is to try preventing the CPU from going through it’s normal boot process. For example, if you’re working on a device where the CPU uses a bootloader on a separate SPI flash, you can manually deselect the SPI by pulling its CS pin high or low (depending on the chip). This leaves the eMMC powered on but untouched by the CPU.
Another option is to try powering the eMMC chip externally when you try reading it. However, attempting to do this could result in other devices getting powered, such as the CPU, which results in the same issues as before. In the case of this test device, I wasn’t able to get it reading while still on the board, so now we’ll look into how to dump it by lifting it off the board.
Lifting & Reading the Chip
The first step is of course to lift the eMMC chip off the board. The easiest way to do this is using either a hot air station, or an infrared rework station. Here’s a simple tutorial on how to do this with hot air.
Once lifted, clean off all the remaining solder on the chip using solder wick. The chip should now look like this:
One of the easiest ways to read the chip is using an adapter, such as those from AllSocket. Most eMMC chips have a standard location for the pins needed for power and communication, so the socket breaks out these pins to an SD card you can plug it into a reader. To use this, simply place the chip inside the socket, aligning the dot on the chip with the arrow in the socket, and close it.
Then, plug the adapter into your laptop/SD card reader and it should detect and read the eMMC chip.
To check if your computer detected the chip correctly, run
dmesg
in your terminal, and look for a snippet similar to this:
dmesg
Output
[25103.832356] mmc0: new high speed MMC card at address 0001
[25103.833673] mmcblk0: mmc0:0001 004GE0 3.69 GiB
[25103.834188] mmcblk0boot0: mmc0:0001 004GE0 partition 1 2.00 MiB
[25103.834722] mmcblk0boot1: mmc0:0001 004GE0 partition 2 2.00 MiB
[25103.836965] mmcblk0: p1 p2 p3 p4 p5 p6 p7 p8
[25104.636138] EXT4-fs (mmcblk0p4): mounting ext3 file system using the ext4 subsystem
[25104.637872] EXT4-fs (mmcblk0p4): warning: maximal mount count reached, running e2fsck is recommended
[25104.638357] EXT4-fs (mmcblk0p4): mounted filesystem with ordered data mode. Opts: (null)
[25104.901046] EXT4-fs (mmcblk0p7): mounting ext3 file system using the ext4 subsystem
[25104.910998] EXT4-fs (mmcblk0p7): mounted filesystem with ordered data mode. Opts: (null)
[25105.165884] EXT4-fs (mmcblk0p5): mounting ext3 file system using the ext4 subsystem
[25105.171570] EXT4-fs (mmcblk0p5): mounted filesystem with ordered data mode. Opts: (null)
[25105.411127] EXT4-fs (mmcblk0p6): mounting ext3 file system using the ext4 subsystem
[25105.420283] EXT4-fs (mmcblk0p6): mounted filesystem with ordered data mode. Opts: (null)
[25105.667704] EXT4-fs (mmcblk0p8): mounting ext3 file system using the ext4 subsystem
[25105.677490] EXT4-fs (mmcblk0p8): mounted filesystem with ordered data mode. Opts: (null)
Mounted Partitions
$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
mmcblk0 179:0 0 3.7G 0 disk
├─mmcblk0p1 179:1 0 896K 0 part
├─mmcblk0p2 179:2 0 16M 0 part /mnt/mmcblk0p2-mmc-004GE0_0xf01af56
├─mmcblk0p3 179:3 0 16M 0 part /mnt/mmcblk0p3-mmc-004GE0_0xf01af56
├─mmcblk0p4 179:4 0 16M 0 part /mnt/mmcblk0p4-mmc-004GE0_0xf01af56
├─mmcblk0p5 179:5 0 128M 0 part /mnt/mmcblk0p5-mmc-004GE0_0xf01af56
├─mmcblk0p6 179:6 0 1G 0 part /mnt/mmcblk0p6-mmc-004GE0_0xf01af56
├─mmcblk0p7 179:7 0 1G 0 part /mnt/mmcblk0p7-mmc-004GE0_0xf01af56
└─mmcblk0p8 179:8 0 1.5G 0 part /mnt/data
mmcblk0boot0 179:256 0 2M 1 disk
mmcblk0boot1 179:512 0 2M 1 disk
It’s that easy! Now we can save a full image of the chip and extract all the partitions from there:
$ sudo dd if=/dev/mmcblk0 of=mmcblk0 status=progress bs=16M
3959422976 bytes (4.0 GB, 3.7 GiB) copied, 165 s, 24.1 MB/s
236+0 records in
236+0 records out
3959422976 bytes (4.0 GB, 3.7 GiB) copied, 164.523 s, 24.1 MB/s
$ 7z x mmcblk0
Scanning the drive for archives:
1 file, 3959422976 bytes (3776 MiB)
Extracting archive: mmcblk0
--
Path = mmcblk0
Type = GPT
Physical Size = 3959422976
ID = F9F21FFF-A8D4-5F0E-9746-594869AEC34E
Everything is Ok
Files: 8
Size: 3959274496
Compressed: 3959422976
$ ls -lh
total 7.4G
-rw-r--r-- 1 user user 16M Mar 3 18:17 boot.img
-rw-r--r-- 1 user user 1.6G Mar 3 18:17 data.img
-rw-r--r-- 1 user user 128M Mar 3 18:17 diags.img
-rw-r--r-- 1 user user 16M Mar 3 18:17 idme.img
-rw-r--r-- 1 user user 1.0G Mar 3 18:17 main-A.img
-rw-r--r-- 1 user user 1.0G Mar 3 18:17 main-B.img
-rw-r--r-- 1 root root 3.7G Mar 3 18:17 mmcblk0
-rw-r--r-- 1 user user 16M Mar 3 18:17 recovery.img
-rw-r--r-- 1 user user 896K Mar 3 18:17 xloader.img
Most of these are regular filesystems that can be mounted, so let’s mount them all so we can see what they contain:
$ for i in *.img; do
NAME=$(basename "$i" .img)
mkdir "$NAME"
sudo mount "$i" "$NAME"
done
ust like that, we now have full dump of the Echo’s firmware!
Conclusion
These are all the basics of how to look for eMMC signals on a board, and how to go about reading these chips. The example device used here conveniently had pads for all of the eMMC pins, but this isn’t always the case. Using what you’ve learned here, you can try capturing traces at any components, such as resistors near an eMMC chip to find an alternate pinout.
With the Echo’s firmware dumped, we can start analyzing all the services running on the device searching for vulnerabilities, as well as look into the data stored on the device.
For more details about eMMC, the full standard can be found on JEDEC’s website.
In our next post in the Hardware Hacking 101 series, we’ll be covering ISP. Keep an eye out for it, and contact us at any time with questions or to discuss how we can help with your product security needs!
UPDATE: Thanks to @m33x, we’ve been made aware of Clinton, Cook, et al’s paper which mentions an “eMMC Root” as a possible method in Section IV.A, although that work doesn’t apply or test the method. Also, he mentions Alexa, Are you Listening? which is using debug pads to mount/boot from an external SD card, which is different than what this article shows.
Recently I have received a request to check data recovery possibilities from a damaged Sony Xperia Z5 Premium smartphone. The phone was dropped and it stopped working. No screen, no charging, no communication on any interfaces, no sign of life, it was nothing more than a brick. Well, a brick, with tons of useful data on it without any cloud synchronisation or offline backup. Needless to say how important was for the owner to get his priceless information back from the device.
Some damage identification and recovery probes were already conducted by other professional parties, even a new screen was ordered and tried, but none of the activities provided any promising result. After the failed attempts the owner almost gave up the hope, but fortunately, we had a common acquaintance and this is how I came to the picture. Due to the previous investigations the phone arrived to me partially dismantled, without a battery and with some metal shields already removed.
As the very first step, I tried to find the data storage. It was quite obvious to identify the memory chip on the PCB, which was a SK hynix H26M64103EMR. This is a simple, 32GB eMMC in a common FBGA package. I had a couple of eMMC related projects in the past, where I had to deal with chip interfacing and direct memory dumping or manipulation. This is often a task in hardware hacking projects I am involved in, for example to gain full access to the OS file system in case of a car head unit or other embedded systems, just to mention another example.
This was the first promising moment to get the owner’s data back. As all of the non-invasive activities failed, I decided to go after the so called “chip-off analysis” technique. This means that the given memory chip has to be removed from the PCB and with the chosen interfacing method its content should be read out directly for further processing.
An important point for this method is that the used encryption settings could be the key for the success, or for the failure. An enabled or enforced encryption could prevent a successful data recovery, even if the memory chip is not dead and its content could be dumped out. If encryption is in place, the decryption also has to be solved somehow, which is nowadays, with more and more careful design and with properly chosen hardware components, is very challenging or could be (nearly) impossible. Fortunately, at least from data recovery perspective, the owner did not turn on the encryption, so circumstances were given to the next step.
After the PCB was removed from the body, I fixed the board to a metal working surface with kapton tape. Then a little flux was injected around the chip for better heat dispersion and I used a hot air station to reflow the BGA balls and to let me pull of the chip from the PCB.
There are multiple ways to communicate with the eMMC chips. Most of them take advantage of the fact, that these chips are basically MMC (MultiMediaCard) standard memories, but in an embedded (this from where the “e” comes from) format. This means, that as soon as the connection to the necessary chip pins are solved, a simple USB card reader could do the job to read and write the memory. These chips usually support multiple communication modes, using e.g. 8 bit or 4 bit parallel interface or a single 1 bit interface. For an easy setup and without special tools usually the 1 bit mode is used. The only criteria for this method is that the reader also has to support 1 bit mode (Transcend USB card readers seems to be good candidates for this job). In such case only CMD, CLK, DAT0, VCC (VCC, VCCQ) and GND (VSS, VSSQ) pins have to be connected. Do not be afraid of the lot of pins, in fact, only a couple of ones are used. The pinout is generic and based on JEDEC standard, so regardless of the vendor or the chip you are dealing with, it is almost sure that you will find the important pins at well known location, as it is showed in the picture below.
I made these connections in the past by manually soldering 0.1mm insulated copper wires to the given BGA balls then wire them directly to the reader. If you have stable hand and good enough soldering skills then it is absolutely not impossible. There are cases when you have to deal with logic level shifting and multiple voltages (different voltage for memory and Flash I/O /this is the VCC/ and for the memory controller core and MMC I/O /which is the VCCQ/), so always be careful and read the datasheet or measure the given voltage levels first. This time, I had a better toolset available, so I used a SD-EMMC plus adapter connected to an E-Mate Pro eMMC Tool. Using this combination it was possible to simply put the removed eMMC chip to the BGA socket without any custom wiring and to communicate with it with a simple USB card reader.
As I attached the tool to my linux machine it recognised the device as an USB mass storage and it was ready to use.
[ 700.932552] usb 1-2: new high-speed USB device number 5 using xhci_hcd
[ 701.066678] usb 1-2: New USB device found, idVendor=8564, idProduct=4000
[ 701.066693] usb 1-2: New USB device strings: Mfr=3, Product=4, SerialNumber=5
[ 701.066702] usb 1-2: Product: Transcend
[ 701.066709] usb 1-2: Manufacturer: TS-RDF5
[ 701.066716] usb 1-2: SerialNumber: 000000000036
[ 701.129205] usb-storage 1-2:1.0: USB Mass Storage device detected
[ 701.130866] scsi host0: usb-storage 1-2:1.0
[ 701.132385] usbcore: registered new interface driver usb-storage
[ 701.137673] usbcore: registered new interface driver uas
[ 702.132411] scsi 0:0:0:0: Direct-Access TS-RDF5 SD Transcend TS3A PQ: 0 ANSI: 6
[ 702.135476] sd 0:0:0:0: Attached scsi generic sg0 type 0
[ 702.144406] sd 0:0:0:0: [sda] Attached SCSI removable disk
[ 723.787452] sd 0:0:0:0: [sda] 61079552 512-byte logical blocks: (31.3 GB/29.1 GiB)
[ 723.809221] sda: sda1 sda2 sda3 sda4 sda5 sda6 sda7 sda8 sda9 sda10 sda11 sda12 sda13 sda14 sda15 sda16 sda17 sda18 sda19 sda20 sda21 sda22 sda23 sda24 sda25 sda26 sda27 sda28 sda29 sda30 sda31 sda32 sda33 sda34 sda35 sda36 sda37 sda38 sda39 sda40 sda41 sda42 sda43
The device was mapped to “sda” device. As you can see from the “dmesg” extract above, there were a lot of partitions (sda1 – sda43) on the filesystem. Before moving forward, as always in a case like this, the first step was to create a dump from the memory chip, then conduct the next steps on an offline backup. The “dd” tool could be used for this purpose:
$ dd if=/dev/sda of=sony_z5p.img status=progress
With the full dump it was safe to continue the analysis. Using “parted” I checked the partition structure:
Model: (file)
Disk /mnt/hgfs/kali/sony_z5p/sony_z5p.img: 31.3GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:
Only one partition, the “userdata” was relevant for the recovery. Using “losetup” it is possible to automatically mount every recognised partition from the image, or only the chosen one by specifying e.g. the proper partition offset in the image.
$ losetup -Prf sony_z5p.img
As soon as the filesystem was mounted the recovery was not a big deal anymore. It is public knowledge where and how Android and common applications store stuffs such as contacts, text messages or pictures. For other applications it is also quite easy to reveal the details by crawling their application folders and by checking their database files.
Based on the owner’s request I focused only on some data:
With a rooted spare device it could be possible e.g. to replace the database files on the new device to the recovered ones to let the phone parse and show the data for further processing, however standard users will not be able to do this. For me, it was easier to go after the direct recovery, instead of playing with another phone. Picture and multimedia files do not need special care as those just had to be saved without any post processing, but in case of other data stored in SQLite databases the extract should take care about the given database structure and the generated output should be something which could be read by humans or could be processed by other tools.
I found a “dump-contacts2db” script on GitHub which was good to parse the contact database and export the items to a common vCard format. This is something which a user can later import to several applications and sync back to the new phone.
For the text messages I did not find anything useful, so I quickly checked the corresponding data structure in the SQLite database:
CREATE TABLE mmssms(
_id INTEGER NOT NULL,
msg_type TEXT NOT NULL,
uri TEXT NOT NULL,
type INTEGER,
thread_id INTEGER,
address TEXT,
date INTEGER,
subject TEXT,
body TEXT,
score INTEGER,
content_type TEXT,
media_uri TEXT,
read INTEGER DEFAULT 0,
UNIQUE(_id,msg_type) ON CONFLICT REPLACE);
It was not too complex, so in 2 minutes I made a quick and dirty but working script to extract the text threads to CSV files:
#!/bin/bash
for thread in $(sqlite3 icing_mmssms.db 'select distinct thread_id from mmssms'); do
address=`sqlite3 icing_mmssms.db 'select distinct address from mmssms where thread_id = '"$thread" | sed 's/[^0-9]*//g'`
sqlite3 -csv icing_mmssms.db 'SELECT datetime(date/1000, "unixepoch","localtime"), address, msg_type, body from mmssms where thread_id = '"$thread"' order by date' > sms_with_${address}_thread_${thread}.csv
done
All done, this was the last step to recover every requested file and info from the phone. I did not spend too much time on the recovery itself and the whole process was also fun for me, especially by knowing the fact that others have failed before me.