This essential resource for software developers highlights the weak points in "well-protected" software, shows how crackers break common protection schemes, and how to defend against crackers. Includes in-depth discussions of anti-debugging and anti-disassembling. The CD-ROM contains compression and encoding software, debuggers and anti-debugging tricks, practical protection demonstrations, and extended examples from the book.
Basically, all i would like to do is to make sure no one is able to step through sensitive code.
I read somewhere it was possible, only i can't find where i read that.
i would like to do is to make sure no one is able to step through sensitive code.
The "no one" part is impossible: a sophisticated attacker will be able to do it no matter what you try.
There are many techniques that will stop less sophisticated attacker, this book shows some of them.
Generally, these techniques are not worth your time -- they make field support of your software hard, they don't stop sophisticated attacker (and you only need one to succeed to render your efforts useless), and your software usually isn't that interesting to begin with.
If it is useful enough, people will buy it. If it is not, adding protections will make it even less useful.
Currently, when I create a shared library, functions from within the same object files like to lie together. Is there a good solution (that does not involve splitting up source files) to try and spread function locations apart? We are currently using a cross-compiled, 4.2.1 version of gcc and the gnu tools.
While you can do what you want using GNU-ld linker script (if you are on platform for which GNU ld works), you can't do it portably.
In addition, it's a totally wasted effort: any hacker worth their salt will not care about moving functions around. If you really want to make it harder to reverse engineer your code (or just bypass your license scheme), you should use much stronger techniques, described e.g. here.
Arguably, that's still totally wasted effort.
Due to license problem, few libraries cannot be linked statically.
So is it possible to prevent/detect preloaded library, either through LD_PRELOAD environment variable or through /etc/ld.so.preload configuration?
The previous can be detected through getenv(). But I have no idea about the other method.
I think there might be a general way to do it, is it?
is it possible to prevent/detect preloaded library, either through LD_PRELOAD environment variable or through /etc/ld.so.preload configuration?
You appear to be trying to implement some kind of anti-hacking protection. If so, it would be worth your while to study existing crackproofing techniques. This book describes a few.
Note that there are many other techniques to inject "foreign" code into your application, besides
/etc/ld.so.preload. A couple that immediately come to mind are:
LD_AUDIT, running under debugger, and renaming/replacing
You have very little hope of stopping a moderately-sophisticated attacker. On Linux, I can build my own
libc.so.6, and I can rename
LD_PRELOAD to something else. I can also build my own kernel, and have it automatically inject
myhack.so into your process without any user-space visible effects. Or I can simply make system calls do something else when executed by your application.
... the LD_PRELOAD ... can be detected through
That would stop only the least sophisticated attacker, for two reasons:
getenv(), and can hide
LD_PRELOADfrom your application, and
LD_PRELOADonly matters at process startup. After the process has started, the preloaded library can easily remove
LD_PRELOADfrom the environment before your application has any chance to examine it.
I need to employ some sort of licensing on some Linux applications that I don't have access to their code base.
What I'm thinking is having a separate process read the license key and check for the availability of that application. I would then need to ensure that process is run during every invocation of the respected application. Is there some feature of Linux that can assist in this? For example something like the sudoers file in which I detect what user and what application is trying to be launched, and if a combination is met, run the license process check first.
Or can I do something like not allow the user to launch the (command-line) application by itself, and force them to pipe it to my license process as so:
/usr/bin/tm | license_process // whereas '/usr/bin/tm' would fail on its own
I need to employ some sort of licensing on some Linux applications
Please note that license checks will generally cost you way more (in support and administration) than they are worth: anybody who wants to bypass the check and has a modicum of skill will do so, and will not pay for the license if he can't anyway (that is, by not implementing a licensing scheme you are generally not leaving any money on the table).
that I don't have access to their code base.
That makes your task pretty much impossible: the only effective copy-protection schemes require that you rebuild your entire application, and make it check the license in so many distinct places that the would be attacker gets bored and goes away. You can read about such schemes here.
I'm thinking is having a separate process read the license key and check for the availability of that application.
Any such scheme will be bypassed in under 5 minutes by someone skilled with
gdb. Don't waste your time.