Is It Possible To Modify an EXE to require run as admin? - exe

I need to modify an EXE that my client no longer has access to the source code, he wants the EXE to automatically Run as Administrator when launching (or at least automatically ask it to run).
Is it possible to modify a compiled EXE to require/ask the user to run as admin before launching? Maybe through hex editing or ollydbg? Are there guides on how to do this?

You don't need OllyDbg for that. An application can define in the application manifest whether it requires elevated privileges or not.
You can edit this manifest (or add one if none exists) and edit/add the setting that controls the required privileges.
Get Resource Hacker and open the EXE file in it.
Check if there is a "Manifest" resource already.
If yes:
Check if the XML contains a key assembly>trustInfo>security>requestedPrivileges>requestedExecutionLevel.
If yes, change its level attribute to requireAdministrator.
If not, add it, according to the script below. Make sure you are not breaking the XML syntax.
If not:
Click "Action" -> "Add using Script Template".
Select type "MANIFEST" and click "Add resource".
Replace the contents with the script below.
Click the big green play button in the toolbar ("Compile Script").
Save the changes.
"The script below" references this:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
<security>
<requestedPrivileges>
<requestedExecutionLevel level="requireAdministrator" uiAccess="false"></requestedExecutionLevel>
</requestedPrivileges>
</security>
</trustInfo>
</assembly>
Here is an example how it may look at the end:
However, as noted by others already, if you need this only for one user, it will be simpler to just set "Run as administrator" in the file properties dialog under "Compatibility" instead of modifying the file itself.

There's an easy work-around here that may be of use.
Right-click the application.
Open properties.
Go to the compatibility tab.
Under settings, check "Run this program as an administrator".
This doesn't modify the application file in any way, it just flags that file so that Windows knows to open it as administrator from now on. This same process will need to be repeated for every separate user account and/or PC that uses the program.

You can attach a manifest file to your exe file
I've written a simple manifest file to get Admin requirements for programs:
Executable: [filename].exe
Manifest:[filename].manifest
Sample application manifest file:
<?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="YOUR PROGRAM NAME"
type="win32"/>
<description>YOUR PROGRAM DESCRIPTION</description>
<!-- Identify the application security requirements. -->
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
<security>
<requestedPrivileges>
<requestedExecutionLevel
level="requireAdministrator"
uiAccess="false"/>
</requestedPrivileges>
</security>
</trustInfo>
</assembly>
Edit this code and then save it in .manifest file and then use this command to embed this file in exe file:
mt.exe -manifest MyApp.exe.manifest -outputresource:MyApp.exe;1
For the mt.exe file, you need to Visual Studio Desktop Development with C++ package

Related

Azure sitesroot does not contain all deployed files

I'm deploying a web role to Azure using VS 2013. I added a Contents element to my .csdef file to deploy extra files that are not included in the Azure deployment package like this:
<?xml version="1.0" encoding="utf-8"?>
<ServiceDefinition name="..." xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition" schemaVersion="2014-06.2.4">
<WebRole name="..." vmsize="Small">
<!-- snip -->
<Contents>
<Content destination="bin/">
<SourceDirectory path="C:\...\bin"/>
</Content>
</Contents>
</WebRole>
</ServiceDefinition>
When the package is deployed, I can see the extra files being put in the approot folder on the instance's F: drive. However, these files are never deployed to the sitesroot\0 folder, from which the web role seems to run. Because these extra files are assemblies that are to be loaded dynamically, I would like them to be together with the application's other assemblies.
Is this behavior intentional or am I doing something wrong? There doesn't seem to be much information about this online.
I ended up using the Content element in the end, but with a different destination path, pointing to the sitesroot folder. It's a bit of a hack, but at least it works without diving into MSBuild or manual packaging of the deployment.
<ServiceDefinition name="..." xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition" schemaVersion="2014-06.2.4">
<WebRole name="..." vmsize="Small">
<!-- snip -->
<Contents>
<Content destination="..\sitesroot\0\bin">
<SourceDirectory path="C:\...\bin" />
</Content>
</Contents>
</WebRole>
</ServiceDefinition>
The behaviour is as per the documentation which states that the deployed location is relative to the Role's APPROOT (the behaviour you are seeing).
If you want them deployed into your site's bin folder you need to package them as part of your Visual Studio solution.
You can add a DLL to your root directory of a project (Add -> Existing Item). If you take that DLL and change the Build Action set to Content and the Copy to Output Directory set to Copy Always then I think this will make sure that the DLL ends up being in your BIN folder, or equiv.
An example of what I've done in the past:
Two projects in a Solution named:
DependenciesProject (Class Library)
WebProject (MVC App)
I had a need where some specific DLLs that needed to be bundled into the compiled package were included but the specific DLL that would be used would change based on my compiled targets (x64 vs x86). The solution we chose to go with was to have the DependenciesProject do what I described for you to do above and we modified the .csproj file to change the path to these native DLLs based on the target specified at compile-time (we disabled Any CPU).
So the DependenciesProject had these DLLs in the root directory (with that .csproj having some tweaks for dynamic paths to the DLLs that existed in our Nuget packages folder) and the DLLs in the Solution Explorer had the Build Action set to Content and the Copy to Output Directory set to Copy Always. This means whenever a DependenciesProject.dll file was compiled, it would move the other DLLs into the same output folder as that .DLL file.
Now WebProject project would have a Project Reference to DependenciesProject. This means every time I try to compile WebProject, it will first compile DependenciesProject and then copy its output folder into the WebProject's output folder.
The end result: DependenciesProject.dll as well as MySpecial.dll existed with my web application every time I needed it.
Does this help?

