Board index » cppbuilder » Re: How to append an integer value to a compiled .exe ??

Re: How to append an integer value to a compiled .exe ??


2004-02-04 03:07:56 AM
cppbuilder6
"Hans Galema" < XXXX@XXXXX.COM >wrote in message
Quote
Yes. We all know that that is impossible while the
executable is running or a file is locked.
We are not talking about some arbitrary file, though. We are talking about
the executable's own file specifically. That is a different matter
altogether, because the application *can* gain access to its own file while
it is running. Just not easily.
Quote
No. His only problem was how to maintain/change
an integervalue in a file. The file was not locked.
It is if the file is the executable file itself. Changing the value after
the program exits is easy enough, he already has the solution to that. But
he wants to also be able to read the value back at runtime. That is harder
since the application is still running at the time.
Quote
It is as simple as loading a file in memory, looking for the
integer, incrementing it and saving the contents back to file.
That is exactly what he is already doing - for UPDATING the value. That is
a bit harder to handle for READING the value back later at application
runtime.
Gambit
 
 

Re:Re: How to append an integer value to a compiled .exe ??

< XXXX@XXXXX.COM >wrote in message
Quote
Create a RC file with the following line as content:
<snip>
That is exactly the same way you implement my earlier suggestion as well.
Simply create a binary file that contains 4 bytes in it, all set to 0, and
then link that file into your resources the exact same way you are with the
secondary .exe file. You can put multiple resources into an .rc file. Then
at runtime, once you eventually call LockResource(), you have access to the
value. Simply cast the returned pointer to get access to the value, ie:
DWORD GetResourceExecuteCount(const char *res)
{
HRSRC hrsrc = FindResource(HInstance, res, RT_RCDATA);
if( hrsrc != NULL )
{
LPVOID rdata = LockResource(LoadResource(HInstance, hrsrc));
if( rdata != NULL )
return *((LPDWORD)rdata);
}
return 0;
}
__fastcall TForm1::TForm1(TComponent *Owner)
: TForm(Owner)
{
if( GetResourceExecuteCount("MyCountResourceID")>= 10 )
{
MessageBox(NULL, "Your trial period has ended!", "Trial Limit",
MB_OK);
Application->Terminate();
}
}
Gambit
 

Re:Re: How to append an integer value to a compiled .exe ??

"Hans Galema" < XXXX@XXXXX.COM >wrote in message
Quote
char limitusestring [] = "My limitedusecounter is now on: \0\001\0\0\0";
You do realize that you just made it easier for anyone to open the exe file
in a viewer and location the counter value, don't you? Don't use a string
to announce what the data is related to. There are better ways to handle
this type of approach. Such as appending the binary value at the end of the
file and then appending a second value that is a fixed "magic" number of
your choosing. You can then simply seek to 4 bytes from the end of the file
and read the magic number. If it matches, then seek back 8 bytes from the
end of the file and read the real value.
Quote
int searchlen = strlen ( searchstr );
That will not work for binary data. strlen() breaks on the first 0 byte
encountered. Binary data is full of 0 bytes for all sorts of reasons.
Quote
TMemoryStream *MemoryStream = new TMemoryStream;

MemoryStream->LoadFromFile ( FileName );
I would suggest using a memory mapping instead. Look at the
CreateFileMapping() and MapViewOfFile() functions. That way you are not
loading the entire file data into memory at one time. Plus you gain direct
access to the file data itself without having to make copies of it.
Gambit
 

{smallsort}

Re:Re: How to append an integer value to a compiled .exe ??

Remy Lebeau (TeamB) wrote:
Quote
>char limitusestring [] = "My limitedusecounter is now on: \0\001\0\0\0";

You do realize that you just made it easier for anyone to open the exe file
in a viewer and location the counter value, don't you?
Of course. Do you really think I do not ?.
Quote
Don't use a string
to announce what the data is related to.
Indeed. That would be asking for troubles. I would rather avoid that.
Quote
There are better ways to handle
this type of approach. Such as appending the binary value at the end of the
file and then appending a second value that is a fixed "magic" number of
your choosing. You can then simply seek to 4 bytes from the end of the file
and read the magic number. If it matches, then seek back 8 bytes from the
end of the file and read the real value.
Something like that yes. See the threads in the nativeapi ng.
Quote
>int searchlen = strlen ( searchstr );
That will not work for binary data. strlen() breaks on the first 0 byte
encountered. Binary data is full of 0 bytes for all sorts of reasons.
Do you really think that I'm not aware of that ? It is for some reason
named strbin() in analogy to strstr(). Would you think that I could not
write a binbin() function ?
Quote
>TMemoryStream *MemoryStream = new TMemoryStream;
>MemoryStream->LoadFromFile ( FileName );

