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:
font1 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.