Interesting registry settings about Microsoft Security Essentials

[NewsArchive]

Hi all,

As you all know, Microsoft Security Essentials does corrupt TPS files.

Please read this article:
http://wpkg.org/MSSecurityEssentials

With the above info and with this info:
http://www.clarionmag.com/Page/23999
it would be possible to check if MSE is active.
If yes, then show a message to the user.

And after that you could exclude your application paths and *.tps files
automatically with those registry settings?

Perhaps doable with SetupBuilder?
Anybody interested in writing a script for this?

--
Best regards,
Jeffrey

[NewsArchive]

Just do it within your program

--
Dan Scott
C55 - C6.3 Legacy
Garage Partner Pro / Invoice Partner
www.garagepartner.com
Plan A is always more effective when the device you are working on
understands that Plan B involves a larger hammer

[NewsArchive]

Hi

I think, in order to WRITE to the registry, I need to run my application
as "requireAdministrator"?

Best regards,
Jeffrey

[NewsArchive]

- Create a little program that's manifested to run as administrator.
- Your main program verifies that the registry entry(ies) exist.
- If the registry needs tweaking, warn the user and give them the
option of trying to fix it, which RUNs that little program.

Mike Hanson
www.boxsoft.net

[NewsArchive]

Jeffrey,

> I think, in order to WRITE to the registry, I need to run my application
> as "requireAdministrator"?

You can use your SetupBuilder and build a little helper tool to handle it.

If you need help, just let me know.

Friedrich

--
Friedrich Linder
Lindersoft
www.lindersoft.com
+1.954.252.3910

SetupBuilder is Windows installation -- "point. click. ship"

-- Official Comodo Code Signing and SSL Certificate Partner

[NewsArchive]

Hi Friedrich,

Thanks, I will try that.

Question:
On a 64-bit machine the registry settings are sometimes under
....\WOW64\... ?
And on a 32-bit machine NOT.

So how does SetupBuilder detect this in order to get the correct
registry path on a 32- and/or 64-bit machine?

Best regards,
Jeffrey

[NewsArchive]

Hi Jeffrey
You would have to detect what OS your program is running in and based upon the result, check for the appropriate registry key.

Ben E. Brady

[NewsArchive]

Hi Jeffrey,

> Thanks, I will try that.
>
> Question:
> On a 64-bit machine the registry settings are sometimes under
> ....\WOW64\... ?
> And on a 32-bit machine NOT.
>
> So how does SetupBuilder detect this in order to get the correct registry
> path on a 32- and/or 64-bit machine?

It's very easy to do with SetupBuilder.

1. Detect whether the operating system is 64-bit or not.

For example:

Set Variable %IS_64BIT% to FUNCTION:Get System Info(WOW64 Status)

2. If it is 64-bit, switch the installer into 64-bit mode.

For example:

If %IS_64BIT% Equals "1" Then
Enable x64 Support
End

3. Read/write the registry. This will automatically process the 64-bit
registry key branch on 64-bit operating systems.

4. After that, switch back to 32-bit mode.

If %IS_64BIT% Equals "1" Then
Disable x64 Support
End

BTW, never specify the "Wow6432node" registry item. Windows handles this
automatically.

http://www.lindersoft.com/forums/showthread.php?p=55605#post55605

Does this help?

Friedrich

[NewsArchive]

Hi Friedrich,

Yes, this helps a lot!
Thanks, what a great tool SetupBuilder is!!

Best regards,
Jeffrey

[NewsArchive]

> Yes, this helps a lot!
> Thanks, what a great tool SetupBuilder is!!

Thank YOU :)

Friedrich

[NewsArchive]

Hi Friedrich,

Another question about this:

My users start my application with a shortcut to for example MYAPP.EXE.
When they start MYAPP.EXE, I want to run a SetupBuilder "silent"
executable to check the registry settings of MSE, for example CHECKMSE.EXE.
So I will use RUN(CHECKMSE.EXE) from MYAPP.EXE.
Will this work to *READ* the registry settings?
Will this work to *WRITE* the registry settings?
I don't want to run my application (MYAPP.EXE) every time asAdministrator.

