Hi All,
I have converted the perl script to perl executable using perlcc .So
Now I want to convert perl executable to perl script. Is there any way
to do this...?
No.
I remember compiling my first C program in 1992, cc -o code.c code.c, and then wondering where my source-code disappeared to. (If this is what you did, restore from backups. No backups? Well, think about doing backups.) No, it's not possible. You might be able to work out the algorithm by studying the binary very very carefully, but it's unlikely to help. It would probably be easier to rewrite the application from scratch.
best way to convert perl and all script to exe stand alone file use htwoo project in sourceforge.net
download project link :
http://downloads.sourceforge.net/project/htwoo/Hadi-Kiamarsi-HTWOO-2.rar?r=&ts=1363693006&use_mirror=freefr
download tutorial movie :
http://youtu.be/UQVuFQX4uOo
Related
How to download the p4.pm(perforce) module for Perl script?
Is it possible to use modules without installing them?
How to download
https://swarm.workshop.perforce.com/projects/p4perl/archives/main.zip
Is it possible to use modules without installing them?
Yes, see blib. What's the point, though? The code has to sit somewhere as a file so that Perl is able to read it, then it might as well be in the intended installation directories so that manipulating the include path becomes unnecessary.
I have a perl program that I want to convert into a bioperl module. How do I do that? Is there an up-to date tutorial? That's really all I need.
Thank you.
For module naming conventions and other information (whether you're writing it for CPAN or not), start with perlnewmod. To make an actual module, first install Module::Starter and use module-starter command line utility to create your skeleton.
I have a perl script that is encrypted. This script can be compiled only if Filter::decrypt is installed. I have that Filter and I installed it and the script is compiled with no problem, but now I want to open that script with some text editor and edit it.
Can someone help me and tell me how can I do this?
Pretty fundamentally - it's extremely difficult to make a script unreadable, simply because perl is an interpreted language. Exactly how to disentangle something is more a question of how it got tangled in the first place.
So I would suggest as a first port of call - have a look through Mastering Perl which has a whole chapter on the subject of disassembling perl code.
However if you just look at the Filter::decrypt module page, it indicates several places which the module simply cannot cover - you can only truly 'protect' code if you've control of the perl interpreter in the first place. However the things it suggests are:
Strip the Perl binary to remove all symbols.
Build the decrypt extension using static linking. If the extension is provided as a dynamic module, there is nothing to stop someone from linking it at run time with a modified Perl binary.
Do not build Perl with -DDEBUGGING. If you do then your source can be retrieved with the -Dp command line option.
The sample filter contains logic to detect the DEBUGGING option.
Do not build Perl with C debugging support enabled.
Do not implement the decryption filter as a sub-process (like the cpp source filter). It is possible to peek into the pipe that connects to the sub-process.
Check that the Perl Compiler isn't being used.
There is code in the BOOT: section of decrypt.xs that shows how to detect the presence of the Compiler. Make sure you include it in your module.
Assuming you haven't taken any steps to spot when the compiler is in use and you have an encrypted Perl script called "myscript.pl", you can get access the source code inside it using the perl Compiler backend, like this
perl -MO=Deparse myscript.pl
Note that even if you have included the BOOT: test, it is still possible to use the Deparse module to get the source code for individual subroutines.
So:
perl -MO=Deparse yourscript
perl -Dp yourscript
If these don't work - look at your local copy of Filter::decrypt and alter it so it prints the decrypted result.
Best option: Just edit your unencrypted copy and reinstall it.
Alternative: Use decr (comes with Filter::decrypt) to decrypt an encrypted file.
I was using PAR::Packer and this question popped up in my mind. How does PAR::Packer work in Perl? Does it actually compile the Perl script to .exe like g++ compiles C++ Sources to .exe or does it work like py2exe in Python that packs the interpreter and the script into an .exe?
To make this absolutely clear:
Tools like PAR::Packer do not “compile” your Perl script. They bundle the perl interpreter together with your source files and any required modules into a big fat executable file. When it is run, the original sources are extracted and fed to the enclosed perl.
This works reasonably well, but does not yield a speed improvement (on the contrary…). The only advantage is that you can distribute your programs as a single (albeit quite large) file, without dependencies.
There is a very experimental tool called perlcc that is able to translate some Perl programs to C or a Perl bytecode serialization. As the docs put it:
The code generated in this way is not guaranteed to work. The whole codegen suite (perlcc included) should be considered very experimental. Use for production purposes is strongly discouraged.
This is because the Perl language does not support static compilation. It needs to be able to execute code during parsing for some dynamic features during the same session where the main execution phase takes place.
There are other, commercial tools, that usually fall in the same category as PAR::Packer (creating fat executables).
Summary: If you want a single executable, use PAR::Packer. If you want speed, inline some C (or use XS). There is no tool that can compile all Perl scripts to machine code.
I was using PAR::Packer and this question popped up in my mind. How
does PAR::Packer work in Perl?
Does it actually compile the Perl
script to .exe like g++ compiles C++ Sources to .exe
no pp and perl2exe doesn't. (though pp is free).
but it looks like perlcc does
or does it work
like py2exe in Python that packs the interpreter and the script into
an .exe?
pp and perl2exe, yes
As an example- sendemail.exe that looks like something done in PAR Packer or Perl2exe
It packs the interpreter into the exe.
You can open sendemail.exe in 7-zip! There are some folders there but one can't really see it actual files.
I suppose it's some form of self extracting executable, but, that executes code.
You can monitor it with process monitor, and you see.
Or with, process explorer and see if it uses any dll from the temp directory that it creates..
It creates a temp directory e.g.
C:\Users\user\AppData\Local\Temp\pdk-user <--- Win7
or
C:\Documents and Settings\user\Local Settings\Temp\pdk-user <-- WinXP
The temporary directory it creates contains a bunch of strange named DLLs and a DLL called perl58.dll which is no doubt, the perl interpreter
I'm sure at one point I saw it had a dll there with a normal name. SSLEAY32.DLL and interestingly when I ran the pl file it used a dll with a similar name from my c:\perl64 directory. So the EXE looks like a bit of a hack really. It's more reliable to run the pl file directly.
DIR /s/b within that directory, shows-
178c2b604baa8a7f1ebc80539f378bff.dll
1823e8f62785746fd29cf0b06c636600.dll
465d2954d90fe6225ea61b3907c91da8.dll
6145f78a34d5ced8200800f1455d578a <-- the directory with the perl58. dll
9c50b5816b0e35f047e41f5899721d46.dll
f4e2e0db77ed1e6572c2f490479cd815.dll
f72f556d99dfb6b0c3bb37f123e2ee96.dll
6145f78a34d5ced8200800f1455d578a\perl58.dll
no normal named DLLs showing other than perl58.dll (though I have seen a normal one there in the past).
if you look in process explorer, you see it using perl58.dll and other normal named dlls
If you look at the PAR website, a page describes perl2exe
Perl2Exe is commercial, command-line application that can build
standalone executables from perl sources. It works by creating an
executable that contains
A standalone perl interpreter (that is capable of grokking perl 5.8.x)
Your perl script and All perl modules that are referenced by your perl
script.
pp - PAR Packager provides that same functionality, but is free.
And if you look here
http://www.perlmonks.org/?node_id=237943
...the perl2exe tool is not a way to hide your source code.
Now it's even come to the attention of the security community (reported in bugtraq, for example).
For details, see the report from net-security's page.
Please stop supporting perl2exe. Please use PAR for a complete installation package, or perlcc to simply compile the top-level program.
-- Randal L. Schwartz, Perl hacker
So, PP and perl2exe combine the interpreter into the EXE, And you can get an idea that there's something funny atypical about the EXE when it opens in 7zip!
perlcc compiles properly.
it appears to have been unmaintained for a while http://www.perlmonks.org/?node_id=654568 , people said it was buggy, but some work was done on it as recently as June 2014 http://www.yapcna.org/yn2014/talk/5603 It gets better performance than interpreted perl. (unlike the EXEs that pack an interpreter, which are slower than running a perl script normally).
I installed perl 5.14 version just before, when I executed script display errors perl58.dll missing. How can solve the problem..
how can I solve this problem?
It sounds to me that the thing you're describing as a 'perl script' is actually an executable built from a perl script using ActiveState's perlapp with the --dependent flag. By default, perlapp executables are self contained, but the perl{version number here}.dll can be left out to save space.
Possible courses of action (roughly in order of ease + sanity):
Get the original source from the guy who wrote it, & just run it.
Get the guy who wrote it to update the perlapp executable to a non-dependent version or a version that runs under your installed version of ActivePerl.
Pony up for ActiveState's 'business' subscription to download & install ActivePerl 5.8 (and no other version) on that machine.
Find a copy of the perl58.dll and place it where windows will find it. (may require subscription, or the guy who built the perlapp may have a copy lying about)
Extract the original script from within the .exe and either build a newer (and non-dependent) perlapp or just run it from the source as Larry intended.
Depending on what options were used to build the perlapp executable you may have the origional source lying about in a temp directory. Otherwise I believe you may be able to open it up with a program that understands .zip files, but I've never tried this.
It is also possible that you've got a directory in your path that contains a v5.8 perl.exe but not it's accompanying .dll and that you've asked your newly installed v5.14 perl not to place its directories at the beginning of your path. I don't expect this is the case.