any compiler that takes encrypted input

S

sh.vipin

Is there any C Compiler that accepts encrypted source files. That is
something which may take decryption key and source file as an input
and generates the object code after decrypting the source file
internally.
 
S

sh.vipin

I don't know of such a compiler (unless you count EBCDIC as
encryption!), but it would not be very difficult to write a wrapper
around an existing compiler.

That means, modifying code (of gcc most likely, others source won't be
available ) and then compiling it for all different platforms.
Yes that is certainly one option. Thanks.
but I thought of if any of the compiler already had it because that
will save me a time for cross compiling and maintenance.
 
B

Bartc

That means, modifying code (of gcc most likely, others source won't be
available ) and then compiling it for all different platforms.
Yes that is certainly one option. Thanks.
but I thought of if any of the compiler already had it because that
will save me a time for cross compiling and maintenance.

Do you already have a means of decrypting the files? If so, decrypt them
once and develop with unencrypted files. When finished, encrypt them again.

If not, why expect any compiler to have any idea what encryption scheme is
being used?

How do you edit the files, does your editor have the decryption built in?

What about include files? If you have (after decrypting) #include <stdio.h>
in your source, do you expect the compiler to have an encrypted version of
stdio.h, or would it accept plain text? How about #include "yourfile.h"?

Whatever your solution turns out to be, I doubt it will involved modifying
gcc. More likely converting your input to C source code.
 
K

Kojak

Le Thu, 19 Feb 2009 04:07:16 -0800 (PST),
(e-mail address removed) a écrit :
That means, modifying code (of gcc most likely, others source won't be
available ) and then compiling it for all different platforms.
Yes that is certainly one option. Thanks.

Unless you are completely paranoid (e.g. temp files issue when
compiling) you need juste an external program that take crypted
source, decrypt it and call the compiler. No need to tweak gcc. :)

but I thought of if any of the compiler already had it because that
will save me a time for cross compiling and maintenance.

One can find crypted source compiler like:

<http://oldsite.vislab.usyd.edu.au/resources/guide/houdini/vex/compiler.html>

selectable via pragmas. Unfortunately, I never heard about
crypted ansi C compiler. But who knows, wait and see...
 
J

James Kuyper

Richard said:
(e-mail address removed) said:


I don't know of such a compiler (unless you count EBCDIC as
encryption!), but it would not be very difficult to write a wrapper
around an existing compiler.

It wouldn't be difficult to write a shell script wrapper for that
purpose, but it would necessarily create a temporary file (or at least a
pipe) that contains the decrypted version of the source code. That might
not be acceptable, depending upon exactly why he needs this capability.
 
S

sh.vipin

It wouldn't be difficult to write a shell script wrapper for that
purpose, but it would necessarily create a temporary file (or at least a
pipe) that contains the decrypted version of the source code. That might
not be acceptable, depending upon exactly why he needs this capability.

exactly, an standalone wrapper will also have to generate some
decrypted file. which i don't want
as far as the usage is concerned it can be used as following

system("gcc -decrypt--offset "10" a.c" -o sim);

here a.c is an encrypted file. integer value 10 is an offset to every
character value i.e. character 'a' becomes 'a'+10 th character in the
file. I am taking the case of easiest way of encryption. in compiler,
parser has to read the source file and for every character decrement
it by 10 before passing the token to "lexical analyzer".


here end user never gets hand to the original source which is used to
generate target binary "sim"
it can be used by tools (largely simulators) which first generate
equivalent "c" code for a design and then compile it to generate a
simulate-able native binary. but the tools generating the equivalent
source code might not want to expose "c" code generated
 
S

sh.vipin

Do you already have a means of decrypting the files? If so, decrypt them
once and develop with unencrypted files. When finished, encrypt them again.

a simple offset scheme mentioned in one of my earlier post is also an
encryption scheme.
If not, why expect any compiler to have any idea what encryption scheme is
being used?
thinking too hard here. what if i also implement my decryption
function in a dll or shared library and ask the compiler to load it
before doing any parsing. this seems the worst of the solution but if
implementing it in that way and giving the decrypting function name as
an argument to compiler should work.
How do you edit the files, does your editor have the decryption built in?
i do not create them by hand. I generate them using a tool for a
specific need. i have a tool to do so.
What about include files? If you have (after decrypting) #include <stdio.h>
in your source, do you expect the compiler to have an encrypted version of
stdio.h, or would it accept plain text? How about #include "yourfile.h"?