File published to successfully to Azure web site can't be found?

I have an Azure shared web site. I publish my web site using Visual Studio 2013 and the operation succeeds, yet certain files are reported by the browser as missing while others are fine. The files that end up in the missing category are all binary data files for a game. All the "normal" web files (HTML, JS, CSS, etc.) appear to be fine. Is there some kind of special steps I need to take to publish binary data to an Azure web site?
Note, from within Visual Studio 2013 I tried to publish individually one of the missing files by using the Publish Single File option. The publish operation succeeds, but still, the browser can't find the file when it tries to load it. Note, I don't think it's a file size issue because several of the binary data files are only around 3 MB in size.
To fix this issue, FTP into your website and upload the following Web.config file which will set the correct MIME types. If you already have a Web.config file in place, just add the below to the appropriate section. Replacing .json and application/json with the file you're trying to load.
<?xml version="1.0"?>
<configuration>
<system.webServer>
<staticContent>
<mimeMap fileExtension=".json" mimeType="application/json" />
</staticContent>
</system.webServer>
</configuration>
I'm guessing in this instance you haven't configured the mimeTypes for these files, if they are to be served through the server. There's a quick explanation and an appropriate resolution to your problem.
HTH

IIS: How to serve a file without extension?

I am using IIS 8 on Windows 8.1. I have an XML file an I need to have it accessed through (servername)/(path)
(path) is predefined by someone else and does not contain an extension. I tried the simple solution of removing the .xml file the file name, but IIS returns HTTP Error 404.3 - Not Found
In the "Physical Path" returned with the error is the correct file path, which when I copy-paste to Run opens the correct file.
Please let me know if this is possible.
Assuming (path) is a physical directory on your machine, create a new web.config file in that directory with the following content:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<staticContent>
<mimeMap fileExtension="." mimeType="text/xml" />
</staticContent>
</system.webServer>
</configuration>
You are telling IIS that for this directory only, any file without an otherwise defined extension (in MIME types) should be considered an xml file. Other file types in the same path should still work.
If you have the Windows feature IIS Management Scripts and Tools installed, you can use PowerShell to create such a web.config file:
Add-WebConfigurationProperty -pspath 'MACHINE/WEBROOT/APPHOST/Default Web Site/.well-known' -filter "system.webServer/staticContent" -name "." -value #{fileExtension='.';mimeType='text/xml'}
in this example Default Web Site is the name of the web site and .well-known is a directory under that site.
It can be done in IIS 6 as well / without using web.config, but instead using the management GUI to add a MIME type for extension . here:
For instance, to serve a .well-known/acme-challenge token, create a virtual directory called .well-known, and have it take its contents from a physical directory (that cannot have names with leading dots in windows). Then add a text/plain MIME type for the extension . in this directory, and you can manually acquire new letsencrypt certificates for a domain that is currently served by an old IIS.
Changing the configurations by hand can be error-prone. So Internet Information Server (IIS) console GUI provides an easier and error-free way to update the MIME-types. Please follow the steps below:
Open IIS
Expand your website's node in the left navigation pane.
Select your application or virtual directory.
Double-click MIME Types feature under IIS section in the right pane:
Click Add.. link in Actions pane. Set-up the mime type to support all files without extension. Then click OK :
Behind the scene, these steps make changes to web.config file of your application or virtual directory (under your website) as suggested in PeterHahndorf's post.
Note: The screenshots shown in the steps above have been taken from Windows 10 machine having IIS v10.
for me, I want only to serve one file
so what I did is just add a simple rewrite as the other methods posted here didn't work for some reasons
<system.webServer>
<rewrite>
<rules>
<rule name="apple-app-site-association" patternSyntax="ExactMatch">
<match url="apple-app-site-association" />
<action type="Rewrite" url="/apple-app-site-association.txt" />
</rule>
</rules>
</rewrite>
</system.webServer>

