Re: encryption

From: Stefan Kaczmarek <stefan_at_thezonie.org>
Date: Thu, 14 Jun 2007 15:50:21 -0700

No, it sends it from whatever port it picks from the ether ... (I
bind to 0)

8222 is the 0x201e port ... That's just the server's udp port.

You could just ignore those messages ... I don't know why your ip and
port would be in there, though.

On Jun 14, 2007, at 2:50 PM, Dylan Douglas wrote:

> It shouldn't be getting them on port 8222 though, should it? That
> would be something that the would be on some other port since it is
> p2p, not p2s.
>
> Z, does the p2p client always send udp traffic from the 8222 port?
>
> From: Ivan Kwok
> Sent: Thursday, June 14, 2007 2:45 PM
> To: Dylan Douglas
> Cc: Stefan Kaczmarek; Ben Ebert; Colin Keller; Gerald Rode; Jay
> Mairs; Nainesh Solanki; Sergio Alvarez; Ty Heath
> Subject: Re: encryption
>
> You're probably seeing the app's or console's UDP messages. Don't
> forget the console app and the client app are also running on the
> miivi server for publishing stuff.
>
> -Ivan
>
>
> On Jun 14, 2007, at 2:41 PM, Dylan Douglas wrote:
>
>> Okay now that I know I'm not on an acid trip, I'm seeing op code
>> 0x10 and 0x20s and things like that. They are the right length
>> for the type of packet they are supposed to be, but am I supposed
>> to be handling these messages some how? Like passing them on or
>> something? Cause the protocol spreadsheet says they are just p2p
>> communications.
>>
>> From: Stefan Kaczmarek [mailto:stefan_at_thezonie.org]
>> Sent: Thursday, June 14, 2007 12:45 PM
>> To: Dylan Douglas
>> Cc: Ben Ebert; Colin Keller; Gerald Rode; Ivan Kwok; Jay Mairs;
>> Nainesh Solanki; Sergio Alvarez; Ty Heath
>> Subject: Re: encryption
>>
>> I decrypted both of those packets fine. The second one was op code
>> 2, length 0x1a, a sha and ip 65.120.42.225.
>>
>> I use the exact same code to encrypt and decrypt ... What do you
>> need from me to figure this out?
>>
>> private static void DoCrypt(int key,byte[] data,int offset)
>> {
>> byte bite=0;
>> for(int i=offset;i<data.length;i++)
>> {
>> // key = (key * 1103515245 + 12345) & 0x7fffffff;
>>
>> // Bork the key
>> int a=key>>>16;
>> int b=key&0xffff;
>> a=(a * (1103515245 >>> 16))+12345;
>> b=(b * (1103515245 & 0xffff))+12345;
>> key=(key ^ a) ^ b;
>>
>> bite=(byte)((key/65536) % 256);
>> data[i] ^= bite;
>> }
>> }
>>
>>
>> - Z
>>
>> On Jun 14, 2007, at 12:32 PM, Dylan Douglas wrote:
>>
>>> Okay, finally got Wireshark to work on the MiiVi server. Here's the
>>> deal:
>>>
>>> I get the encrypted ping:
>>> { 0x61, 0xef, 0xb9, 0x16, 0x75, 0x28, 0xb3 }
>>> Decrypt it and get:
>>> { 0x00, 0x00, 0x00 }
>>> Yay teh shit works, right?
>>>
>>> I get the pierce, I'll assume by the length:
>>> { 0xb8, 0xde, 0xa1, 0x23, 0xff, 0x0f, 0xc4, 0xd9, 0x51, 0x93, 0x8d,
>>> 0x85, 0x3d, 0xe0, 0xa8, 0x87, 0x5a, 0xf6, 0x93, 0x69, 0xdc, 0xdb,
>>> 0x8c,
>>> 0x5d, 0x30, 0x2e, 0x1c, 0xfd, 0x8b, 0xcf, 0x8f, 0x2a, 0xf1 }
>>> Decrypt it and get:
>>> { 0x03, 0x01, 0x19, 0x0c ..... }
>>> Doh! WTF is a 0x03 op code? Also the length is screwed, since it
>>> should
>>> come out to be 1A.
>>>
>>> Both of these are from my office machine, so why does one work
>>> and the
>>> other is borkered? I checked several ping packets and they all
>>> work.
>>> All the other packets are fucked. Can you check your encryption is
>>> being happy for the piercing and not just the pinging? The weird
>>> thing
>>> is the packet aren't unencrypted either.
>>>
>>>
>>>
>>> -----
>>> Dylan Douglas
>>> MediaDefender
>>>
>>>
>>>
>>> <winmail.dat>
>>
>
Received on Fri Sep 14 2007 - 10:55:51 BST

This archive was generated by hypermail 2.2.0 : Sun Sep 16 2007 - 22:19:45 BST