well, that's a good point but a string can be placed in the beginning
of the file which will tell if file is decrypted or encrypted.
Whatever your solution turns out to be, I doubt it will involved modifying
gcc. More likely converting your input to C source code.
that is exactly i want to avoid.
thanks for bringing interesting points to the problem.
 
R

Richard

James Kuyper said:
It wouldn't be difficult to write a shell script wrapper for that
purpose, but it would necessarily create a temporary file (or at least
a pipe) that contains the decrypted version of the source code. That
might not be acceptable, depending upon exactly why he needs this
capability.

Moe than one because of includes and dependencies.

You would basically needs to Faraday Cage your compiler environment, and
decrypt the lot and then compile. Which is, lets face it, a much wiser
idea since theoretically any in process work being done after the
compiler has decrypted a file is accessible too.
 
E

Eric Sosman

Kojak said:
Le Thu, 19 Feb 2009 04:07:16 -0800 (PST),
(e-mail address removed) a écrit :


Unless you are completely paranoid (e.g. temp files issue when
compiling) you need juste an external program that take crypted
source, decrypt it and call the compiler. No need to tweak gcc. :)

If the start of a decrypted source file looks like

#include "encrypted.h"

.... there'll be need for more effort.
 
R

Richard

Chris Dollin said:
The includes could be spliced in-line into the decrypted output,
could they not?

Output? Did you mean input?

But my main point, which you snipped, remains.

