I've tried to download a signed executable
( http://live.sysinternals.com/procexp.exe )
and modify it. I've thought it can't be done and Windows will somehow prevent me from running it (or warn me at least). But when I change a single character (for example in DOS stub or any other text data) it is still runable.
Before modification, when I run this app it splashes UAC warning showing it signed Microsoft and asking whether I want to run it. After modification, there is no such thing. Even when I revert changes back, it still won't show up. I've compared modified and reverted executable to the original (in total commander) and it shows no difference. But the original still splashes UAC.
Why is that?
I'm using Windows 7 and Firefox.
I've never tried to do it. Yet when you edited the file, you invalidated the digital signature, you should see it in the Properties of the file.
Windows usually does not check digital signatures. Digital signatures come into play when the file is marked as downloaded from the Internet (if the signature is valid, Windows will show its publisher in the confirmation dialog; otherwise, the publisher will be unknown), and UAC (in this case, the digital signature also confirms the file came from a publisher stored as part of the digital signature).
Whether to show or not to show UAC confirmation is not controlled with digital signature, it's controlled with the application manifest.
So in my understanding, UAC dialog should be shown. But since the modified file fails digital signature check, Windows may decide the file is unsafe to elevate. You could look for messages in Windows event log, there could be events explaining the behavior you see.
I have copied chrome.exe in other directory and started writing random bytes in the application.
I checked properties , the digital signature was there. I have changed the application. It was unable to execute (giving some king of internal error not windows error) but still showing valid certificate in properties. Its strange.
I think windows validates certificate of an application only once.
After you change the file it will still show a digital signature but if you click on the Details button for that signature I think you will find that it says the signature is not valid.
When i changed it back to exactly what it originally containsed it once again told me that the signature was valid. (But you have to use an editor that edits the bytes in place - not one that might add a line break or something unintentionally.)
Related
Windows 8 has a feature: it can launch an application from the search panel (on the right side of the screen). It works like following:
Developer registers his or her application following this instruction. It is a bit legacy instruction, but the project I participate in uses this way to register its settings.
At user logon Windows creates (if none exists) a special .xml file in C:\User\<UserName>\AppData\Packages\windows.immersivecontrolpanel_cw5n1h2txyewy\LocalState\Indexed\Settings\en-US with content shown below. This file has extension settingscontent-ms
As soon as user clicked on this file, the system launches the specified application (actually explorer calls for it, as I discovered by ProcMon).
Xml file content:
<?xml version="1.0" encoding="UTF-8"?>
<PCSettings>
<SearchableContent xmlns="http://schemas.microsoft.com/Search/2013/SettingContent">
<ApplicationInformation>
<AppID>windows.immersivecontrolpanel_cw5n1h2txyewy!microsoft.windows.immersivecontrolpanel</AppID>
<DeepLink>%Canonical name or application path%</DeepLink>
<Icon>%App path%,-%Resource number%</Icon>
</ApplicationInformation>
<SettingIdentity>
<PageID>%GUID as in instruction above%</PageID>
<HostID>{7E0522FC-1AC4-41CA-AFD0-3610417A9C41}</HostID>
<Condition>shcond://v1#RegkeyExists;0;Regkey;HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\ControlPanel\NameSpace\%GUID as in instruction above%</Condition>
</SettingIdentity>
<SettingInformation>
<Name>#%App path%,-%Resource number%</Name>
<Description>#%App path%,-%Resource number%</Description>
<HighKeywords>%App decription%</HighKeywords>
</SettingInformation>
</SearchableContent>
</PCSettings>
We can see node with the name HostID. Windows writes specified in code GUID to this node, but it breaks the ability of my application to work. If I try to execute my app through this "shortcut" by clicking on xml file or chosing my app in search panel, the system shows me a message: "Unspecified error".
When I manually change the HostID value to {12B1697E-D3A0-4DBC-B568-CCF64A3F934D}, it starts to wrk fine.
I looked through registry in order to find something about these two GUIDs, but I didn't find anything. Also I looked for the difference between registry values corresponding to my app and to another, but working, app and didn't find any significand differences too.
Also I tried to delete this file and login into the system under ProcMon, I caught some moments: explorer tries to open the file and fails with ERROR_FILE_NOT_FOUND, explorer creates missing file, reads registry and writes something to created file, then it closes the file. But I didn't find anything interesting in between of these messages, that can help me to solve my problem.
I found out that registry key HKEY_CLASSES_ROOT\CLSID\%App GUID%\System.ApplicationName contains exactly the same with DeepLink tag (it was the first error in my app - specified key was empty), but the proble with "wrong" HostID remains.
Does anyone know, what it is and how to make Windows to write the rigth GUID to this tag, or at least some useful info about this tag? I just can't imagine anything else to change, but I think, that I need to change something in corresponding to my app registry keys.
I found the solution: just put app's GUID (the same as in PageID) into DeepLink.
To do this, you need to write this GUID as string value to HKEY_CLASSES_ROOT\CLSID\%App GUID%\System.ApplicationName.
That's the solution. However, I haven't found the meaning of HostID tag :(
We've released a new application but we're getting reports that when users try and download it in Internet Explorer, they get a red error message after they choose to save or run the EXE file:
What we want to know is, how can we stop this red version of the banner appearing for IE users? Will code signing persuade IE to instead show the yellow banner which gives the users the option to run or save the file? And if so, is it possible to get a temporarily/trial certificate (not self signed) to test this with? Self signing doesn't seem to help.
Edit:
I've also noticed Google Chrome has a similar banner and effectively the same problem that the users will be scared off installing the file.
This behavior is entirely controlled by SmartScreen Filter from IE. You cannot control it when creating the setup packages, not matter the tool you use to author them. Here are more details:
http://windows.microsoft.com/en-US/windows7/SmartScreen-Filter-frequently-asked-questions-IE9
http://windows.microsoft.com/en-US/windows7/When-to-trust-a-software-publisher-IE9
What I can recommend is to use the same name of the setup file for future versions, i.e. do not change it for every version and digitally sign the package using a code signing certificate. When more users will download the package the browsers will gather statistics and start trusting your file.
I have a COM DLL, coded in Delphi. It should be invoked via an Active X control when a web page loads in MS IE (via soem JavaScript on the page).
Btw, this all works fine with an existing serial port interface, but I am recoding teh DLL to read from USB; all else is unchaged.
It works fine in the Delphi IDE, but not "in the field". The active X control should request it to read some input from a USB port and should then send that to the web page.
Reading from the USB device works, as I can open Notepad and see the value being written there.
The DLL will display a form, and a dialog box, and will write to the system debug trace. Since I am seeing none of these when loading the web page in MS IE, I think we can assume that Aective X control is not calling into the DLL.
In MS IE I have enabled all Active X options.
in c:\Windows\System32 (which is equivalent to c:\Windows\SysWOW64), I have regsvr32.exe -u my_dll.dll and then regsvr32.exe my_dll.dll both of which the system announced to be successful
I searched, and there is only one copy of my_dll.dll under c:\Windows
and it has the correct size and date/time
my %path% is %SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem; for system and empty for user
Any idea what I am doing wrong? Or how I can go about tracking it down?
If you are loading the ActiveX control in webpage through javascript, you will have to package the control for web deployment. See this example for how to do this in your javascript and check whether you have done properly it or not:
Calling Activex Control 's Functions from javascript
Once you do the above thing correctly and open your website in IE, the web-page will at least "load" the ActiveX control. Beyond that, you can display message-boxes or write logs in your Delphi code to track down the actual coding issues.
Background:
I'm working on an Outlook addin which adds an attachment to outgoing emails. Support is required for all versions of Outlook.
When a MailItem has been signed with a digital signature, adding an attachment to this mailItem generally fails unless you save the mail item. This removes the signature from mailitem. To me, this is somewhat expected behaviour. Nothing weird here.
The problem is when the user turns digital signatures on (whether through the UI or as a Outlook default behavior) and then turns it off again. The MailItem is no longer signed but it still behaves as if it is -- we're unable to add an attachment to this email.
I found a newsgroup post which might explain why; it appears that objects retrieved through the outlook API aren't the actual objects.
http://www.tech-archive.net/Archive/Development/microsoft.public.win32.programmer.messaging/2006-02/msg00000.html
At the moment, I've given up trying to fix this problem nicely; saving the MailItem to a temporary file appears to fix this however for performance reasons we'd like to only save when a MailItem has transitioned from signed to unsigned. Another acceptable alternative is to detect whether digital signatures has been enabled by default or not. Though there is a registry entry related to the default setting of a digital signature, it is merely a suggestion and does not reflect accurately whether the email would have been signed by default or not.
Any ideas?
You can use redemption api library to call that method from C#.
Also have you tried creating a PInvoke signature from the extended mapi dll?
Turns out that you can use EMAPI in C++ to call IMessagePtr->SaveChanges(), which seems to work quite nicely. Unfortunately, you can't access this in C#.
I have a very simple VS2005 deployment project that aims to install for all users on a PC.
All the application files are written to %Program Files%\MyProg. A shortcut is created in the start menu and the startup folder. No registry settings or anything else are created. I have set
'InstallAllUsers' to true.
The created MSI runs fine and installs the software. It works without any problems when running under the user account from which it was installed.
When logging in as another user, the start menu and startup icons are present. It attempts to launch the application however an installation window pops up and states that 'the feature you are trying to use is on a network resource that is unavailable.' The installer will only proceed if pointed to the original MSI file.
Why does this happen? I want my application to be installed completely for all users when it is installed by a single user.
edit: Solution
I was getting similar event log messages as shown on this page. In my case it turned out to be as simple as ensuring that the User's Program Menu had its 'AlwaysCreate' attribute turned to false. If it was true, windows would try and recreate the folder when a new user logged in. This somehow required the invocation of the installer and thus resulted in the 'please insert the installation media' prompts.
It is actually kind of hard to say without some more information. I would recommend checking on the rights in the installed folder (seeing if only the one who installed it has rights) and also checking the file list for the directory (to make sure VS didn't automatically place some files in the user profile). Let me know what comes out from those two steps and we can try to keep digging if that didn't shed any light on it.
Keep in mind chances are this is most def not specific to Visual Studio, look at this MS support article here where the same message is coming back for office.
I know this is an old post but I thought I'd add another cause and solution in case the above didn't work for you.
There is a bug in VS Setup and Deployment Projects which results in registry values being entered into HKCU instead of HKLM irrespective of the InstallAllUsers property being set to true.
You must use Orca msi editor to change the registry root for "DesktopFolder" and "ProgramMenuFolder" from either 1 or 2 to -1. The issue cannot be resolved via VS.
http://www.qa.downappz.com/questions/vs-2010-deploys-per-user-features-during-install-which-require-access-to-install-media.html