analysing IP camera's UDP packages

Question

I have an industrial IP camera and I want to read its images with a micro-controller, but the camera is only operable from a computer running its drivers/firmware.

I used WireShark to access the UDP packages, but the messages seem to be encrypted (or at least I cannot make any sense of them) and I don't really know how to proceed on deciphering the control requests.

I would really appreciate any ideas, hints or general comments on how to go on.

Here are a couple of frames sent by the computer to the camera during the initialization and capture. (Working on getting the frames from the cam, but WireShark and Windows have this problem with LANs).

Here's one of the frames sent by the camera to a not supported device. The two data bytes between ** change sequentially, the rest (of the data) stays the same.

0000   ff ff ff ff ff ff 00 1b a2 12 c6 b4 08 00 45 00  ..............E.
0010   01 1c 00 01 00 00 80 11 8f d1 a9 fe 00 01 ff ff  ................
0020   ff ff c3 52 c3 52 01 08 5e 5e 71 00 e0 00*01*00  ...R.R..^^q.....
0030   f8 00 34 30 30 32 39 32 32 30 35 31 00 00 84 01  ..4002922051....
0040   13 00 20 00 00 00 0a 00 04 01 00 00 00 00 05 21  .. ............!
0050   00 00 02 0a 00 00*cc*01 e8 03 00 1b a2 12 c6 b4  ................
0060   ff ff a9 fe 00 01 ff ff 00 00 00 00 00 00 a9 fe  ................
0070   00 01 ff ff 00 00 00 00 00 00 00 00 00 00 00 00  ................
0080   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0090   00 00 00 00 00 00 00 00 00 12 c6 b4 00 00 19 01  ................
00a0   01 01 00 00 00 00 00 00 00 00 11 00 03 01 01 00  ................
00b0   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00c0   00 00 00 00 00 00 00 00 00 00 e8 03 05 00 00 00  ................
00d0   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00e0   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00f0   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0100   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0110   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0120   00 00 00 00 00 00 00 00 00 00                    ..........

edit: I spent these last hours "doing my homework" and thought, since I only want to read its images, deciphering might be a bit of an overkill. Is it probable that a replay attack would also do the trick?

Answer 1

There's only one solution that always works.

Look at the code.

That is, disassemble the firmware and find the code which is sending or receiving the packets. It's often not very difficult with many embedded solutions - they tend to have unstripped symbols and copious amounts of debug output which will help you finding the necessary place.

It's possible in theory to run some cryptoanalysis and try to deduce the encryption used and the key, but that generally requires much more experience and effort.

Answer 2

I've never closely analyzed an IP camera's proprietary protocol, but I've reversed a fair number of protocols over the years.

If you can grab several hundred packets there might be more that we could do to help you out. Just reading what you've written, my gut feeling that I would pursue is that the sequential value is in fact just that; a sequential value that is being used within the protocol to order frames, especially since they are being sent over UDP. Add to that the minimum packet size and I think you've got your padding.

Next, a question. What's going on in front of the camera while you're sniffing? If I were implementing this type of protocol I would periodically send key frames interspersed with significantly larger numbers of encoded "difference" frames. I would capture packets with nothing happening and then compare that to packets captured while waving your hand in front of the camera. I strongly suspect that the hand-waving compared to the peaceful scene will give you far more to work for. I would also expect key frames to be significantly larger, but I'm sure you're onto that already!