,----
| You would basically needs to Faraday Cage your compiler environment, and
| decrypt the lot and then compile. Which is, lets face it, a much wiser
| idea since theoretically any in process work being done after the
| compiler has decrypted a file is accessible too.
`----

Assuming this is a high security thing. At the end of the day the
translation units do have to be decrypted for the compiler to work and
so then its a case of balancing the risks of the different approaches.

I have done some work for Government agencies btw where compilations and
source code security were quite important and suitably secured.
 
E

Eric Sosman

Chris said:
[...]
The includes could be spliced in-line into the decrypted output,
could they not?

That would require a decryptor with most of the power
of the preprocessor: Able to parse #include lines (possibly
with macros), able to evaluate #ifdef and #if and so on,
searching for inclusions in the same places the compiler
would (taking the compiler's flags into account), generating
#line directives ...

Some of this power might not be needed in the O.P.'s
scenario (he might know that his generated code doesn't
use #ifdef, for example), but he hasn't said what features
of C he's willing to forgo.

It seems to me the O.P. is looking at the wrong piece
of the tool chain. An encrypted file system on a RAM disk
seems more suitable, putting the protect-the-source burden
on the compiler's environment rather than on the compiler
itself.

It also seems to me that the O.P.'s quest is ultimately
futile, since the Black Hats can replace his gcc with a
hacked version of their own, one that simply copies the
decrypted source to somewhere else. Perhaps it's time to
take a step back and ponder the reasons for wanting to shield
the source, and how much effort they justify.
 
R

Richard

Eric Sosman said:
Chris said:
[...]
The includes could be spliced in-line into the decrypted output,
could they not?

That would require a decryptor with most of the power
of the preprocessor: Able to parse #include lines (possibly
with macros), able to evaluate #ifdef and #if and so on,
searching for inclusions in the same places the compiler
would (taking the compiler's flags into account), generating
#line directives ...

Some of this power might not be needed in the O.P.'s
scenario (he might know that his generated code doesn't
use #ifdef, for example), but he hasn't said what features
of C he's willing to forgo.

It seems to me the O.P. is looking at the wrong piece
of the tool chain. An encrypted file system on a RAM disk
seems more suitable, putting the protect-the-source burden
on the compiler's environment rather than on the compiler
itself.

It also seems to me that the O.P.'s quest is ultimately
futile, since the Black Hats can replace his gcc with a
hacked version of their own, one that simply copies the
decrypted source to somewhere else. Perhaps it's time to
take a step back and ponder the reasons for wanting to shield
the source, and how much effort they justify.

Or lock it all up in a Faraday Cage......

Simple.
 
C

Chris Dollin

Richard said:
Output? Did you mean input?

No; I said output (of the temporary file creating process) and I
meant output (ditto). It's then /used/ as the input to the compiler,
I'll grant. But that's not what I meant.
But my main point, which you snipped, remains.

I was not critiquing that; there's no need for you to repeat it.
 
N

Nate Eldredge

exactly, an standalone wrapper will also have to generate some
decrypted file. which i don't want
as far as the usage is concerned it can be used as following

system("gcc -decrypt--offset "10" a.c" -o sim);

here a.c is an encrypted file. integer value 10 is an offset to every
character value i.e. character 'a' becomes 'a'+10 th character in the
file. I am taking the case of easiest way of encryption. in compiler,
parser has to read the source file and for every character decrement
it by 10 before passing the token to "lexical analyzer".

If you insist that decrypted data never hits the file system, it
wouldn't even be enough to splice your decryption into gcc's input
routines. Various passes of gcc create temporary files with
intermediate representations of the code, the most obvious being the
output of the preprocessor, which is almost as good as the original
source. Using the -pipe option might help if your system supports it,
but I wouldn't count on it.
here end user never gets hand to the original source which is used to
generate target binary "sim"
it can be used by tools (largely simulators) which first generate
equivalent "c" code for a design and then compile it to generate a
simulate-able native binary. but the tools generating the equivalent
source code might not want to expose "c" code generated

But if the user can run this toolchain, he can also hack the given
decrypting copy of gcc to get it to output the source after it's
decrypted. You can't win.

The closest you can come, I think, is to obfuscate the C source to make
it hard to read. There are tools to do this, but I won't say more
because I object to such things on principle.
 
W

Walter Banks

There are quite a few compilers that have encrypted output
for use with smart cards and military applications. Encrypted
source for security has lots of implementation problems.

Simple encryption is pointless. Hard encryption of source
has lots of weaknesses that can be exploited. (debug
information, symbol table references, and code image)

Regards,
 
R

Richard

Chris Dollin said:
No; I said output (of the temporary file creating process) and I
meant output (ditto). It's then /used/ as the input to the compiler,
I'll grant. But that's not what I meant.


I was not critiquing that; there's no need for you to repeat it.

I repeated it because I felt you had glossed over it as inconsequential
- that any pre/post encryption cross over causes leaks and makes the
rest of the conversation pretty much a moot point.

You very mention of "decrypted output" is the security hole.
 
B

Bertrand Mollinier Toublet

exactly, an standalone wrapper will also have to generate some
decrypted file. which i don't want
as far as the usage is concerned it can be used as following

system("gcc -decrypt--offset "10" a.c" -o sim);

here a.c is an encrypted file. integer value 10 is an offset to every
character value i.e. character 'a' becomes 'a'+10 th character in the
file. I am taking the case of easiest way of encryption. in compiler,
parser has to read the source file and for every character decrement
it by 10 before passing the token to "lexical analyzer".


here end user never gets hand to the original source which is used to
generate target binary "sim"

That is pretty naive of you to assume.
Whatever you are considering, the "encrypted" source file will have to
be "decrypted", if only into the running compiler's memory. The
decrypted source file can be captured there.

Additionally, in the scheme you are proposing, the key to decrypt the
source file is passed to the compiler (and therefore exposed to the
user). This means that the use is now able to "decrypt" the encrypted
source file by using the exposed key with the encryption algorithm.

If this is the point where you indicate that "of course" the algorithm
in question is secret, I suggest you read up on cryptography a little
and understand why "secret algorithms" are largely antithetic with
strong, practically unbreakable, algorithms.



To summarize, it sounds like your threat model is that which DRM systems
attempt to address (the attacker is the user). There is much more to
those systems than just encrypting the asset that you want to protect.
It may be worth reflecting about the worth you are putting on keeping
your source files from your users and weigh that against the cost of
protecting said files.
 
C

Chris McDonald

Is there any C Compiler that accepts encrypted source files. That is
something which may take decryption key and source file as an input
and generates the object code after decrypting the source file
internally.

Is there a reason that you asked this question, here, rather than reading
the response already given to your identical question that you posted
earlier in other groups ??
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top