KuiperBeltObject

Brute force on a standalone exe

21 posts in this topic

Hi, I am a field tech for a small computer repair shop.

A customer of ours has a database prog written in-house apparently.

The person who wrote it has passed on and they do not have the password to the app.

Everything runs local.

It presents a dialog box for UN/PASS , I looked in one of the files in the program directory and was able to glean the usernames.

I want to run a brute force / dictionary attack on it , but am hitting a wall.

All of the crackers I have found > Ophcrack , Cain , john the ripper etc. appear to work on hashes only.

I need a way to put passwords in the dialog, or even better throw them at the exe without having to invoke the dialog box.

I did something similar for a pass protected wordperfect doc years ago using a program called claymore.

http://www.hfactorx.org/en/archives/applications/cracking/

Wow , that really dates me. Date on the program is 1996. This one lets you setup keys like File > open > tab so you can navigate through fields in a dialog box.

At least thats the way I remember it, though I cant seem to get it to work.

I even tried my hand at reverse eng it with ollydbg but I am out of my depth.

Any suggestion greatly appreciated.

0

Share this post


Link to post
Share on other sites

Any clue as to how it stores and checks the passwords? If it's hardcoded into the executable or supporting files, you might get lucky simply by running the unix command "strings" against them to print out any ascii strings in the executable.

It's hard to speculate how one would go about breaking this, but if it's an in-house developed app, chances are it shouldn't be too hard to reverse engineer. If you don't manage to figure something out, nobody else has any ideas, and you get into a tight spot, feel free to contact me privately.

Edited by McGrewSecurity
0

Share this post


Link to post
Share on other sites

Andrewg over at felinemenace.org wrote a great paper on that type of stuff. It's called Binary Protection Schemes. Although it deals with ELF files (binaries in UNIX/Linux), the same concept applies for PE-COFF binaries (exe's in windows).

0

Share this post


Link to post
Share on other sites

I'd suggest you compress the program and upload it somewhere, so people can try to break it. Ollydbg alone might not be sufficient, I suggest you also try W32Dasm.

Edited by Aghaster
0

Share this post


Link to post
Share on other sites
I'd suggest you compress the program and upload it somewhere, so people can try to break it. Ollydbg alone might not be sufficient, I suggest you also try W32Dasm.

I've never used W32Dasm. What does it do that Ollydbg can't?

