M7 Wifi Camera Notes

I picked up a cheap Wifi security camera on Amazon, it uses a mobile app called “seeing”. Which appears to be that referenced at seeing.store.

No ports were open when scanned with nmap. Monitoring traffic on the router indicated it was talking to a remote server (appears to be on Alibaba’s cloud service):

traffic when streaming video: 
18:19:21.995059 IP 192.168.8.191.36198 > 47.79.82.123.443: Flags [F.], seq 228080, ack 6579, win 6169, length 0
18:19:21.998765 IP 47.79.82.123.443 > 192.168.8.191.36198: Flags [F.], seq 6579, ack 228080, win 831, length 0
18:19:22.671581 IP 192.168.8.191.36200 > 47.79.82.123.443: Flags [S], seq 4002814628, win 29200, options [mss 1460,sackOK,TS val 4294938745 ecr 0,nop,wscale 3], length 0

With some more fiddling it appears that the cloud service coordinates with the phone/camera but if they are on the same network the camera will stream directly to the phone:

8:52:29.753976 IP navas-iPhone.lan.49936 > 192.168.8.191.10666: UDP, length 48
...
18:52:29.841608 IP 192.168.8.191.10666 > navas-iPhone.lan.49936: UDP, length 1332
18:52:29.841943 IP 192.168.8.191.10666 > navas-iPhone.lan.49936: UDP, length 1332

Whatever communication the phone coordinates via the cloud appears to open up a UDP port on the camera. It first sends a packet with a payload of “dummy”:

Which the camera seems to echo back:

The phone then sends a more complex binary payload:

The camera then replies with some clear text:

The phone sends some more binary data to setup the stream… I was able to replay the initial packet from a PC and receive the clear text reply. But this only works if the port has been opened via the phone first.

With no clear routes into the camera via the network I pulled it apart. The camera uses a AllWinner IP Camera SoC. I tried probing all the pads labelled RX/TX for a serial interface but didn’t have any luck here.

So, dumped the flash next.

Via a raspberry pi using: sudo flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=500K -r m7_firmware.bin

The camera appears to use an OpenWRT fork called Tina Linux. eGON header found at beginning of flash, indicating use of Allwinner’s built-in BROM and SPL bootloader. Bootargs suggest a serial console should be present.. so some more hunting may reveal it.

That’s all for now!

More notes.

The pins on the top right of the board above labeled W-RX0 etc. show an interface which responds only during boot, here is some sample output:

