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
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
THE TIME/WEATHER IS
Don't know how to use APIs or have problem with them,
Download API-Guide & API-Viewer from http://www.allapi.net
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.
THE TIME/WEATHER IS
Don't know how to use APIs or have problem with them,
Download API-Guide & API-Viewer from http://www.allapi.net
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
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...
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.
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...
- If at first you dont succeed, then give up, cause you will never will!
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)
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 !
THE TIME/WEATHER IS
Don't know how to use APIs or have problem with them,
Download API-Guide & API-Viewer from http://www.allapi.net
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
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...
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
god! how long are the hours where you live?
Last edited by saracen; May 24th, 2002 at 07:24 AM.
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.
"Today's mighty oak is just yesterday's nut,
that held its ground."
Reply With Quote
done
.
am I right or wrong ?
god! how long are the hours where you live?
