|
HockeyDude wrote:
18446744073709551616 unless i missed something...
Don't want to sound picky, but that's a 64-bit value.
8-bit: 256
16-bit: 65,536
32-bit: 4,294,967,296
64-bit: 18,446,744,073,709,551,616
128-bit: ~3.4028236692093846346337460743e+38
I would've been more precise but the calc I'm using sucks. I let my cousin borrow my Text Instruments calc way back when and it has mysteriously dissappeared. 
Jeremy L. Falcon
"The One Who Said, 'The One Who Said...'"
Homepage: imputek.com
|
|
|
|
|
Make the code long enough.
Say 12 characters.
That should take several months to bruteforce.
Nish
I am the Keyboard Smasher
|
|
|
|
|
Crackers do not use brute force. They're using kernel debuggers like SoftICE to get insight into your software. So you have to be quite smart and make them tired during this process to avoid creation of patches. And, for God's sake, *do not* put statements like this in your code:
if (daysSinceInstall > 7)
{
MessageBox("Money makes the world go round");
return;
}
because it's super-easy to find/remove the test.
OTOH, you can avoid pirated key generators if you go for strong encryption, like RSA.
Tomasz Sowinski -- http://www.shooltz.com
- It's for protection
- Protection from what? Zee Germans?
|
|
|
|
|
Don't most serious software packages use some form of encryption...?
This makes it absolutely nessecary to brute force attack. Unless i'm missing something here???
If you try and protect your code by hardcoding the protection scheme into your exe, like your code snippet above, it's (can be) easy to dissassemble change whats stopping you from using the full package and re-assemble.
The above can be accomplished with a binary search and replace utility, i've done it. 
I always thought(or starting too) that programs now incorporate some form of encryption, because then disassembly doesn't do anything and a brute force attack is required, thus the 128 bit thing...takes forever...
IMO there is NOTHING anyone can currently do to prevent the determined from hacking(you call it cracking and I know thats the proper term)any software. So ultimately...
if(DaysLeft == 7)
would suffice under most circumstances. Even if you have the know how to search for a BYTE,WORD, LONG and replace the value with something else...it's pretty tricky finding it and only the determined know-how individuals will try it.
Cheers!
"An expert is someone who has made all the mistakes in his or her field" - Niels Bohr
|
|
|
|
|
HockeyDude wrote:
So ultimately...
if(DaysLeft == 7)
would suffice under most circumstances.
No, you're wrong here. While there's no 100% protection, you may greatly reduce the risk by being smarter than that. Detemined, best-of-breed crackers can break into anything, but your scheme is crackable even by 9-year old with basic cracking experience.
There used to be a cracker's site called fravia.org containing lots of tips on protection against cracking, but it seems they went underground now.
Tomasz Sowinski -- http://www.shooltz.com
- It's for protection
- Protection from what? Zee Germans?
|
|
|
|
|
I just think ts so funny that when a company spends so much money on a new protection algorythm and then after 1 day it is cracked and the world can get it for free.
I'm not late, I'm just not as early as I could have been.
MSN Messenger address: jonathann4@hotmail.com feel free to chat!
|
|
|
|
|
By far the most secure and reliable way to implement security that i've found is a system which involves an interactive registration process, over the internet. You can make your client app have some kind of key exchange over the network. This is fairly hard to beat.
If you do choose to go for an encrytped product key, a good way of doing this is to use data from the executable itself as the key for the encryption. This is a lot harder to change.
ie, rather than use "myp4ssw0rd", somewhere in a data segment of the program, as a key, use CFile to open the executable file, go forward X bytes and read from there.
|
|
|
|
|
Jon Hulatt wrote:
By far the most secure and reliable way to implement security that i've found is a system which involves an interactive registration process, over the internet. You can make your client app have some kind of key exchange over the network. This is fairly hard to beat.
Microsoft did that with Office XP and within 2 days someone had cracked it. Windows XP is one of the harder though. Has anyone cracked it yet do u know?
I'm not late, I'm just not as early as I could have been.
MSN Messenger address: jonathann4@hotmail.com feel free to chat!
|
|
|
|
|
as a defense against that, you can do a CRC on your EXE. if that fails, you know someone has tweaked your app. yes, they can disable the CRC code too, but they probably won't even know it's doing a CRC until their first few crack attempts fail.
and, if you're clever, you can use the CRC check to do subtle failures; don't just pop up a message box and quit, do something strange - allocate huge (100MB) chunks of memory for no reason, put a random delay in a message pump, disable random controls - make it look like the crack attempt has broken something vital inside the app. you don't have to worry about annoying valid users - at this point you know the app has been tampered with somehow - either by a virus or a cracker.
the way they're going to discover the CRC is to watch the files that your EXE opens (by intercepting file open calls to the OS). so, make sure your EXE reads itself a lot, for many different reasons. also only do the CRC once in a while (only on odd-numbered days or something). there's no point in making it easy to discover.
beside CRC, you can use the results from your key checking code as vital parts of your app's functionality. encrypt important numbers (like the number of days in a year, the value of pi, or something else your app uses a lot) in your user keys - use the value from the key. that way, without decrypting a valid key, the app won't work as planned.
do the key check in many places.
don't use a function to do it. write a macro. this way, there isn't a single place to break, they have to find every place you've used the macro. even better, write many different macros that all do the test in a different way, and use them all. this adds yet another step they have to go through to crack your app.
as everyone is going to say , you can't really stop people. but you can try to make them give up in frustration.
use public key encryption if you can. it's easy to find the encryption keys in your code, so all they have to do is find the keys and start testing the key in various symmetric ciphers till they find the one that gives the same results as your app. then it's just a matter of arranging user data to get a keygen. this ain't gonna happen with public key encryption.
-c
Ah, but a programmer's reach should exceed his grasp, or what are late nights for?
Smaller Animals Software, Inc.
|
|
|
|
|
Chris Losinger wrote:
allocate huge (100MB) chunks of memory for no reason, put a random delay in a message pump, disable random controls
Is it just me, or does anyone else get that "don't piss Chris off" kinda feeling from this post?
Jeremy L. Falcon
"The One Who Said, 'The One Who Said...'"
Homepage: imputek.com
|
|
|
|
|
nobody's gonna get my $29.95 without a fight, that's for damn sure!
-c
Ah, but a programmer's reach should exceed his grasp, or what are late nights for?
Smaller Animals Software, Inc.
|
|
|
|
|
Chris Losinger wrote:
if you're clever, you can use the CRC check to do subtle failures; don't just pop up a message box and quit, do something strange - allocate huge (100MB) chunks of memory for no reason, put a random delay in a message pump, disable random controls - make it look like the crack attempt has broken something vital inside the app.
My variation on this for inside of a computer game would be to make the game not as fun or easy with a cracked version. For instance:
The cracked players health always drops 4 * times as fast as a legitimate version. Ammunition or money dissappear faster than normal. Hardly any damage is incurred from their weapons.
All in all I think that it is a very clever way to thwart hackers, because they will never really know if they have gotten rid of all of the security checks.
|
|
|
|
|
Lots of good ideas Chris. In addition I'd suggest doing various checks in a separate thread and also using PostMessage to hide what's happening. Challenge - response is another technique to look at. I use a range of techniques in ED.
If anyone has some spare time on their hands I'd be interested to see if they can crack ED's licensing. By that I mean change the Free Trial version into a full working version. A free copy to anyone that can.;P
Neville Franks, Author of ED for Windows. www.getsoft.com
|
|
|
|
|
One simple technique to slow brute force techniques down is to add a short sleep after the validation is done.
Also don't inform the user that the Rego code is wrong, then and there, but some time later. In ED the user uses Help|Registration to enter the license details, but they need to use Help|About to see if the license was accepted.
The fravia pages mentioned elsewhere are a great source of information.
Neville Franks, Author of ED for Windows. www.getsoft.com
|
|
|
|
|
Thanks Mauricio for starting a very interesting thread.
Chris is obviously well versed in protecting his software. The concept is to think like a cracker and defeat him through a combination of frustration and wasted time.
All us programmers who chase bugs find it really annoying when we think the bug is fixed, and it crops up again 2 days later!
Imagine how it makes a cracker feel when every time he (BTW, are there any female crackers...or does one require high-levels of testosterone to be a complete d@$&head?) thinks he's broken your security, it stops working again.
And, of course, there's the most important formula:
B = P * U * K
where B is the benefit derived in cracking your product
P is the price of your product
U is the popularity of your product
K is the kudos the cracker gets from his peers
So, if your product costs a lot or is really popular, then you need the best protection possible.
We're in the process of releasing a product that addresses all the critical issues in Software Protection.
For a chance to *win* some great prizes, why not complete our survey? This isn't advertising, but a genuine survey - and there's no advertising on our site, so we're not even trying to increase our hit counts!
So, if you'd like to see a well design product that meets your needs, please complete our survey. To participate in the survey, visit our developers' site at dev.rootsoftware.com
Russell Robinson (russellr@rootsoftware.com)
Author of TTMaker (Advanced Timetabling Software)
http://www.rootsoftware.com
|
|
|
|
|
Hi,
I would like to load a gray image(which is been stored in a file).Does anyone knows anything, that is specific to gray image(other than true color 24 bit rgb)?
|
|
|
|
|
LoadImage() has a LR_MONOCHROME flag
-Jack
To an optimist the glass is half full.
To a pessimist the glass is half empty.
To a programmer the glass is twice as big as it needs to be.
|
|
|
|
|
LR_MONOCHROME "loads the image in black and white", according to MSDN. May not work for grayscale.
Tomasz Sowinski -- http://www.shooltz.com
- It's for protection
- Protection from what? Zee Germans?
|
|
|
|
|
It is a gray image not B/W.
|
|
|
|
|
What kind of file it is? .bmp?
Tomasz Sowinski -- http://www.shooltz.com
- It's for protection
- Protection from what? Zee Germans?
|
|
|
|
|
|
LoadImage will work. In fact, it should work with all .bmp files - just use LR_LOADFROMFILE flag.
Tomasz Sowinski -- http://www.shooltz.com
- It's for protection
- Protection from what? Zee Germans?
|
|
|
|
|
What is specific to grey images is they do not have more than 256 colours because all the grey colours have the same r g and b values. But as has been said, there is not reason the computer will even realise an image is grey when it loads it, using any standard method, such as loadimage.
Christian
The tragedy of cyberspace - that so much can travel so far, and yet mean so little.
"I'm somewhat suspicious of STL though. My (test,experimental) program worked first time. Whats that all about??!?!
- Jon Hulatt, 22/3/2002
|
|
|
|
|
The best way of being sure that the image you load is greyscale, would be to greyscale it yourself upon loading. Do this by setting r,g,b each to the same value, (r+g+b)/3.
Sorry to dissapoint you all with my lack of a witty or poignant signature.
|
|
|
|
|
class A
{
public:
A()
{
}
virtual ~A()
{
}
void (A::*ptFunc)();
};
class B:public A
{
public:
B()
{
ptFunc = &(B::b_func);
}
virtual ~B()
{
}
void b_func()
{
cout<<"B::b_func"<
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
