|
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"<
|
|
|
|
|
I have think it out, thank you 
#include <iostream.h>
template <class T>
class A
{
public:
A()
{
}
virtual ~A()
{
}
void (T::*ptFunc)();
};
class B:public A<B>
{
public:
B()
{
ptFunc = &(B::b_func);
}
virtual ~B()
{
}
void b_func()
{
cout<<"B::b_func"<<endl;
}
};
int main()
{
B b;
(b.*(b.ptFunc))();
return 0;
}
I'm amumu, and you?
|
|
|
|
|
But now I meet another question:
I want to define a array whose item is pointer of A<t>, which may be store B or C or D ( any classes inherited from A<t> ), how to write it?
I'm amumu, and you?
|
|
|
|
|
By creating an array of pointers to A. OR even better, a std::vector of pointers to A, but if you use a vector, remember to call delete on items before removing them.
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
|
|
|
|
|
Christian Graus wrote:
if you use a vector, remember to call delete on items before removing them.
The same thing applies to plain array...
Tomasz Sowinski -- http://www.shooltz.com
- It's for protection
- Protection from what? Zee Germans?
|
|
|
|
|
Tomasz Sowinski wrote:
Christian Graus wrote:
if you use a vector, remember to call delete on items before removing them.
The same thing applies to plain array...
Yes, and no. A plain array does not offer an erase method, which a beginner would probably assume will clean up after them, therefore it's probably more obvious with a plain array that you need to delete your pointers.
But you're right, I should have clarified, lest I give the impression that I was saying that somehow a vector makes it necessary to call delete
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
|
|
|
|
|
No,no,no, my meaning is how to write like the following code:
A<T>* ptA;
B b;
C c;
ptA=&b; //upcast here
ptA->xxx();
ptA=&c; //upcast here
ptA->xxx();
But the "A<T>* ptA" is invalid, because it need instantiation here, I must fill the T with B or C, but if I write A<B>* ptA, then ptA=&c is invalid, the same as writing A<C>* ptA.
Now I want to know, how to define a pointer can pointer b or c?
I'm amumu, and you?
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
