any compiler that takes encrypted input

Discussion in 'C Programming' started by sh.vipin@gmail.com, Feb 19, 2009.

  1. Guest

    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
     
    , Feb 19, 2009
    #1
    1. Advertising

  2. Guest


    >
    > 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
     
    , Feb 19, 2009
    #2
    1. Advertising

  3. Bartc Guest

    <> wrote in message
    news:...
    >
    >>
    >> 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
     
    Bartc, Feb 19, 2009
    #3
  4. Kojak Guest

    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.
     
    Kojak, Feb 19, 2009
    #4
  5. James Kuyper Guest

    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.
     
    James Kuyper, Feb 19, 2009
    #5
  6. Guest


    > 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
     
    , Feb 19, 2009
    #6
  7. Guest


    > 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
     
    , Feb 19, 2009
    #7
  8. Richard Guest

    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.
     
    Richard, Feb 19, 2009
    #8
  9. Eric Sosman Guest

    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
     
    Eric Sosman, Feb 19, 2009
    #9
  10. Chris Dollin Guest

    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
     
    Chris Dollin, Feb 19, 2009
    #10
  11. Richard Guest

    Chris Dollin <> writes:

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


    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.
     
    Richard, Feb 19, 2009
    #11
  12. Eric Sosman Guest

    Chris Dollin wrote:
    > [...]
    > 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.

    --
    Eric Sosman
    lid
     
    Eric Sosman, Feb 19, 2009
    #12
  13. Richard Guest

    Eric Sosman <> writes:

    > Chris Dollin wrote:
    >> [...]
    >> 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.
     
    Richard, Feb 19, 2009
    #13
  14. Chris Dollin Guest

    Richard wrote:

    > Chris Dollin <> writes:
    >
    >> 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?

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

    --
    "It's just the beginning we've seen." - Colosseum, /Tomorrow's Blues/

    Hewlett-Packard Limited Cain Road, Bracknell, registered no:
    registered office: Berks RG12 1HN 690597 England
     
    Chris Dollin, Feb 19, 2009
    #14
  15. Chris Dollin Guest

    Richard wrote:

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


    Arms race.

    --
    "If I were you, I would go to the crackpots." /They Shall Have Stars/

    Hewlett-Packard Limited Cain Road, Bracknell, registered no:
    registered office: Berks RG12 1HN 690597 England
     
    Chris Dollin, Feb 19, 2009
    #15
  16. "" <> writes:

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


    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.
     
    Nate Eldredge, Feb 19, 2009
    #16
  17. Walter Banks Guest

    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,

    --
    Walter Banks
    Byte Craft Limited
    http://www.bytecraft.com





    "" wrote:

    > 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
     
    Walter Banks, Feb 19, 2009
    #17
  18. Richard Guest

    Chris Dollin <> writes:

    > Richard wrote:
    >
    >> Chris Dollin <> writes:
    >>
    >>> 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?

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


    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.
     
    Richard, Feb 19, 2009
    #18
  19. wrote:
    >> 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"


    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.
    --
    "Relax, kick back, and have a nice big frosty mug full of STFU."
    -Re:Animator/NANAE/9-3-07
     
    Bertrand Mollinier Toublet, Feb 19, 2009
    #19
  20. "" <> writes:

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

    --
    Chris.
     
    Chris McDonald, Feb 20, 2009
    #20
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    0
    Views:
    345
  2. Merciadri Luca
    Replies:
    5
    Views:
    1,091
    Merciadri Luca
    Oct 14, 2010
  3. Shivanand Kadwadkar
    Replies:
    1
    Views:
    278
    Eric Sosman
    Jan 9, 2011
  4. Paul
    Replies:
    1
    Views:
    112
    Sebastian Hungerecker
    Apr 24, 2007
  5. Dann Corbit
    Replies:
    7
    Views:
    977
    Jorgen Grahn
    Jul 13, 2012
Loading...

Share This Page