So what is the best to check if MSE is running from MYAPP.EXE?
And after that, writing the necessary MSE changes to the registry?

What I want to do is:

1. When the user runs MYAPP.EXE, check if MSE has been installed and
check if my folder and *.tps files are excluded, as mentioned in this
article:
http://wpkg.org/MSSecurityEssentials
2. If MSE is installed and my application folder and *.tps files ARE
excluded, then continue with MYAPP.EXE.
3. If MSE is installed and my application folder and *.tps files ARE NOT
excluded, then the necessary registry changes must be applied (by a SB
silent "tool") in order to continue with MYAPP.EXE.

Best regards,
Jeffrey

[NewsArchive]

Hi Jeffrey,

> Another question about this:
>
> My users start my application with a shortcut to for example MYAPP.EXE.
> When they start MYAPP.EXE, I want to run a SetupBuilder "silent"
> executable to check the registry settings of MSE, for example
> CHECKMSE.EXE. So I will use RUN(CHECKMSE.EXE) from MYAPP.EXE.

I assume that both your MYAPP.EXE and CHECKMSE.EXE are "asInvoker"
manifested (and run non-elevated by default).

> Will this work to *READ* the registry settings?

Yes. You can read from the "protected" registry key.

> Will this work to *WRITE* the registry settings?

No. To write to the protected resource, you need an elevated running
application.

> I don't want to run my application (MYAPP.EXE) every time asAdministrator.
>
> So what is the best to check if MSE is running from MYAPP.EXE?

You can directly read the required registry values from your own MYAPP.EXE

-or-