(Also, it would probably be appropriate to ask the client's permission before distributing the program, and might not be a good idea considering the sort of information about a company an in-house app can contain)

0

Share this post


Link to post
Share on other sites
I'd suggest you compress the program and upload it somewhere, so people can try to break it. Ollydbg alone might not be sufficient, I suggest you also try W32Dasm.

I've never used W32Dasm. What does it do that Ollydbg can't?

(Also, it would probably be appropriate to ask the client's permission before distributing the program, and might not be a good idea considering the sort of information about a company an in-house app can contain)

W32Dasm is a dissassembler, while Ollydbg is a debugger. With Ollydbg, you can run the program and place breakpoints in it at relevant parts of the program (in the case, where your password is asked). From the breakpoint, you can trace (execute the program instruction by instruction, while seeing the state of the system registers, and some variables). With W32Dasm, you can dissassemble the program, search through it, check out what it does, without running it at the same time. Both programs will give you the offset of the instructions you are looking at. So, for example, you could locate the relevant part of your program using Ollydbg, and then dissamble your program with W32Dasm and try to figure out what you could modify in the program in order to get what you want (e.g. change a jmp instruction). In order to modify the program, you would need a hex editor (XVI32 is a nice and free one) in order to manually change the bytes at a particular offset (you will need a table of equivalents for your assembly instructions). That's called cracking. But you could also find out how and where the program looks for the password in order to verify its authenticity.

Ask the client's permission first, it would certainly help if people on binrev could try to break it. Just don't include the database along with it if the program can run without it.

Edited by Aghaster
0

Share this post


Link to post
Share on other sites
W32Dasm is a dissassembler, while Ollydbg is a debugger. With Ollydbg, you can run the program and place breakpoints in it at relevant parts of the program (in the case, where your password is asked). From the breakpoint, you can trace (execute the program instruction by instruction, while seeing the state of the system registers, and some variables). With W32Dasm, you can dissassemble the program, search through it, check out what it does, without running it at the same time. Both programs will give you the offset of the instructions you are looking at. So, for example, you could locate the relevant part of your program using Ollydbg, and then dissamble your program with W32Dasm and try to figure out what you could modify in the program in order to get what you want (e.g. change a jmp instruction). In order to modify the program, you would need a hex editor (XVI32 is a nice and free one) in order to manually change the bytes at a particular offset (you will need a table of equivalents for your assembly instructions). That's called cracking. But you could also find out how and where the program looks for the password in order to verify its authenticity.

You can load up things in Ollydbg without running them, and it does an excellent job of disassembly. One of the nice features of Ollydbg that you might not be aware of is that you can make the changes you mention straight in Ollydbg, in assembly (so you don't have to do it manually with a hex editor). It even has an option of writing the changes back out to disk. That ought to save you a lot of the jumping around between programs you seem to be doing.

0

Share this post


Link to post
Share on other sites
W32Dasm is a dissassembler, while Ollydbg is a debugger. With Ollydbg, you can run the program and place breakpoints in it at relevant parts of the program (in the case, where your password is asked). From the breakpoint, you can trace (execute the program instruction by instruction, while seeing the state of the system registers, and some variables). With W32Dasm, you can dissassemble the program, search through it, check out what it does, without running it at the same time. Both programs will give you the offset of the instructions you are looking at. So, for example, you could locate the relevant part of your program using Ollydbg, and then dissamble your program with W32Dasm and try to figure out what you could modify in the program in order to get what you want (e.g. change a jmp instruction). In order to modify the program, you would need a hex editor (XVI32 is a nice and free one) in order to manually change the bytes at a particular offset (you will need a table of equivalents for your assembly instructions). That's called cracking. But you could also find out how and where the program looks for the password in order to verify its authenticity.

You can load up things in Ollydbg without running them, and it does an excellent job of disassembly. One of the nice features of Ollydbg that you might not be aware of is that you can make the changes you mention straight in Ollydbg, in assembly (so you don't have to do it manually with a hex editor). It even has an option of writing the changes back out to disk. That ought to save you a lot of the jumping around between programs you seem to be doing.

hum... interesting. I haven't been really far in cracking, that's why I haven't seen these features.

0

Share this post


Link to post
Share on other sites
W32Dasm is a dissassembler, while Ollydbg is a debugger. With Ollydbg, you can run the program and place breakpoints in it at relevant parts of the program (in the case, where your password is asked). From the breakpoint, you can trace (execute the program instruction by instruction, while seeing the state of the system registers, and some variables). With W32Dasm, you can dissassemble the program, search through it, check out what it does, without running it at the same time. Both programs will give you the offset of the instructions you are looking at. So, for example, you could locate the relevant part of your program using Ollydbg, and then dissamble your program with W32Dasm and try to figure out what you could modify in the program in order to get what you want (e.g. change a jmp instruction). In order to modify the program, you would need a hex editor (XVI32 is a nice and free one) in order to manually change the bytes at a particular offset (you will need a table of equivalents for your assembly instructions). That's called cracking. But you could also find out how and where the program looks for the password in order to verify its authenticity.

You can load up things in Ollydbg without running them, and it does an excellent job of disassembly. One of the nice features of Ollydbg that you might not be aware of is that you can make the changes you mention straight in Ollydbg, in assembly (so you don't have to do it manually with a hex editor). It even has an option of writing the changes back out to disk. That ought to save you a lot of the jumping around between programs you seem to be doing.

hum... interesting. I haven't been really far in cracking, that's why I haven't seen these features.

If it's hardcoded into the .EXE and the person left it unencrypted than a monkey with a good (in other words, professional quality) hex editor could find it. "Hacker Disassembly Uncovered" covers this is some degree of detail.

0

Share this post


Link to post
Share on other sites

Thanks for the replys.

I've done a bit more digging.

There is an agency.tps and a password.tps in a folder called data.

The agency.tps is where I got the usernames from. (thought of that one deadc0de, wish it were so simple)

If you delete password.tps , it generates a new one on execute.

if you delete agency , it cant find the username and just whines at you.

Turns out .tps files are Clarion for Windows Topspeed Data File.

AH , now maybe were getting somewhere?

Well , maybe not. Found this post:

From http://en.allexperts.com/q/Clarion-2368/Pa...ected-files.htm

Answer

There is only one way to unlock password protected tps files and that is to know the password. The password can be easily be found if you have the dictionary where the files were originally defined. This would be a .DCT file.

If you have that there are various options open to you. If you have the Clarion development environment you can use it to unlock the files.

Otherwise, you will need someone who has that environment. That person can then determine the file passwords.

Without the dictionary you must obtain service from the person having the dictionary.

Quick search for *.dct (oh please oh please) 0 files found , ah fuck.

Hey , how about a clarion cracker?

Only one I can find is this one:

http://www.password-crackers.com/en/catego...program_64.html

Which was written in 1996. It doesnt recognize the files. Damn.

I've tried windasm , ida pro , ollydbg and immunity all to the same effect. My lack of debugging skills is going to prevent solving the problem this way , though I am going to keep trying just because it's fun,

I've cracked a couple of simple ones from crackmes.de , but this is a much tougher nut.

Wish I could post the files , but they do contain a buttload of personal data.

I'm d/l a copy of clarion 6 just to see if it can do anything.

Other than that I think I'll try to throw some crap together in VB that will let me throw passwords at the dialog box.

Thanks for your responses.

PS I'm uploading the password.tps file as that only contains a few first names and nothing else identifiable just in case anyone wants to see if they can decode it.

passwd.zip

0

Share this post


Link to post
Share on other sites

I've taken a look at passwd.tps with an hex editor. Here is what I can see:

There seem to be a header filled with a lot of 0x00 and 0x04. I have no idea what it is used for.

Login names then appear, all ending with a space (0x20). These login names are:

antwyne

betty

dsynch

holly

Then, these four login names reappear, all ending with a space (0x20), BUT this time there seem to be some kind of a key or at least something that looks meaningful following them.

It looks like this: ANTWYNE - SPACE(0x20) - KEY (0x0D, 0x08, 0x36, 0x25, 0x2B, 0x7A, 0x59, 0x24, 0x24) - SPACE (0x20) - NUMBER? (0x0D, 0x0E) - PA (litterally) - Unknown stuff that also looks relevant

Also, at the end of the file seem to appear two sequences of numbers from 0x00 to 0xFF. Are they substitution tables? I don't know, because they appear to be identical. Weird.

I suspect the "keys" to be used in some kind of XOR cipher. Maybe we should XOR the key against the part following PA in order to get the deciphered password?

0

Share this post


Link to post
Share on other sites
Thanks for the replys.

I've done a bit more digging.

There is an agency.tps and a password.tps in a folder called data.

The agency.tps is where I got the usernames from. (thought of that one deadc0de, wish it were so simple)

If you delete password.tps , it generates a new one on execute.

if you delete agency , it cant find the username and just whines at you.

Turns out .tps files are Clarion for Windows Topspeed Data File.

AH , now maybe were getting somewhere?

Well , maybe not. Found this post:

From http://en.allexperts.com/q/Clarion-2368/Pa...ected-files.htm

Answer

There is only one way to unlock password protected tps files and that is to know the password. The password can be easily be found if you have the dictionary where the files were originally defined. This would be a .DCT file.

If you have that there are various options open to you. If you have the Clarion development environment you can use it to unlock the files.

Otherwise, you will need someone who has that environment. That person can then determine the file passwords.

Without the dictionary you must obtain service from the person having the dictionary.

Quick search for *.dct (oh please oh please) 0 files found , ah fuck.

Hey , how about a clarion cracker?

Only one I can find is this one:

http://www.password-crackers.com/en/catego...program_64.html

Which was written in 1996. It doesnt recognize the files. Damn.

I've tried windasm , ida pro , ollydbg and immunity all to the same effect. My lack of debugging skills is going to prevent solving the problem this way , though I am going to keep trying just because it's fun,

I've cracked a couple of simple ones from crackmes.de , but this is a much tougher nut.

Wish I could post the files , but they do contain a buttload of personal data.

I'm d/l a copy of clarion 6 just to see if it can do anything.

Other than that I think I'll try to throw some crap together in VB that will let me throw passwords at the dialog box.

Thanks for your responses.

PS I'm uploading the password.tps file as that only contains a few first names and nothing else identifiable just in case anyone wants to see if they can decode it.

The book Reversing: Secrets of Reverse Engineering covers file type reversing fairly comprehensively. As for cross application development I would not recommend VB. I would recommend C++. I have yet to hear of a DLL injection technique (which is the primary way to get one application to "talk" to another) for VB. If Aghaster is telling the truth just download clarion and make a simple password file (I.E. "1234" or "abcd") and try to identify it in the file. Once you know where it is stored you can move on to learning how it's encrypted (if any encryption even exists) and then move on to brute forcing. Simple steps you should follow before just jumping head first into a unknown file format.

Seeing that the file format isn't recognized by an older version of the program (I'll bet more than one program use .TPS), that probably means there is a header. Try to identify that first. Decode the header and then decode the rest. Also, remember that brute forcing isn't a "fix all" to everything you do. Basically you're going to be running millions of different passcodes through it and the chances of you finding one are almost nil. Just keep that in mind and ask yourself if it's really worth it.

Edited by deadc0de
0

Share this post


Link to post
Share on other sites

At the risk of sounding simple, did you try some educated guessing against those usernames aghaster came up with? I can't imagine an old in-house database had any password complexity requirement. I'd be willing to bet your odds are probably as good if not better doing that versus a brute force dictionary attack.

Don't suppose Betty or Holly are still with the company? :P

Good luck with it.

0

Share this post


Link to post
Share on other sites
At the risk of sounding simple, did you try some educated guessing against those usernames aghaster came up with? I can't imagine an old in-house database had any password complexity requirement. I'd be willing to bet your odds are probably as good if not better doing that versus a brute force dictionary attack.

Don't suppose Betty or Holly are still with the company? :P

Good luck with it.

yeah... there's something weird with this story. Only the programmer has a login name and password? Nobody else? Maybe we could trace Betty and Holly and ask them for their password :P

0

Share this post


Link to post
Share on other sites
At the risk of sounding simple, did you try some educated guessing against those usernames aghaster came up with? I can't imagine an old in-house database had any password complexity requirement. I'd be willing to bet your odds are probably as good if not better doing that versus a brute force dictionary attack.

Don't suppose Betty or Holly are still with the company? :P

Good luck with it.

yeah... there's something weird with this story. Only the programmer has a login name and password? Nobody else? Maybe we could trace Betty and Holly and ask them for their password :P

Forget that, lets take a page from the Wargames playbook... make a dossier on the dead guy. Find out the programmers home address, phone number, date of birth, and don't forget about his dead son Joshua :o

P.S.

I'm only half kidding... it might work and a dictionary attack can't replicate that.

0

Share this post


Link to post
Share on other sites

Agaster:

Yeah I saw those too, but it is a commercial app that made this , which isnt saying much, but it could be using 3DES or blowfish or anything , I have no way of knowing where to start.

which gives me 3 options.

1 Reverse eng it so it doesnt ask for a pw or will accept what you give it .

2 Find out what it uses to validate pw and subvert it .

The entire prog and db = less than 7 megs, so the pw, or more likely , its hash are stored somewhere. If I could find something like that , I could run cain or ophcrack against it easily.

Thats my whole problem , I have nowhere to point my weapons.

Which brings me to my 3rd option.

3 Guess (dict attack or brute)

In order to guess the pw automatically , I will either have to go through the dialog box or find a way to send it to the exe without invoking the gui. Like when you go to an ftp site >> ftp://ftp.whatever.com:username@password.

Not knowing how to do this , I am left with the gui.

So how to manipulate the dialog to my ends?

1 Lauch exe

2 Type UN

3 tab to pw field

4 enter random or dic word

5 hit OK

6 test for success or failure (hwnd handle)

6a if success, end , else

6b hit retry

7 increment brute or dic

8 goto 4

Or something like that.

So i can do it just with hwnd and sendkeys if I have to , but was hoping for a more elagant solution.

diverter:

The PW itself is problably pretty simple.

This is a typical business enviroment where they do not take security seriously.

Strong PW are not enforced.

I scoured the PC (protected storage ,cached , IE , looked for post it notes, no good)

I would be suprised if it is not in the dictionary.

Or , if not , is probably less than 8 or 10 chars, so is within the capabilities of my hardware to do a brute force in a resonable amount of time.

I have tried all the basics by hand with all the UN I found.

Contacted the 1 remaining employee in the tps file and their PW does not work.

As for the coder himself.

I assume he is the dsynch UN in dct file, there is no info on him at all, and , unless I hire Magnum P.I. there will be none forthcoming. Nothing from his ex-coworkers, not a very tight crew.

Of course I challenged it to a game of Global Thermonuclear Warfare , but it declined. (Lucky for us)

Aghaster:

More than likely , he was using the Clarion dev tools to make the app, he didnt code it from hand. In which case I need the .dct files to recover the PW. Which are problably on his old PC which was long ago re-imaged and give to someone else.

Havent screwed with VB for a while , this will give me a good excuse.

Thanks for your input.

0

Share this post


Link to post
Share on other sites

Could you use an old school trick to brute force this??

Could you pipe the output of the brute force program to the input of the target? Set up some kind of script to rerun the target after it bombs out?

I admit I like Aghasters route though...

Have you tinkered with Xoring the 'password file' with whatever it takes to make it printable characters? and try those first? Most people don't include control codes in their passwords... if it's a simple xor you should have it pretty quick.. (relatively speaking) if that 'table' is used you may have to index via that; and that'll take a while..

0

Share this post


Link to post
Share on other sites

Hmmm....

Found this site: http://www.tek-tips.com/viewthread.cfm?qid=600590&page=9

They mention a program called TOPSCAN for viewing .tps files, Did a google search and found download link. Opened your passwd.tps file in it and it nicely arranged the usernames and passwords in columnes for your viewing :) The only problem is that the passwords look strange... I highly doubt that they are the actual passwords... TOPSCAN might work better for you since you have all the original files, plus other .tps files that might have the passwords on them.

On the site above they mention another program called CSCN.exe for opening clarion .dat files. However it seems to be part of an old version of Clarion that I can't find on the web anywhere... They mention another program called XSCAN written by a Vadim Berman however all I can find on that is a network scanner called xScan that seems to be flagged as a computer virus...

I'm uploading TOPSCAN for your convenience...

If you want a link to where I found it, here it is: http://bluesoftware.tripod.com/product_mailinglist.html

if you use the link, you may need to do a word search for TOPSCAN. Its a large webpage with tons of text. :wacko:

I am also attaching a screenshot of TOPSCAN at work, for those who just want to view my results. :D

Hope this helps,

SC(+)PE

post-12743-1193533327_thumb.jpg

TopScan.zip

0

Share this post


Link to post
Share on other sites

Cool find SC(+)PE, thanks. :D

There are other tps files it also opens nicely , but no pwd info.

User type PA = prog admin??

I tried all the UN/PW combos and they all failed.

I suspect 6%+zY$$ is a hash of some sort.

I tried it on Cain , but the hash(if it is a hash) in hex is 36252b7a592424=7 bytes which doesnt conform to any hash length I can find.

0

Share this post


Link to post
Share on other sites

I had the same thoughts concerning the passwords as hashes... Using the same technique that you used to get that hash (if it is a hash) you get 066045053172131044044 if you switch your hex editor to Octal. However that would still be 7 bits long and most likely not the hash you are looking for. Another interesting thing about the passwords that TOPSCAN displays is that the passwords are different lengths... dsynch = 6%+zY$$ =7 characters hence the 7 bit hashes we are coming up with. Antwyne = V,/p5, = 6 characters, Holly = 2v+j = 4 characters, Betty = ,)(d( = 5 characters. I think that those represent the password length of the actual passwords which might help you to brute force or guess them...

Also when you opened the other .tps files did you see anymore text similar to yet different from the passwords? Also if you open the database in a text or hex editor does it look encrypted? (Similar to the way that the passwords look) If so you could copy all the text to a giant .txt file and open it in an Analyzer that you could run on the passwords to try to decrypt or at least determine what kind of encryption they use. But it need lots of text...

Then again its another shot in the dark...

Here is a link to the Analyzer: http://www.cryptool.com/download.en.html

And some quick info about it: http://www.cryptool.com/cryptool2.en.html

Check it out and see if it has any luck on those passwords.

Thats all I have right now... I'm gonna try incrementing and decrementing characters in the passwords up and down on the ANSI character chart to see if it is just a weak attempt by the programmer to conceal the passwords in the .tps files and we'll see if the passwords turn into something understandable. :lol:

Laterz,

SC(+)PE

Edited by SC(+)PE
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now