Software Cracker Challenge #3

This time, the challenge is focused on exposing security flaws in my DLL protection system. The challenge:

In the zip file you will find a VB project with a module and a form and you will also find a compiled DLL. The VB project first verifies if the DLL file has not been tampered with. If the VB project is convinced it is not, it will retrieve a string from the DLL and will display it in a message box. The challenge is to try to change what appears in the message box without changing any code in the VB project. Indirectly what I mean to say is that you have to try to edit the string from the DLL thus changing the message box's text

This challenge is not very easy nor hard. We are still perfecting are DLL protection method but I want to see what all the crackers over here think. There is no conflict issue with Win 9x. I know someone will eventually crack it. As soon as you do that I will put up Challenge #4

After you extract the files, be sure you register the DLL by double clicking on Register Me.bat.

O yeah... forgot to say that the only rule is not to change the VB project's source code/references.... but... u could try all sorts of things like replacing the DLL with a fake one.... using a hex editor... debugging it... etc... just dont change anything within the VB project! And yeah... my suggestion is you analyze the VB checking routines within it and try faking the DLL by creating your own. Then your own DLL could pass a different string to the VB project. In my opinion, thats the easiest

Looks like fun :)

I changed the text in the message box. But not in the way you might want it or professional crackers would have done.

I noticed that the IsCorrupt() had a line
name = App.Path & "\LockXDll.dll"
which was obviously static.

So I opened a hex editor edited the LockXDll.dll file with my own message and saved it in Windows\System directory.

Later when I executed the project... it found that the file in the current path was valid, but the one in the Windows System directory was the one being used :)

I am not sure about this, but I think Windows checks the Windows and Windows System directory before checking the current path for the required dll files.

Hence giving a static path would suck.

In the attachment, there is an additional file: 'LockXDll2.dll'
copy that file to the Windows system directory and then open the project and execute it. You will get my message.

I just hope this is the loop hole that you might have feared

its exactly the same 007shahid

oh no i did it wrong, u have to rename LockXDLL2 to LOCKXDLL in the system folder.

wicked - 007shahid cracked it, well done

or you could just change the reference file.

yea but ur not allowed to change the vb project in any way

ArjanNutz, as I said, you can't change the VB project in anyway. The aim of this is to expose any vulnerabilities in my DLL protection system.

nope, I didn't change any vb source codes. And I didn't see Yash's 2nd post either (Clue). Did I do it correctly ?

Just a passing thought. Does windows look for dll files in the System directory before the current one. Because if it does that, then I don't even have to worry about setting references in the compiled exe.

Anyway, even if I have not cracked it, here is a probable bug that I found.
I compiled the project into an exe file. I put the exe file and dll file in...

