pp on Win32: Signing executable inside package (it's a question, not a bug)

[assysttest]

Hi, At first something about the intension of my request. A win32 executable made by pp will create a subfolder with temporary files and an executable inside. This executable with the name of the self extracting archive will be started after extraction. I've the request to sign this inner executable by signtool. Otherwise the execution is blocked by some security rules. The executable is not part of the archive, it is made by another way. I see that the executable is always the same for different perl scripts, only the name is changed. I've some experiences with problems caused by different icon size. When I exchange myldr\winres\pp.ico by a file with a different size the executable may crash. With this background I expect that the exe file is made during extraction and that there are some magic numbers used for the size of the executable. I suppose I've to look deep inside in the code of the packer to get a signed file in the cache folder. Now I'm looking for an entry point. Can you give me some hints:

• I did not found a detailed description for the tasks of some modules/functions, the build process of the archive and the creation of the executable in the cahe folder. Do you have such a description? Where to look at first if such a description not exists?
• Is there something like a template for the inner executable which can be signed? And a "magic number" to define the size of this template? How to change this template (if it exists)?

Thank you for an answer. Bye Torsten

[rschupp]

I suppose I've to look deep inside in the code of the packer to get a signed file in the cache folder.

The file you're looking for is myldr/par.exe (when building PAR::Packer) - this is the executable in the cache folder with the same name as the packed executable. When you modify it (e.g. using signtool on it) after building (and installing) PAR::Packer, you must rerun make and make install afterwards. That is necessary as myldr/par.exe is stuffed (as a byte array) into boot.exe which in turn is transformed into PAR::StrippedPARL::Static (or PAR::StrippedPARL::Dynamic, can't remember which) which is used by pp to construct the packed executable.

I've some experiences with problems caused by different icon size. When I exchange myldr\winres\pp.ico by a file with a different size the executable may crash. With this background I expect that the exe file is made during extraction and that there are some magic numbers used for the size of the executable.

There are no magic numbers, myldr/par.exe is extracted as is. myldr/winres/pp.ico is added to this file with the winres utility and PAR::Packer doesn't care about it. Check Microsoft docs what size of icons is allowed for it.

[rschupp]

Thinking a bit more about this signing business... There's a problem with the --gui of pp. This option changes a byte in the object header of the packed executable so that Windows will run it without a console window. But that doesn't work for the embedded copy of myldr/par.exe. So after the packed executable has extracted this copy into the cache folder it examines its own header byte and patches the copy to match it. If the copy was signed this will invalidate the signature ☹️

[assysttest]

Hi Roderich, you are right, of course. The loader in the DATA section has some general disadvantages:

• Signing is difficult
• Changing of icon is impossible during pack operation (I spent some time to have the right icons in task bar, in the app window and the task manager)
• Version information is fix

A solution would be an option for an universal exe manipulation tool. This can change the icon, sign the loader, insert version number and copyright information and so on. When I understand the code right, in PAR\StrippedPARL\Base.pm you write the content of the exe into a file. May be it is possible to use this point to start a customer exe processor to do all this tasks and patch the exe to avoid a console window.

Bye Torsten

---

Dr. Ing. Torsten Werner | Product Manager plan.assyst E-Mail: @.*** P +49 89 905050 | F +49 89 90505-271

Assyst GmbH | Max-Planck-Str. 3 | 85609 Aschheim-Dornach Registration / Eintragung beim Amtsgericht München: HRB 180174 Managing Director / Geschäftsführer: Hans Peter Hiemer www.assyst.de

Von: Roderich Schupp @.> An: rschupp/PAR-Packer @.>, Kopie: assysttest @.>, Author @.> Datum: 04.05.2023 15:33 Betreff: Re: [rschupp/PAR-Packer] pp on Win32: Signing executable inside package (it's a question, not a bug) (Issue #73)

Thinking a bit more about this signing business... There's a problem with the --gui of pp. This option changes a byte in the object header of the packed executable so that Windows will run it without a console window. But that doesn't work for the embedded copy of myldr/par.exe. So after the packed executable has extracted this copy into the cache folder it examines its own header byte and patches the copy to match it. If the copy was signed this will invalidate the signature ☹️ — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

[assysttest]

Hi Roderich, I had a look in the code and I saw that it is not so easy to change the par.exe during packaging. It's finally too complicated. On the other hand I need this --gui option qite often. I think I've a solution. Really not nice, but it solves my problem.

I can sign par.exe and I get a signed par.exe in the archive, the signature is valid. Now I can install the PAR in a non-default folder.

In a second step I patch par.exe to get a gui app (like your do it in _fix_console), sign it again and create a second PAR in anoter folder.

Now it is a question of @INC to load the right PAR version, with or without console window. This is quite simple, I use a wrapper for pp. When ever there is a chance to have a good solution for this issue it would be great.

Bye, thank you and have a nice weekend Torsten

---

Dr. Ing. Torsten Werner | Product Manager plan.assyst E-Mail: @.*** P +49 89 905050 | F +49 89 90505-271

Assyst GmbH | Max-Planck-Str. 3 | 85609 Aschheim-Dornach Registration / Eintragung beim Amtsgericht München: HRB 180174 Managing Director / Geschäftsführer: Hans Peter Hiemer www.assyst.de

Von: Roderich Schupp @.> An: rschupp/PAR-Packer @.>, Kopie: assysttest @.>, Author @.> Datum: 04.05.2023 15:33 Betreff: Re: [rschupp/PAR-Packer] pp on Win32: Signing executable inside package (it's a question, not a bug) (Issue #73)

Thinking a bit more about this signing business... There's a problem with the --gui of pp. This option changes a byte in the object header of the packed executable so that Windows will run it without a console window. But that doesn't work for the embedded copy of myldr/par.exe. So after the packed executable has extracted this copy into the cache folder it examines its own header byte and patches the copy to match it. If the copy was signed this will invalidate the signature ☹️ — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

[rschupp]

Yeah, in effect you're creating GUI variants of PAR::StrippedParl::{Static,Dynamic} and use these variants when packing with --gui.

Cheers, Roderich