I see no reason why not. However, I think it's a lot easier to "crack" your DLL than your application. Crackers will be able to brute-force your DLL and/or replace the DLL with some sort of fake DLL.Originally Posted by Robert Kosek
I see no reason why not. However, I think it's a lot easier to "crack" your DLL than your application. Crackers will be able to brute-force your DLL and/or replace the DLL with some sort of fake DLL.Originally Posted by Robert Kosek
Well, if you UPX it and spaghetti code it then it should be fine. As well as certain DLL check functions named "GetWindowText" and whatnot.
Can we code special DLL loading functions?
Unpacking UPX is easy: it comes with unpacker, right?Originally Posted by Robert Kosek
As for function names, I doubt crackers will look at function names anyway, so it can be "GetWindowText" or "HelloThere" - makes no difference.
Besides, "GetWindowText" name will be quite suspicious anyway, since it's usually located in "User32.dll".
But when called it is harder to tell where you're calling it from. Thus using things using names that imitate your form functions for instance.
But yes, UPX does have an unpacker. Which is why I asked if there is a way to write your own DLL loader functions. Then I could encrypt my DLLs in a strong fashion.
Ha, seems that you guys dont know anything about cracking and how they beat protections. UPX is useless. It only packs your exe, it does not protect.
UPX can be unpacked with 1 minute, even less.
If u want serious protector then purchase Execryptor or Armadillo, use maximum protection that they give. ASPR: crc check, debugger check, time changing etc, ARMA: copymem, nanomites, anything it gives to you. Also try to use FindWindow API to find cheating tools windows by its name etc. Also game hacking tools. Like "Trainer creation kit" etc. If this window is active then kill this window or just dont load game. Do not display messageboxes like: Game cheating program is active, Please close it before running game". By these messages, the cheating tool check can be busted with changing one byte.
Need more inf? Just ask me.
Remember! There is no BEST protector!! EVERYTHING is crackable but with my tips u can make it harder!
You're missing the point. We're mostly small timers, and I know I can't afford a protection package. Thus the discussion on how to protect it ourselves.
Crackers/Hackers often take the bread from our mouths.
Just who do you think you are? If I actually had money I'd buy a copy of Delphi '06 first, so I could make some money. Protection I can code for myself, and you didn't give any real tips, just a recommendation to get a component set.
Want to help us? Then talk in methods and code, not "get this and turn it fully on". I'd buy ICE License before I get "EXECryptor".
Sorry for the tone, but today I'm in a "don't mess with me" mood.
I doubt this will ever work. Think of it, you create a game, then someone makes a trainer with window name "G@me Trainer by ThR-ash". How would you know such window name in the first place? What if they change window name to something like "Mega C00l Helper"?Originally Posted by BytePtr
Just curious. Is there any game doing that?Originally Posted by BytePtr
If you have time, you might want some article about protecting programs or at least give some suggestions (preferably not related to commercial software). This could be very handyOriginally Posted by BytePtr
Hi,
i also have had a lot of trouble with "hackers" who spread my software. Similar like Erik i tried to make the application secure. In my opinion i think the easier a protection works, the better it is. Just put pieces of the key checks all around the application, add some parts in your sprite class for example and never ever combine the "enter key" with a "check key" routine. Just close the app and restart it again. This way it is harder to find the logic
UPX is also fine and if you edit the header you can not decompile it via upx -d filename.exe.
Finally, i know this link is not very serious but the author has had damn cool ideas: http://www.iamaphex.cjb.net/
Especially the "load an encrypted dll out of a ressource" sample.
Christian
Yes. Spyro the Dragon on PSX. It had CRCs of sections of code embedded in the section of code that it was doing the CRC on. These CRC'd sections of code would also overlap with other CRC'd sections of code. When it detected that a CRC did not match, it did not inform the user straight away. It removed a few gems from the level so the user could not complete the level, or later on a NPC character would mention that you are using a cracked version of the game. That was just one of the anti-crack methods they used. It took the crackers over three months to release a properly cracked version of Spyro with several dud versions released beforehand (the majority of a game's sales are in the first three months), and the crackers thanked the Spyro developers for making it such a challenge.Originally Posted by Lifepower
Here's the article on Gamasutra.
Keeping the Pirates at Bay: Implementing Crack Protection for Spyro: Year of the Dragon
UPX is extremely easy to unpack - use a custom UPX implemenation of your own. I.e. scramble the alogorithm a bit and customize it so no hacker can find a decompressor for your packing alogorithm.
He can still unpack your program by looking into the assembly, but it is much harder when it is your own custom packing alogorithm.
Get the program called Stud_PE and find the site called "pro tools". Use all the tools you can, and pretend you yourself are the cracker.
http://z505.com
Bookmarks