Running program from uncompressed directory tree

Hi All,

how can I run a program directly from the *unpacked* file tree?

I just want to use PAR to bundle all dependencies to get a "portable"
Perl based Windows application, with dedicated unpacking instead of the
automatic "runtime" unpacking.

Thanks in advance,

Oliver
0
list_ob
5/7/2019 4:04:16 PM
perl.par 1166 articles. 0 followers. Follow

5 Replies
0 Views

Similar Articles

[PageSpeed] 45

--000000000000bec22b05885ae4cc
Content-Type: text/plain; charset="UTF-8"

On Tue, May 7, 2019, 18:09 Oliver Betz <list_ob@gmx.net> wrote:

>
> how can I run a program directly from the *unpacked* file tree?
>

TL;DR You can't


I just want to use PAR to bundle all dependencies to get a "portable"
> Perl based Windows application, with dedicated unpacking instead of the
> automatic "runtime" unpacking.
>

Can you elaborate on what you are trying to achieve?

Cheers, Roderich

>

--000000000000bec22b05885ae4cc
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D=
"gmail_attr">On Tue, May 7, 2019, 18:09 Oliver Betz &lt;<a href=3D"mailto:l=
ist_ob@gmx.net">list_ob@gmx.net</a>&gt; wrote:</div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex">
<br>
how can I run a program directly from the *unpacked* file tree?<br></blockq=
uote></div></div><div dir=3D"auto"><br></div><div dir=3D"auto">TL;DR You ca=
n&#39;t</div><div dir=3D"auto"><br></div><div dir=3D"auto"><div class=3D"gm=
ail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"></blockquote></div></div><div dir=
=3D"auto"><br></div><div dir=3D"auto"><div class=3D"gmail_quote"><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex">
I just want to use PAR to bundle all dependencies to get a &quot;portable&q=
uot;<br>
Perl based Windows application, with dedicated unpacking instead of the<br>
automatic &quot;runtime&quot; unpacking.<br></blockquote></div></div><div d=
ir=3D"auto"><br></div><div dir=3D"auto">Can you elaborate on what you are t=
rying to achieve?</div><div dir=3D"auto"><br></div><div dir=3D"auto">Cheers=
, Roderich</div><div dir=3D"auto"><div class=3D"gmail_quote"><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex">
</blockquote></div></div></div>

--000000000000bec22b05885ae4cc--
0
roderich
5/8/2019 7:00:39 AM
Hi Roderich,

first, I would like to thank you for maintaining PAR!

[...]

>     I just want to use PAR to bundle all dependencies to get a "portable=
"
>     Perl based Windows application, with dedicated unpacking instead of =
the
>     automatic "runtime" unpacking.
>
> Can you elaborate on what you are trying to achieve?

I want to avoid the automatic unpacking, especially below the temp
directory. BTW, I'm using Windows.

Unpacking and running executables in temp is considered suspicious by AV
products, and it can be a security risk: Consider a widespread program
like ExifTool: Malware can easily find the runtime files and infect them
without elevated rights.

The Windows standards suggest to make exectuables write protected.

Unpacking the runtime files in a dedicated step seems to be a natural
solution to me. That's how most (portable) programs are "installed".

A PAR archive seems to contain (nearly?) everything to run the program
(Perl interpreter, libraries, DLLs etc.) so I think it would be great if
I just could unpack it to a directory of my choice and run the
application directly from there.

Oliver
0
list_ob
5/8/2019 7:37:32 AM
--000000000000c672380588653cb7
Content-Type: text/plain; charset="UTF-8"

On Wed, May 8, 2019 at 9:42 AM Oliver Betz <list_ob@gmx.net> wrote:

> ...

Consider a widespread program
> like ExifTool: Malware can easily find the runtime files and infect them
> without elevated rights.
>

So what?

The Windows standards suggest to make exectuables write protected.
>
>
Bullshit advice. If the files are owned by the user, the malware can
unprotect them.

Unpacking the runtime files in a dedicated step seems to be a natural
> solution to me. That's how most (portable) programs are "installed".
>
>
If they can be installed by the user (i.e. without "admin" rights), this
gains you nothing.

A PAR archive seems to contain (nearly?) everything to run the program
> (Perl interpreter, libraries, DLLs etc.)
>

What do you consider a "PAR archive"? In PAR lingo this is a .par file,
actually a zip file
with a certain directory structure. It may contain Perl modules (including
"glue" DLLs for
XS modules) and data. It does *not* include a Perl interpreter. In fact,
you need
a core Perl installation + Archive::Zip to make use of it.

If you don't to use the standalone executables generated by "pp -o ..." and
rather go
for a classic installer approach, fine. But PAR::Packer is not of much help
for this.
You may want its dependency resolution (what modules are used by your
program,
what modules are used in turn by these modules etc), but that is provided
by Module::ScanDeps.

Cheers, Roderich

