This article is the fourth in the 'What to do when you have something' series, and the research object isH3C TC2100 Smart Camera(Pan-tilt unit), the focus is onTraffic CaptureAndProtocol Analysis.
This time, the focus is on traffic and protocol analysis,
The false reason: The previous articles have involved some hardware debugging and firmware reverse engineering, which are similar in nature;
The real reason: The firmware was not installed, the extraction requires disassembly, the device is new, and it can still be sold to recover some money.$.
The content mainly includes:
0x00 Basic Knowledge: Principles of Smart Camera and Traffic Packet Capture
0x01 Standing on the Shoulders of Giants: Device Information and Failed Social Engineering
0x02 DIY: Analysis of Traffic and Protocols
00x3 Summary: A Simple Summary
0x04 Reference Materials: Reference Links
Previous Review:
What to do when you have something (Part 1) — Xiaomi Mi Band 3
What to do when you have something (Part 2) — Cat Disc
What to do when you have something (Part 3) — WiFi Signal Amplifier
0x00 Basic Knowledge
0x00 - 00 Working Principle of Smart Camera (Generally)
Cameras of different types have different management architectures. Some earlier or external cameras directly open web, ssh, and other management interfaces, making access and management convenient, but security issues are prominent, and research materials are abundant. While home smart cameras generally use apps to manage through cloud services, the management end and camera are not in a direct CS relationship, and the direct network between the management app and the camera (or other smart home devices) is not necessary, as shown in the following figure:
0x00 - 01 Andriod APP packet capture
There are many ways to capture packets of APP, you can directly use APP-side software (Http Canary, etc.), mobile phone (simulator) APP + BP/Fiddler Proxy, or directly capture packets at the bottom of the mobile phone, etc. In addition to the bottom-level capture after obtaining permissions, the rest of the ideas are basically intermediaries, the steps are basically the same:
Install the certificate
Set up the server
Set up the client
This articleDetailed, can be used as a reference.
0x01 Stand on the shoulders of giants
0x01 - 00 Device information
Hardware information
Device information from the official website, which is basically of no value to researchers.
Port information
Through Nmap scanning, there are no commonly used ports open, the results are as follows:
0x01 - 01 Failed Social Engineering
As mentioned above, due to certain economic reasons, I don't want to disassemble the machine, and the firmware can't be found on the Internet. On a whim, I asked the customer service for it, but the means were not enough cunning, and it ended in failure. However, it does not hinder traffic analysis.
The specific communication was forgotten without screenshots, the customer service was very patient, chatted for a while and couldn't go on, and finally the customer service asked for a fault video, too麻烦 So I gave up,
0x02 Do it yourself
0x02 - 00 Traffic capture
Capture the device traffic on the router side
On the device side, it added a layer before flashing pandorarouter, through tcpdumpCapture packets, simply filter out the traffic in and out of the device IP, among which the device IP is 192.168.123.142:
tcpdump -i eth2 dst 192.168.123.142 or src 192.168.123.142 -w /tmp/tc2100.pcap
Store as pcapConvenient for analysis:
Capture the APP traffic on the mobile phone side
Firstly, do a simple reverse engineering of the app, the code can be used as a reference during analysis, and it can be seen that it uses kotlin, There are also some alibaba/j256/juphoon/qqfolder, may have used some of these services.
Directly use HTTP Canary to capture packets on the mobile phone side, at this time you need to install the root certificate:
There may be errors in certificate installation, the author uses MIUI, and refers tothis link, throughDownloadInstalled the APP through backup and restore, and then you can import the certificate to capture packets.
During packet capture, it was found that once packet capture mode is turned on, the APP cannot connect to the service, indicating that there is mutual authentication between the APP and the server (at least the server verifies the APP certificate), so this man-in-the-middle packet capture method may not be able to capture the entire process of data.
0x02 - 01 protocol analysis
Starting from the device side traffic, analyzing the intercepted pcapFiles. Among many TCP, HTTP protocol was seen, starting with this simple one:
It can be seen that the device accessed the following several IP HTTP services:
36.111.152.223
221.228.33.234
58.216.20.8
By visiting through the browser, it was found that the service is indeed open:
36.111.152.223
Start from the IP address 36, follow the TCP stream:
In addition to noticing the IP conversion domain name cte.ux.21cn.com, the most obvious thing is the two base64 encoded strings. After decoding, the short string is 0x20 bytes, the long string is 0x160 bytes, and they are all binary garbage. The string lengths are all multiples of 16, so let's start guessing.
Guess that the long string is the ciphertext, and the short one is the key (it is generally not possible to transmit the key in plain text, but there are no other clues, so we can only try). The transmitted 32 bytes may be AES256/ECBIt may be AES128 + IV/CBCAfter multiple attempts, it was all garbled code, and I also tried OFB and CFB, of course, without any results.
So I decoded the long base64 string of the two HTTP requests and found that the first 0x20 bytes are the same:
Also wrote an article about the 0x20 byte, but also failed to decrypt. So turned to look at cte.ux.21cn.com
The domain name:
From the official website, it can be seen that it is a data analysis service website that can be directly logged in with the China Telecom Skyline account. Using BP testing, it was found that modifying the short string before also does not affect success Return value, but this item cannot be empty:
Modifying some long strings does not affect the return results, which completely eliminates the above guess. In order toNot allowing any device research project to mutate into a penetration testing project, so the author did not perform too many tests on the website, which brought the research back to the starting point.
Returning to the website itself, I found that it has SDK, so I referred toManual.
Further determining the platform to be a data service platform from the platform overview, mainly for data statistics and analysis. When using the service, a public key is needed as a unique identifier for the client, indicating that the service has a perfect authentication system, making the previous decryption attempts even more laughable.
By checking Andriod SDKManual, it was found that the public key will appear in the Andriod APP's AndroidManifest.xml In the file:
Go back and check the decompiled Yige Master APP, and indeed found the relevant code:
The usage agreement on the device side should be similar, starting from POSTof URL /collect/custom/v1.0/reportDataIt also collects device status data, sends it to the APP side after backend analysis, because the private key cannot be obtained, it is difficult to further analyze, and it can be regarded as a more powerful log server for the time being.
By the way, if RSA is used for key exchange, after obtaining the private key, you can obtain the session key from the traffic and decrypt the historical traffic, so after authentication, it is best to chooseDH key negotiationmechanism, so even if the private key is obtained, it is difficult to decrypt historical traffic, but for IOT devices, being able to authenticate and encrypt is already quite good.
221.228.33.234
By following the TCP stream, it was found that the device submitted a lot of information to the URL, all in plain text, which can be directly viewed without further analysis:
After URL decoding, it is in JSON format, which is the same as the data in the POST body:
jsonstr=
{
"VER": "03",
"CTEI": "18XXXXXXXXXXXXXX",
"MAC": "70:XX:XX:XX:XX:XX",
"IP": "192.168.123.142",
"UPLINKMAC": "28:XX:XX:XX:XX:XX",
"LINK": "2",
"FWVER": "V1.2.6-00-220914",
"DATE": "2023-01-17 20:49:30"
}
Noticed reqIdShould be the device identifier.
58.216.20.8
This packet is longer and also uses PUTKeywords:
ThroughJFIFKeywords, it is obvious that JPEG formatted images are being transmitted, save it as a new file and open it, and indeed it is a screenshot of the camera content captured by the camera. Fortunately, the author always pointed the camera at the wall during the analysis, otherwise it would have been caught in the picture. ~.~ Please enjoy the desktop jumble:
So far, a simple analysis of several HTTP packets has roughly learned some content of the HTTP service, and let's see the more difficult TLS/SSL next.
Similarly, several destination IPs can be seen:
203.195.93.62
203.195.95.24
121.229.44.227
Because complete SSL encryption is used, it is difficult to see more information other than the obvious protocol handshake process, so let's start with the IP, and check the domain first:
are all related to ehome.21cn.com related domains, with the previous HTTP The root domain of the server is the same, accessed directly by the browser, and both 80/443 are open. As mentioned before, the author does not want to test the server. From the packet capture screenshot of the APP, it can be seen that these domains also appear among them, so let's turn to the APP data packets to see if there are any further discoveries.
ux.21cn.com
It is still the previous cloud analysis platform, the APP also posts a lot of data information to it, and the data is still a base64 string at the end. In my opinion, some data collection is unnecessary, such as my phone brand and model, which would expose my poverty... -.-.
Specific information is as follows, too much personal information has been blurred out:
ehome.21cn.com
The device side already knows that this is the main cloud service for data transmission, as follows is an extracted APP session:
POST /app2/sigtran/ZJ_UpgradeDevice HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 548
Host: ehome.21cn.com
Connection: Keep-Alive
Accept-Encoding: gzip
User-Agent: okhttp/3.12.2
clientType=1005&method=ZJ_UpgradeDevice&signature=a6a18426154b538180348cadf64216a00ef6656e91b19e95574a038f7775898f&appKey=xy_guanjia¶ms=7cfab4794568bf75c2a74c7f9e613d4ec6f74ab4993a8bb7796de7e68b5310263874f95e5516ba5f537ad85624a80912868a950c03ec97ca4adf6bf8ccc5f4e3284f49e007d6b7f5803799e55cae9080e094c739fbdbd7b72e981e6a92f036f4c4073f36cfc5e821921572777c22d803c8a97187fae5cc8a944b1affc239f94313d744d29c27dc3414402bca0b82b88821ab2e4070ce10e126dd136ee97f94ce8e252a2b3cd42ef5685ef14dba0b718a&version=404&nonce=d7c7e13e-ace8-4d×tamp=1673529077
HTTP/1.1 200 OK
Date: Thu, 12 Jan 2023 13:11:19 GMT
Content-Type: text/plain; charset=utf-8
Content-Length: 210
Connection: keep-alive
{"METHOD":"3415","SEQID":"200166","CODE":"0","FROM":{"DID":"3XXXXXXXXXXXXX"},"TO":{"UserToken":"cbxxxxxxxxxxxxxxxxxxxxfe
It is obviously related to the device upgrade,signature=a6a18426154b538180348cadf64216a00ef6656e91b19e95574a038f7775898f
128 bits, should be the MD5 value, the 160 bytes after params should be the encrypted data,
FromappKey=xy_guanjiaIt cannot be determined the encryption method and the key generation method, in the return value,"UpdateFlag":"0"Indicates the latest version, no upgrade is required.
From the captured data, it can be seen that the APP also interacts with many servers, such as maketapi.189smarthome.com, adashbc.ut.taobao.com, etc., but due to time and space limitations, no analysis was made.
0x02 - 02 Perhaps a better method
Traffic capture may be better with the following method, but the cost is also greater.
APP side
Use a rooted Android phone to installr0capture, certificate issues can be ignored, and packet capture can be performed at the Android bottom layer.
Device side
Disassemble the device to extract the firmware, find the hardware or software debugging port, because there is likely only a public key on the device, so it can be assisted with gdb debugging (when the system is Linux-like), to obtain decrypted memory data, of course, it is better to install ssl packet capture software, which depends on the complexity of the system.
0x03 Make a summary
This article analyzes the traffic and protocol of H3C TC2100 Intelligent Camera, and it can be seen that with the increasing emphasis on security in smart home devices, protective measures and management protocols are also becoming more reasonable. Due to some limiting factors, a comprehensive analysis was not possible, especially at the device binding stage, but every time a little knowledge gap was filled, which was not a waste. During the holidays, let's take a break ~.~, then see the next device (po) (lan).
0x04 References
H3C TC2100 Home Full-Function Cloud台Machine - Huawei 3Com Group - H3C
Security analysis and case reference of smart camera - FreeBuf cyber security industry portal
Network traffic analysis for terminal application security
Reverse Engineering the cheap Chinese "VRCAM" protocol
Installation of HttpCanary root certificate (available for MIUI13 Android 12)
评论已关闭