«

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.

--
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.

--
vipin

<> wrote in message
news:334a867b-dc5d-4db3-a546-...
>
>>
>> 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.

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.

--
Bartc

Le Thu, 19 Feb 2009 04:07:16 -0800 (PST),
a écrit :

>
> > 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.

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...

--
Jacques.

Richard Heathfield wrote:
> said:
>
>> 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.
>
> 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.

> 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

--
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.


--
vipin

James Kuyper <> writes:

> Richard Heathfield wrote:
>> said:
>>
>>> 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.
>>
>> 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.

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.

Kojak wrote:
> Le Thu, 19 Feb 2009 04:07:16 -0800 (PST),
> a écrit :
>
>>> 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.
>
> 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.

--
Eric Sosman
lid

Richard wrote:

> James Kuyper <> writes:
>
>> Richard Heathfield wrote:
>>> said:
>>>
>>>> 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.
>>>
>>> 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.
>
> Moe than one because of includes and dependencies.

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

--
"I don't make decisions. I'm a bird." /A Fine and Private Place/

Hewlett-Packard Limited registered no:
registered office: Cain Road, Bracknell, Berks RG12 1HN 690597 England