[PIX-LINK A10] PIXA-123456-XXXXX protocol reversing

[Python1320]

Documenting my findings here for a camera that is likely a derivative of pppp in case a dissector can be made.

Device: Aliexpress camera https://www.aliexpress.com/item/1005006054720973.html (PIX-LINK A10)

• has a BK7252 (verified inside, pictures pending).
• apk can be downloaded from: https://qr01.cn/E3BMyh
• apk name is "shix.pixlink.camera".
• apk contains libobject_jni.so which appears to be similar to libpppp, since it contains functions such as cs2p2p_PPPP_Initialize and cs2p2p__P2P_Proprietary_Decrypt("SSD@cs2-network.",...) which appears on the internet at least here and here.
• PPPP_SIMPLE_SHUFFLE table is the same in the apk's .so as here.
• Default camera password is SHIX_DEFUALT_PWD = "6666" (DEFUALT is not a typo)
• did is of format PIXA123456XXXXX

Tested on non-direct mode (aka connected to WiFi AP):

• Traffic is different to pppp-dissector's: every packet starts with 0x9f instead of 0x2c (both directions). Opcodes do not match if the magic packet alone is changed.
• The device keeps on broadcasting a UDP packet IP 10.0.9.44.11007 > 0.0.0.0.0: UDP, length 48 with payload starting with 0x9f 0x83 0x24 0x22 .... (payload does not change between broadcastings).
• Simulating offline mode by blocking phone and the device prevents connecting to the device. (Speculation: maybe DNS also needs to be blocked, will keep on testing.)

Intercepted with jnitrace and frida-gadget. Phone is sending json messages to the .so for some commands (might be towards cloud, still learning jnitrace):

{"pro":"set_cypush","cmd":1,"user":"admin","pwd":"1234","pushIp":"47.106.146.11","pushPort":9093,"pushInterval":180,"cyAdmin":"admin","cyPwd":"admin123","isPushPic":1,"isPushVideo":1}
{"pro":"set_datetime","cmd":126,"user":"admin","pwd":"1234","time":1699723191,"tz":-7200}
{"pro":"get_parms","cmd":101,"user":"admin","pwd":"1234"}

Called functions according to jnitrace: PPPPMsgNotify, CallBack_H264Data, SearchResult. Likely similar SDK.

getServer() (StartPPPP?) has likely decryption key at least for some traffic:

if(strcmp("PIXA", vendorstring_or_something))
  {
    return "EIHGFNBBKAIEGEJLELHBFEELGDNNGBMIHFFMAPDMAAJEKEKPDLAJDPPKGALBIBLAAENOKNDAOFNFBICNIF:SHIX";
  }

Keys also exist for XIAODOU and MANY others.

[magicus]

Interesting. :) This sounds very similar to the app my camera ("vi365") is using. The APK contains a libobject_jni.so which matches your description. The string "shix" (or "SHIX") is all over the place.

The json commands you are seeing are sent using DRW packets on channel 0. I'm currently working on documenting the set of commands available on my camera, but your examples matches 100% my camera.

That your packets start with 0x9f means the encryption is different. Before decryption, my packets all begin with 2c.

The broadcast packet which you say is 0x9f 0x83 0x24 0x22 is for me 0x2c 0xba 0x5f 0x5d. After decryption, it becomes 0xf1 0x30 0x00 0x00.

[magicus]

I honestly have not spent much time on the decryption; I found the algorithm + tables in a javascript linked from a Home Assistant forum, and it Just Worked. But if you found the same table as the keytable array in the dissector, then maybe it is the four byte dec_key that is incorrect?

[Python1320]

I have not been able to find the four byte key in the dissector indeed. Will continue investigating later.
Trying to decompile the broadcast packet with the "v4 encryption" (correct SSD@... string which might be the key but with extra steps) gives "\xdf\xd1\xf4\x0e" which does not correspond at least to your decrypted example.

Reading the ha thread more I tested shix.cy.camera and it also works and the app appears more polished, also asking for WeChat cloud payments. "Check FwVer" only has a slider and appears to not do anything (did not check logcat or network traffic yet), bummer.

Forgot to add that the camera is called "CYCAM_VM191p_v85_0729" in both apps and that string appears to come from inside the camera. The camera has JTAG test points and the usb port cannot be used for UART as the data pins appeared to not go into the PCB, will recheck when I open it again.

[Python1320]

More findings to prevent others from straying to wrong paths: The EIHGFNB... string is just an encoded string for server IPs for each vendor (apparently decoded by PPPP_DecodeString).
This online decoder has the same EIHGFNB...SHIX string as my PIXA.

[magicus]

