Advanced machine learning technology not so advanced

[Raistlin]

Just a quickey - Do I need to sign (generate) a PublicKeyToken uniquely for each assembly (using SDK -> sn.exe tool)
or just use the same / everybody else's re: publicKeyToken="6595b64144ccf1df" <- as found in internet/msdn examples ?

Does it matter?

Thanks
Raistlin

[hutch--]

The latter has been doing the job for years.

[adeyblue]

Just a quickey - Do I need to sign (generate) a PublicKeyToken uniquely for each assembly (using SDK -> sn.exe tool)
or just use the same / everybody else's re: publicKeyToken="6595b64144ccf1df" <- as found in internet/msdn examples ?

Does it matter?

Strong names are for .net assemblies, so they can be installed in the Global Assembly Cache (c:\Windows\assembly) and uniquely referenced. sn.exe of little use to anything not .Net. Authenticode signing is basically all native code has, and proper signing certificates are usually triple-digit US dollars.

In native manifests, that one you posted for the common controls is literally the only one you'll ever need to put in manually, since nobody but Microsoft ever installs anything into the Native Assembly Cache (WinSxS) and the only three assemblies you'll find the tokens for are comctl32, gdiplus and the 2005-2013? Visual Studio CRTs.
From Vista on, there are literally millions of exes/dlls in WinSxS but you don't need their keys since most of them are hardlinks to the same files in system32 (ie, the file is in two places, but they both reference a single copy of the file data)

[Raistlin]

So here's my manifest - and it still triggers Symantec A/V alert 

What could be wrong?

Code: [Select]

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly manifestVersion="1.0" xmlns="urn:schemas-microsoft-com:asm.v1" xmlns:asmv3="urn:schemas-microsoft-com:asm.v3">
<assemblyIdentity version="1.0.0.0"
     processorArchitecture="X86"
     name="ExtremeID"
     type="win32"/>
<description>Extreme ID Tester</description>
<dependency>
<dependentAssembly>
<assemblyIdentity
type="win32"
name="Microsoft.Windows.Common-Controls"
version="6.0.0.0"
processorArchitecture="X86"
publicKeyToken="6595b64144ccf1df"
language="*"
/>
</dependentAssembly>
</dependency>
    <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
        <security>
            <requestedPrivileges>
                <requestedExecutionLevel
                    level="asInvoker"
                    uiAccess="false"
                />
            </requestedPrivileges>
        </security>
    </trustInfo>
    <compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
        <application>
            <!-- Windows 10 -->
            <supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}"/>
            <!-- Windows 8.1 -->
            <supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}"/>
            <!-- Windows 8 -->
            <supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}"/>
            <!-- Windows 7 -->
            <supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/>           
            <!-- Windows Vista -->
            <supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"/>
        </application>
    </compatibility>
</assembly>

[jj2007]

So here's my manifest - and it still triggers Symantec A/V alert 

What could be wrong?

It could be that Symantec have reached phase II: "Assume that virus writers have attended JJ's course and know how to add manifests; look for other nasties instead"

Try disabling (temporarily) certain "suspicious" invokes; if that helps, I may have a solution for you.

[hutch--]

Try this, its a lot simpler.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<description>Windows Application</description>
<dependency>
<dependentAssembly>
<assemblyIdentity
type="win32"
name="Microsoft.Windows.Common-Controls"
version="6.0.0.0"
processorArchitecture="X86"
publicKeyToken="6595b64144ccf1df"
language="*"
/>
</dependentAssembly>
</dependency>
</assembly>


This goes in the resource script.

VS_VERSION_INFO VERSIONINFO
FILEVERSION 1, 0, 0, 0
PRODUCTVERSION 1, 0, 0, 0
FILEOS VOS__WINDOWS32
FILETYPE VFT_APP
// FILETYPE VFT_DLL
BEGIN
  BLOCK "StringFileInfo"
  BEGIN
    BLOCK "040904B0"
    BEGIN
      VALUE "CompanyName",      "Your Company Name\000"
      VALUE "FileDescription",  "Description Of Application\000"
      VALUE "FileVersion",      "1.0\000"
      VALUE "InternalName",     "Item Name\000"
      VALUE "OriginalFilename", "Original File\000"
      VALUE "LegalCopyright",   "\251 2010-2020 Application Copyright Holder\000"
      VALUE "ProductName",      "Item Name\000"
      VALUE "ProductVersion",   "1.0\000"
    END
  END
  BLOCK "VarFileInfo"
  BEGIN
    VALUE "Translation", 0x409, 0x4B0
  END
END

[TWell]

@hutch
SnakeOil

Raistlin needs that <compatibility> section ?

A manifest just occasionally helps, as sometimes just a usage of winsock alarms AV.

[hutch--]

Tim,

It has that irritating habit of having worked well since the early XP days, I did not invent manifests or version control blocks but I do know that an app is virus scanner bait if it does not have them. DEP was a pest as well that broke a lot of my software back when it was introduced and I had to re-write a lot of code at the time but the choice was to not be able to run software on the later OS versions.

This pile of clutter imposed by Microsoft as a sequence of gates may be a nuisance and it has annoyed many people including me but fail to get past this set of gates and you consign your software to the scrapheap.

[nidud]

From my experience a manifest doesn't really help. Using POLINK or merge segments doesn't help either.

However adding an Icon may help.

[Vortex]

Some antivirus programs are only bad jokes. Here are some quick examples.

Consider this simple application :

Code: [Select]

.386
.model flat,stdcall
option casemap:none

.code

start:

    ret

END start
dummy1.exe :

https://virustotal.com/sl/file/fe651a4b9d66774ad3574d1333fbe590df53071e7efafb19d7e0aa85e59a9736/analysis/1486805335/

Win32.Trojan.WisdomEyes.16070401.9500.9513
malicious (moderate confidence)

Only one ret instruction and two engines identifying this simple exe as malware.

Let's remove the ret instruction above and let see what happens :

Code: [Select]

.386
.model flat,stdcall
option casemap:none

.code

start:

END start
dummy2.exe :

https://virustotal.com/sl/file/d7057cbb55a1f678bf85e1b3eff3d4501d63a26676328650ecda964eaebc4ec6/analysis/1486805642/

Win32.Trojan.WisdomEyes.16070401.9500.9774
malicious (moderate confidence)
HEUR/QVM20.1.0000.Malware.Gen

The more simple looks more dangerous(!) Another engine joining the group.

I guess the next victimes will be plain text files.

[Raistlin]

Update: So hutch-- was correct - if you stick a Version control block/Manifest in your'e RC the
              the heuristics in Symantec AV End-point - now does'nt see my app as a threat. THANK YOU