Re: Making a partial C compiler

vbdis@aol.com (VBDis)
3 Jun 2003 00:39:40 -0400

          From comp.compilers

Related articles
Making a partial C compiler cyberheg@l115.langkaer.dk (John Eskie) (2003-05-18)
Re: Making a partial C compiler torbenm@diku.dk (2003-05-23)
Re: Making a partial C compiler matt@peakfive.com (Matt Rosing) (2003-05-24)
Re: Making a partial C compiler blackmarlin@asean-mail.com (2003-05-24)
Re: Making a partial C compiler idbaxter@semdesigns.com (2003-05-24)
Re: Making a partial C compiler cyberheg@l115.langkaer.dk (John Eskie) (2003-05-29)
Re: Making a partial C compiler vbdis@aol.com (2003-06-03)
Re: Making a partial C compiler lars@bearnip.com (2003-06-03)
Re: Making a partial C compiler boldyrev@cgitftp.uiggm.nsc.ru (Ivan Boldyrev) (2003-06-03)
Re: Making a partial C compiler jyrixx@astro.temple.edu (2003-06-03)
Re: Making a partial C compiler torbenm@diku.dk (2003-06-05)
Re: Making a partial C compiler cyberheg@l115.langkaer.dk (John Eskie) (2003-06-08)
Re: Making a partial C compiler cyberheg@l115.langkaer.dk (John Eskie) (2003-06-08)
[1 later articles]
| List of all articles for this month |
From: vbdis@aol.com (VBDis)
Newsgroups: comp.compilers
Date: 3 Jun 2003 00:39:40 -0400
Organization: AOL Bertelsmann Online GmbH & Co. KG http://www.germany.aol.com
References: 03-05-202
Keywords: C
Posted-Date: 03 Jun 2003 00:39:40 EDT

"John Eskie" <cyberheg@l115.langkaer.dk> schreibt:


>1. Variable and function name string replacement (more of you already wrote
>how that can be done).


IMO you should do the following, before your next posting:
- learn about your tools (linker, debug info...)
- define your enemies
- learn more about your enemies


A choice of your possible enemies:
- source code thiefs
- users of hex editors
- users of disassemblers
- users of debuggers
each with subgroups from dumb to expert.


If you are concerned about strings, then you should not only consider
variable names, which most probably never are exported, but also all
string literals. Finding strings like "enter password" is worth more
than hundreds of other unimportant names. I'd suggest to encrypt all
strings, and decrypt at runtime only those strings, which are
presented to the user. This and many other suggestions may require
more changes to your code, than a source code tool can do for itself.


A good disassembler will find (and name) many library procedures in a
program, regardless of their names in source code. You best use an
infrequently used compiler, with a widely unknown system library. You
also should avoid any standard libraries, whose code may be detected
in your programs.


>2. Introduction of parallel code i.e. dummy code which doesn't interfear
>with the real program but make things harder to read since you gotta figure
>out what is real and what isn't real.


Recompilation of a disassembly will eliminate all dead code, even if
I'm not sure about the cleverness of assemblers. Data flow analysis
allows to eliminate such code.


>3. Rearranging of code so if you got 3 blocks of statements A, B, C you can...


Undone by control flow analysis.


>4. Dynamic "linking" by making exact function calls to be resolved at
>runtime by using function pointers.


Then you must take special care to obfuscate the code which initializes these
pointers!




As mentioned above, when you specifiy your enemies first, I can tell
you more about modifications, which /really/ can make their life
harder.


DoDi


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.