call the CHECKMSE.EXE helper tool from your own application. The "check"
utility can then return a value to your application (e.g. 1 = "MSE is
running" and 2 = "MSE is not running").

>
> And after that, writing the necessary MSE changes to the registry?
>

You have two different options.

1. Develop an "asInvoker" manifested CHECKMSE.EXE with SetupBuilder that can
*read* from the registry to check if MSE is running and that can *write* to
the registry. You can add custom command line switches to handle the
different actions. For example:

CHECKMSE.EXE /READ

CHECKMSE.EXE /WRITE

Depending on the command line switch, read -or- write the registry from your
script.

Okay, but how to write from an "asInvoker" manifested application to
protected registry resources? Very easy. Elevate your CHECKMSE.EXE through
ShellExecute(Ex) from within your application. The trick is to use the
"runas" in the lpVerb.

There is a very simple (quick-and-dirty) ShellExecute Clarion source demo
available at:

http://www.lindersoft.com/projects/ClarionShellExec.zip

In the above demo, change:

FileAction = 'open'

to:

FileAction = 'runsas'

and it should start the "asInvoker" manifested application elevated. Of
course, this will prompt for elevation!

2. Not recommended, but also possible. Provide two different versions of
your CHECKMSE tool. For example, CHECKMSE1.EXE ("asInvoker" manifested) to
read the registry and CHECKMSE2.EXE ("requireAdministrator" manifested) to
write to the registry.

Friedrich

--
Friedrich Linder
Lindersoft
www.lindersoft.com
+1.954.252.3910

SetupBuilder is Windows installation -- "point. click. ship"

-- Official Comodo Code Signing and SSL Certificate Partner

[NewsArchive]

Hi Friedrich,

> I assume that both your MYAPP.EXE and CHECKMSE.EXE are "asInvoker"
> manifested (and run non-elevated by default).
Yes, correct.

Thanks for your great explanation!
This will help me a lot!

SB rocks!

Best regards,
Jeffrey

[NewsArchive]

Hi Friedrich,

In this article:
http://wpkg.org/MSSecurityEssentials
I read that I can use:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Antimalware\Exclusions\Paths

to exclude my data path in which my TPS files are.

*BUT* the article also says:

===
Permissions:
Note that 'HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Antimalware'
is read-only for all users apart from SYSTEM. If you use a script, such
as a batch file, to alter Microsoft Antimalware registry settings then
it will need to run as SYSTEM, which WPKG Client does.
===

So is this possible with SetupBuilder "to run as SYSTEM"?

Best regards,
Jeffrey

[NewsArchive]

Hi Jeffrey,

System run level is EXTREMELY dangerous. The system run level is higher
than administrator, and has full control of the operating system and it's
kernel. A very bad thing <g> You can do this with Windows Services running
as SYSTEM or with applications running as SYSTEM instead of a least
privilege service account. But IMO, you should not try to do this, it is
the "dark side". BTW, an application installer should not do this at all.

Friedrich

[NewsArchive]

Hi Friedrich,

So then it is not possible to set the file and path exclusions with
SetupBuilder?
That would be a pity.
I was hoping to fully automate this MSE issue by setting the file and path
exclusions and Excluded File Types.
Now I can only check the registry and warn the user.

--
Best regards,
Jeffrey

[NewsArchive]

> As you all know, Microsoft Security Essentials does corrupt TPS files.

I do not know that. I have MSE installed on my development computer and
have had no corruption to this date.

Do you know under which circumstances this happen?

Bjarne Havnen

[NewsArchive]

Hi Bjarne,

Our customers have a share on the server, for example F:\DATA, with
*.tps files in it.
Some of these customers suddenly reported data corruption.
(BUT they ran our application without any problem for many years!)
When I took their machine over (via TeamViewer) I saw that MSE had been
installed.
So I changed the following settings in MSE:
- Excluded files and folders -> F:\DATA
- Excluded File Types -> *.TPS
After that NO MORE PROBLEMS.

Everytime when a customer calls me with data corruption, MSE has
suddenly been installed. And when I exclude our data path and *.tps
files, no more problems!

So that's why I want to make a tool now with SetupBuilder to avoid this
problem as more and more computers have been installed with MSE and
cause a lot of problems.

This issue has cost me a lot of time and money! :-(

Best regards,
Jeffrey

[NewsArchive]

It's a multi-user issue, with files on a shared server. If all the
files are on your local machine, it's not an issue.

Mike Hanson
www.boxsoft.net

[NewsArchive]

Hi Jeffrey,

> So then it is not possible to set the file and path exclusions with
> SetupBuilder?
> That would be a pity.
> I was hoping to fully automate this MSE issue by setting the file and path
> exclusions and Excluded File Types.
> Now I can only check the registry and warn the user.

What you can try to do is set the MSE registry permission.

See attached screenshots. This will "grant" write access to the MSE file
extension registry key. Don't forget to "deny" write access after you
manipulated the extension list!!!!

Friedrich

[NewsArchive]

Looks like this after the "manipulation".

Friedrich

[NewsArchive]

Hi Friedrich,

This is GREAT!!! Thanks a lot!
I think other users can use this info as well!

One final question:
I think I have to check if a user runs on 64-bit or 32-bit and after
that do what you mentioned before (see beneath)?
Also the "grant" write access part?

===
1. Detect whether the operating system is 64-bit or not.

For example:

Set Variable %IS_64BIT% to FUNCTION:Get System Info(WOW64 Status)

2. If it is 64-bit, switch the installer into 64-bit mode.

For example:

If %IS_64BIT% Equals "1" Then
Enable x64 Support
End

3. Read/write the registry. This will automatically process the 64-bit
registry key branch on 64-bit operating systems.

4. After that, switch back to 32-bit mode.

If %IS_64BIT% Equals "1" Then
Disable x64 Support
End
===

Best regards,
Jeffrey

[NewsArchive]

Hi Jeffrey,

> One final question:
> I think I have to check if a user runs on 64-bit or 32-bit and after that
> do what you mentioned before (see beneath)?
> Also the "grant" write access part?

Unfortunately, I don't have an answer. I have not tested it on x64, only in
a virtual 32-bit XP machine. We do not (and will never ever) use MSE here
<g>.

Friedrich

[NewsArchive]

BTW, I think that it is not possible to manipulate the 64-bit MSE registry
branch. This is not covered by registry redirection and a native 64-bit ACL
component is required in order to set the write permission.

But this native 64-bit component is only available in the next SB8 version,
not in SB7.

Friedrich

[NewsArchive]

BTW, what's your deadline? I can check if it's possible to prepare an
internal 64-bit test component for you that can be called from a SB7
install...

The native 64-bit Services, 64-bit ODBC, 64-bit Processes, 64-bit ACL, etc.
components for SB8 are already code-complete, but they can't be used
directly from SB7.

Friedrich

[NewsArchive]

Hi Friedrich,

Our deadline is that we come out with a new update of our application in
the beginning of January 2012, in which we want to build this "MSE check
& repair". ;-)

I have a 64-bit Windows 7 machine here on which I can install MSE 64-bit
version and test the SB tool.

Best regards,
Jeffrey

[NewsArchive]

Hi Jeffrey,

> Our deadline is that we come out with a new update of our application
> in the beginning of January 2012, in which we want to build this "MSE
> check & repair". ;-)
>
> I have a 64-bit Windows 7 machine here on which I can install MSE
> 64-bit version and test the SB tool.

We'll see what we can do.

Friedrich

[NewsArchive]

Thanks, Friedrich!

Best regards,
Jeffrey

[NewsArchive]

Hi Friedrich,

I have a VirtualBox with Windows 7 Ultimate 32-bits with MSE 32-bits.
The "Granting" part is not working, returns error 7.
So after that, writing to the registry is also failing.

Please see the zip attachment with the script, exe and pdf error document.
So at this moment I can only READ the settings. :-(

Can you please look at my script?

Best regards,
Jeffrey

[NewsArchive]

Hi Jeffrey,

> I have a VirtualBox with Windows 7 Ultimate 32-bits with MSE 32-bits.
> The "Granting" part is not working, returns error 7.
> So after that, writing to the registry is also failing.
>
> Please see the zip attachment with the script, exe and pdf error document.
> So at this moment I can only READ the settings. :-(
>
> Can you please look at my script?

It's very well possible that, in Windows 7, the MSE keys are "better"
protected.

Error 7 means "Cannot apply new access control list". In other words, the
key is protected.

In fact, it does not make any sense (from the security point-of-view) to let
an installer manipulate the file extension. If it would be that easy, any
malware could do it.

Unfortunately, we do not have 32-bit versions of Windows 7 available. We'll
check the 64-bit keys with our 64-bit ACL component (both 32-bit and 64-bit
components share the same code base) to see if it is possible to manipulate
that key.

If this is not possible, then I fear you can't do anything here. Then
Windows protects itself (which is a good thing, from the security
point-of-view <g>).

BTW, and Windows 8 will again enhance key protection!

Friedrich

[NewsArchive]

Jeffrey,

> I have a VirtualBox with Windows 7 Ultimate 32-bits with MSE 32-bits.
> The "Granting" part is not working, returns error 7.
> So after that, writing to the registry is also failing.

This is not only on Win7, but (IMO) on all UAC-aware systems. There is
again another layer of MSE key protection involved.

I tried another "dirty trick" and it worked here on one of our Vista 32-bit
test machines. We'll check if it also works on 64-bit machines and Win7.

Friedrich

[NewsArchive]

Hi Friedrich,

I hope I can test your "dirty trick" if it works? ;-)

Best regards,
Jeffrey

[NewsArchive]

> It's a multi-user issue, with files on a shared server. If all the
> files are on your local machine, it's not an issue.

Thank you. I suspected that. I use TPS for single user applications
only, else I use MSSQL.

Bjarne

[NewsArchive]

Hi Friedrich,

Any news about your "dirty trick"?
I need it very soon, if possible.

Best regards,
Jeffrey

[NewsArchive]

Hi Jeffrey,

> Any news about your "dirty trick"?
> I need it very soon, if possible.

Our 32-bit solution "seems" to work fine, but on x64 you need a native
64-bit ACL component to manipulate the key permission. In SB7, there is not
such a 64-bit ACL available (this will be a SB8 feature).

Friedrich