1. Any root drive. [Path="C:\", "D:\", etc...] where it gives me an error

2. A sub folder where it does not give error. ["C:\Temp", "D:\LockX", etc]

I have attached 2 pictures to show it.

Yeah.. strange... I never thought it would look into the System directory first... anyway... all the ActiveX Controls protected by my system will be in the System directory so it wouldn't be a problem. Well... you did highlight a small problem but no one has cracked it yet.

ok, something strange. i pt 007shahid's version of the lockXDLL.dll in the system folder. Then you told us that that wasnt the way so i deleted it!, but i still get 007shahid text appear

why???

... and what about the errors I pointed out in my previous reply.

And about the point about fooling the program with multiple dlls, you can use this tip from VB World to find duplicate files.

<edit> i didnt say anything here... move on

as i said... we are still working on it.... its not perfect... guess this was a fail... i'll be putting up challenge #4 shortly... anyway... no one still was able to edit the DLL... u just found ways around it... which we will eventually fix...

Can I

1. Use a memory patcher (will patch the dll at runtime)

2. Compile the project to a exe and then patch it ?

OK... this challenge is officially closed... please wait for 12 hours and I will put challenge #4... we fixed all the problems

When do I get to beta test your stuff? i sent you my request a while ago

you may want to try using checksums. it's freakishly hard getting around those, and even if you do get around it, what you'll be able to change it into won't be what you want anyway.

Look at what I found on PSC!

http://www.pscode.com/vb/scripts/Sho...29871&lngWId=1

Quote:

---

I have decided to write a small copy protection article, mainly to summarise the previous posts and to help me get my mind around the idea, which I will present towards the end of this article.

First lets look at some of the statements made previously,

I will take LockX first,

Statements made were -
* The system is bullet proof

This is one of the comments made for the first version, I thought yes great finally something on the protection side. Before I got the chance to have a look at the code, version 2 came out and its 200 times more secure.

One of the Statements made was -
* LockX 2.0 Software Protection is the ultimate security system

I finally got some time to check the code, it took me all of 10 minutes to figure out a way of bypassing "the most secure ActiveX control ever " yep.

And then there was version 3 with the comment

* LockX 3.0 Software Protection is the ultimate security system (100 times more secure then Version 2.0).

I spent about 5 minutes on version 3 and it was bypassed, my be the authors comment should have read 100 less secure ? .

Version 3.1 was not any better, so we are now at version 3.2. Ok the OCX has been removed, but is it more secure, I don't ' believe so.

Attached to this article is a patch file, which will patch a particular LockX protected application. In this case the one I compiled, with this version the author can claim that it is 1% more secure than version 3.1 but that is all.

The security of any protection product that relies on the following code is cr.p!!!

If .AppRegistered Then
Do something
Else
End
End if


If the author is as he claims a cracker then I would say that he is not very good if he cannot even crack his own software. Any cracker will see the above code and bypass it in a matter of minutes.

That brings me to the second Solution for a protection scheme "Copy Protection Scheme" this author has at least thought about protecting software, the supplied code still has the above structure and therefore will not work. But the implementation of the protection scheme is sufficiently different to make me believe that he maybe on the right track.

I have been thinking along similar lines for the last couple of years, but never got around some problems. I think Guy Gervais my have just provided a possible solution.

A possible Solution
Guy's Solution
In Pseudo Code we have the following from Guy's code,
1 Load security Script into the Script Control
2 Decrypt the security script
3 Run the security script
4
5 If Me.Caption = TITLE Then
6 "Sorry, key is invalid"
7 End
8 End If
9 Do Something

The above is Guy's code, and that got me thinking if the security code can be placed into a separate thread to the main program thread, my extension to the above idea is as follows,

Main Program Thread
1 Load security Script into the Script Control
2 Decrypt the security script
3 Run the security script
4
5 If .IsDemoMode Then
6 "You are In Demo Mode" // no need to end even if the app has been patched
7 elseif .IsElapsed then
8 Show Registration Screen
9 End
10 End If

{the above block takes care of honest users, and at this stage we still don't care if we have been cracked so just keep loading the program}

11 Do Something

{now anywhere in the program we do the following, form load or form activate, etc.)

12 Start Security Thread // Sprinkled through out the program

13 Do Something Else


Security Thread
1 Load security Script into the Script Control
2 Decrypt the security script
3 Run the security script
4 Sleep for a random time A minutes/Hours
5 If .IsElapsed or .IsPatched or isTimeSetBack then

{this block will know if the App has been patched,Time set back, or has just elapsed.}

6 End Main Program Thread
7 End Random Timer Thread
8 End Security Thread
9 {don't show that we are not registered just stop the program}

10 End If
12 End Security Thread
After all of this Blurb, I come back to the same conclusion we cannot protect a program from being copied, all we can do is make it hard for the attacker.
In the above example if the attacker finds all of the 'Start Security Thread' references and NOP's them out then the protection is bypassed.
I have just gone through Guy's code again and it suffers from the same problems as I have had with the above idea. All the attacker needs to do is to NOP out the

'script.ExecuteStatement sCode' line and ' the program will never get checked.
'
The only other change that needs to be made is,

If Me.Caption = TITLE Then -- changed to -- If Me.Caption <> TITLE Then

And the program is useable, no need to worry about registration files, or key.

I have included a compiled patch file to prove the point. With a bit of assembler knowledge the above is not difficult to do.

I will still upload this, someone may find it useful and have some more ideas. I hope that this article spurs on some more discussion in this area.


Tombr...

---

Just has a thought....

Isn't only allowing hacking of the OCX a bit pointless? If you want to crack the protection, you'd hack either the exe or the OCX. THe security is only as good as it's weakest point (so in this case you'd hack the exe sothat the IsCorrupt always returned false, and the hash comparison function always returned true. The OCX might be safe as houses, but if the way you call it is dodgy, then its effectively useless.

Next time Yash_Kumar, you probably need to let us hack BOTH files - If I want to break the security, I'll hack the exe, not the OCX (cos it's a lot easier)

- gaffa

I just want to add an opinion. As discussed by many, No software is 100% secure. The required data is some where in the memory. And if no one else can Microsoft can. The only probable way to prevent Cracking is from Microsoft's side.
There are attributes like read only, rw, w, etc... Keeping this in mind, If a compiler can compile a program in such a way that...
1. Only Windows should be able to read it.
2. It should be protected by Windows, like it protects it's NT SAM file.
ie... no one can open the executable file if the programmer wishes, by adding a toggle some where in the file.
Yes the sam file can be retrieved in DOS, but the EXEs won't be able to run in DOS. If it is a good idea, the above method should have been implemented earlier and now it will surely take a lot of time and resources. Maybe implement this in the 64bit applications of the future.

In my opinion, people who use crack softwares will probably never buy the software. Even if a crack is available or not, they for some reason will never buy legal softwares. Hence shareware companies still give out shareware softwares. If the consumer is quality concious, he would pay for it. In return he gets good consumer services like product upgrade, 24 hours online help, etc... (Atleast for good companies). Mostly people do not buy due to money reasons. In my country (India), though the game prices have fallen (Mostly around Rs 500 [$ 10 US]), softwares are still expensive. Hence mostly people get a free copy from their Hardware engineer. Hence I feel companies should supply a few copies of older version at a cheaper rate.
Lets take MS Office for example. How many people actually use all the extra features that Office XP gives over Office 97 & 2000. Some times the consumer does not make a correct decision. Many people go for office, just because it is MICROSOFT. But a person who needs a good word processor for office use, can easily download a free copy of Star Office or get it from some computer CD.

So what do you think !

Couldn't you use exe compressors/packers like the ones found on http://protools.cjb.net/ to improve the security? I have never tried any of the stuff there but apparently some of the tools will

Quote:

---

Help protect executables against tampering

---

...goto packers and look for exe32pack..

Quote:

---

Couldn't you use exe compressors/packers like the ones found on http://protools.cjb.net/ to improve the security?

---

also see the section UNPACKERS :)

i would expect that packing it would reduce the chance that it could be unpacked again. anyway, its just another hinder which might be good to add to keep the casual hacker off...

Quote:

---

Originally posted by Yash_Kumar
OK... this challenge is officially closed... please wait for 12 hours and I will put challenge #4... we fixed all the problems

---

:o god! how long are the hours where you live?

lol :D

I ALREADY DID!!!! Its at Chit Chat!! Challenge #4!!!! I did it within 12 hours!!

D`oh !!!!

why didn`t you say :)

