Hi all,
We are having a problem, and I hope some of you may give me pointers on how to solve this :-)

A client of us, has an EXE (VB5) provided by us. This exe uses ODBC to connect to our SQL Servers.
Basically what they did is to gain access to our SQL servers, decrypt some stored procedures, and access directly to our sql servers to perform business operations. They are not doing 'bad' things, but they may bypass business validations that are being performed by our front end app. And basically, we do not want other people to access our servers.

Our application uses a generic user to connect to the sql server (with very restrictive permissions). Then, the fully authorised username and pass is retrieved from the db in an encrypted form and then the app reconnects with this user. This user, however, is not the dbo, and it cannot create stored procedures, access most of the tables, it may only use the stored procedures, which are encrypted.

We understand they used a sniffer to detect the fully operational user/pass used to connect to the SQL Servers. We used CAIN to reproduce this. The infrastructure guys installed a certificate in the SQL Server, so the connection is now encrypted. After this, CAIN can't tell us the user and pass any longer.

Now, I took cards into the matter, and I decided to attack our own systems to detect the flaws. First I used a debugger (WKTVBDE - found at http://exetools.com/debuggers.htm) and I could see what the exe was doing, and even though the certificate was installed and the connection was now encrypted, I could see the connection string while it was built. To solve this, I thought of some things. First, to compile the exe without Pseudo Code, directly to native. Second, I think I can encrypt the exe (though I didn't do this in the past, I think it shouldn't be that hard - any hints are welcomed). And third to store the strings encrypted in memory; this I don't know yet how to accomplish. I think that though all of these solutions may only delay their attempts to crack our system, these things must be done.

What I couldn't figure out so far is how to decrypt the stored procedures. We think they may have had access to some SQL Server with a dbo user. However, I want to be absolutely certain that without that kind of access they can not decrypt the stored procedures. I found a bunch of things on this, and here (http://www.sql-shield.com/decrypt-stored-procedure.html) I found a way to decrypt them, but I need sa access or 'create procedure' permissions.

Well... I think that's all. Btw, the SQL Server version is 2000 and most of our servers have SP4 installed.

Any and all the help is certainly welcomed.

Thanks guys!!