Beefy Boxes and Bandwidth Generously Provided by pair Networks
Don't ask to ask, just ask
 
PerlMonks  

How can I integrate within the PDK perlapp the manifest assembly workaround for Vista UAC?

by ddn123456 (Pilgrim)
on Apr 03, 2007 at 08:52 UTC ( [id://608007]=perlquestion: print w/replies, xml ) Need Help??

ddn123456 has asked for the wisdom of the Perl Monks concerning the following question:

PDK: how can I integrate the manifest assembly workaround for Vista UAC?

Hi,

Summarised. I need to workaround Vista's UAC on a perlapp executable.

On a win32 c++ compiled executable, I can "workaround" Vista UAC by inheriting the current user security context through applying with mt.exe the following manifest settings.

<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3"> <security> <requestedPrivileges><requestedExecutionLevel level="asInvoker" uiA +ccess="false"/> </requestedPrivileges> </security> </trustInfo>


More info about this at
"How to embed a manifest in an assembly: let me count the ways...
Windows Vista - Demand UAC elevation for an application by adding a manifest using mt.exe
pdk RE: Win32::Msg

This works fine for the c++compiled executables thus far encountered. When applying this with mt.exe to a perlapp created exe this does not work unfortunately. When binding this file in pdk 6|7 and running it again, no solution either. Hmm. Interesting challenge...
Finally I ended up opening the exe file in a hex editor.
Herein I found the following manifest information.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion= +"1.0"> <assemblyIdentity version="0.0.0.0" processorArchitecture="X86" nam +e="Perl" type="win32" /> <description>Perl</description> <dependency><dependentAssembly> <assemblyIdentity type="win32" name="Microsoft.Windows.Common-Contr +ols" version="6.0.0.0" processorArchitecture="X86" publicKeyToken="6595b64144ccf1df" langu +age="*" /> </dependentAssembly></dependency> </assembly>


Aha a manifest xml section. So let's insert the required data as shown below.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion= +"1.0"> <assemblyIdentity version="0.0.0.0" processorArchitecture="X86" nam +e="Perl" type="win32" /> <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3"> <security> <requestedPrivileges> <requestedExecutionLevel level="asInvoker"/> </requestedPrivileges> </security> </trustInfo> <description>Perl</description> <dependency><dependentAssembly> <assemblyIdentity type="win32" name="Microsoft.Windows.Common-Contr +ols" version="6.0.0.0" processorArchitecture="X86" publicKeyToken="6595b64144ccf1df" langu +age="*" /> </dependentAssembly></dependency> </assembly>


This returns:
'The application has failed to start because its side-by-side configuration is incorrect. Activation context generation failed for "executable". Error in manifest or policy file "executable" on lineXX. Invalid XML Syntax.'

The XML syntax is fine however.

The only delta I could notice is that my proven samples refer to assemblyIdentity version="1.0.0.0" and pdk to assemblyIdentity version="0.0.0.0".

So the assemblyIdentity version="0.0.0.0" changed to assemblyIdentity version="1.0.0.0" as shown below.

<assemblyIdentity version="1.0.0.0" processorArchitecture="X86" na +me="Perl" type="win32" />


This returns:
'This program cannot be run in DOS mode.'

Aha no XML syntax errors. So the issue seems to reside in the assembly version.

Here I'm facing a wall.

Anyone having a clue for this kind of assembly configuration issues?

How can I workaround or what is the reason for the no run in DOS mode?

Many thanks in advance.

With kind regards.

ddn123456

Replies are listed 'Best First'.
Re: How can I integrate within the PDK perlapp the manifest assembly workaround for Vista UAC?
by BrowserUk (Patriarch) on Apr 03, 2007 at 09:16 UTC

    Just a guess, but from the error message (Cannot be run in DOS mode), it sounds like by inserting data into the binary, you are changing the offsets of the subsequent PE format sections, but failing to adjust the appropriate offsets within the PE header.

    Hence, when NTLDR attempts to load the executable image by following the now mis-sized offsets, it fails to locate the appropriate sections, and so rejects it with a generic error message indicating that it does not recognise, or cannot make sense of the format of the file.

    To correct this would require you to parse the header, figure out which section offsets come after the position where you are inserting your xml, and adjust them by the amount you insert. There is the additional complication that the offsets have to be aligned to certain boundaries. I'm not sure whether these would be 4-byte, 8-byte or conceivably even page-sized boundaries under Vista. Conceivably it could be processor size (32-bit -v- 60-bit dependant. You would need to find a document describing the latest (Vista compatible) definition of the PE executable format. I have previously found these to be available on-line, but depending where you get it, it may or may not be complete description.

    Like I say, just a semi-informed guess.


    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
      Hi BrowserUK,

      Many thanks for the info. I'm googling on it now.

      Yesterday I fumbled with the number of whitespaces behind the xml (reducing the whitespaces for the number of chars added).

      The mt.exe does all the math for c++ files however for the pdk compiler mt.exe doesn't seem to be fully compliant.

      Now in parallel on a colleague's hunch I'm busy applying the "mt.exe -manifest ExeName.exe.manifest -outputresource:ExeName.exe" line to all perl and pdk executables and dlls.

      The idea is that possibly some of these pe's are compiled into the perlapp.exe. However I don't put much faith in this idea.

      I'll keep you posted.

      Many thanks so far for the great pe info!

      With kind regards.

      DDN
        in parallel on a colleague's hunch I'm busy applying the "mt.exe -manifest ExeName.exe.manifest -outputresource:ExeName.exe" line to all perl and pdk executables and dlls.

        Actually, I think that could work.

        Baring in mind I've never use perlapp and I've only the vaguest notion of what mt.exe actually does.

        It seems likely that the manifest checking would not work when you run the distributable .exe resulting from perlapp processing, as (I assume) that is a standalone, all-in-one distributable. It's only when all the bits and pieces of that file are unpacked and decompressed, one of which will be perl.exe and the latter gets run, that the manifest will be checked. Is the right version of perl5x.dll available? Ecetera.

        So, theoretically thinking, if you apply mt.exe to everything in your \perl\bin directory, along with all the dlls that are in perl\lib\auto\*\*.dll and perl\site\lib\auto\*\*.dll; and if running the script passes the validation prior to being packaged, it should also pass validation after it's be packaged and unpacked.

        Again, that purely a thoughware suggestion.


        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.
Re: How can I integrate within the PDK perlapp the manifest assembly workaround for Vista UAC?
by syphilis (Archbishop) on Apr 03, 2007 at 09:51 UTC
    If you can't get a satisfactory solution here, consider posting to ActiveState's PDK mailing list.

    Cheers,
    Rob
    Afterthought: Can you achieve success by creating a separate file ? ie, assuming your executable is named 'script.exe', create another file (in the same folder) called 'script.exe.manifest' that looks like this:
    <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1. +0"> <assemblyIdentity version="1.0.0.0" processorArchitecture="X86" name="script.exe" type="win32"/> <!-- Identify the application security requirements. --> <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3"> <security> <requestedPrivileges> <requestedExecutionLevel level="asInvoker" uiAccess="false"/> </requestedPrivileges> </security> </trustInfo> </assembly>
    That worked for me in relation to a 'patch.exe' that I copied across from a Windows 2000 box. (The excutable wouldn't run until I created 'patch.exe.manifest')
      Hi Rob, Just tried out your suggestion. Unfortunately as of Win2003 and now also on Vista, if an internal manifest exists this is executed and any external manifest is ignored. Once I have "manifested" all the exe's from the pdk & perl. (I'm especially thinking of the perl.exe). I'll run a last test. If this doesn't do the trick. I'll post it with a link to this page on ActiveState Thanks anyway! With kind regards. DDN
Re: How can I integrate within the PDK perlapp the manifest assembly workaround for Vista UAC?
by ddn123456 (Pilgrim) on Apr 03, 2007 at 13:25 UTC
    Hi All, I manifested all files below.
    • "\Perl\bin\perl.exe"
    • "\Perl\bin\perl5.8.6.exe"
    • "\Perl\bin\perlglob.exe"
    • "\Perl\bin\wperl.exe"

    • "\Program Files\ActiveState Perl Dev Kit 6.0\bin\lib\netcheck.exe"
    • "\Program Files\ActiveState Perl Dev Kit 6.0\bin\lib\pai.exe"
    • "\Program Files\ActiveState Perl Dev Kit 6.0\bin\lib\pai_icons.exe"
    • "\Program Files\ActiveState Perl Dev Kit 6.0\bin\lib\pdkcheck.exe"
    • "\Program Files\ActiveState Perl Dev Kit 6.0\bin\lib\pdklib.dll"
    • "\Program Files\ActiveState Perl Dev Kit 6.0\bin\lib\perl58.dll"
    • "\Program Files\ActiveState Perl Dev Kit 6.0\bin\lib\scineplex.exe"
    • "\Program Files\ActiveState Perl Dev Kit 6.0\bin\lib\tkkit.dll"
    • "\Program Files\ActiveState Perl Dev Kit 6.0\bin\lib\vbsperlui.exe"
    • "\Program Files\ActiveState Perl Dev Kit 6.0\bin\lib\vpmd.exe"
    • "\Program Files\ActiveState Perl Dev Kit 6.0\bin\pdkdebug.exe"
    • "\Program Files\ActiveState Perl Dev Kit 6.0\bin\perlapp.exe"
    • "\Program Files\ActiveState Perl Dev Kit 6.0\bin\perlctrl.exe"
    • "\Program Files\ActiveState Perl Dev Kit 6.0\bin\PerlDB.exe"
    • "\Program Files\ActiveState Perl Dev Kit 6.0\bin\perlfb.exe"
    • "\Program Files\ActiveState Perl Dev Kit 6.0\bin\PerlNH60.dll"
    • "\Program Files\ActiveState Perl Dev Kit 6.0\bin\perlsvc.exe"
    • "\Program Files\ActiveState Perl Dev Kit 6.0\bin\perltray.exe"
    • "\Program Files\ActiveState Perl Dev Kit 6.0\bin\plc.exe"
    • "\Program Files\ActiveState Perl Dev Kit 6.0\bin\vbsperl.exe"
    • "\Program Files\ActiveState Perl Dev Kit 6.0\bin\vpm.exe"
    • "\Program Files\ActiveState Perl Dev Kit 6.0\lib\auto\MSI\Util\Util.dll"
    • "\Program Files\ActiveState Perl Dev Kit 6.0\lib\auto\Win32\Cabinet\Cabinet.dll"

    The PDK could no longer launch after being manifested so fallback to none-manifested binaries.
    After fallback of PDK only, the compilation with PDK went fine.

    At execution however the problem remains.

    Summarised. I did not manage to launch a manifested-PDK-created-executable as a parent process within the "asInvoker" security context thus executing other none-manifested executables. The manifested subprocesses within the same context did run fine however.

    I see something similar happening with a manifested-perl.exe launching a script. Similar impression is mentioned at <Ahref="http://aspn.activestate.com/ASPN/Mail/Message/pdk/3396900">RE: Win32::Msg

    I have posted this on the ActiveState PDK Support forum

    Many thanks to all who provided me with their valuable insights.

    With kind regards.

    DDN
      Dear PerlMonks, Following quote from Mark Minasi at link: WindowsITpro Article 96375 explains this behaviour.

      "Or what about the small-but-essential fact that adding an external manifest to a legacy program in hopes of solving a User Account Control compatibility problem works sometimes but not always, thanks to a glitch in the disk-caching algorithm?"

      I guess we'll just have to wait praying that the next Vista Service Pack solves this issue.

      Regards.
      DDN123456

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://608007]
Approved by Corion
Front-paged by Corion
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others meditating upon the Monastery: (4)
As of 2024-03-29 07:28 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found