Comment from the Author:
I would like to wish everybody a happy new year and of course I would like to thank you for reading my column in the last year. I hope you enjoyed reading my column and still enjoy reading the column for the present and of course for further years. If you think that there are some things that could be done better or should be changed, don’t hestitate to e-mail me and we will talk about that.
Sonu Kapoor
Introduction:
Lots of hot topics are covered in the Discussion Forums on CodeGuru. If you missed the forums this week, you missed some interesting ways to solve a problem. Some of the hot topics this week include:
- How is software cracked?
- Why does my CStatic control on a TabCtrl have a different bgcolor than the TabCtrl?
- How do I instantiate a class by name?
- Is the & operator intelligent?
- How do I set the size when minimizing a window in pure C?
|
Thread:
Admin Note:
This thread is not to digress into talking about how to illegally crack software, rather it is to help people understand how to prevent cracking and to understand the implications of such.
Mathew Joy asked this question because he is curious about the security of software.
We all know that there are cracks available for most of the s/w that have a few restrictions/disabled features in them. Recently I've met a person who has done some R&Ds in security. He told me that it is not very difficult to trace the equalities in the exe. Once that is traced out, a few statements can be inserted to bypass that block (or something like that). According to what he said, if I have a statement like:
if(TotEvalDays > 30) {
[.display a message that s/w has expired.]
[.exit.]
}
This can be traced and bypassed. The tracing is facilitated by checking the code that is executed when the message box is displayed. And, as from what he said, defence can be added by avoiding these two statements (esp the message box) from the checking part. I found this a bit tough to digest...but is this true? If not, how is s/w cracked? Any opinions? Thanx
Unfortunaly, the statement given by the friend of Mathey is correct. There is no 100% foolproof way to protect your software (by software). However, there are several ways to make your software secure. But remember that even Microsoft fails in this area. The best way is probably to obscure the protection code as much as possible. This will confuse crackers. Some will try five minutes; others may go on for five hours. It’s just a matter of time and skill before someone breaks it. Another possiblity to make your application secure is suggested by DHillard:
“I think the root of this problem is developers releasing complete applications as shareware trial versions. To keep shareware from being cracked, the developer should keep some basic critical functionality out of the code. Once registered (paid for), the user would then get a new executable with the needed code in it.
“One step short of this is to include the code but restrict its usage. Again, this restriction must be the only code available in the executable to prevent the equality detection/skip/hack/patch.
“The trial version can contain menu items of the missing functionality, but keep the code out of the finished executable. Then, if the hacker wants to try to crack it, let ’em try. They’ve got more time than you, plus they’ll be wasting their time trying to crack into code that isn’t there, plus the time they spend trying to crack it is time they won’t spend trying to crack something else.
“(This won’t do jack to keep your registered users from distributing their full version to the world, but you will be guaranteed at least one sale.)”
Besides that, take a look at the following article. It provides very good techniques to protect your software.
|
Thread:
Geno Carman is working with a CTabCtrl CStatic control in a Windows XP environment. Unfortunaly, the background color of the CStatic controls is different than the background color of the CTabCtrl. But why?
All of my CStatic controls that sit on a CTabCtrl have a different background color than the CTabCtrl. What is going on and how do I fix it?
This is a bug in the Windows XP theme engine. A workaround is to handle WM_CTLCOLOR and return a hbrush. It should work something like this:
HBRUSH CMyDlg::OnCtlColor(CDC* pDC, CWnd* pWnd, UINT nCtlColor)
{
HBRUSH hbr = CDialog::OnCtlColor(pDC, pWnd, nCtlColor);
if(nCtlColor == CTLCOLOR_STATIC)
{
hbr = m_HollowBrush;
pDC->SetBkMode(TRANSPARENT);
}
return hbr;
}
|
Thread:
reset-leo wants to know whether is it possible to instantiate classes by their class names.
Is there a possibility to instantiate classes through their name as a string, not their type? Normally, I would use:
CMyClass *myClass; myClass = new CMyClass;
but I want to use:
CMyBaseClass *myBaseClass;
myBaseClass = <certainfunction>("CMyClass");
Well, the best solution is to use a map:
class CMyClass1 : public CObject
{
// this is a must!!
DECLARE_DYNCREATE(CMyClass1);
} ;
// in .cpp
IMPLEMENT_DYNCREATE(CMyClass1, CObject);
.. etc
class CMyClass2 : public CObject
{
// again, must do this!
DECLARE_DYNCREATE(CMyClass2);
}
// in .cpp
IMPLEMENT_DYNCREATE(CMyClass2, CObject);
.. etc
class CMyClassCreator
{
public:
virtual ~CMyClassCreator();
static CMyClassCreator &Get();
CObject *CreateObject(LPCSTR szName);
private:
CMyClassCreator();
void Initialise();
BOOL m_fInitialised;
CMapStringToOb m_mapNameToObject;
void AddObject(LPCSTR szName, CObject *pObject);
static CMyClassCreator m_theObject;
} ;
// .cpp
CMyClassCreator CMyClassCreator::m_theObject;
CMyClassCreator::CMyClassCreator()
{
m_fInitialised = FALSE;
}
CMyClassCreator::~CMyClassCreator()
{
POSITION pPos = m_mapNameToObject.GetStartPosition();
while (pPos != NULL)
{
CString sName;
CObject *pObject = NULL;
m_mapNameToObject.GetNextAssoc(pPos, sName, pObject);
delete pObject;
}
}
void CMyClassCreator::AddObject(LPCSTR szName, CObject *pObject)
{
// debug test
#ifdef _DEBUG
CObject *pTestObject = NULL;
if (m_mapNameToObject.Lookup(szName, pTestObject)
{
ASSERT(FALSE);
}
#endif
m_mapNameToObject.SetAt(szName, pObject);
}
void CMyClassCreator::Initialise()
{
m_fInitialised = TRUE;
AddObject("CMyClass1", new CMyClass1);
AddObject("CMyClass2", new CMyClass2);
// etc.
}
CMyClassCreator &CMyClassCreator::Get()
{
if (!m_fInitialised)
{
Initialise();
}
return m_theObject;
}
CObject *CMyClassCreator::CreateObject(LPCSTR szName)
{
CObject *pObject = NULL;
if (m_mapNameToObject.Lookup(szName, pObject))
{
return pObject->GetRuntimeClass()->CreateObject();
}
else
{
return NULL;
}
}
// usage:
CMyClass1 *pClass1 = static_cast<CMyClass1>(CMyClassCreator::
Get().CreateObject
("CMyClass1"));
|
Thread:
newbee240 is working on the following simple code:
void Bar (void *); char foo[256]; Bar (foo); Bar ((void*)&foo);
And now, he wants to know why both calls work the same?
Well, the solution is simple and came from Gabriel Fleseriu:
The compiler is able to implicitely convert any pointer to a pointer to void. It’s in the standard.
|
Thread:
Al_Pennyworth asked a very interesting question. He is currently working on a C project. In that project, he needs to set a particular size of the window when the user presses the minimize button. Do you know how to do that?
I am trying to incorporate functionality into an application so that the user can hit the Minimize button on a window and the window will minimize to a particular size. I am trying to do this with the Minimize, Maximize, and Close buttons on the top right of the window (standard window functions). My problem is I am not sure how to do it. If the user resizes the window, I am preventing the window from going below a specific size. But is there any way to do the same thing when the minimize button is hit, or I am forced to allow the window to be fully minimized? This is not C++ or MFC, I am having to do this in an application that is written in C. Any suggestions?
So, well guys, do you know how to accomplish such a task? Unfortunately, we did not get any solution as yet. Do you know the solution? If yes, you can e-mail it to me and I will publish it in next week’s article.