oops :(

Quote:

---

Originally posted by gaffa
Just has a thought....

Isn't only allowing hacking of the OCX a bit pointless? If you want to crack the protection, you'd hack either the exe or the OCX. THe security is only as good as it's weakest point (so in this case you'd hack the exe sothat the IsCorrupt always returned false, and the hash comparison function always returned true. The OCX might be safe as houses, but if the way you call it is dodgy, then its effectively useless.

Next time Yash_Kumar, you probably need to let us hack BOTH files - If I want to break the security, I'll hack the exe, not the OCX (cos it's a lot easier)

- gaffa

---

gaffa, your comment is sooo correct. :D

Quote:

---

Originally posted by Alan777


gaffa, your comment is sooo correct. :D

---

yea it is, but yash is only seeing if the protection on the ocx is good, wait till Hackers Challenge 4, it will all be there :)

Yash - you really need to work on your dead lines, if you say its gonna be that year/month/week/day/hour/min/sec/(milli sec :D), it should be

Quote:

---

Originally posted by saracen


yea it is, but yash is only seeing if the protection on the ocx is good, wait till Hackers Challenge 4, it will all be there :)

Yash - you really need to work on your dead lines, if you say its gonna be that year/month/week/day/hour/min/sec/(milli sec :D), it should be

---

challenge 4 IS THERE
use the search to find it

It's funny because he's still claiming it's 100% in challenge 4.

yet it's been cracked already

LMAO. Cracked already!

And he was looking for several thousand dollars from people to market this thingy.

..
i don't think challenge 4 was cracked
but the previous challenges were

and in this one, i don't think it was cracked, but then again, he sort of closed the challenge WAY too early