RE: [OT] Dissecting Ethernet packets

["Paul Smith" <ukha@xxxxxxxxxxxxx>]

Thanks Barry,

The great, it would have taken me ages to get even that far. But I see
where your coming from.

So how did you work out what the device was ?

That last packet is the data returned from the list of recordings.

0	06/03/17 11:33:29	06/03/17 11:35:17	00011b90
0  	06 03 11 0b 21 1d 06 03 11 0b 23 11	00011b90

Which you are right is basically the start and stop date and time and the
LBA of the file on the disk.

Thanks for you help with this, I should now be able to get the start and
stop bit going on the hour. This will be my first attempt at tcp
programming, but looks like an easy one to start with.

The next bit will be to see if a can access the stream of video which the
device will issue. As what I am looking to do will be to put a web
interface on it.

Regards,

Paul



-----Original Message-----
From: ukha_d@xxxxxxx [mailto:ukha_d@xxxxxxx] On Behalf Of Barry
Myles
Sent: 17 March 2006 22:04
To: ukha_d@xxxxxxx
Subject: Re: [ukha_d] [OT] Dissecting Ethernet packets

Paul Smith wrote:

> Here goes, www.ptu.biz/cctv.zip contains 4 files

Merged all the files into a big one using 'mergecap' and then put a
tcp.flags.push==1 filter on to show just the data packets. It is
interesting that the push flag is set on the packets as there doesn't
seem to be any sort of delimiter or length parameter anywhere in the
packets. The push flag will prevent intermediate routers from
fragmenting or joining these packet with others in the same TCP stream
which keeps each packet nicely together as a message.

Interesting protocol. It's quite densely packed and efficient. I take it
that it's one of these devices:

http://www.q-see.com/newwebsite-design/support/installGuide-16ch-DVR.htm

According to that page the default password is '0000' and sure enough in
the login packet [2006-03-17 17:59:50.985] is the ascii text '0000'.

The size of the packets doesn't vary much: 16,24, 52 or 80 bytes but
with quite extensive zero padding at the end of some. All the packets
from either endpoint start with hex 'AAAA' so presumably this is some
sort of marker - except the last packet which doesn't . I can't quite
get my head around the next two bytes - they're always either '0202',
'0101', '0103' - perhaps some kind of bit field representing state? The
fifth byte is very interesting - it looks like a command byte 01 -
login, 11 - start, 15 - stop. Even more interesting is the fifth byte of
any response which is always the command byte+1. The remainder of the
packet varies completely depending on what command or response is being
sent.

The last packet is quite interesting as it doesn't have the AAAA header
nor the usual following three bytes but it does have some obvious fields
in it corresponding to dates:

yy mm dd hh? mi? yy mm dd hh? mi? ?? ?? ?? ?? ??
06 03 11 0b  21  06 03 11 0b  23  11 00 01 1b 90
06 03 11 0b  23  06 03 11 0b  28  2a 00 06 15 ca
...

Are these the start and end times of the files that were dumped, perhaps.

There's 10 minutes worth of analysis for you. Doesn't look too tricky to
reverse engineer completely really if you have the box and the software.