[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [coldsync-hackers] Ritual Packets and origination of long arguments
[I've reordered your message. I hope you don't mind. :-)]
On Wednesday 06 March 2002 11:25 am, you wrote:
> Is this what you're seeing? From include/pconn/netsync.h :
[snip -- netsync encapsulation format]
Yes, actually, that's precisely what I'm seeing. Next time I'll read the
headers more closely before getting all confused. :-)
Though I have noticed that the xid -can- be 0xFF, contrary to the comments
toward the top of netsync.h. This only occurs -once- in each of my sync
dumps, and that's when the Clie sends its spontaneous userinfo announcement.
From that point forward, the skipping-0xFF rule seems to apply. Which brings
us to...
> Then presumably the mystery block contains some sort of
> identification. Host ID? Host password? User ID? User password?
This mystery block is all zeros with a very few exceptions (the 0x003c003c
string, the 0xFFFFFFFF string, etc). There's no data in it that I can link
to any of my information here (i.e. my IP address, 0xCOA81E02, doesn't
appear; my user ID, 0x0964, doesn't appear, etc.). There's no sequence of
non-zero values long enough to be a CRC (since 0x3c is reported in other
ritual packets) or an MD5, and my password itself certainly isn't present.
> I'm guessing that this is a security thing: the Clie starts by
> announcing, "I am user Joe Bob, ID 12345", and won't sync unless the
> desktop proves that it's allowed to sync Joe Bob's stuff. Try turning
> the password off on the Clie. Also, if you have a password, run it
> through MD5 and see if you can find that in the initial exchange.
See above. :-)
There's not enough user data involved to be some sort of shared-secret
handshake (even a simple cleartext one), but it -could- be a handshake to
ensure that both ends are speaking the same version of the protocol (albeit a
twisted one). The initial packets with long arguments from the Clie may very
well be what broke compatibility with my Visor version of Palm Desktop
(though I don't have dumps of the Visor at the moment to work with -- I'll
borrow the girlfriend's later).
Here's the Clie's spontaneous userinfo packet, and the initial poke from the
PC, broken into packets and commented:
-- FROM CLIE --
Now that the netsync encapsulation's been pointed out to me, the initial Clie
-> PC packet decodes perfectly as well, though the contents are still cryptic.
This packet is the first transmission on the link once transfer control
handshaking has completed (the first transmission in BULK/INTERRUPT).
All data passed here is for 'argument id 0x20'. I've been going over the
source, but I haven't been able to find any definitions of argument IDs. Do
any exist?
01 FF 00 00 00 16 // netsync header, 22 byte encapsulated packet
// note: the following is all one packet at the USB level
90 01 00 00 00 00 00 00 // userinfo response, one argument, padded
00 20 00 00 00 08 // long argument ID 20, length 8
00 00 01 00 00 00 00 00 // eight bytes
// in ritual source: 00 00 00 01 80 00 00 00
-- FROM PC --
The PC then comes back with the following:
01 02 00 00 00 32 // netsync header, 50 byte encapsulated packet
12 01 00 00 00 00 00 00 // sysinfo request, one argument, padded
00 20 00 00 00 24 // argument ID 20, length 36
// the packet seen below appears in every sync with this Clie.
// next to it is the ritual packet defined in the source.
FF FF FF FF // FF FF FF FF
3C 00 3C 00 // 3C 00 3C 00
00 00 00 00 // 00 00 00 00
00 00 00 01 // 00 00 00 00
00 04 00 00 // C0 A8 A5 1F (ip address)
00 04 00 00 // 04 27 00 00
3C 00 3C 00 // 00 00 00 00
00 00 00 00 // 00 00 00 00
00 00 00 00 // 00 00 00 00
If the PC sends this sysinfo request without an argument, it gets 'invalid
parameter' back from the Clie. I'm not sure what happens if the response is
slightly malformed; I'll play with that later.
-- FROM CLIE --
The Clie responds to this with a slightly transformed version:
01 02 00 00 00 32 // netsync header, 50 byte packet
// note that the xid above did not change from the
// packet this is in response to -- is this normal?
92 01 00 00 00 00 00 00 // sysinfo response, one argument, padded
00 20 00 00 00 24 // argument ID 20, length 36
FF FF FF FF
00 3C 00 3C // this is reversed
40 00 00 00 // this is entirely new
01 00 00 00 // this is reversed
00 00 04 00 // this is reversed
00 00 04 00 // this is reversed
00 3C 00 3C // this is reversed
00 00 00 00
00 00 00 00
-- FROM PC --
The PC then asks for the Clie's system time/date:
01 03 00 00 00 2e // netsync, 46 bytes
13 01 00 00 00 00 00 00 // get system time/date, one arg
00 20 00 00 00 20 // arg ID #20, length 32
FF FF FF FF // here we have the mystery data as passed to us by the Clie
00 3C 00 3C // a moment ago, with a few changes:
00 00 00 00 // <--this line is zeroed
01 00 00 00
00 00 04 00
00 00 04 00
00 3C 00 3C
00 00 00 00
// <-- this line is omitted -->
-- FROM CLIE --
The Clie responds with a rather unhelpful string of zeros.
01 03 00 00 00 08 // netsync, eight bytes
93 00 00 00 00 00 00 00 // systime response, no error, no args, zeros
-- FROM PC --
The PC then re-requests sysinfo with a -different- argument 20, this time in
short form:
01 04 00 00 00 08 // netsync, eight bytes
12 01 20 04 00 01 00 03 // sysinfo, one arg, id 20, length 4, 0x00010003
[side note: the command or request header is -always- padded to eight bytes
when long arguments follow.]
-- FROM CLIE --
Now, things start making sense.
01 04 00 00 00 22 // netsync, 34 bytes
92 02 00 00 // sysinfo response, two arguments, no error
20 0e // first argument, id 20, length 14
04 10 30 00 // ROM version (4.1.3)
00 01 00 00 // Localization 0x010000
00 // unused
04 // product ID is four bytes
00 03 00 00 // product ID
21 0c // second argument, id 21, length 12
00 01 00 02 // DLP 1.2
00 03 00 00 // Product compatibility: 3.0
00 00 FF E1 // Maximum record size: 0xFFE1 (65505 bytes)
(from this point forward, I'm just using the analyzed version for easier
reading, now that I'm confident that this is in fact DLP)
-- FROM PC --
Feature Request (0x38)
One argument, id 0x20, length 6: 78 70 6e 00 00 (ASCII 'xpn\0\0')
-- FROM CLIE --
Feature response, one argument, no error.
Argument 0x20, length 4: 00 00 00 c8
-- FROM PC --
Undocumented request (0x55), one argument (0x20) with zero bytes
-- FROM CLIE --
Undocumented response (0xD5), no arguments, error code 0x290D (undocumented)
-- FROM PC --
Find DB, one argument.
Arg 22: 10 bytes: 00 80 68 74 61 6c 68 74 63 70 (htal htcp)
-- FROM CLIE --
Find DB response, no arguments, no error.
-- FROM PC --
Read feature 'netl\0\0'
-- FROM CLIE --
Feature response, no error, arg 20 reads 0x03200000 (version number)
Anyway. From this point forward, it's all standard DLP. I can't even find
any long arguments after the initial exchange (though I could be wrong).
Any thoughts?
-Cliff L. Biffle
--
This message was sent through the coldsync-hackers mailing list. To remove
yourself from this mailing list, send a message to majordomo@thedotin.net
with the words "unsubscribe coldsync-hackers" in the message body. For more
information on Coldsync, send mail to coldsync-hackers-owner@thedotin.net.