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 

[Raistlin]

Hi guys - sorry to resurrect this thread - but sheeesh - I'am pissed.

It's now all antivirus vendors that's genetically giving me grief. (Sh@t list: Symantec, Avira .. and counting)

I can download the masm32 zip examples from random posts across the forum - but as soon
as they unzip - "the reputation" or "small amount of users" bomb drops and good-bye exe's. Does'nt matter
the code samples are from reputable people, which I believe would have included version blocks and manifests (or maybe not?).
I'am normally researching in an enterprise environment and don't have control over the virus policy.

Any further hints as to get around the 'small number of users and reputation' false positive detects ? Heard something
about embedded certs someplace....

Code: [Select]

Step 1 – Using Digital Signatures

One of the easiest ways to identify that a file is good is to know where it came from and who created it. One of the most important factors in building a positive file reputation is to check its digital signature. Executable files without a digital signature are at risk of being identified as unknown.

• Custom or home grown application should be digitally signed with class three digital certificates

• Customers should insist that their software vendors digitally sign their application



Thanks
Raistlin

[hutch--]

Can you load the source and build it yourself ? As far as I can tell, certificates are just another way for some American company to try and make money.

[jj2007]

certificates are just another way for some American company to try and make money.

Indeed

@Raistlin: Try to add bloat. Random stuff before the entry point, for example.

[Raistlin]

@hutch: Building it myself - also triggers the false positive again 

The 3rd level (personal/user) cert from a 3rd party cert authority  - doesn't look too expensive about $10 US
- BUT, I would just like a guarantee that it would work though. https://www.trustcentre.co.za/personal_certificates.php

Anyone currently doing this ?