I would suggest using a memory mapping instead. Look at the
CreateFileMapping() and MapViewOfFile() functions. That way you are not
loading the entire file data into memory at one time. Plus you gain direct
access to the file data itself without having to make copies of it.
That I know all too. And I do not care for that in the posted code yes.
What I posted was a working solution for incrementing an integer.
I had offered to do that. So I did. For Oren to use and everybody else
who wants to do the same. I intentionally used the string "My limitedusecounter
is now on: " to be as illustrative as possible and to give everybody the
possibility to check all at ease with a hexviewer.
Of course being solved the major problems of incrementing an int, then
everybody is free and is expected to make the necessary adjustments for the
needed security. Everybody by then would have read all the posts about this
issue on google and in the nativeapi ng. The first thing then would be to make
the searchstring binary and change strbin to binbin. And then there was nothing
to wish anymore.
I expected people would say: ok I understand it, now I make it
tight. But then there was one who could only complain.
It would be nice if you could implement a limitcounter to the replies
to my posts/replies. Increment when you told me that I was wrong/did not
understand the post/that all could be done better. You can initialise the
counter to value one for every new day. After incrementing check for a
value equal or exceeding two, and in that case think twice.
Hans.
 

Re:Re: How to append an integer value to a compiled .exe ??

thanks Hans & Remy for all your help...as soon as I return to my work-pc
all try your suggestions :-)
Oren
 

Re:Re: How to append an integer value to a compiled .exe ??

"Remy Lebeau (TeamB)" < XXXX@XXXXX.COM >wrote:
Quote

Simply create a binary file that contains 4 bytes in it, all set to 0, and
then link that file into your resources the exact same way you are with
the
secondary .exe file. You can put multiple resources into an .rc file.
Then
at runtime, once you eventually call LockResource(), you have access to
the
value. Simply cast the returned pointer to get access to the value, ie:

Personally I've been very successfull with a security scheeme used in the
past, but it was more elaborate and, most important, not so straight
forward.
I suppose the key point to prevent cracking is to drive them crazy: make
your unfaithfull user so frustrated that he/she will give up.
- Never store data as such. Manipulate their binary value, by masking,
switching and/or swapping bits. A CRC or checksum are 'easy' to be traced,
but not if the first byte is rotated right 6 times while in the second byte
bit 2 and 5 are swapped.
- Hide your securityr data. For instance, if using resources, add a couple
of dummy icons in which you dedicate a few bits each for your counter.
By the way, you will not really need a full 4 byte int. Alternativelly
extend some text labels by valid ascii characters.
- Add some scheeme of multiple interdependant securities. For instance you
might use a displayed last-log-in indicator, which you double check with a
hidden crc. Further add a second ( and third?) crc for the crc itself. Also
store the previous last-log-in to detect system clock resetting. It's
unbelievable how many also renomeed programs do not check this. (I always
install on 1st April 2000...)
- Do not modify just the 4 bytes you intend to use. Rather modify a wider
portion of data loading random data. The cracker easily identifies which
data have been changed, but it's damned hard to reconstruct a 12 bit counter
within 256 Bytes of data. Checking also portions of the random data will
totally misslead him/her.
- If possible, do not block the program when opening. That requires a
would-be cracker much more time to attempt. For instance lock a key menu
item.
Finally, there are components on the market which do security checkings.
Considered using them?
Rgds, Martin
 

Re:Re: How to append an integer value to a compiled .exe ??

Martin Moeller wrote:
Quote
I suppose the key point to prevent cracking is to drive them crazy: make
your unfaithfull user so frustrated that he/she will give up.
That's the way yes.
Quote
- Do not modify just the 4 bytes you intend to use. Rather modify a wider
portion of data loading random data. The cracker easily identifies which
data have been changed, but it's damned hard to reconstruct a 12 bit counter
within 256 Bytes of data. Checking also portions of the random data will
totally misslead him/her.
That's the way indeed.
Quote
- If possible, do not block the program when opening. That requires a
would-be cracker much more time to attempt.
Heh ? Don't you mean: "much less time to attempt" because he could then
easily find the place in the code to look further ?
What I have not read here until now is that all code will have some
function that checks if everything is ok and will return true after a lot
of code has executed, else it will return false. A hacker can just
place a return true statement at the beginning of the function. Or
change the code in such a way that the function is nor even called,
by inserteing NOP's.
Hans.
 

Re:Re: How to append an integer value to a compiled .exe ??

"Hans Galema" < XXXX@XXXXX.COM >wrote:
Quote

What I have not read here until now is that all code will have some
function that checks if everything is ok and will return true after a lot
of code has executed, else it will return false. A hacker can just
place a return true statement at the beginning of the function. Or
change the code in such a way that the function is nor even called,
by inserteing NOP's.

You can hardly do anything on pure software basis if your cracker is capable
& willing to deassemble your exe, while you can do a lot aginst simple
register crackers.
Still also to deassemblers you can at least make life difficult and may get
them that frustrated that they give up. Just as an idea, I would try to
create some dynamic instances to separate the security check from the actual
program close. Immagine a random crated value array and its counter part
computed from the security values. Process them to index to a function
pointer array to switch your program's activity. Mistakes will let your
program fail and exit by the execption system, where you can check again
your security and display the message. Your display function arrives too
late (you are already off the program), while the actual code where it fails
might be always different.
Rgds, Martin