PureBasic Forums - English

No, this isn't a question about how to protect against cracking, so relax.

What I mean in the topic, is what could a cracker do to modify my app to
make it behave differently? For example, if my app checked something at
12pm each day, could the cracker modify my app and rebuild the exe to
make it do the check at 1pm instead?

Or, if my app saved an image as JPG at 80% quality, could they modify
it to always save it at 100% quality? Or even as a BMP image instead?

Can they tell when an app is exiting, with PureBasic's "End" command?

Just want to get a feel for what they can do with other people's apps.

I would say they could do everything with it. It depends on how deep a hacker wants to dive into your application.

Example: It would be pretty simple to change the time your application checks. If it's a hard-coded value like 12 we just need to find it and change it to what ever we want.
Once I had a "fan" of my application, who translated it in to Chinese by replacing all hard-coded strings. It's not something bad and he even asked me but I was a little shocked. So now I'm saving them in a more complex way.

But remember, that's just the simplest thing someone can do. Basically everything can be done!

yes everything can be done.
I used to patch some stuff in a game called sacred. There was a file located in the ressource section of the .exe. I wanted that file on as a single file on the hdd and made sacred load it from the hdd by rewriting the loading procedure of the file in assembler with ollydbg. worked very good.

Another time i fixed a crash in that game.

All is possible, it,s just a matter of how much time someone whats to invest.

He can change the version info and about box to his name and sell it. It's happened to me before and I think JC had it happen with his internet TV program as well.

> If it's a hard-coded value like 12 we just need to find it and change it to what ever we want

So, is it better to store the value as a calculation? Like 6+6 instead of hard-coded 12?
But then they can just trace that anyway, right? What if the number is obtained by
reading a Registry string? Can they change the app so that it doesn't read the Registry
and they put the 12 back in as a hard-coded number?

> I had a "fan" of my application, who translated it in to Chinese by replacing all hard-coded strings

If a string is hard-coded as "hello" can they change it to something longer, like "goodbye"?
You can't if you modify the string with a hex editor, but I guess OllyDbg can change them
to longer strings if the cracker wants?

> He can change the version info and about box to his name and sell it

Now THAT sucks! But I plan to put secret copyright info in my apps, that the
user is never aware of, so that if they claim ownership, I can challenge them in
court by saying "okay, press Shift+Ctrl+Alt+O and see what happens" (which of
course will show MY encrypted details as the owner).

Another thing: can embedded images and sounds be changed? Not merely extracted
or ripped, but actually changed in the exe? My exe will check its own filesize when
running, so if it doesn't match I know it's been tampered with, but I guess if the
cracker knows about that, they can remove the filesize check too?

PB wrote:Can they change the app so that it doesn't read the Registry
and they put the 12 back in as a hard-coded number?

yes

PB wrote: If a string is hard-coded as "hello" can they change it to something longer, like "goodbye"?
You can't if you modify the string with a hex editor, but I guess OllyDbg can change them
to longer strings if the cracker wants?

Yes, it's possible. But much more complicated than just overwriting the strings. Basicly you need some space in the executable (which can be added) and store the new string in there. Now you have to change the address of the hardcoded string to the address of the new string. That must be done to every instruction that references the string.

PB wrote: Another thing: can embedded images and sounds be changed? Not merely extracted
or ripped, but actually changed in the exe? My exe will check its own filesize when
running, so if it doesn't match I know it's been tampered with, but I guess if the
cracker knows about that, they can remove the filesize check too?

Yes and yes.

This "hannyflow" is a smart bot, its replies are pretty much on-topic!

yea, i want one of those.

c ya,
nco2k

PB wrote:This "hannyflow" is a smart bot, its replies are pretty much on-topic!

Hes back. ^^

PB wrote:My exe will check its own filesize when
running, so if it doesn't match I know it's been tampered with

Better do this:
http://www.purebasic.fr/english/viewtop ... 12&t=26369
But nothing is perfect of course.

Joakim Christiansen wrote:

PB wrote:My exe will check its own filesize when
running, so if it doesn't match I know it's been tampered with

Better do this:
http://www.purebasic.fr/english/viewtop ... 12&t=26369
But nothing is perfect of course.

Very cool example.

Just dont use the message box/error message in production, because its a big red flag that says "jmp over me," when they see it in the debugger .

What can a cracker do to my app?

http://www.youtube.com/watch?v=em9PtzQzWOg

CLASSIC

Num3 wrote:What can a cracker do to my app?

http://www.youtube.com/watch?v=em9PtzQzWOg

CLASSIC

Hackers - are experienced coders who are good guys.

Crackers - that's bad guys, they do not usually delve into the mechanism of the entire program to studying only settle for the minimum protection mechanism, and often use very dirty methods, such as patching executables. YUCK!

Codereaper - it is maximalists, will do so if possible not to change executable files (key generation, stealth wrappers, e.t.c).

Reverse engineers - extreme qualified, will disassemble the program into components, down to the level of obtaining the source code, allowing to make changes at the source code and compile the program again.
The services of reverse engineers often called themselves software developers and systems to identify possible shortcomings in the protection system (WHITE HACKING), as well as in the case of loss of sources.