--000000000000c672380588653cb7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div>On Wed, May 8, 2019 at 9:42 AM =
Oliver Betz &lt;<a href=3D"mailto:list_ob@gmx.net">list_ob@gmx.net</a>&gt; =
wrote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin=
g-left:1ex">...=C2=A0</blockquote><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex">Consider a widespread program<br>
like ExifTool: Malware can easily find the runtime files and infect them<br=
>
without elevated rights.<br></blockquote><div><br></div><div>So what?</div>=
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
The Windows standards suggest to make exectuables write protected.<br>
<br></blockquote><div><br></div><div>Bullshit advice. If the files are owne=
d by the user, the malware can unprotect them.</div><div><br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px=
 solid rgb(204,204,204);padding-left:1ex">
Unpacking the runtime files in a dedicated step seems to be a natural<br>
solution to me. That&#39;s how most (portable) programs are &quot;installed=
&quot;.<br>
<br></blockquote><div><br></div><div>If they can be installed by the user (=
i.e. without &quot;admin&quot; rights), this gains you nothing.</div><div> =
<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
A PAR archive seems to contain (nearly?) everything to run the program<br>
(Perl interpreter, libraries, DLLs etc.) <br></blockquote><div><br></div><d=
iv>What do you consider a &quot;PAR archive&quot;? In PAR lingo this is a .=
par file, actually a zip file</div><div>with a certain directory structure.=
 It may contain Perl modules (including &quot;glue&quot; DLLs for</div><div=
>XS modules) and data. It does <b>not</b> include a Perl interpreter. In fa=
ct, you need</div><div>a core Perl installation + Archive::Zip to make use =
of it.</div><div><br></div><div>If you don&#39;t to use the standalone exec=
utables generated by &quot;pp -o ...&quot; and rather go</div><div>for a cl=
assic installer approach, fine. But PAR::Packer is not of much help for thi=
s.<br></div><div>You may want its dependency resolution (what modules are u=
sed by your program,</div><div>what modules are used in turn by these modul=
es etc), but that is provided</div><div>by Module::ScanDeps.</div><div><br>=
</div><div>Cheers, Roderich<br></div><div><br></div><div><br></div></div></=
div>

--000000000000c672380588653cb7--
0
roderich
5/8/2019 7:21:05 PM
Roderich Schupp wrote:

[...]

>     The Windows standards suggest to make exectuables write protected.
>
> Bullshit advice. If the files are owned by the user, the malware can
> unprotect them.

with the correct ACL, a restricted user cannot modify the files
unnoticed (needs at least to confirm in the UAC dialog).

>     Unpacking the runtime files in a dedicated step seems to be a natura=
l
>     solution to me. That's how most (portable) programs are "installed".
>
> If they can be installed by the user (i.e. without "admin" rights), this
> gains you nothing.

The user needs to run the installer with elevated rights, which requires
confirming the UAC dialog or logging in as admin. On my machine, I can't
write to "C:\Program Files" from my working account. I need admin rights
to write there. Well, you can weaken the UAC settings.

In business environments, it can be even enforced by a SRP that
executables can be executed only from protected locations.

>     A PAR archive seems to contain (nearly?) everything to run the progr=
am
>     (Perl interpreter, libraries, DLLs etc.)
>
> What do you consider a "PAR archive"? In PAR lingo this is a .par file,
> actually a zip file

Sorry for using the wrong terms...

> If you don't to use the standalone executables generated by "pp -o ..."

....I actually mean the content of the executable created by pp -o.

As far as I see, this exe contains an archive with all dependencies
including the Perl interpreter, the unpacker and a small stub to call
the interpreter, correct?

On the first run, the archive contents are unpacked somewhere.
Alternatively, I can use my preferred unpacker to extract the files
directly from the exe.

What would be wrong with executing this unpacked stuff directly, without
the "auto unpacking to temp" magic?

What do I need to run it?

Oliver
0
list_ob
5/8/2019 8:58:37 PM
--000000000000a918e7058871d88e
Content-Type: text/plain; charset="UTF-8"

 Hello everybody,

I would like to point out that the issue presented by Oliver is quite
common nowadays. I know of business environments where the security
settings do not allow - in the entire company IT infrastructure - to launch
any application from the temp directory, for example. In these cases, I
simply could not use the executable generated by pp. I have the feeling
that these restrictions are getting more and more common, so a more
flexible solution for pp could be very useful.

Best
Welle

Am Mi., 8. Mai 2019 um 22:58 Uhr schrieb Oliver Betz <list_ob@gmx.net>:

