Friday, May 25, 2007

RSA ACE/Server, Progress DB ODBC connection

I'm in the process of trying to enable an ODBC connection to the Progress database embedded in RSA's ACE/Server.

According to the version file on the server, I am running:
PROGRESS PATCH Version 8.3D10 as of September 24, 2001

I ordered the database client and the ODBC driver from Progress, installed, and attempted to set up an ODBC data source.

I initially received an error "Specified driver could not be loaded due to system error 126" when trying to test the connection. I found a tip on a messageboard which instructed me to copy prosql32.dll into c:\windows\system32, which resolved the error.

I received a couple of error messages which were resolved by setting appropriate environment variables:

I then started receiving:
[MERANT][ODBC PROGRESS driver][PROGRESS]A PROGRESS database server cannot handle a non-Progress database connection. (2664)

I followed the instructions in Progress Knowledge Base article 17204. I am running the oibroker on localhost (it is not available on the server), and have the OID/OIB options hostname set appropriately. The Database Options tab points to the remote host. I am able to connect, but I am not able to authenticate. Error:
[MERANT][ODBC PROGRESS driver][PROGRESS]** Disconnected by the server, code 36. (706)[MERANT][ODBC PROGRESS driver][PROGRESS]** Server rejected login. (700)

The sdserv.lg file on the ACE server says:
14:31:07 SRV 4: Login by my_username rejected: secure client required.

Oddly, it is passing the username that I am logged into the PC with, not the username I entered in the login field.

I think this could potentially work if I had _prooibk (the OI broker binary) available on the server, but it's not there.

I'm out of ideas for now. Waiting for a response back from support. Hopefully they will have some ideas.

EDIT: Support confirmed that the server is requiring an SSL connection, and the SQL-89 ODBC driver does not support SSL. On to plan B...

Tuesday, May 22, 2007

Reversing Drawball

I've spent some time lately trying to reverse-engineer the protocol for Granted, the client is in Flash, so in theory I could just decompile it and reverse it that way, but what fun is that?

Here's what I've found so far:

(All communication is in the form of null-terminated strings. The server listens on port 8007.)


Upon connecting, the client sends what seems to be an arbitrary 7-byte alpha (mixed upper and lower) string. One string can be reused a few times before a new one is required. I assume it's based on time somehow. For the time being, I've just been using Wireshark to retrieve the key generated and sent by the client. I need to spend more time on this one. I really need to figure out how this is generated, because it's a huge pain to open up the actual client and get a new key every time.
EDIT: Duh, got it. "View Source," idiot: <param name="FlashVars" value="l=myvalue">

The server responds with a 14-character string consisting of all uppercase letters.

The client responds with a 7-character string of printable ASCII characters. If the incorrect string is sent, the server disconnects. I figured out that the string is generated by taking each character of the first string sent by the client and subtracting the numeric value (0-25) of every other character in the server response. That's not a very clear explanation...will post the Perl function that performs this operation once I clean it up a bit.

EDIT: Here it is.

sub decode {
my @seed = split //, shift;
my @chal = split //, shift;
my $response;

while(@seed) {
# get the numeric (0-25) value of the next character of @chal
my $num = ord(shift @chal) - 65;
# throw away the next character of @chal
shift @chal;
# subtract $num from the next character of @seed, add to response
$response .= chr(ord(shift @seed) - $num);
return $response;


The client asks the server how much ink it has left by sending a lowercase "i". The server responds with the letter "i", and what appears to be a 4-byte integer. The first byte is always 01; I think it's just there to avoid having any nulls in the response, since communications are in the form of null-terminated strings.


To draw, the client sends a packet containing the following data:
  • ASCII "a" (0x61)
  • 0x1 (seems to be constant, not sure what it's for)
  • 0x1 (same)
  • a 1-byte sequence number, must start with 1 and increment with each transmission
  • 0x2 (constant, not sure)
  • color - 4-byte integer, don't know how it's being represented. black is 0x01010101, white is 0x09191908
  • a sequence of (x,y) coordinates where each coordinate is 3 bytes. the minimum number of coordinate pairs is 2, and the minimum line length is 2 pixels. this will draw a line between each coordinate.
I've successfully managed to automate drawing onto the ball, but I'm not going to be able to do anything really useful until I can figure out how the initial seed is generated.

Update: I may have been banned...I can load and navigate the site normally, and I seem to have a normal amount of ink, but any attempt to draw results in an immediate disconnection.