in reply to Re^15: What happened to perlcc?
in thread What happened to perlcc?

$ perl perlc.pl a.pl -key password -exe a
Out: a.c
Exe: a

$ gdb a
...
(gdb) start
Temporary breakpoint 1 at 0x8062cc5
Starting program: /tmp/eric/b/a 

Temporary breakpoint 1, 0x08062cc5 in main ()
(gdb) disassemble
Dump of assembler code for function main:
...
0x08062df0 <main+302>:  movl   $0x1,0x4(%esp)
0x08062df8 <main+310>:  movl   $0x8167020,(%esp)
0x08062dff <main+317>:  call   0x8075b30 <Perl_eval_pv>
...
End of assembler dump.
(gdb) break *0x08062dff
Breakpoint 2 at 0x8062dff
(gdb) continue
Continuing.

Breakpoint 2, 0x08062dff in main ()
(gdb) printf "%s", 0x8167020
# Super secret!
print("Hello World\n");

[download]

Took me 6 minutes to figure out, and I've never used gdb or this assembler language.

If bleached, follow up with unbleach.pl.

Update: Oops, I have used gdb to get a backtrace of a segfaulting process. I never used any of the commands uses here, though.

Replies are listed 'Best First'.
Re^17: What happened to perlcc?
by jdporter (Paladin) on Mar 03, 2011 at 16:20 UTC

    And this is precisely why ikegami has a well-deserved reputation as one who rocks. Very, very hard.

[reply]
      Oh come on, this isn't "WUB" connection
[reply]
Re^17: What happened to perlcc?
by daveola (Sexton) on Mar 05, 2011 at 06:23 UTC
    Great! I'm glad that you are a capable enough programmer that you are able to figure that out. As I mentioned in the home page, anyone capable enough *will* be able to extract the code. But do you honestly believe that the casual user will be able to do that? I don't even think that most users, looking at what you've done, would be able to figure out how to do this for a generic script. If anything, you've demonstrated how much knowledge is required to get to that point.

    In fact, the first reply to your post was to state that this is exactly why you rock. So clearly this is not an easy task for the casual user. My comment on the home page still stands:

      Besides, if you make it hard enough to get to the code, than the person talented enough to extract it will probably be fully capable to write it themselves and won't bother. :)

    Secondly, I've been told multiple times that I am misleading people. I write a simple tool and put up on the docs about the tool about all of it's shortcomings, and somehow I am misleading people. If anyone can show me where I'm misleading people, I'd love to know.

    I highly recommend that people who don't believe in closed source should not use my script. And if they choose to attack it, please feel free to do so on the ethical issues of open/closed source.

    I highly recommend that people who want their code completely secure do NOT use my script. Then again, even if they choose to use a compiled language such as C, there are ways to disassemble C and even convert it back into C code.

    I highly recommend that anyone who is comfortable with hiding their script from casual users, feel free to use perlc! And if they want something stronger than Bleach and the weak encryption that perlc offers, then they can obfuscate in some other manner, and yes, anyone who is able to run a debugger and deal with assembly will be able to get your code. There isn't anything you can do about that. You can dust off perlcc and get it working, and even then someone smart enough will be able to effectively reconstruct your code from that.

    There is no guaranteed answer to hiding your code. That's a fact. I never claimed to have the answer to that. All I claimed is to write this:

      Regardless, it IS possible to wrap your perl script into a C program that evals the script in a perl interpretor,

    And that's all.

    Sorry you didn't like my script. Sorry it didn't live up to your standards. You're welcome to write something better. :)

[reply]

      But do you honestly believe that the casual user will be able to do that?

      Yes. Especially since I just showed them how to do it.

      Do you know how safes are rated? Based on how long it takes to break into them. The point of a safe is to delay the attacker long enough for other measures to take effect (such as the cops responding to the alarm).

      The same applies here. The purpose of hiding code is to make it cost prohibitive for someone to use the code instead of writing it from scratch. perlc doesn't do that.

      Secondly, I've been told multiple times that I am misleading people.

      That may be, but not by me. My comments have been about the tool, not you. Besides, I believe you think your tool has worth.

      I highly recommend that anyone who is comfortable with hiding their script from casual users, feel free to use perlc!

      I highly recommend that noone use perlc. The recommendation isn't based on politics; it's purely a comment on the quality of perlc.

      there are ways to disassemble C and even convert it back into C code.

      Ok, let's compare perlc against C decompilation. (It's not disassembly if it doesn't produce assembler.) perlc returns the original code intact. Decompilation loses formatting, comments, variable names, function names, function calls, etc, etc. By your own metric, perlc fails miserably.

      There is no guaranteed answer to hiding your code.

      Noone has faulted it for not doing that.

      You're welcome to write something better. :)

      No thanks. This is based on politics.

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom