Hi all, need some help here ^^.

Here's the catch: login protection in VB$6 but client - server application.

The protection is simple:
input username (8 char max)
input password (6 char max)

client -> request a 4 digit encryption key to the server

server -> acknowledge and send such as 7321, A723, 32B3, etc... (this 4 key digit is always changes)

client -> use the 4 digit to encrypt the password (and perhaps username), send this data to server

server -> send success message if the password correct, or invalid/user-d password

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

on cases like this, does reversing the encryption scheme and bruteforcing is the only way to do this?? were there any other feasible approach to crack client - server application.

The application is using vb6 and winsock. The message is not encrypted, EXCEPT the username/password for authentication. Using WPE, we can fish the send/receive message.

Any inputs ?? Thanks and regards.

I think you need to explain your target more. There are too many unknowns at the moment. For example:

Is this client/server login purely to validate the license of a local application, and once the license has been validated no more network comms are used? If so, then how about bypassing the entire auth process completely and just patching the appropriate "good boy" flags in the client app.

Is this client/server login needed for ongoing communications with the server on a session basis? If so then your only options are to either find a flaw in the server that lets you bypass authentication checks when establishing a session, or attack the authentication process itself (homebrew encryption is measurably easier to break than industry standard encryption, unless of course the author is a little known encryption hobbyist called Mr B Schneier).

Is this client/server comms used to authenticate the client, but also provides some kind of decryption service for local data or code? The encryption statements above apply, but you can also try dumping when the decryption has been completed to hopefully give you something in plain-data/code.

At the end of the day it does sound like this is a proper client/server app that uses ongoing sessions, on the basis that only the user/pw is encrypted. If so you're going to have to break the encryption or brute force it.

AND, unless you want this Thread to "disappear," DO NOT mention the NAME of the target, now that you are discussing it's CODE. Such things may be discussed in PM but NOT in the Forums. Make sure your actually READ the FAQ on this issue dvntae.

Regards,

Question @dvnte: The server is remote, and you do not have access to its code, right?? I assume so

If you could get your hands on the server side module, you could analyze/reverse the password decryption/validation algo.


Otherwise Server-As-BlackBox approach Ummhh

@Silver:

Patching is useless I think.... before the verification is success, server does not respond to any messages the client sends. So if the verification for un/pwd failed, the server will disconnect socket connection.

It is possible to bypass the bad boy flag, but it has no use and will lead to error in client due to 'client expect more messages from server' (login message, etc) but the server will not send more data to client.

@Silver wrote:
>If so then your only options are to either find a flaw in the server that lets you >bypass authentication checks when establishing a session, or attack the >authentication process itself (homebrew encryption is measurably easier to >break than industry standard encryption, unless of course the author is a little >known encryption hobbyist called Mr B Schneier).

My problem is to find the flaw in server, because the communication process is so simple. Encrypt password, send it one way. Server will return ok/not ok. If not ok the session / socket connection will be close. So there is no decryption routine needed in client.

The truth this is my biggest question of all. I've learnt cracking quite some times ago (when fravia were still updated >_<. But it's limited to client only.

DOES IT REALLY IMPOSSIBLE TO R.E/CRACK THE SERVER CODE OR PLAY WITH IT ?? OR IN ANY WAY TO MAKE THE SERVER RESPOND IN SOME WAY THAT WE WANT.

Client side security has been proof worthless. We can do anything we want by memory editing, patching, packet editing, etc. But if the server is quite secure?? does it mean, there's just no way to fool it?

@JMI
I understand. Target name is useless, because it's nowhere in the web. And nothing is illegal. In fact, by doing this... I'm helping the authorities in my country... LOL

Of course, if someone is interested enough I could give the program to play with it.

@naides
yes, it's server black box. does it mean just impossible...hmm...


Anybody in here quite good at encryption... ^^? I do believe the encryption is weak. But I'm nowhere in encryption field. If someone has an opinion, does it easier:
1. get hundreds sample, with different encryption code (server send this) and different passwords. I can also manipulate the code (that server sends) to be always the same. So u can play with password 'a' then 'b' then 'c'. The client will generate the encrypted result.

or

2. do the elaborate task reading ASM, and find the encyption scheme. this, for me is quite hard... coz the proggie is in vb6 @'@ and been years since i touched softice. I tried OllyDbg now.. but have some problem doing memory scanning like the old softice do: s 0 l ffffffff 'sometin'


