I've had the 'odd' occasion in the past where one of my apps has thrown up a virus warning with my AV software.... I'm sure this is multiplied many times over with people with different AV checkers. I wondered.... how interactive are AV companies in general? If I alert them to the issue on my 1k (public) user app will they even read the email? Are they likely to reply and suggest I not do something or do I just have to twiddle bits till I beat their virus checker :lol?
Getting a false positive with AVG after adding the following to my application prompted this question :lol:
REPEAT 2000
nop
ENDM
A very dangerous piece of code it seems
Try putting both a manifest file and a version control block in the resource section of the file. As long as the file is clean it seems to shut up most of the crappy end of AV scanners.
I have a manifest but a 'version control block'?
The error above is a most bizzare one and I dont have that many problems with AV but every time I do I worry about my customers
Plonk something like this in the RC file.
// ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤
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 Inc.\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 1998-2009 Copyright Name\000"
VALUE "ProductName", "Item Name\000"
VALUE "ProductVersion", "1.0\000"
END
END
BLOCK "VarFileInfo"
BEGIN
VALUE "Translation", 0x409, 0x4B0
END
END
// ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤
There are a couple of constants that are not in WINDOWS.INC yet but do this with the file and it will probably shut up the AV idiot fringe.
Do a right click on the EXE file name in Explorer and it should display the version info for you.
awesome ty Hutch
Quote
REPEAT 2000
nop
ENDM
A very dangerous piece of code it seems
On their own, the NOP instructions are benign. Some exploits and malware used (still use?) what is termed a 'NOP slide' though. The purpose of the NOPs was to provide a generalized landing area for the execution to be directed to when the exploit was realized. This could also be what the AV was complaining about in that particular case if Hutch's version info fix doesnt resolve it. It may have been the final check in a list, such as file size, not being a compiled exe (assembler coder = virii coder, right? o0 ) or any of the other 'quirks' which set assembler aside from mainstream and commercialized (yet totally socially acceptable) garbage.
The worst thing about AV companies is they will only pander to the 'big guy' because there is money at stake. When it comes to the 'little guy' however, we're behind the eight ball from the word go because the 'heuristics' employed by these twits will squeal about any 'anomoly' which doesn't fit within their idea of what is acceptable. Protection companies, ones such as Silicon Realms and Oreans, would have to be in contact with the AV companies, providing samples of their stubs and such so that come time to release a new stub/update their product can be used without fear of the dreaded "Danger! Danger!" messages we get from our own work.
When a protector is abused however, like in the case of some earlier versions of Themida, then those particular versions can be blacklisted and anything protected with them will flag AV which have added them. I can only imagine in a case such as this, legitimate customers might be recompensated by the company, but that part is pure conjecture on my behalf.
HR,
Ghandi
Hey Hutch,
I tried adding that stuff but it wouldnt work.... after I'd pulled all my hair out and punched the screen a few times I tried it on your color picker app (that you'd already coded right) but it didnt work on that either.... Below is the build info.... do I have the wrong version of link/ml or something?
Microsoft (R) Windows (R) Resource Compiler, Version 5.00.1823.1 - Build 1823
Copyright (C) Microsoft Corp. 1985-1998. All rights reserved.
Using codepage 1252 as default
Creating rsrc.RES
RC: RCPP -CP 1252 -f C:\masm32\crap\getcolor1\RCa05924 -g C:\masm32\crap\getcolor1\RDa05924 -DRC_INV
OKED -D_WIN32 -pc\:/ -E -I. -I . -I C:\Program Files\Microsoft Visual Studio\VC98\atl\include -I C:\
Program Files\Microsoft Visual Studio\VC98\mfc\include -I C:\Program Files\Microsoft Visual Studio\V
C98\include
rsrc.rc.
Writing 24:1, lang:0x409, size 442.
Writing ICON:1, lang:0x409, size 744
Writing GROUP_ICON:500, lang:0x409, size 20.
Writing CURSOR:2, lang:0x409, size 4268
Writing GROUP_CURSOR:200, lang:0x409, size 20.
Writing DIALOG:1000, lang:0x409, size 578.
Writing VERSION:VS_VERSION_INFO, lang:0x409, size 700
Microsoft (R) Windows Resource To Object Converter Version 5.00.1736.1
Copyright (C) Microsoft Corp. 1992-1997. All rights reserved.
Microsoft (R) Macro Assembler Version 6.15.8803
Copyright (C) Microsoft Corp 1981-2000. All rights reserved.
Assembling: C:\masm32\crap\getcolor1\getcolor.asm
Microsoft (R) Incremental Linker Version 5.12.8078
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.
Cheeky bump here only a couple days after posting but I did only Hey Hutch.... Now my query is more desperate.... Can *ANYONE* help me :lol.... I dont know why my apps arent building with *properties tab* even with the correct info in the rc file.... The exe contains the rc contents but something is not right still.... I tried building Hutch's color picker example (which has all info correct in rc file etc but still no properties tab
http://www.masm32.com/board/index.php?topic=13720.msg107722#msg107722
Anyone else with similar problem or solution? I'd give my left mnumonic for a solution
a while back, Edgar was showing us how to write some manifest files
maybe these related threads can help...
http://www.masm32.com/board/index.php?topic=10641.0
http://www.masm32.com/board/index.php?topic=13348.0
http://www.masm32.com/board/index.php?topic=13366.0
Even building Hutchs example above (I'm assuming he didnt change anything after build) I still had the same problem.... I tried copying his manifest and rc changing only the most essential bits, also checked out http://webster.cs.ucr.edu/AsmTools/GoAsm/Doc/RESOURCE.HTM#ver but still everything builds ok but the final exe is slightly different from hutchs (though it contains property pane info) but doesnt display property pane
It's a sad day when you cant even get by as a script kiddy :lol
The standard masm32 example run with Build All gives this result and runs correctly.
Microsoft (R) Windows (R) Resource Compiler Version 5.2.3690.0
Copyright (C) Microsoft Corporation. All rights reserved.
Using codepage 1252 as default
Creating rsrc.RES
RC: RCPP -CP 1252 -f H:\cpicker\RCa00696 -g H:\cpicker\RDa00696 -DRC_INVOKED -D_
WIN32 -pc\:/ -E -I. -I .
rsrc.rc.
Writing ICON:1, lang:0x409, size 744
Writing GROUP_ICON:1, lang:0x409, size 20.
Writing DIALOG:100, lang:0x409, size 560
Microsoft (R) Windows Resource To Object Converter Version 5.00.1736.1
Copyright (C) Microsoft Corp. 1992-1997. All rights reserved.
Microsoft (R) Macro Assembler Version 9.00.30729.01
Copyright (C) Microsoft Corporation. All rights reserved.
Assembling: H:\cpicker\cpicker.asm
Microsoft (R) Incremental Linker Version 5.12.8078
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.
Volume in drive H is quad_h
Volume Serial Number is 5C73-AC89
Directory of H:\cpicker
09/22/2000 10:04 PM 6,031 cpicker.asm
04/23/2010 12:18 AM 7,168 cpicker.exe
09/21/2000 08:31 PM 766 cpicker.ico
04/23/2010 12:18 AM 3,518 cpicker.obj
4 File(s) 17,483 bytes
0 Dir(s) 236,485,304,320 bytes free
Press any key to continue . . .
OK for direct comparison I have:
Microsoft (R) Windows (R) Resource Compiler, Version 5.00.1823.1 - Build 1823
Copyright (C) Microsoft Corp. 1985-1998. All rights reserved.
Using codepage 1252 as default
Creating rsrc.RES
RC: RCPP -CP 1252 -f C:\masm32\crap\cpicker2\RCa07344 -g C:\masm32\crap\cpicker2\RDa07344 -DRC_INVOK
ED -D_WIN32 -pc\:/ -E -I. -I . -I C:\Program Files\Microsoft Visual Studio\VC98\atl\include -I C:\Pr
ogram Files\Microsoft Visual Studio\VC98\mfc\include -I C:\Program Files\Microsoft Visual Studio\VC9
8\include
rsrc.rc.
Writing 24:1, lang:0x409, size 427.
Writing ICON:1, lang:0x409, size 744
Writing GROUP_ICON:10, lang:0x409, size 20.
Writing DIALOG:100, lang:0x409, size 560.
Writing VERSION:VS_VERSION_INFO, lang:0x409, size 708
Microsoft (R) Macro Assembler Version 6.15.8803
Copyright (C) Microsoft Corp 1981-2000. All rights reserved.
Assembling: cpicker.asm
Volume in drive C has no label.
Volume Serial Number is E86C-5560
Directory of C:\masm32\crap\cpicker2
03/04/2010 16:32 6,129 cpicker.asm
22/04/2010 15:49 7,168 cpicker.exe
21/09/2000 20:31 766 cpicker.ico
22/04/2010 15:49 3,918 cpicker.obj
03/04/2010 16:34 427 cpicker.xml
5 File(s) 18,408 bytes
0 Dir(s) 77,832,495,104 bytes free
It looks like VS98 is interfering with it somehow I guess some global paths are set somewhere.... The app I build is slightly different and doesnt have a property pane it still seems to contain the rc version data but incorrectly as it's not actioning it
You seem to have a later version of the resource compiler
Resource Compiler Version 5.2.3690.0
vs
Resource Compiler, Version 5.00.1823.1 - Build 1823
Maybe this is the issue
PS: Excuse the folder name 'crap' it bares no suggestion to your color picker it's simply where I download everything to :lol
QuotePS: Excuse the folder name 'crap' it bares no suggestion to your color picker it's simply where I download everything to
what a coincidence !!!
i have a folder named "crap" that i use for
all of Hutch's stuff :bdg
(j/k Hutch)
oex,
The two binaries in you last zip file appear on my XP SP3 as identical and run in identical ways.
they are the same size and icon rc bits ran ok however there are differences in the files (some indicated below with FC)
In explorer tile view app and company name dont show on mine and if you right click and click properties only yours shows version tab
00000088: 04 90
00000089: 62 E2
0000008A: D0 B6
0000010C: 38 14
000001D0: 38 14
00000DC4: 90 8A
00000DD6: FD E2
00000DE6: 98 84
00000DF2: FA F2
00000E00: 3D 22
00000E12: B4 AD
00000E2C: B6 AF
00000E38: 57 48
00000E48: 2D 24
00000E54: F5 ED
00000E5C: F4 D9
00000E6E: 40 31
00000E7C: EE D3
00000E88: E9 E1
00000EA4: 34 09
00000EB8: 9B 80
00000EF2: D7 65
00001004: 04 90
00001005: 62 E2
00001006: D0 B6
0000103C: 04 90
0000103D: 62 E2
0000103E: D0 B6
00001054: 04 90
00001055: 62 E2
00001056: D0 B6
00001068: 9C 78
0000107C: 04 90
0000107D: 62 E2
0000107E: D0 B6
00001094: 04 90
00001095: 62 E2
00001096: D0 B6
000010A8: 84 60
000010BC: 04 90
000010BD: 62 E2
000010BE: D0 B6
000010D4: 04 90
000010D5: 62 E2
000010D6: D0 B6
000010E8: B4 90
000010FC: 04 90
000010FD: 62 E2
000010FE: D0 B6
00001104: 01 00
00001106: 00 01
00001108: 78 01
I think the rc.exe supplied with masm is not capable of version tab rc? I noticed you built with a later version
Quote from: oex on April 18, 2010, 06:32:38 PM
REPEAT 2000
nop
ENDM
A very dangerous piece of code it seems
It is, lexotan32 methamorph code do something like this before adding the metamorphed data + junk opcodes.
And also i dont see the big blame to AV companys, is the heuristic method that cant keep going further. Making the virus is much more easier than make the detection.
The solution is on smarter systems of detection. Ofc is easy to say but, from the point of view of a metamorph virus + algorithm based on random numbers, the only thing to detect are little pieces of code block in the "core" (wich is always static).
Example:
Lexotan32 way to prepare the code block before addition of junk and others.
And in other viruses that have no imagination....
REPEAT 2000
nop
ENDMAnd i agree about AV company dont pay attention to "home developers", but should they?.
Finally:"A detection complexity is determinated by the compression of the code plus the common usage of the instructions"If a virus manage to self mutate its "core" (wich is static) with a algo that uses random numbers then you had just landed hell under AV company for a long time.
Lucky for AV companys, people with this level of knowledge dont care to do it. :cheekygreen:
I think the point with the example I gave is that this a is a very general rule. Just because this is found in a virus doesnt make it remotely dangerous it is simply padding.... Viruses open .exe files to modify their contents however you wouldnt highlight every application that opened a file as being a virus....
This isnt an intended stab at AV companies but more aimed at this rigourous discussion. It is often easy as with optimisation for time to be spent on the unneccesary whilst the blatently obvious is overlooked.
Quote from: oex on April 27, 2010, 11:59:48 AM
I think the point with the example I gave is that this a is a very general rule. Just because this is found in a virus doesnt make it remotely dangerous it is simply padding.... Viruses open .exe files to modify their contents however you wouldnt highlight every application that opened a file as being a virus....
This isnt an intended stab at AV companies but more aimed at this rigourous discussion. It is often easy as with optimisation for time to be spent on the unneccesary whilst the blatently obvious is overlooked.
Well grandma say: "Is easier to prevent than to risk".
Also AV company it isnt like they say: "ok guys lets f*ck up all the work of home maker softs".
The thing is some virus and most new ones are detected by quiet small signatures and the virus makers try to make their work the more compressed and complex possible.
So if AV would have some kind of detection that could choose if some code block seems dangerous or not. (this is actually done by probability, but if they have a full match then its consider dangerous 100%) then the picture of false detection would change.