5

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?

  • Could you attack the packets in question? Otherwise it seem pretty futile. – cb88 Jul 9 '13 at 15:00
  • do you mean attack or attach? And if you mean attack, do you mean network attacks like ARP spoofing and replay attacks? Cause that is what I have been trying to do. – McMa Jul 10 '13 at 7:47
  • attack of course! The data must be assimilated resistance is futile... in all seriousness though it was a typo on my part I'm only human :-/ so yeah just attach it and let some computer heads look at it ;) – cb88 Jul 10 '13 at 12:43
7

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.

  • 1
    Guess that's a simple and concise answer. Thank you and wish me luck! – McMa Jul 10 '13 at 7:43
3

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!

  • Well, here are some of the packages the computer sends to the camera during the initialisation and capture. For the moment it's the answers from the computer I am the most interested in. If you think the cam answer is important I will look for a way to include it (WireShark can't read incoming VLAN connection under Windows :/). Thanks again! – McMa Jul 17 '13 at 7:52
  • You had initially said that you wanted to decode and display the picture.. This would require an analysis of the packets from the camera. Saying that you're most interested in the packets from the computer makes me think you're trying to do something very different. – David Hoelzer Jul 17 '13 at 12:29
  • Yes, sorry if I am being unclear. My goal is to obtain images using a device that is not supported. On the one hand I need to decode the images sent by the camera, but first I need to figure out the control sequences sent by the computer, so that I am able to initialise the camera and tell it to send me the images in first place. So it's a bit of both... – McMa Jul 17 '13 at 13:08
  • 1
    Capture the packets from the computer to the camera. After you analyze them recreate them using Scapy and then start tinkering with fields to see what happens. – David Hoelzer Jul 19 '13 at 17:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.