When you hear the phrase "The AOL Protocol", I bet most of you immediately think of FDO, right? Although FDO is a part of the AOL protocol, it in no way encompasses the big picture. When I use the term "The AOL protocol", I refer to how the AOL client and server interact with each other, how data is prepared, how it is sent, and how it can be manipulated.
There currently exists no formal documentation of the AOL protocol, or at least one that is publicly available. For this reason, I have taken it upon myself to strip the bits of information from my feeble mind and write a document with at least basic information about the AOL protocol. The information included in this document is what I have learned, from exploration, help from others, and just stumbling upon it. I in no way guarantee the accuracy of the information contained herein. That said, here is what I know.
Table of Contents
1) Establishing a connection
A. Servers
B. The handshake
C. Sending the screenname and password
D. Completing the login
2) The packet
A. The first byte
B. The second and third bytes(CRC)
C. The fourth byte
D. The fifth byte
E. The sixth and seventh bytes
F. The eighth byte
G. The ninth and tenth bytes
3) Logging AOL's Data Packets
4) Forming Data Packets
5) Pings
6) About FDO Decompression
7) Putting it all together
8) Using Common Sense
1) Establishing a connection
A. Servers - America Online Servers generally run on port 5190. The server that the clients connect to is randomly chosen via the DNS Round Robin 'AmericaOnline.aol.com'. There are literally hundreds of America Online servers linked together. It makes you wonder how they avoid the common IRC occurrence of "Net Splits". To connect to an AOL server, all one has to do is connect to 'AmericaOnline.aol.com' on port 5190. I'm sure all of you can do this, you can even test it in Telnet. AOL servers that people generally connect to are called "berps". An example AOL server is 'berp-cr01.dial.aol.com'.
B. The handshake - Upon connecting to America Online, the client first sends an identification packet that includes the version of the AOL client being used. On success, the server will send back go ahead packet(SD) and the client will then send Screenname/Password. On failure, the AOL server will send an XS and the client will disconnect. AOL uses this in order to disable older clients from connecting and force people to upgrade. If the server gives no response, the packet wasn't formed correctly.
C. Sending the screenname and password - After the server accepts the initial handshake, the screennname and password are sent. If the screenname and password match, the server then sends the Master Tool disabling information, and also sends the Welcome Window FDO. If the screenname and password do not match, the server will ask for the password once more, if it fails twice, the server sends the XS and the client is disconnected.
D. After receiving the Welcome Window FDO, the client sends the 'ya' token. This causes AOL to tell you if you have mail, assign you an IP address, and, if you have configured it, show your buddy list. Once you are assigned an IP address you are completely logged in and can now send other commands to the AOL service.
2) The packet - Ah, the illusive AOL packet. The structure of these packets have remained a mystery throughout America Online's life. I will now make an attempt at breaking down these packets.
Here's a basic idea of what a packet may look like:
That?s the first ten bytes in any AOL packet. The only bytes that don't change constantly are the first, Z(5A in Hex), and the fourth, A null(00 in hex). Anything after the first ten bytes is compressed FDO or data strings. Here is a breakdown of the ten bytes in greater detail.
A. The first byte for all AOL versions is Z or 5A in Hex. This is probably the least troublesome byte because it never changes and you can't forget to add it as easily as you can the fourth.
B. The second and third bytes are 'Hi' and 'Lo' bytes produced from the CRC16 Algorithm. CRC stands for "Cyclic Redundancy Check". The CRC is often used in compression to make sure no data was corrupted. If the CRC header does not match the data in a zip file, the file is assumed corrupted. The same goes for AOL packets. If the CRC does not match the packet, the AOL server ignores it. The CRC is taken from the packet with the first 5 bytes(the header) removed. The number produced by the algorithm is then used to produce a 'Hi' and a 'Lo' byte that is placed in the 2nd and 3rd spots in the header. The CRC only applies to versions of AOL clients 3.0 and below. The newer AOL clients simply send '**' as the 2nd and 3rd byte. you can get along with using newer AOL packets without a CRC, but you'll end up sending more data. If you can use the CRC it will actually be easier to just use it with the older, smaller packets.
Here is the CRC function and 'Hi' and 'Lo' byte subs for C++ and Visual Basic programmers. These are public functions, I did not write them:
C++:
Function AOLCrc (strng$, lenstr)
unsigned short
CRC16(byte * buffer, int length)
{
unsigned short crc = 0;
unsigned short ch;
int i, j;
for (i = 0; i > 1) ^ 0xa001;
Else
crc >>= 1;
ch >>= 1;
}
}
return (crc);
}
Visual Basic:
Function AOLCRC(strng$, lenstr)
Dim crc As Long
Dim ch As Long
Dim i As Long
Dim j As Long
For i = 0 To lenstr - 1
ch = Asc(Mid(strng$, i + 1, 1))
For j = 0 To 7
If ((crc Xor ch) And 1) Then
crc = (Int((crc / 2)) Xor 40961)
Else
crc = Int(crc / 2)
End If
ch = Int(ch / 2)
Next j
Next i
AOLCRC = crc
End Function
Function gethibyte(mybyte As Variant) As Variant
gethibyte = Int(mybyte / 256)
End Function
Function getlobyte(mybyte As Variant) As Variant
getlobyte = Int((mybyte - (gethibyte(mybyte) * 256)))
End Function
The use of these functions will be explained more later on.
C. The 4th byte for all AOL versions is a null(00 in Hex). This byte never changes, but it is required, just try to remember to include it.
D. The 5th byte is the length byte, The length byte is roughly the length of the packet with the first 5 bytes(The Header) removed. I say roughly because another thing can effect the length byte besides actual physical length. The byte directly before any string in the packet(screennames, chat, form data, etc..) is also a length byte. This byte represents the length of the string immediately following it, and is not counted in the 5th byte representation of the length. I have written a Visual Basic sub that will calculate the 5th byte in any given packet:
Function give5th(pack As String, inputz as integer)
'You need the EnHex function for this, you will find it later on in this document.
Dim give5th1 As Integer
inputz = inputz + 4
give5th1 = Len(DeHex(pack)) - inputz
give5th = EnHex(Chr(give5th1))
End Function
This function was written by me. Its use is simple. Just include the hexed entire packet(even header) and the # of inputs your form has to calculate the 5th byte to be places in your packet.
E. The 6th and 7th bytes - These 2 bytes are almost as mind boggling as the 2nd and 3rd. If you watch AOL packets go by, you'll see what I mean. The 6th and 7th seem to change wildly, with no way to tell what the next will be. These packets are different for every new packet sent, but actually go in a loop. If you look at the login packets I use, you'll see the 6th byte(in hex) is 10(Int 16), and the seventh is 18(Int 24). Before every packet sent, I simply increase each by 1. Although the actual client seems to do something a little different, adding 1 works. You can't add 1 forever, of course. You'll notice after a while the AOL server will stop responding. The solution to this is resetting the 6th and 7th bytes to their original values, 10(Int 10) and 18(Int 24). I'm sure most of you don't want to explore this yourself, so the 6th and 7th reset at Int 127 and Int 135. I'm a little confused on what to call these bytes. I call them "counter bytes", but I've often heard them referred to as 'heartbeats'. It seems to me the 9 char "ping-like" packets should be called heartbeats(Who knows? maybe they are). Regardless of terminology, this works.
F. The 8th byte is simply a space.
G. Finally, the 9th and 10th bytes(in ASCII) represent the token. for those of you who know FDO, you know that token kind of tells the server what to expect. If you aren't sure what you're looking at, just look for these tokens and cross check them with the AOL-Files token list to see what kind of packet it is.
3) Logging AOL's Data Packets
Logging the packets AOL uses is a very important skill when dealing with the AOL protocol. Without it, you will get nowhere. When you form a packet to send to the AOL server, you don't build it from the ground up(At least I don't). To build it from scratch would require you to write it in FDO, compress the FDO, and add the header. Although it is possible to do it that way, it is much easier to use logged packets and just change them where needed. Getting AOL packets is actually pretty simple. First, you create a program that listens on port 5190 for incoming connections. You then choose a version of AOL to spy on. This document revolves around 2.5 packets, so I suggest using AOL 2.5(available at http://clients.aol-files.com). You have to set up the AOL client to connect to your computer locally, rather than to 'AmericaOnline.aol.com'. To do this open the 'tcp.ccl' file in the 'ccl' directory and change the 'AmericaOnline.aol.com' to 'localhost'. Save and close the file. you then connect your AOL client. If you did it correctly, you should see an incoming connection in your program. Now, your program make it so that when a client connects your program connects to 'AmericaOnline.aol.com' on port 5190. Set up your program so that when Data is received, depending on the ID of the socket, it will direct the data to the client or server socket. If data is sent from the client, send it to the server, if it is sent from the server, sent it to the client. The idea behind this is to become a type of "data link" between the server and client. We can now begin to intercept data.
Intercepting the data is nothing more than creating a textbox and displaying incoming data from the client or server. Its a good idea to mark it 'client' or 'server' to get a better idea of what you're looking at. The only trick to doing this is editing out the null characters. When a null character is put in any textbox or other viewing object, it represents to Windows the end of a line, so any text after it is unreadable. By editing out the null characters in a string, you allow yourself to see the entire packet. Here is a Visual Basic function I wrote to edit out null characters:
Function stripnulls(thedata as String)
Dim torem as Integer
torem = 1
Do Until crap = 0
torem = InStr(1, thedata, Chr$(0))
If torem > 0 Then Mid(thedata, torem, 1) = "Å"
Loop
End Function
When displaying a packet in ASCII, its is pretty much ruined for sending back to the server, even if you try putting the nulls back in. So most editing for packets is done in Hex. Here are some Visual Basic functions to Hex and DeHex strings and integers:
Public Function EnHex(Data As String) As String
Dim iCount As Double
Dim sTemp As String
For iCount = 1 To Len(Data)
sTemp = Hex$(Asc(Mid$(Data, iCount, 1)))
If Len(sTemp) 0 Then Mid(sData, crap, 1) = "Å"
Loop
status.Text = status.Text & "Server: " & sData & vbCrLf & vbCrLf
If InStr(1, sData, "Invalid password") Then
status.Text = status.Text & "Invalid Password" & vbCrLf
Call Winsock1.Close
End If
If InStr(1, sData, "Invalid account") Then
status.Text = status.Text & "Invalid account" & vbCrLf
Call Winsock1.Close
End If
If InStr(1, sData, "SD") Then
screenname1$ = Int2Hex(Len(screenname.Text) + 1) & EnHex(screenname.Text)
password1$ = Int2Hex(Len(password.Text)) & EnHex(password.Text)
fifth$ = give5th("5AD69400411010A044640015000100010A0400000 001010B04000000010301" & screenname1$ & "20011D00011D00010A04000000020301" & password1$ & "011D000002000D", 2)
packet$ = DeHex("00" & fifth$ & "1010A044640015000100010A0400000001010B04000000010 301" & screenname1$ & "20011D00011D00010A04000000020301" & password1$ & "011D000002000D")
crc1 = AOLCRC(packet$, Len(packet$) - 1)
thehi$ = Chr(gethibyte(crc1))
thelo$ = Chr(getlobyte(crc1))
packet$ = DeHex("5A" & EnHex(thehi$) & EnHex(thelo$) & "00" & fifth$ & "1010A044640015000100010A0400000001010B04000000010 301" & screenname1$ & "20011D00011D00010A04000000020301" & password1$ & "011D000002000D")
Winsock1.SendData packet$ 'Sends the screenname/password. If you don?t understand this refer above to 'Forming Packets'
packet$ = DeHex("5A3A0A00031018A40D") 'This is a logged ping packet
Winsock1.SendData packet$
End If
If InStr(1, sData, "Master Tool") Then
packet$ = DeHex("5A3A0A00031018A40D5AC6910008111CA0796107010 10D5A5C340022121CA0746C00170001000A0F04007BB5E80A1 0041DA6DDF20A4504000000070002000D5A6F4A000D131CA05 34300150001000002000D")
Winsock1.SendData packet$ 'This sends the ya login packet, NO CHANGES HAVE BEEN MADE
sixth=Hex2Int("13")
seventh=Hex2Int("21") 'This is where you set your sixth and seventh at first.
End If
In the Winsock control's 'SendComplete' event, put this:
Dim crap as Integer
crap = 1
Do Until crap = 0
crap = InStr(1, packet$, Chr$(0))
If crap > 0 Then Mid(packet$, crap, 1) = "Å"
Loop
status.Text = status.Text & "Client: " & packet$ & vbCrLf & vbCrLf
In the status textbox's 'Change' event, put this:
status.SelStart = Len(status.Text) 'Auto Scrolls
If Len(status.Text) >= 32000 Then status.Text = Right$(status.Text, Len(status.Text) / 2) 'Keeps the length from getting too large
Make sure your status.Text is set MultiLine to True and has scrollbars. If you did it correctly, you should now have a working AOL client that has a status box and can send IMs. Welcome to Winsock AOL.
8) Common Sense
Ok, most of you have probably stopped reading by now. But I need to make a point.
The only reason that the information above is not already widely available is because of the fear of abuse. Putting this information in immature hands is dangerous. Some people believe that if it gets out, the walls of the America Online service will come crashing down as things like faster mail bombers, spammers, IM bombers, and cloners begin to immerge. It may very well be impossible to enter a chat room without being so lagged by scrolling, IMs, and emails that you cannot even stay connected. I don't personally believe that though. Due to the complexity of these packets, it is far harder to use even copied source of this than to use copied source of the infamous "AOL Progs" that eventually died out. If you are learning from this document, I implore you to use common sense in your use of this information.
This document would not be possible if it weren?t from the help I received from my friends.
Thanks to phrea, nec, jay, ceramic, and anyone else who I forgot.
Thank you for listening,
Gods Misfit
binary0100@yahoo.com
http://aol.necrocosm.com
well, hotspot compiles only the most used parts of the code, in my experience it works perfectly well for most apps...
In fact the real slowness of java came not from the application code but from two things:
the loading of Swing (horrible... Swing was loaded by the normal classloader and was bytecode-validated at each load !)
and the BAD implementation of AWT...
Of course for small apps, the loading time is all-important and any interpretor overhead is BAD... but for long running apps (server side is a perfect case:-) the adventage of dynamic recompilation and "auto-profiling" is GOOD !
I do not know the details of the.NET CLR but I hope (in reality I do not mind because i doubt that the platform will be ported to any non microsoft OS now that the breakup is void) it has an interpreter, otherwise, dynamic class loading will be much too slow. Self-modifying code would be impossible too (and Yes, I have made self modifing code in Java !)
In unstable, gnucash 1.6 does not install at all, some fcking package needed has 'vanished'
I suppose it was too broken even for unstable !
Compiling from source IS hard (I suppose impossible for poor newbie Mandrake Users !): the number of libs required, while certainly not 60 was quite impressive (NO, the gnome dev libs are not enough)
Whatever, the pretty reports (arghh are they slow to render... fsck scheme !) did ease my GFs transition from money:-)...
Slashdot Mirror
Even better: /Applications/TextEdit.app
open -a
It is not about the value of life, killing somebody is not "selling his life" it is "selling his death"
Of course a human life has probably much more value then 1 M$ but nobody trades in human lifes, deaths are so much more affordable
Karma whoring at its brightest...
7 0A1000080400000000035F0000010004000300080000000000 000000000000020D
0 0D
4 0000000103010A686F6C797461626C6520011D00011D00010A 0400000002030108736174616E363636011D000002000D
C 340022121CA0746C00170001000A0F04007BB5E80A10041DA6 DDF20A4504000000070002000D5A6F4A000D131CA053430150 001000002000D
8 A3CE86070101050203C00A153135332D34362D31362E697074 2E616F6C2E636F6D0D5A7E91001E1E132076A007BB5E81DA6D DF20000000000696D66617274702E627574000D
0 001010B04000000010301" & screenname$ & "20011D00011D00010A04000000020301" & password$ & "011D000002000D", 2)
0 001010B04000000010301" & screenname1$ & "20011D00011D00010A04000000020301" & password1$ & "011D000002000D", 2)
0 301" & screenname1$ & "20011D00011D00010A04000000020301" & password1$ & "011D000002000D")
0 301" & screenname1$ & "20011D00011D00010A04000000020301" & password1$ & "011D000002000D")
0 10D5A5C340022121CA0746C00170001000A0F04007BB5E80A1 0041DA6DDF20A4504000000070002000D5A6F4A000D131CA05 34300150001000002000D")
0 003010A04000000010301" & screenname1$ & "011D00010A04000000020301" & IM1$ & "011D00011D00011D000002000D", 2)
" & screenname1$ & "011D00010A04000000020301" & IM1$ & "011D00011D00011D000002000D")
" & screenname1$ & "011D00010A04000000020301" & IM1$ & "011D00011D00011D000002000D")
The AOL Protocol
When you hear the phrase "The AOL Protocol", I bet most of you immediately think of FDO, right? Although FDO is a part of the AOL protocol, it in no way encompasses the big picture. When I use the term "The AOL protocol", I refer to how the AOL client and server interact with each other, how data is prepared, how it is sent, and how it can be manipulated.
There currently exists no formal documentation of the AOL protocol, or at least one that is publicly available. For this reason, I have taken it upon myself to strip the bits of information from my feeble mind and write a document with at least basic information about the AOL protocol. The information included in this document is what I have learned, from exploration, help from others, and just stumbling upon it. I in no way guarantee the accuracy of the information contained herein. That said, here is what I know.
Table of Contents
1) Establishing a connection
A. Servers
B. The handshake
C. Sending the screenname and password
D. Completing the login
2) The packet
A. The first byte
B. The second and third bytes(CRC)
C. The fourth byte
D. The fifth byte
E. The sixth and seventh bytes
F. The eighth byte
G. The ninth and tenth bytes
3) Logging AOL's Data Packets
4) Forming Data Packets
5) Pings
6) About FDO Decompression
7) Putting it all together
8) Using Common Sense
1) Establishing a connection
A. Servers - America Online Servers generally run on port 5190. The server that the clients connect to is randomly chosen via the DNS Round Robin 'AmericaOnline.aol.com'. There are literally hundreds of America Online servers linked together. It makes you wonder how they avoid the common IRC occurrence of "Net Splits". To connect to an AOL server, all one has to do is connect to 'AmericaOnline.aol.com' on port 5190. I'm sure all of you can do this, you can even test it in Telnet. AOL servers that people generally connect to are called "berps". An example AOL server is 'berp-cr01.dial.aol.com'.
B. The handshake - Upon connecting to America Online, the client first sends an identification packet that includes the version of the AOL client being used. On success, the server will send back go ahead packet(SD) and the client will then send Screenname/Password. On failure, the AOL server will send an XS and the client will disconnect. AOL uses this in order to disable older clients from connecting and force people to upgrade. If the server gives no response, the packet wasn't formed correctly.
Client: 5A413800347F7FA3036B0100F5000000050F00002152CBCA0
Client: ZA8Å4??£kÅõÅÅÅÅÅ!RËÊÅÅÅÅÅ_ÅÅÅÅÅÅÅÅÅÅÅÅÅÅÅÅ
Server: 5AB71100037F7F240D5A88E9000B107F20534454D1F68B000
Server: Z-Å??$Z?éÅ? SDTÑö?ÅÅ
C. Sending the screenname and password - After the server accepts the initial handshake, the screennname and password are sent. If the screenname and password match, the server then sends the Master Tool disabling information, and also sends the Welcome Window FDO. If the screenname and password do not match, the server will ask for the password once more, if it fails twice, the server sends the XS and the client is disconnected.
Client: 5A243F00431010A044640015000100010A0400000001010B0
Client: Z$?ÅCDdÅÅÅÅÅÅÅÅÅholytable ÅÅÅÅÅsatan666ÅÅÅ
D. After receiving the Welcome Window FDO, the client sends the 'ya' token. This causes AOL to tell you if you have mail, assign you an IP address, and, if you have configured it, show your buddy list. Once you are assigned an IP address you are completely logged in and can now send other commands to the AOL service.
Client: 5A4EBA00031018A40D5AC6910008111CA079610701010D5A5
Client: ZNÅZÆ?Å-yaZ\4Å" tlÅÅÅÅ{è¦ÝòEÅÅÅÅÅZoJÅSCÅÅÅÅÅ
Server: 5A419B00351D132079610304AC992E1002010201010004049
Server: ZA?Å5 ya?.Å?£Î?À153-46-16.ipt.aol.comZ~?Å-- tjÅ{è¦ÝòÅÅÅÅÅimfartp.butÅ
2) The packet - Ah, the illusive AOL packet. The structure of these packets have remained a mystery throughout America Online's life. I will now make an attempt at breaking down these packets.
Here's a basic idea of what a packet may look like:
Z (CRC) (CRC) [NULL] (LENGTH BYTE) (HB 6TH) (HB 7TH) [SPACE] (TOKEN) (TOKEN)
That?s the first ten bytes in any AOL packet. The only bytes that don't change constantly are the first, Z(5A in Hex), and the fourth, A null(00 in hex). Anything after the first ten bytes is compressed FDO or data strings. Here is a breakdown of the ten bytes in greater detail.
A. The first byte for all AOL versions is Z or 5A in Hex. This is probably the least troublesome byte because it never changes and you can't forget to add it as easily as you can the fourth.
B. The second and third bytes are 'Hi' and 'Lo' bytes produced from the CRC16 Algorithm. CRC stands for "Cyclic Redundancy Check". The CRC is often used in compression to make sure no data was corrupted. If the CRC header does not match the data in a zip file, the file is assumed corrupted. The same goes for AOL packets. If the CRC does not match the packet, the AOL server ignores it. The CRC is taken from the packet with the first 5 bytes(the header) removed. The number produced by the algorithm is then used to produce a 'Hi' and a 'Lo' byte that is placed in the 2nd and 3rd spots in the header. The CRC only applies to versions of AOL clients 3.0 and below. The newer AOL clients simply send '**' as the 2nd and 3rd byte. you can get along with using newer AOL packets without a CRC, but you'll end up sending more data. If you can use the CRC it will actually be easier to just use it with the older, smaller packets.
Here is the CRC function and 'Hi' and 'Lo' byte subs for C++ and Visual Basic programmers. These are public functions, I did not write them:
C++:
Function AOLCrc (strng$, lenstr)
unsigned short
CRC16(byte * buffer, int length)
{
unsigned short crc = 0;
unsigned short ch;
int i, j;
for (i = 0; i > 1) ^ 0xa001;
Else
crc >>= 1;
ch >>= 1;
}
}
return (crc);
}
Visual Basic:
Function AOLCRC(strng$, lenstr)
Dim crc As Long
Dim ch As Long
Dim i As Long
Dim j As Long
For i = 0 To lenstr - 1
ch = Asc(Mid(strng$, i + 1, 1))
For j = 0 To 7
If ((crc Xor ch) And 1) Then
crc = (Int((crc / 2)) Xor 40961)
Else
crc = Int(crc / 2)
End If
ch = Int(ch / 2)
Next j
Next i
AOLCRC = crc
End Function
Function gethibyte(mybyte As Variant) As Variant
gethibyte = Int(mybyte / 256)
End Function
Function getlobyte(mybyte As Variant) As Variant
getlobyte = Int((mybyte - (gethibyte(mybyte) * 256)))
End Function
The use of these functions will be explained more later on.
C. The 4th byte for all AOL versions is a null(00 in Hex). This byte never changes, but it is required, just try to remember to include it.
D. The 5th byte is the length byte, The length byte is roughly the length of the packet with the first 5 bytes(The Header) removed. I say roughly because another thing can effect the length byte besides actual physical length. The byte directly before any string in the packet(screennames, chat, form data, etc..) is also a length byte. This byte represents the length of the string immediately following it, and is not counted in the 5th byte representation of the length. I have written a Visual Basic sub that will calculate the 5th byte in any given packet:
Function give5th(pack As String, inputz as integer)
'You need the EnHex function for this, you will find it later on in this document.
Dim give5th1 As Integer
inputz = inputz + 4
give5th1 = Len(DeHex(pack)) - inputz
give5th = EnHex(Chr(give5th1))
End Function
This function was written by me. Its use is simple. Just include the hexed entire packet(even header) and the # of inputs your form has to calculate the 5th byte to be places in your packet.
Example: give5th("5AD69400411010A044640015000100010A040000
E. The 6th and 7th bytes - These 2 bytes are almost as mind boggling as the 2nd and 3rd. If you watch AOL packets go by, you'll see what I mean. The 6th and 7th seem to change wildly, with no way to tell what the next will be. These packets are different for every new packet sent, but actually go in a loop. If you look at the login packets I use, you'll see the 6th byte(in hex) is 10(Int 16), and the seventh is 18(Int 24). Before every packet sent, I simply increase each by 1. Although the actual client seems to do something a little different, adding 1 works. You can't add 1 forever, of course. You'll notice after a while the AOL server will stop responding. The solution to this is resetting the 6th and 7th bytes to their original values, 10(Int 10) and 18(Int 24). I'm sure most of you don't want to explore this yourself, so the 6th and 7th reset at Int 127 and Int 135. I'm a little confused on what to call these bytes. I call them "counter bytes", but I've often heard them referred to as 'heartbeats'. It seems to me the 9 char "ping-like" packets should be called heartbeats(Who knows? maybe they are). Regardless of terminology, this works.
F. The 8th byte is simply a space.
G. Finally, the 9th and 10th bytes(in ASCII) represent the token. for those of you who know FDO, you know that token kind of tells the server what to expect. If you aren't sure what you're looking at, just look for these tokens and cross check them with the AOL-Files token list to see what kind of packet it is.
3) Logging AOL's Data Packets
Logging the packets AOL uses is a very important skill when dealing with the AOL protocol. Without it, you will get nowhere. When you form a packet to send to the AOL server, you don't build it from the ground up(At least I don't). To build it from scratch would require you to write it in FDO, compress the FDO, and add the header. Although it is possible to do it that way, it is much easier to use logged packets and just change them where needed. Getting AOL packets is actually pretty simple. First, you create a program that listens on port 5190 for incoming connections. You then choose a version of AOL to spy on. This document revolves around 2.5 packets, so I suggest using AOL 2.5(available at http://clients.aol-files.com). You have to set up the AOL client to connect to your computer locally, rather than to 'AmericaOnline.aol.com'. To do this open the 'tcp.ccl' file in the 'ccl' directory and change the 'AmericaOnline.aol.com' to 'localhost'. Save and close the file. you then connect your AOL client. If you did it correctly, you should see an incoming connection in your program. Now, your program make it so that when a client connects your program connects to 'AmericaOnline.aol.com' on port 5190. Set up your program so that when Data is received, depending on the ID of the socket, it will direct the data to the client or server socket. If data is sent from the client, send it to the server, if it is sent from the server, sent it to the client. The idea behind this is to become a type of "data link" between the server and client. We can now begin to intercept data.
Intercepting the data is nothing more than creating a textbox and displaying incoming data from the client or server. Its a good idea to mark it 'client' or 'server' to get a better idea of what you're looking at. The only trick to doing this is editing out the null characters. When a null character is put in any textbox or other viewing object, it represents to Windows the end of a line, so any text after it is unreadable. By editing out the null characters in a string, you allow yourself to see the entire packet. Here is a Visual Basic function I wrote to edit out null characters:
Function stripnulls(thedata as String)
Dim torem as Integer
torem = 1
Do Until crap = 0
torem = InStr(1, thedata, Chr$(0))
If torem > 0 Then Mid(thedata, torem, 1) = "Å"
Loop
End Function
When displaying a packet in ASCII, its is pretty much ruined for sending back to the server, even if you try putting the nulls back in. So most editing for packets is done in Hex. Here are some Visual Basic functions to Hex and DeHex strings and integers:
Public Function EnHex(Data As String) As String
Dim iCount As Double
Dim sTemp As String
For iCount = 1 To Len(Data)
sTemp = Hex$(Asc(Mid$(Data, iCount, 1)))
If Len(sTemp) 0 Then Mid(sData, crap, 1) = "Å"
Loop
status.Text = status.Text & "Server: " & sData & vbCrLf & vbCrLf
If InStr(1, sData, "Invalid password") Then
status.Text = status.Text & "Invalid Password" & vbCrLf
Call Winsock1.Close
End If
If InStr(1, sData, "Invalid account") Then
status.Text = status.Text & "Invalid account" & vbCrLf
Call Winsock1.Close
End If
If InStr(1, sData, "SD") Then
screenname1$ = Int2Hex(Len(screenname.Text) + 1) & EnHex(screenname.Text)
password1$ = Int2Hex(Len(password.Text)) & EnHex(password.Text)
fifth$ = give5th("5AD69400411010A044640015000100010A040000
packet$ = DeHex("00" & fifth$ & "1010A044640015000100010A0400000001010B0400000001
crc1 = AOLCRC(packet$, Len(packet$) - 1)
thehi$ = Chr(gethibyte(crc1))
thelo$ = Chr(getlobyte(crc1))
packet$ = DeHex("5A" & EnHex(thehi$) & EnHex(thelo$) & "00" & fifth$ & "1010A044640015000100010A0400000001010B0400000001
Winsock1.SendData packet$ 'Sends the screenname/password. If you don?t understand this refer above to 'Forming Packets'
packet$ = DeHex("5A3A0A00031018A40D") 'This is a logged ping packet
Winsock1.SendData packet$
End If
If InStr(1, sData, "Master Tool") Then
packet$ = DeHex("5A3A0A00031018A40D5AC6910008111CA079610701
Winsock1.SendData packet$ 'This sends the ya login packet, NO CHANGES HAVE BEEN MADE
sixth=Hex2Int("13")
seventh=Hex2Int("21") 'This is where you set your sixth and seventh at first.
End If
In your send IM command button put this:
screenname1$ = Int2Hex(Len(IMName.Text)) & EnHex(IMName.Text)
IM1$ = Int2Hex(Len(IMMsg.Text)) & EnHex(IMMsg.Text)
If sixth = "127" Then
sixth = "15" 'Backtrack 1 because we are going to add 1 soon
seventh = "23" 'THIS IS THE CODE TO RESET THE BYTES
End If
sixth = CInt(sixth) + 1
seventh = CInt(seventh) + 1
fifth$ = give5th("5A606700001522A0695300250001000107040000
packet$ = DeHex("00" & fifth$ & Int2Hex(sixth) & Int2Hex(seventh) & "A06953002500010001070400000003010A04000000010301
crc1 = AOLCRC(packet$, Len(packet$) - 1)
thehi$ = Chr(gethibyte(crc1))
thelo$ = Chr(getlobyte(crc1))
packet$ = DeHex("5A" & EnHex(thehi$) & EnHex(thelo$) & "00" & fifth$ & Int2Hex(sixth) & Int2Hex(seventh) & "A06953002500010001070400000003010A04000000010301
Winsock1.SendData packet$
IMMsg.Text=""
In the Winsock control's 'SendComplete' event, put this:
Dim crap as Integer
crap = 1
Do Until crap = 0
crap = InStr(1, packet$, Chr$(0))
If crap > 0 Then Mid(packet$, crap, 1) = "Å"
Loop
status.Text = status.Text & "Client: " & packet$ & vbCrLf & vbCrLf
In the status textbox's 'Change' event, put this:
status.SelStart = Len(status.Text) 'Auto Scrolls
If Len(status.Text) >= 32000 Then status.Text = Right$(status.Text, Len(status.Text) / 2) 'Keeps the length from getting too large
Make sure your status.Text is set MultiLine to True and has scrollbars. If you did it correctly, you should now have a working AOL client that has a status box and can send IMs. Welcome to Winsock AOL.
8) Common Sense
Ok, most of you have probably stopped reading by now. But I need to make a point.
The only reason that the information above is not already widely available is because of the fear of abuse. Putting this information in immature hands is dangerous. Some people believe that if it gets out, the walls of the America Online service will come crashing down as things like faster mail bombers, spammers, IM bombers, and cloners begin to immerge. It may very well be impossible to enter a chat room without being so lagged by scrolling, IMs, and emails that you cannot even stay connected. I don't personally believe that though. Due to the complexity of these packets, it is far harder to use even copied source of this than to use copied source of the infamous "AOL Progs" that eventually died out. If you are learning from this document, I implore you to use common sense in your use of this information.
This document would not be possible if it weren?t from the help I received from my friends.
Thanks to phrea, nec, jay, ceramic, and anyone else who I forgot.
Thank you for listening,
Gods Misfit
binary0100@yahoo.com
http://aol.necrocosm.com
well, hotspot compiles only the most used parts of the code, in my experience it works perfectly well for most apps...
In fact the real slowness of java came not from the application code but from two things:Of course for small apps, the loading time is all-important and any interpretor overhead is BAD... but for long running apps (server side is a perfect case :-) the adventage of dynamic recompilation and "auto-profiling" is GOOD !
I do not know the details of the .NET CLR but I hope (in reality I do not mind because i doubt that the platform will be ported to any non microsoft OS now that the breakup is void) it has an interpreter, otherwise, dynamic class loading will be much too slow. Self-modifying code would be impossible too (and Yes, I have made self modifing code in Java !)
In unstable, gnucash 1.6 does not install at all, some fcking package needed has 'vanished' :-)...
I suppose it was too broken even for unstable !
Compiling from source IS hard (I suppose impossible for poor newbie Mandrake Users !): the number of libs required, while certainly not 60 was quite impressive (NO, the gnome dev libs are not enough)
Whatever, the pretty reports (arghh are they slow to render... fsck scheme !) did ease my GFs transition from money
It may only be free as in beer but it is free.
Last time i checked, IE 5.5 could be downloaded for free, and installs whithout problem on win95...