GTK Notes:
----------

Packet Notes:
-------------

If you get a service 15 packet with content of "0,", you should
reread the buddy list.  (I don't do this yet.)

------------------

Content for chat invite - split into three pieces by control-A:
	Invite From:
	Invite Message:
	Invite URL:

Start conference: content for all of these is split on control-B indicated
	below with a caret (^)
service 24, split on control-b  (^X)
	send: id^invited-users^msg^0
	recv: id^host^invited-users^msg^0

	The ^0 indicates that it is a text-only chat, ^1 would indicate voice
	chat capability. I've sent a note to the hearme.com people about their
	SDK, but I doubt that they are going to be too interested in a unix client
	for the service.

	trysend: nneul-1^dpf,sensory_perception,tnneul^test conf nneul-1^0   (ok)

From my testing, it appears that the conference ID can be anything, windows
client doesn't let you name it though.

service 25 - conference logon   (^Y)
	recv: id^user-who-logged-onto-conf
	send: id^all-invited-users-and-host
when sending to accept, looks like on is sent to each user in the conference
or maybe just back to the 'host', user is list from invite

service 26 - declined conference (^Z)
	recv: id^user-who-declined^msg
	send:  id^all-invited-users-and-host^msg
content split on ^b: conference-id, host, msg

service 27 - conference logoff (sent and received)
	send: id^all-invited-users
	recv: id^user-who-left-conference

service 28 - non-owner conference invite
	send: id^invited-user^previous-users^previous-users^msg^0
	recv: id^inviter^invited-user

	recv-inviteduser: id^inviter^who-else-invited^who-else-in-conf^msg^0
		messagetype == normal == 1
	recv-noninviteduser: id^inviter^invited-user
		messagetype == 11

service 29 - conference message
	send: id^users-in-conf^msg
	recv: id^who-from^msg
content split on ^b


-------------------------

Funky new stuff with new pager:

^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@YPNS1.4^@\Sys^V^@^@^@^@^@^@^@iver
^@^@^Fc^@n^@nneul^@l^@a^@n^@e^@t^@.^@o^@r^@g^@^@^@^@^@^@^@^@^@^@^@^@^@nneul^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@C=0^AF=0,P=0,H=0,S=0,W
=0,O=0^AM=0,P=0,C=0,S=0^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@

Service=^V   and look at those weird = things.


------------------------------------------------
unknown3 - last four bytes before first id
various different values:
00-00-00-00 - ?
00-00-00-01 - ok?
00-00-00-02 - error - user not on or unknown user, also unknown 2 will be 0
00-00-00-04 - "nneul(0)" in content
80-00-00-00 - bumped


--------------------------------------------------------------------

Notes on ncclogin crypt string

tnneul,a    cpasswd=$1$_2S43d5f$0f.GkSQV0QQ0PhLZp9TG41&n=1
tnneul2,a   cpasswd=$1$_2S43d5f$0f.GkSQV0QQ0PhLZp9TG41&n=1
tnneul,b    cpasswd=$1$_2S43d5f$sKjHZWKjOc9DbvmB48M961&n=1
tnneul2,b   cpasswd=$1$_2S43d5f$sKjHZWKjOc9DbvmB48M961&n=1
tnneul,c    cpasswd=$1$_2S43d5f$B54Yn8tMKBynGpXKIwGoa/&n=1
tnneul,d    cpasswd=$1$_2S43d5f$KsbTfbF1U/XBfU6AyPyK20&n=1

./0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz
that is 64 characters, which would represent 6 bits each

tnneul,a    0f.GkSQV0QQ0PhLZp9TG41
tnneul2,a   0f.GkSQV0QQ0PhLZp9TG41
tnneul,b    sKjHZWKjOc9DbvmB48M961
tnneul2,b   sKjHZWKjOc9DbvmB48M961
tnneul,c    B54Yn8tMKBynGpXKIwGoa/
tnneul,d    KsbTfbF1U/XBfU6AyPyK20
            
those are 22 characters, *6 bits each = 132 bits
I'm presuming that it's a 128 bit value
Since the last digit appears to always be in [./01] I'm assuming that 
. = 111111
/ = 111110
0 = 111101
1 = 111100

Breaking: 	KsbTfbF1U/XBfU6AyPyK20 into chunks
			KsbT fbF1 U/XB fU6A yPyK 20	
		each chunk is 24 bits

If you assume that the last two bytes (12 bits) are like the following, and 
that the memory is filled from the left.

[xxxxxxyy][yyyy----]
 121-128   129-132

I would assume the first two bits of y will be 00,01,10,11

I don't know. Basically somehow the last 4 bits should probably be zero.

Another possibility is that the string is reversed, or is built up from
right-to-left such that the last two chars form the leftmost 12 bits of
the resultant hash value. 

Another possibility is simply that the last char simply is a minimal
representation of two bits. 
	



=======
From mhash driver:
infinity(87)>echo "d" | driver 1 1    (MD5)
8277E0910D750195B448797616E091AD
infinity(91)>echo "d" | driver 5 1    (RIPEMD128)
F9A9096C02686573032D15642ABD1964


I have not had any luck with any of my fiddling with trying to determine how
that hash/key/password is determined.



-----------------------

Yahoo has a couple of web interfaces now - to send messages and to 
generate an image to see if a user is online:

<img src="http://um6.yahoo.com/online?u=USERIDHERE&m=g&t=1"

-----------------------

Noticed that windows messenger seems to set the connection id to 
0x0600000a when logging in... not sure why. But it seems to be
pretty consistent. Also note the two new MSGTYPE's in yahoolib.h.
I think that the msgtype field is actually a bitfield, but I
don't have enough info to determine meanings yet.



Multiple fonts support is HTML like:
        Raw Content = nneul,,test <font face="Comic Sans MS">font1 <font size="34">font2 hello


---------------------------

values of unknown flag 1:

0x15209783
0x890D12D0
0x00000000

seems to be 15209783 most of the time

Duh... Just realized. That appears to be my IP in little endian. Why is it
telling me what MY ip address is. That's just bizarre.