[74648][D]PACKET_CMD_USER_DATA 5a 51 0 0 64 d2 66 24
[74649][D]PACKET_CMD_USER_DATA 5a 51 0 0 64 d2 66 24
[74724][D]ecd.poweron_qrcode 0, ecd.ring_power_off_valid_count 0
[75051][I]GET_WIFI_DATA(3) len: 9 1
[75052][I]GET_NET_INFO(25) len: 8 0
$>Welcome to Wlan Bluetooth Console Tools ......
$>[75202][D]PACKET_CMD_USER_DATA 5a 51 0 0 64 d2 66 24
[75202][I]GET_SOME_DATA(7) len: 8 0
[75724][D]ecd.poweron_qrcode 0, ecd.ring_power_off_valid_count 0
[75724][I][W0] wifi: 0 81 0 | 335 137, 0(0/0/0), 0(0/0/0) | 403 0 135 112002 1042001100 | 127320 67068 60252
[UMAC WARN] sta_add():360, scan entry >= 10, discard rssi lowest one
[UMAC WARN] sta_add():360, scan entry >= 10, discard rssi lowest one
[UMAC WARN] sta_add():360, scan entry >= 10, discard rssi lowest one
[76715][D]PACKET_CMD_USER_DATA 5a 51 0 0 64 d2 66 24
[76715][I]GET_WIFI_DATA(3) len: 9 1
[76724][D]ecd.poweron_qrcode 0, ecd.ring_power_off_valid_count 0
[76724][I][W0] wifi: 0 81 0 | 169 33, 0(0/0/0), 0(0/0/0) | 403 0 135 112002 1042001100 | 127320 67716 59604
[76733][D]PACKET_CMD_USER_DATA 5a 51 0 0 64 d2 66 24
[76738][I]GET_SOME_DATA(7) len: 8 0
[net INF] msg <wlan scan success>
[76888][D]NET_CTRL_MSG_WLAN_SCAN_SUCCESS
en1: Trying to associate with 94:83:c4:6c:98:2c (SSID='youanji1' freq=2412 MHz)
en1: Associated with 94:83:c4:6c:98:2c
en1: Clear keys to send no encrypt 4 of 4-way handshake
en1: WPA: Key negotiation completed with 94:83:c4:6c:98:2c [PTK=CCMP GTK=CCMP]
en1: CTRL-EVENT-CONNECTED - Connection to 94:83:c4:6c:98:2c completed [id=0 id_str=]
[net INF] msg <wlan connected>
[net INF] netif is link up
[net INF] start DHCP...
[77267][D]============= dhcp =============
[77269][D]ip:0.0.0.0
[77271][D]netmask: 0.0.0.0
[77274][D]gateway: 0.0.0.0
[77276][D]dns[0]: 0.0.0.0
[77279][D]dns[1]: 0.0.0.0
[77281][D]dns[2]: 0.0.0.0
[77283][D]dns[3]: 0.0.0.0
[77286][D]invalid ip
[77288][D]NET_CTRL_MSG_WLAN_CONNECTED
[77724][D]ecd.poweron_qrcode 0, ecd.ring_power_off_valid_count 0
[77724][I][W0] wifi: 0 81 0 | 182 48, 0(0/0/0), 98(1/0/0) | 403 0 135 112002 1042001100 | 127320 71412 55908
[77746][D]PACKET_CMD_USER_DATA 5a 51 0 0 64 d2 66 24
[77746][I]GET_WIFI_DATA(3) len: 9 1
[77761][D]PACKET_CMD_USER_DATA 5a 51 0 0 64 d2 66 24
[77761][I]GET_SOME_DATA(7) len: 8 0
[net INF] netif (IPv4) is up
[net INF] address: 192.168.8.207
[net INF] gateway: 192.168.8.1
[net INF] netmask: 255.255.255.0
[net INF] msg <network up>
[78221][D]============= dhcp =============
[78224][D]ip:192.168.8.207
[78227][D]netmask: 255.255.255.0

More Lasertec C130 Notes

I’ve been playing around a bit more with the Lasertec microscope. Looking at the literature Lasertec microscopes are often described as “Semi-confocal” this explains the lack of a galvo or anything that I could see that would deflect the light in X and Y:

So I suspect that the silver box at the top of the unit is the AOD and the detect (which is after all marked “slit detector”) is a silt detector!

I decided to pull out the CCD:

And cram a different sensor into the vacated void:

This for taking epi-illuminated images, this works somewhat reasonably:

LaserTec C130 Notes

I was pulling apart an old LaserTec C140 confocal microscope. Here are some pics! Here’s the main optical block:

There’s a photodiode, I assume with a pinhole and CCD sensor here:

On the other side of the unit there’s an FPGA.

Under the unit there’s a stepper (right) and a BL55 “Laserscale”.

I’ve been trying to figure out how all this fits together. The unit appears to be white light only, but I’m unclear on where the actuation is. It looks like everything is on the bottom of the unit. I guess the BL55 laser scale is used in combination with that stepper. But I’m not clear if there’s a full sub-micron precision XYZ stage here or if there’s something else going on. I was really expecting to see Galvos to scan the spot across the sample… hmmm.

Arducam Pivistation 5 Klarity I2C

I was trying to interface directly with the I2C on the Arducam Pivistation 5 Klarity camera module for… reasons.

Anyway I figured this would just expose the I2C on the IMX283… but it doesn’t seem to. There seems in fact to be another little microcontroller (GD e230f8?) there which uses a different I2C command set. It seems similar to the interface from this camera:

https://github.com/ArduCAM/Arducam-Pivariety-V4L2-Driver/blob/7d49aa22558254cd415ef5bbca458a39ad130dce/patchs/arducam_driver.patch#L38

Anyway… I was able to get some info out of it using a Glasgow Interface Explorer. This note is here so someone else doesn’t waste time wondering why the IMX283 (which I think should respond on 0x1a) is responding on 0x0c on this camera.

The Glasgow commands required are below:

Also, it seems that you can crash the microcontroller pretty easily by doing additional reads?