> Roderich Schupp wrote:
>
> [...]
>
> >     The Windows standards suggest to make exectuables write protected.
> >
> > Bullshit advice. If the files are owned by the user, the malware can
> > unprotect them.
>
> with the correct ACL, a restricted user cannot modify the files
> unnoticed (needs at least to confirm in the UAC dialog).
>
> >     Unpacking the runtime files in a dedicated step seems to be a natural
> >     solution to me. That's how most (portable) programs are "installed".
> >
> > If they can be installed by the user (i.e. without "admin" rights), this
> > gains you nothing.
>
> The user needs to run the installer with elevated rights, which requires
> confirming the UAC dialog or logging in as admin. On my machine, I can't
> write to "C:\Program Files" from my working account. I need admin rights
> to write there. Well, you can weaken the UAC settings.
>
> In business environments, it can be even enforced by a SRP that
> executables can be executed only from protected locations.
>
> >     A PAR archive seems to contain (nearly?) everything to run the
> program
> >     (Perl interpreter, libraries, DLLs etc.)
> >
> > What do you consider a "PAR archive"? In PAR lingo this is a .par file,
> > actually a zip file
>
> Sorry for using the wrong terms...
>
> > If you don't to use the standalone executables generated by "pp -o ..."
>
> ...I actually mean the content of the executable created by pp -o.
>
> As far as I see, this exe contains an archive with all dependencies
> including the Perl interpreter, the unpacker and a small stub to call
> the interpreter, correct?
>
> On the first run, the archive contents are unpacked somewhere.
> Alternatively, I can use my preferred unpacker to extract the files
> directly from the exe.
>
> What would be wrong with executing this unpacked stuff directly, without
> the "auto unpacking to temp" magic?
>
> What do I need to run it?
>
> Oliver
>

--000000000000a918e7058871d88e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">
<div>Hello everybody,</div><div><br></div><div>I would like to point out th=
at the issue presented by Oliver is quite common nowadays. I know of busine=
ss environments where the security settings do not allow - in the entire co=
mpany IT infrastructure - to launch any application from the temp directory=
, for example. In these cases, I simply could not use the executable genera=
ted by pp. I have the feeling that these restrictions are getting more and =
more common, so a more flexible solution for pp could be very useful.</div>=
<div><br></div><div>Best</div><div>Welle<br></div>

</div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">=
Am Mi., 8. Mai 2019 um 22:58=C2=A0Uhr schrieb Oliver Betz &lt;<a href=3D"ma=
ilto:list_ob@gmx.net">list_ob@gmx.net</a>&gt;:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">Roderich Schupp wrote:<br>
<br>
[...]<br>
<br>
&gt;=C2=A0 =C2=A0 =C2=A0The Windows standards suggest to make exectuables w=
rite protected.<br>
&gt;<br>
&gt; Bullshit advice. If the files are owned by the user, the malware can<b=
r>
&gt; unprotect them.<br>
<br>
with the correct ACL, a restricted user cannot modify the files<br>
unnoticed (needs at least to confirm in the UAC dialog).<br>
<br>
&gt;=C2=A0 =C2=A0 =C2=A0Unpacking the runtime files in a dedicated step see=
ms to be a natural<br>
&gt;=C2=A0 =C2=A0 =C2=A0solution to me. That&#39;s how most (portable) prog=
rams are &quot;installed&quot;.<br>
&gt;<br>
&gt; If they can be installed by the user (i.e. without &quot;admin&quot; r=
ights), this<br>
&gt; gains you nothing.<br>
<br>
The user needs to run the installer with elevated rights, which requires<br=
>
confirming the UAC dialog or logging in as admin. On my machine, I can&#39;=
t<br>
write to &quot;C:\Program Files&quot; from my working account. I need admin=
 rights<br>
to write there. Well, you can weaken the UAC settings.<br>
<br>
In business environments, it can be even enforced by a SRP that<br>
executables can be executed only from protected locations.<br>
<br>
&gt;=C2=A0 =C2=A0 =C2=A0A PAR archive seems to contain (nearly?) everything=
 to run the program<br>
&gt;=C2=A0 =C2=A0 =C2=A0(Perl interpreter, libraries, DLLs etc.)<br>
&gt;<br>
&gt; What do you consider a &quot;PAR archive&quot;? In PAR lingo this is a=
 .par file,<br>
&gt; actually a zip file<br>
<br>
Sorry for using the wrong terms...<br>
<br>
&gt; If you don&#39;t to use the standalone executables generated by &quot;=
pp -o ...&quot;<br>
<br>
....I actually mean the content of the executable created by pp -o.<br>
<br>
As far as I see, this exe contains an archive with all dependencies<br>
including the Perl interpreter, the unpacker and a small stub to call<br>
the interpreter, correct?<br>
<br>
On the first run, the archive contents are unpacked somewhere.<br>
Alternatively, I can use my preferred unpacker to extract the files<br>
directly from the exe.<br>
<br>
What would be wrong with executing this unpacked stuff directly, without<br=
>
the &quot;auto unpacking to temp&quot; magic?<br>
<br>
What do I need to run it?<br>
<br>
Oliver<br>
</blockquote></div>

--000000000000a918e7058871d88e--
0
par
5/9/2019 10:24:01 AM
Reply: