The UK Home Automation Archive

Archive Home
Group Home
Search Archive


Advanced Search

The UKHA-ARCHIVE IS CEASING OPERATIONS 31 DEC 2024

Latest message you have seen: Bye Bye Standby Motion Sensor


[Message Prev][Message Next][Thread Prev][Thread Next][Message Index][Thread Index]

Re: [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.





UKHA_D Main Index | UKHA_D Thread Index | UKHA_D Home | Archives Home

Comments to the Webmaster are always welcomed, please use this contact form . Note that as this site is a mailing list archive, the Webmaster has no control over the contents of the messages. Comments about message content should be directed to the relevant mailing list.