The "v4 encryption" link was enlightening. It gives an algoritm how the dec_key (they call it seed; a much better name; I'll update my dissector to use it) is calculated from the string "camera". I can see the "SSD@cs2-network." being used as the seed string in the APK, but I think this is only when encrypting for when doing P2P calls, not for device/controller communications.

You can try setting dec_key = { 0x97, 0x69, 0xd6, 0x5b } (that's the dec_key/seed for "SSD@cs2-network.") in the lua and see if you get any sane values out.

[magicus]

I think I got it! I believe your camera has "SHIX" as the seed string. If that is correct, then you should use dec_key = { 0x3c, 0xc4, 0x68, 0x0a } in the lua script. Try it, and see if you can get decrypted packages beginning with 0x1f.

[Python1320]

Thank you! With that the broadcast becomes

PPPP Packet (encrypted)
    Decrypted Packet: f112002c....
PPPP Packet (MSG_DEV_LGN_CRC)
    Magic Byte: 0xf1
    Opcode: 0x12 (MSG_DEV_LGN_CRC) <- ???
    Payload Length: 44 <- CORRECT!!!
    Payload: 9097...
PPPP Payload

...this opcode leads to another presentation I'll have to digest another weekend.

In the code cs2p2p_gP2PKeyString (set in PPPP_Initialize()) indeed appears to be derived from the EIHGFNB...:SHIX value, which appears to be SHIX.

[magicus]

There is a huge getServer() function that returns ":" for all possible prefixes. I'm trying to extract those values into something usable.

The opcode MSG_DEV_LGN_CRC has something to do with how the device sets up P2P communication over the Internet. I'm guessing it is being sent to an external server. I highly recommend you block UDP port 32100 for outgoing traffic to avoid this. (And/or block the entire device from accessing Internet at all...)

[Python1320]

Indeed I had a MSG_DEV_LGN_CRC instead of MSG_HELLO which I now got after restarting the camera.

I blocked the device from internet except for DNS but it is still sending the CRC messages and a hello ever 10 seconds even after mode button "reset" and wifi ap reconnect.

It can be made connect to the wifi again but it will not be connectable by the app, I'll try blocking the phone also. I'll check the pure p2p mode next if for example the A9_PPPP example would work with this camera.

Just to confirm:

PPPP Packet (MSG_HELLO)
    Magic Byte: 0xf1
    Opcode: 0x00 (MSG_HELLO)
    Payload Length: 0

[magicus]

You might have some success with A9_PPPP but you need to update the four seed key bytes.

For me, I had a lot of success by factory resetting the camera to force it to AP mode, and then letting my phone connect to the AP with the app, and setting my laptop in monitor mode and sniffing the AP SSID. This way it stayed off internet, but I could do basically everything (except sending push notifications on motion detected which are done by the camera to an external http server).

[magicus]

(The nice thing is though that the controller tells the camera which ip and port to send the push notifications to, so I'm basically planning to tell it to send it to my Home Assistant server on a port I chose, and use that to get motion detection from the camera, without having to go on the external internet).

[Python1320]

More testings: VI365 does not find the device in AP mode at all, so only CY365 works.
Monitor mode says that all packets are identified (and the messages look sane: MSG_HELLO, MSG_DRW followed by MSG_DRW_ACK, etc) so this ticket can likely be closed, but I will continue figuring out if this actually supports h264 or just mjpeg like the others when I make more sense of the packets.

Commands are decoded nicely from the monitor traffic also:

PPPP Command Channel
    Command Block
        Command Flags: 0x060aa080
        Command Length: 181
        Command: {"pro":"set_cypush","cmd":1,"user":"admin","pwd":"6666","pushIp":"120.76.133.14","pushPort":80,"pushInterval":180,"cyAdmin":"admin","cyPwd":"admin123","isPushPic":1,"isPushVideo":0}
    Command Block
        Command Flags: 0x060aa080
        Command Length: 89
        Command: {"pro":"set_datetime","cmd":126,"user":"admin","pwd":"6666","time":1699822878,"tz":-7200}
PPPP Command Channel
    Command Block
        Command Flags: 0x060aa080
        Command Length: 293
        Command:{
	"cmd":	101,
	"result":	0,
	"time":	1699830096,
	"stream":	0,
	"icut":	0,
	"power":	100,
	"charging":	1,
	"sysver":	"CYCAM_VM101P_v85_0729",
	"server_ver":	"",
	"upgrade":	0,
	"rotmir":	4,
	"lamp":	1,
	"isShowIcutAuto":	1,
	"bright":	4,
	"contrast":	2,
	"rate_bit":	26,
	"sensor":	"HI0704"
}

Interestingly the HI0704 sensor ID does not appear in github or on the internet.

Also indeed no UART on this one, damn:



Board ID: LV-mw102p

[magicus]

What kind of controls do your app offer you? For my camera, I can change pan, tilt, IR-mode on/off and flashlight on/off. I can look at video and listen to audio (although I'm just getting static, don't know if that is a software problem, a defect unit, or just that the sellers lied about the hardware capabilities), and finally I can send output to a speaker on the camera.

If you have anything like this, I'd be interested in seeing the corresponding cmd messages and their replies for activating these functions.

[magicus]

(Btw, the VI365 app is likely hard-coded with the "camera" PSK, so I'm guessing it will not even send a proper discovery packet for your camera.)