Azure Web Role Startup Action

Okay, the Startup Action option in Azure project in VS2012 is located in the WebRole Properties.
But where is it saved? Is is nowhere in the solution file. After changing the file does not appear modified.
I have to occasionally change these settings after merge, and once changed they are persistent (until the next merge/ modification outside the IDE).
Does someone know where it is saved? I can't find it. no files modified after changing this setting.
If there are no file changes in any of your projects, check if there is a user settings file. This will be in the same directory as the project file (.csproj,
.ccproj) but will have am extension with a U in it (I'm not at a machine I can check this on).
it is in the service definition file (the .CSDEF)
This should be added in the file:
<Startup>
<Task commandLine="" executionContext="elevated" taskType="simple" />
</Startup>

Configuring CruiseControl.net project directory

CruiseControl.net creates (by default) for each project a subdirectory under: c:\Program File\CruiseControl.NET\server
How can I change that? (it's such a bad idea to mix data with program files...)
I found a way to configure the artifacts directory per project, but that's not quite it (it's merely a subdirectory of the project directory).
Set the project's working and artifact directory and you're done. They default to:
[ccnet-install-dir]\[project-name]\WorkingDirectory
[ccnet-install-dir]\[project-name]\Artifacts.
If you e.g. set these directories to...
[projects-dir]\[project-name]\WorkingDirectory
[projects-dir]\[project-name]\Artifacts
... you can safely remove the [ccnet-install-dir]\[project-name] subtree (You will loose your project build history then).
So your configuration will look like this:
<project name="foo">
[...]
<workingDirectory>C:\projects\foo\WorkingDirectory</workingDirectory>
<artifactDirectory>C:\projects\foo\Artifacts</artifactDirectory>
[...]
</project>
I have CC.NEt not installed here, and I have atm no access to my build-server at work, but if I remember well, you should find 2 configuration files in your c:\Program Files\CruiseControl.NET folder.
ccnet.exe.config and ccservice.exe.config.
The first configuration file is used when you run CC.NET using the console app, the second one is used when you start CC.NET as a service.
In those files, you should find a configuration-setting which points to the location where the configuration-file(s) that describe the build-process for your projects can be found.
edit:
In the ccservice.exe.config file, you'll find a key in the appSettings section which is called ccnet.config. Change the value of this key to the path where you want to put the ccnet.config file.
If this key is not present, you can add it:
<appSettings>
<!-- Without this appSetting ccservice will look for ccnet.config in its own directory. -->
<add key="ccnet.config" value="D:\CCNetConfigFiles\ccnet.config"/>
</appSettings>
This is how I've done it:
I've changed the ccnet.config appSetting in the ccservice.exe.config file, so that CruiseControl.NET searches for the ccnet.config file in a different location instead of the standard location. (As described above). (I understand that you do not want to do this ?)
I've changed the ccnet.config file itself, so that it looks like this:
<!DOCTYPE cruisecontrol [
<!ENTITY project1 SYSTEM "file:D:\CCNETConfigFiles\project1\project1buildconfig.xml.config">
<!ENTITY project2 SYSTEM "file:D:\CCNETConfigFiles\project2\project2buildconfig.xml.config">
<!ENTITY project3 SYSTEM "file:D:\CCNETConfigFiles\project3\project3buildconfig.xml.config">
]>
<cruisecontrol>
&project1;
&project2;
&project3;
</cruisecontrol>
By doing this, I can have each project configuration in its own file, and I can put each project-configuration in its own directory.
Then, I just have to make sure that in each project config-file, I remove the cruisecontrol tags, because otherwise the ccnet.config file wouldn't validate against the schema.
Probably not the answer you're waiting for, but could still be interesting: we're using about twenty build machines with about fifty different builds. Because indeed it's not a good idea to mix data with program files, we decided to put our ccnet installation in source control. Each server has its own configuration file in that directory (also in source control) and a local batch file or short cut starting ccnet specifies which configuration file is used. This means that local data (the build logs) are mixed with data that is in perforce (ccnet binaries/configuration files), but we have accepted that situation. Hope this helps.
Regards,
Sebastiaan

Resources