Rather advanced for a domestic product of the era, the em@iler included smartcard functionality that was expected to be used for payment or authentication cards.
The smartcard reader is based around a single chip:
Tip the device over, and remove the 4 screws shown.
Tip the device back over, and unclip the top trim.
Remove the small screw to the right of the qwerty keyboard
Gently split the case open.
Disconnect the keypad looms (2), screen ribbon and aux cables (2), ringer cable and hook switch cable.
After disconnecting the remaining cables, remove two screws to extract the Main PCB.
PCB can then be lifted from the can after bending back 6 retaining tabs.
Underside of the Main PCBTopside of the Main PCB
The Screen has two screws in the back (hidden by rubber stoppers). With these removed, the rear can be wiggled away (there are 2 hook/clips at the top). This exposes the Display, backlight inverter, and three sub PCB with the indicator LED’s and a button (these all connect back through the middle board to the Keypad PCB in the base. The Left LED has a small capacitor, which connects back to the mainboard via a dedicated cable … it’s not obvious what purpose this serves! The screen can be unscrewed, and the can opened by prizing back a number of tabs. This separates with the backlight in one half and the TFT panel in the other, with a small driver board consisting of a couple Op-Amps (a VHC244-042 and a BA1032AAF).
The device was initially reviewed with minimal invasion – noting it’s physical and logical behaviour, and trying to avoid activities that would connect to cloud services (eg not connecting it to an internet connected router – this will be done later).
On power up from reset (connecting from laptop, no android app)
LEDs light and flash, indicating power, mode and activity (assumed based on labels).
Creates unencrypted wifi AP Video_ZT953K
Connecting to this gives a 192.168.0.2 local address, with GW 192.168.0.1
“GW” ip (believed to be camera) responds to ping (although sometimes duplicates packets)
GW mac : 78:28:f2:ec:ae:b0
Nmap shows no open TCP ports on GW, and no other devices on network (other than laptop)
Nmap OS fingerprint inconclusive (no open ports), but suggests Expressive esp8266 (FreeRTOS/lwIP) or similar embedded device IP stack.
$ sudo nmap 192.168.0.1 -p0-65535 -O
Starting Nmap 7.80 ( https://nmap.org ) at 2022-09-06 12:02 BST
Nmap scan report for 192.168.0.1
Host is up (0.0025s latency).
All 65536 scanned ports on 192.168.0.1 are closed
MAC Address: 78:28:F2:EC:AE:B0 (Unknown)
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Aggressive OS guesses: 2N Helios IP VoIP doorbell (95%), Advanced Illumination DCS-100E lighting controller (95%), AudioControl D3400 network amplifier (95%), British Gas GS-Z3 data logger (95%), Daysequerra M4.2SI radio (95%), Denver Electronics AC-5000W MK2 camera (95%), DTE Energy Bridge (lwIP stack) (95%), Enlogic PDU (FreeRTOS/lwIP) (95%), Espressif esp8266 firmware (lwIP stack) (95%), Espressif ESP8266 WiFi system-on-a-chip (95%)
No exact OS matches for host (test conditions non-ideal).
Network Distance: 1 hop
OS detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 48.16 seconds
Nmap UDP scan shows some ports in “open/filtered” state. None of these respond to random data via netcat.
$ sudo nmap 192.168.0.1 -p0-65535 -sU -O
Starting Nmap 7.80 ( https://nmap.org ) at 2022-09-06 12:06 BST
Nmap scan report for 192.168.0.1
Host is up (0.0020s latency).
Not shown: 65532 closed ports
PORT STATE SERVICE
67/udp open|filtered dhcps
3889/udp open|filtered dandv-tester
32761/udp open|filtered unknown
55556/udp open|filtered unknown
MAC Address: 78:28:F2:EC:AE:B0 (Unknown)
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Aggressive OS guesses: 2N Helios IP VoIP doorbell (95%), Advanced Illumination DCS-100E lighting controller (95%), AudioControl D3400 network amplifier (95%), British Gas GS-Z3 data logger (95%), Daysequerra M4.2SI radio (95%), Denver Electronics AC-5000W MK2 camera (95%), DTE Energy Bridge (lwIP stack) (95%), Enlogic PDU (FreeRTOS/lwIP) (95%), Espressif esp8266 firmware (lwIP stack) (95%), Espressif ESP8266 WiFi system-on-a-chip (95%)
No exact OS matches for host (test conditions non-ideal).
Network Distance: 1 hop
OS detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 51.25 seconds
Removing power, device stays active with wifi AP. No change in network presentation.
Powering off (press and hold power button) disables WiFi AP (and LED’s extinguish)
No change in network behaviour when SD card inserted.
Camera mac changes with each powercycle some seen include:
e0:3a:54:02:cf:6b
68:e5:f1:b3:14:13
d8:df:5e:9f:cb:29
After a while the camera starts emitting SSDP like packets on UDP port 3889 (to broadcast).
UDP Broadcast Packet as seen in WireShark
Android Video0 App (Running in emulator)
When operating the app in a android emulator, the following entwork behaviour was observed:
T&C window tries to reach out to www.tplook.com (note TLS not used on the request http://www.tplook.com/video0/UserAgreement_en.html)
On startup App tries to DNS resolve
android.bugly.qq.com
api.ipify.org
ip-api.com
ip.nf
Triggering camera add functions (both network and standalone) doesn’t appear to emit any network traffic (guess is listening for the packets noted above).
Following manual add option (Completing form with UID from UDP broadcast packet shown above, and default password from manual) above triggers DNS lookups to all-master.iotcplatform.com but doesn’t communicate locally with the camera.
Android App (running on rooted device for packet capture)
Tablet was manually connected to Camera AP, and App then detects camera automatically. Application functions perform as expected, although it was later found that setting very long passwords in the App caused the device to enter a boot loop (which was recovered by re-flashing the SPI flash). All network communication occurs over UDP, with a unknown binary format (although shows repeated patterns in messages). Further analysis needed!
Having reviewed the camera behaviour “as-is” then next step is to dismantle it, and see what can be learnt from the circuit board and chip choices. For an unknown device extra care should be taken to avoid any anti-tamper devices, however in this case, the device isn’t important and can be easily replaced if damaged.
Outside
Side View
Front
Base
Inside
Board removed from case
Rear of PCB
Front of PCB
SOC Connectors
Connectors/devices with obvious traces to the SOP-48 chip