Of course, finding encryption scheme will be the last resort. Because if I did found the encryption, it still take times to bruteforce (eventhough it's 6 character only >_<. I'm planning on doing brute force on digits only. (For this I can build a client that communicate with the server to do the bruteforce *IF ONLY* I knew the encryption scheme).


Simpler ways or idea to fool the server is appreaciated ^^'

That one step is workable, at least in theory.

My feeling is that the 4 digit "challenge" the server sends is just a random number, used as a seed for the encryption. All it does is avoid a legit client from having to send the good password as plain text, which could be sniffed.

BUT: the encryption of the password takes place at the client side. You can disassemble it, trace it, and/or scan the file with several crypt signature heuristics that have been described here in this board a few years ago.

Then you could code or rip your own encrytion machine to mount a bruteforce attack

I'm thinking more along the lines of finding a buffer overflow or unchecked input 'sploit. You could root their machine

Many times the programmers didn't think about the case of something other than their client connecting to the server, and so are lax with input checking.

@LLXX:
I'm aware of sending a little bit garbage data to server. The truth I have already successfull to make their machine crash (cannot find server) twice... and it's up to me to do it again. But I have problem on identifying ways to exploit the server so the server is still up and running but allow user authentication. Dun have many experience with bufffer overflow I guess >_<

It's not easy to make a buffer overflow actually do something useful. You have to essentially make many guesses at how their server program handles incoming packets, and then come up with a way of making your own code execute.

There is a famous Phrack article about buffer overflow attacks, and I recommend you read it if you haven't already. There are also a lot more of such information throughout the Internet, you'll have to Search for it.

Once you have figured out how to get arbitrary code executing, inject a packet that will cause the server's executable file to be sent back through the connection to you. Then you can analyze it more and possibly upload a "cracked" version through the same vulnerability (by patching some code), which will do what you intended.

@LLXX:

That's so cool. Makes me shiver while reading your post. But this proggie is in VB6, I believe big chance the server apps also use VB. I've heard somewhere that buffer overflow is classic problem in php, but is it possible to do buffer overflow in VB6 or perhaps C/Delphi program in Win32??

I think I'm going to research some more about this issue. If anyone got good links to the articles is really appreaciated.

thx

I haven't heard much about buffer overflows with PHP (perhaps you were confusing overflows with unchecked input?) but it *is* a classic problem in C, and virtually every other high-level language.

As the theme of this site is, Search for the information you desire, then ask. I'll give you a start with "Phrack 49-14".

Hi all, thx for the reply.

To-date I have analyze the encryption and byfar I think it's quite simple... eventhough not that simple letter to letter substitution or xor (i guess)

As I'm no encryption wizard, I welcome anybody who could give some information/view about the encryption.

I'm trying standard attack to choose certain username and password and change it a little bit. Eventhough, I'm not expert enough to determined which username and password is the easiest to use to crack the encryption.

The 4 digit key used: 6802, (Hex: 36 38 30 32)

The format is: [Start of Message, length=1][username, length=8][separator i guess, length=1][password, length=6][separator, length=1][2 byte 0D 0A as End of Message]

Total: 19 byte

The first byte is always &H30, I believe it's the code the server search in the first place.

For the username, it's quite obvious trying to replace 1 letter resulting *CHANGES* on the replaced letter only. For password is not that obvious.

Here's some sample input and out:

input (username,password)
output: 19 byte in hexadecimal of encrypted username + password

(abcdefgh,123456)
30 50 55 57 55 54 23 25 5B 3F 03 74 06 05 02 02 3C 0D 0A

(abcdefga,123456)
30 50 55 57 55 54 23 25 52 3F 03 74 06 05 02 02 3C 0D 0A

(abcdefga,123451)
30 50 55 57 55 54 23 25 52 3F 03 74 06 05 02 05 3C 0D 0A

(aaaaaaaa,aaaaaa)
30 50 56 55 50 50 24 23 52 3F 53 27 54 50 56 55 3C 0D 0A

(bbbbbbbb,aaaaaa)
30 53 55 56 53 53 27 20 51 3F 53 27 54 50 56 55 3C 0D 0A

(cccccccc,aaaaaa)
30 51 23 21 25 3D 24 53 58 50 51 50 4B 52 2E 2E 20 0D 0A

(aaaaaaaa,111111)
30 50 56 55 50 50 24 23 52 3F 53 27 54 50 56 55 3C 0D 0A

(aaabaaaa,112111)
30 50 56 55 53 50 24 23 52 3F 03 77 07 00 06 05 3C 0D 0A

I believe the encryption is not hard, but *NOT THAT EASY* also.

If any1 needs another sample input/output I can work it on for you also. I'm not very good at encryption topic thus quite hard to determined the easiest input - output to use.

Any inputs about how the encryption works is welcome. If it's possible to post this topic in different sub-forums or another forum? (that specialize in encryption) please let me know.

Thanx.

dvnte:

You can play the black box game of encryption, and is certainly an entertaining puzzle. But the simplest, most direct way is to reverse the client's encryption code, which is the main talent of the people in this board. Unless that crypt code is highly protected.

Interesting puzzle, like naides says! Taking a quick look in a nicely formatted manner:



As you said the first byte is always 0x30. Looking at the sequence it seems that the delineating byte between username and password is always 0x3F, except in sequence 6. Based on what you've shown I'd discard sequence 6 as an anomaly or mistype on your part. 0x3F is also the code for "?", this being a network app and "?" being the delineator for parameters to a server side script that might be significant.

(from here on the sequence numbers I refer to are as posted above in the code blocks, not as posted by the OP).

Looking at the first block of bytes (username?) the interesting thing is that same characters in same positions generate the same resulting byte. Eg: sequences 1 to 4 have "a" as the first character and all provide 0x50 as the output byte. Sequences 4 and 6 have "a" as the second character and produce a different byte 0x56 to sequences 1 to 4, but the same byte to each other.

Looking at the first and third sequence we can see both "b" and "d" produce the same output byte, 0x55, but are in different positions in the input string. In sequence 5, "b" is the fourth character and produces 0x53 whereas in sequence 1, "d" is the fourth character and produces 0x55.

So this tells us:

1. This is not a public/commercial/well known encryption scheme
2. This is not a hashing function
3. The encryption is almost certainly to be a single byte calculation based on the position of the character in the string, otherwise there would be no way to distinguish between the "b" and "d" as above.

You'll need more data to test this out, but I'd guess right now that you'll find a pattern if you test every character from a-z while keeping the remainder constant. For example:



and continue this for each character. It should be easy to generate a lookup table based on input character and position.

The password side needs more data to review. Discarding the initial 0x3F as above, and also discarding the 0x0D and 0x0A (hex codes for ASCII carriage return and line feed, so a reasonable assumption to ignore), and discarding the 0x3C as it's consistent for all entries we have an interesting set of data left.

Most curious is why the sequence "aaaaaa" produces the same output bytes as "111111". Also the fact that the password sequence "aaaaaa" produces the same output bytes for username sequences "aaaaaaaa" and "bbbbbbbb" probably indicates that the username and password data is encoded separately and does not affect each other.

Looks like one of those math puzzles you used to get at school, "find the next number in the sequence"

Of course Mike might just pop in and shoot all this down in flames as I'm hardly a cryptographic expert.

Why bother bruteforcing the server for passwords? It sounds like you can sniff the network for login sessions. Since the server uses the 4-byte seed or "nonce", you can't just use a simple replay attack. But you still have plenty of client-side options that can be done offline:

Reverse the client-side encryption by analyzing the client code
Reverse the client-side encryption by analyzing it's input and output
Brute force a password offline by feeding the sniffed seed from the server to the client, and try every possible password until the client spits out the sniffed, encrypted password.

The last two options would require emulating the server's response to a client login request, but it sounds like you already know how that conversation goes. I'd exhaust those options before I tried an on-line bruteforcing via the server. It's a lot less obvious to anyone who might be watching, for you to passively sniff the passwords you need, and do your bruteforcing offline.

Howdy,

Correct me if I am wrong.....

dvntae needs to gain access to the server.
That needs to be done with a vb6 app ?


OR, the server is running a vb login program ?


So this is a windows server I will assume.

Are you just working on this one vb login prog or
are you just trying to gain access to the server any way possible ?

Woodmann

This is a very simple XOR-based encryption scheme on the username. By XOR'ing the ciphertext with the plaintext, the keytext is easily recovered. The keystream for the above data is 31 37 34 31 31 45 42 33, which in ASCII is "17411EB3", suspiciously similar to a hex dord although that may be a coincidence.
Now that I think about it, the server application might be just a script - and one without any input checking, it seems. Fravia explains a few script exploits, which can be found here:

http://www.woodmann.com/fravia/ideale3.htm
http://www.woodmann.com/fravia/ideale4.htm

I was thinking of nmap or some other such utility.

Woodmann

Though very subtle, this is a HACKER's job, not a CRACKER's job.

What you are asking is akin to this: I have xyz.com porno site. I gotta login. Help me man!

You were correct in your first post. You have to bruteforce. But since the server is providing you with an arbitary 4 digit code to encrypt the password, it may be that much more difficult. Having password encrypted by a 4 digit code is very TRIVAL to break. NOT SO when the verification is being done at the server, however!

The logic is very simple. You cannot crack what is not there. And since the verification routine is in the server, whose code (disassembly) you do not have access to, its going to be nigh impossible.

The only other way is to get into the server using exploits. But like I said, that's a HACKER's job. Of course, in the recent years the lines between HACKERS and CRACKERS have blurred somewhat, and yet you may wish to ask this question on a hacker board. They have better solutions. Not many willing to share though

Applications that connect to the internet for verification, like say, CUTEFTP can be cracked because they connect to the internet JUST for verification. Not for functioning. However, your client application NEEDS the server to function (some data, perhaps) or is designed in such a way that the logic is in the server (then code too).

So IDA and SOFTICE and other softs are NOT going to be of use here. However, you might try a more powerful weapon. Social Re-engineering. Work at it and you will never need IDA/ICE. Ever.

Of course, I am assuming you do not have any access to the server, physical or remote or otherwise.

Have Phun