C / C++ / MFC

8-Sep-03 19:23

Hi guys,
I want to control an IP camera from my program. The IP camera can be controlled through a web browser. Initially I captured the packets ( using Winpcap API calls) going from my machine to the IP camera, and again tried to send those packets to control the camera from my program. ( I established a TCP connection before sending those control packets). I couldn't get the result. Now my doubt is what I did is correct or not. Could any body guide me?? Any links on this may be helpful to me.
Thanks and Regards,
Satya Smile | :)

geo_m9-Sep-03 7:19

9-Sep-03 7:19

If it is controlled only through browser, it's enough to send correct http requests, which can be easily done by opening tcp connection to the device and sending the request. You should see then in captured data something like GET /image HTTP/1.0 followed by crlf and some set of headers, ended by 2*crlf

If there's some ActiveX or whatever that keeps separate tcp connection there can be a problem, that the protocol inside doesn't allow simple replaying, but I don't see a reason for doing that. Maybe that you just missed something or add some more data or whatever that your protocol differs from the protocol of device.

SatyaDY9-Sep-03 17:53

9-Sep-03 17:53

Hi
Thanks for ur reply. As you said, the http header is there in the captured packet. But what I did is I sent the data after the http (ended by 2 ctrlf) thinking as that payload is having the control signal. Beacause when I captured packets (in four directions top,left,bottom,right) they are differing only in the content after the http header.

So what I can do, any clues??

Regards,
SatyaDY

geo_m9-Sep-03 21:48

9-Sep-03 21:48

Hmm then I assume that the header contains POST on beginning and these are the POST data. Then there's only one URL and the 'commands' are transferred to the camera inside the POST data.

I think, that if you try to do left, left, left, capture the packets, and these three packets doesn't differ in their content, you have to do something wrong in your sending side - try to capture your packets as well and compare the data at this binary level with originally captured 'left command'

If the data in these three commands differ, it will be much more difficult, because then you have really to hack the protocol. Even that can be done, but before I'd recommend to contact the vendor asking for the description. They are usually willing to do it, if you're doing something serious with that hw - like integrating that to your application or whatever.

We'll see what it will do Wink | ;)

SatyaDY9-Sep-03 22:15

9-Sep-03 22:15

Hi,
I could not understand what u told, sorry. Can U explain in detail??
I am trying to integrate this IP camera to my existing application, which plots the path of a falling object whose coordinates(x,y,z) are given by radars. I just want control this IP camera to track the falling object from the inputs given by the radars in addtion to plotting it on bitmap, so that people can view the object with their web browsers.
Thanks a lot for ur help.
Regards, Smile | :)

SatyaDY

geo_m9-Sep-03 22:25

9-Sep-03 22:25

well, so again Wink | ;-)

I would check this:
- send and capture 3x left command sent from webbrowser.
- compare these captured packet, if they are the same
- if yes, construct my packet (the same as the original)
- send it and capture it
- compare my captured packet with original captured, shouldn't differ

if the three packets generated by the 3x left commands differs in a data section, this will be more complicated to do and first think I would do is to contact the vendor of the hardware to get the protocol

SatyaDY12-Sep-03 2:02

12-Sep-03 2:02

Hi again,
I have given the 3 left commands, and saw the packets.
The packets details are like this:

One command is having the following packets twice.
1.368 byte packet (with http header)(from my pc to IP camera)
2.60 byte packet (without http header)(from IP camera to mypc)
3.121 byte packet(with http header)(from IP camera to mypc)

And there is a change in the payload of 368 byte packet.

I thought, the first 368 is the control signal, 60 is the ack, and this 121 I could not guess?? What it could be?? Any guess.
Thanks again,
SatyaDY Smile | :)

geo_m12-Sep-03 2:13

12-Sep-03 2:13

Hmm important question - is it pure browser or inside that browser sits some applet/activex component/driver/whatever?

Normally the ACK should be only on TCP level, therefore every data you receive are supposed to be delivered to the application. For that reason I assume that there must be something that understands the data returned back.

How about content of the control packets (PC to IPcam) - does it changes between the three left commands?

SatyaDY12-Sep-03 18:54

12-Sep-03 18:54

Yeah you right it's not pure browser it's opening an applet for viewing the picture and one more for showing the controls.

As I told the control(left) is sending sequence of 368,60,121 byte packets. For one control(left button) it is sending two sets of the above sequence. And the 368 byte packet is having only one byte change in the payload(that is after the http content).

Satya

geo_m12-Sep-03 22:06

12-Sep-03 22:06

Hmm then they are open to use any sort of custom protocol they want...
That means you have to analyse the content of the packets, not only their length - hack the protocol Wink | ;-)

.
This means taking a piece of paper, changing the input conditions (left command, right command or other combinations) and make notes what and how was changed - even in replies, trying to figure out the whole system.

Or, the easier method, you can try to contact the vendor of the hardware, simply asking for a protocol, I'm doing that time to time and it works. Sometimes only you need to sign an NDA, but it's OK as long as the project is working Wink | ;-)

. If this is not an option we can go on and try to hack it, but, you know, I would try it at least.

SatyaDY13-Sep-03 0:15

13-Sep-03 0:15

Hi,
Definetely I will contact the vendor, meanwhile I will continue to analyse the packets. What shall I do now ?? Shall I try to send the 368 byte packets and see what happens?? How shall I proceed ?? Shall I see if I get the same response (60,121 byte) packets ?? What is NDA Confused | :confused:

One more doubt, sending the packet (368 byte) is it not sufficient?? (Is that no hacking??). What we have to do exactly??
Regards Rose | [Rose]

SatyaDY.

geo_m13-Sep-03 0:48

13-Sep-03 0:48

NDA = Non Disclosure Agreement - something in general saying that if they tell you something, you're not allowed to tell it someone else, except written permisson...

OK, let's rock it!

To make things easy I would try to send the first 368 byte packet and see what's on. If the camera makes what it should, we're on the safe side, else it means that the protocol between needs deeper analysis.

What I do usually is to try to send the same command under exactly the same conditions and then analysing the content of the data flow if there are some changes. If the nature of protocol alows it, I'm usually focusing on one command and continue with another commands in a moment, when the first one works.

During that I usually makes a notes regarding what byte/string on which position mean - or what I think it can mean. This includes command bytes, parameters, checksums, sequence numbers, timestamps and other parts usually used in protocols. For that you need to catch the same command (move left for example) several times under the same conditions (camera position etc) that you can compare the content of the packet - what changes and when.

This makes a some homemade protocol description, that I can use later for constructing my own packets or whole communication.

SatyaDY13-Sep-03 1:05