virus in oficial driver

Viruses and worms
1

I’m using Avast 4.8.1229, and VPS updated (right now 080817-0).

I’m using Vista home basic 86 (32 bits).

I downloaded a driver from giga-byte home page (the lan driver of the GA-G33-MDS2R motherboard).

Here’s the link:

http://asia.giga-byte.com/FileList/Driver/motherboard_driver_lan_realtek_8111_vista.exe

(replace the http://asia… with http://europe… or …america… or …china…)

Avast claims the setup.exe inside this archive has a sign of win32:trojan-gen {other}.

I have no other antivirus, so I can’t doublecheck.

I have not run nor installed the driver archive. I will wait for avast to confim this.

After dl’ing the file, I checked it with avast (right click, scan) several times. I redownloaded it. All again happened like before.

In the past I have downloaded other drivers from giga-byte’s site, until now without virus problems.

Is it possible this is a false alarm?

2

You could also check the offending/suspect file at: VirusTotal - Multi engine on-line virus scanner and report the findings here. You can’t do this with the file securely in the chest, you need to extract it to a temporary (not original) location first, see below.

Create a folder called Suspect in the C:\ drive, e.g. C:\Suspect. Now exclude that folder in the Standard Shield, Customize, Advanced, Add, type (or copy and paste) C:\Suspect* That will stop the standard shield scanning any file you put in that folder. You should now be able to export any file in the chest to this folder and upload it to VirusTotal without avast alerting.

3

Thank you for helping.

I added the entire archive to the chest, extracted the archive from the chest to c:/suspect according to your previous post.

Then I check its hash values.

I checked at virustotal, using their hash check service.

Virustotal reports 7/35 engines reporting the file, since 2008-08-13, including Avast.

The hash is:

CRC32: 10D75398
MD5: 46B255D40ED4C9BEBA659C6075036226
SHA1: 903F186B11374CDB4FEAB089704C47DEDFEAB3A5

In my system, Avast actually reports 1 file inside the whole archive as sign as win32:trojan-gen {other}. I check the hash info of the whole archive, not of the specific file inside, because I don’t want to run the extraction process to expand it, until I’ll be sure it doesn’t contain any malware.

The name of the whole archive is

motherboard_driver_lan_realtek_8111_vista.exe

and Avast recognizes the file named setup.exe inside it as the problematic one.

As I already said, I downloaded the file from

http://asia.giga-byte.com/FileList/Driver/motherboard_driver_lan_realtek_8111_vista.exe

Please, I would like to know if this is really a problematic file, or a false alarm (of several engines according to VirusTotal).

Thank you very much.

4

I can’t say if this is definitely an FP, though 7 detections is high for a possible FP without info on what the others detected we can’t give any confirmation one way or the other.

You could have posted a link to the VT results, copy and paste the url from the browser address bar.

Send an email as outlined in reporting a possible false positive, giving an outline of the problem, a link to this topic (a link to the VT results would help) and a link to the source file as you have here.

Or you could send the whole installation file if it isn’t too large for you to send.

Send the sample to virus@avast.com zipped and password protected with the password in email body, a link to this topic might help and possible false positive in the subject.

Or you can also add the file to the User Files (File, Add) section of the avast chest (if it isn’t already there) where it can do no harm and send it from there (select the file, right click, email to Alwil Software). No need to zip and PW protect when the sample is sent from chest. A copy of the file/s will remain in the original location, so any further action you take can remove that.

5

for me and my pal this problem!!! :‘( :’( :‘( :’( :cry:

6

Then follow the same directions.
Upload to VT and report findings, etc.

7

DavirR, first of all, thanks. Now, I’m sorry that I didn’t post the exact link, but I think with the data I already posted anyone in avast support team or any user willing to help could follow exactly what was happening.

Nevertheless, here’s what I did (and anyone could do it again with this data):

1- Open http://www.virustotal.com/buscaHash.html
2- Paste there the sha1 hash: 903F186B11374CDB4FEAB089704C47DEDFEAB3A5
3- Take a look at the results

Since VT requests some code to be entered before checking the hash info, I think I can’t give you a simple link, but following these directions is simple enough for anyone willing to help. Moreover, with these steps anyone could check the most updated results, instead of just seeing my first results (last time I checked it was already 7/36).

If the support team wants to improve Avast, and to check if this is a FP or not, they could download the file from the address I already gave, and here is again:

http://asia.giga-byte.com/FileList/Driver/motherboard_driver_lan_realtek_8111_vista.exe

Also, in this address you can replace the first word “asia” with “china”, or “america” or “europe”. There is no need to emails, zips, passwords…

Bear with me, please. I gave all the needed details to resolve this. Think about this: if the file was uploaded in gigabyte’s site on 2008-07-25 (or sth like that), then this potential trojan is spreading, without gigabyte’s people knowing it. I already send them an email, but I think Avast support team would also want to improve this issue.

DavidR, thank you for your help. If you or anyone else could get the Avast support team to check the file and the VT reports, that would be great. I’ll be very thankful.

8

this fp will be fixed with next VPS update…

9

I’m just an avast user like yourself and it is my approach that the more we do to help the quicker it is likely to be analysed and resolved.

That looks to have taken place already though.

10

DavidR and Maxx_original, thank you very much.

In the meantime, I took a chance, and extracted the setup.exe from the archive, but not runing it. Instead, I used some zip utility to read the archive, and extracted just the setup.exe. Since I have Avast also configured to check any task done by the zip utility, again a message about the trojan pop up, as I expected.

I then move the setup.exe file to the c:\suspect folder, and took its hash info. I checked this in VT as before. This file is way smaller than the whole archive. Here the relevants results of VT:

File Setup.exe received on 08.17.2008 03:32:18 (CET)Antivirus Version Last Update Result
Avast 4.8.1195.0 2008.08.15 Win32:Trojan-gen {Other}
BitDefender 7.2 2008.08.17 DeepScan:Generic.Malware.P!Pk.F2DDCE78
Fortinet 3.14.0.0 2008.08.16 PossibleThreat
GData 2.0.7306.1023 2008.08.16 Win32:Trojan-gen
Ikarus T3.1.1.34.0 2008.08.17 Win32.SuspectCrc
Norman 5.80.02 2008.08.15 W32/Agent.GQGL
Sunbelt 3.1.1546.1 2008.08.15 Trojan.Agent

Additional information
File size: 211464 bytes
MD5…: 7a046dc9d808a0002396a686063dc6bb
SHA1…: ffdd6ac0528da60a0b8a8ca2e4c09be96156bbc6
SHA256: 527d02f13c1648657795c305c2048833bb8c614637e1731912334478b5e21388
SHA512: 0e8351a1820af129fe4647e0be4e432b444518e080ff5d77a6fc7009d6ad87e5
6e89e04329386b59879e713743ad32dbe66fa352b24baec9944faf72fd67ba4a
PEiD…: Armadillo v1.71
PEInfo: PE Structure information

( base data )
entrypointaddress.: 0x409ec3
timedatestamp…: 0x467b9618 (Fri Jun 22 09:27:52 2007)
machinetype…: 0x14c (I386)

( 4 sections )
name viradd virsiz rawdsiz ntrpy md5
.text 0x1000 0x20786 0x21000 6.55 428a2ae430e6ccaa2db47388ea7962c9
.rdata 0x22000 0x842a 0x9000 4.55 77aafdeedd4bc0f593dafe179fc8ecbc
.data 0x2b000 0x6548 0x3000 3.31 478f458e2048021ad74d89185d160b57
.rsrc 0x32000 0x3e20 0x4000 4.30 511d16a3188ec9a90cc093b359606298

( 11 imports )
> KERNEL32.dll: TerminateProcess, GetStartupInfoA, ExitProcess, RtlUnwind, GetCommandLineA, HeapAlloc, RaiseException, HeapFree, HeapReAlloc, GetACP, GetTimeZoneInformation, UnhandledExceptionFilter, FreeEnvironmentStringsA, FreeEnvironmentStringsW, GetEnvironmentStrings, HeapSize, SetHandleCount, GetEnvironmentStringsW, HeapDestroy, HeapCreate, VirtualFree, VirtualAlloc, IsBadWritePtr, LCMapStringA, LCMapStringW, GlobalHandle, LeaveCriticalSection, GlobalUnlock, IsBadReadPtr, IsBadCodePtr, SetStdHandle, SizeofResource, CompareStringW, SetEnvironmentVariableA, FileTimeToSystemTime, GetTickCount, FileTimeToLocalFileTime, GetCPInfo, GetOEMCP, SetErrorMode, GetFileTime, GetProcessVersion, GetFileSize, GetFileAttributesA, GlobalAddAtomA, GetVersion, GlobalGetAtomNameA, GlobalFindAtomA, GetModuleHandleA, GlobalFlags, lstrcatA, WritePrivateProfileStringA, LocalReAlloc, MulDiv, TlsGetValue, GlobalReAlloc, TlsSetValue, EnterCriticalSection, GetStdHandle, TlsFree, lstrcmpiA, GetCurrentThread, GetCurrentThreadId, CreateToolhelp32Snapshot, Process32First, Process32Next, GetLastError, OpenProcess, CloseHandle, LoadLibraryA, GetProcAddress, GetCurrentProcess, FreeLibrary, GetVersionExA, GetModuleFileNameA, SetCurrentDirectoryA, WinExec, GetStringTypeA, DeleteCriticalSection, TlsAlloc, GetProfileStringA, InitializeCriticalSection, LocalAlloc, GetThreadLocale, GetFullPathNameA, GetVolumeInformationA, FindFirstFileA, FindClose, lstrcpyA, SetEndOfFile, UnlockFile, LockFile, FlushFileBuffers, SetFilePointer, WriteFile, ReadFile, CreateFileA, DuplicateHandle, lstrcpynA, SetLastError, FindResourceA, LoadResource, LockResource, GlobalFree, FormatMessageA, LocalFree, MultiByteToWideChar, WideCharToMultiByte, lstrlenA, InterlockedDecrement, InterlockedIncrement, GlobalLock, GlobalAlloc, GlobalDeleteAtom, lstrcmpA, GetStringTypeW, SetUnhandledExceptionFilter, GetFileType, CompareStringA, Sleep
> USER32.dll: InvalidateRect, InflateRect, RegisterClipboardFormatA, PostThreadMessageA, CreateDialogIndirectParamA, EndDialog, MessageBeep, GetNextDlgGroupItem, SetRect, CopyAcceleratorTableA, CharNextA, LoadStringA, GetSysColorBrush, LoadIconA, UpdateWindow, MapWindowPoints, GetSysColor, SetActiveWindow, IsWindow, AdjustWindowRectEx, GetClientRect, CopyRect, GetTopWindow, IsChild, WinHelpA, GetClassInfoA, RegisterClassA, GetMenu, GetSubMenu, GetMenuItemID, DefWindowProcA, DestroyWindow, CreateWindowExA, GetClassLongA, SetPropA, GetPropA, CallWindowProcA, GetMessagePos, GetForegroundWindow, SetForegroundWindow, RegisterWindowMessageA, OffsetRect, IntersectRect, SystemParametersInfoA, IsIconic, GetWindowPlacement, SetFocus, ShowWindow, MoveWindow, SetWindowLongA, GetWindowTextLengthA, IsDialogMessageA, SendDlgItemMessageA, GetDlgItem, GrayStringA, DrawTextA, TabbedTextOutA, EndPaint, BeginPaint, GetWindowDC, ReleaseDC, GetDC, GetMenuItemCount, GetWindowTextA, SetWindowTextA, GetDlgCtrlID, GetWindowRect, PtInRect, GetClassNameA, ScreenToClient, ClientToScreen, GetDesktopWindow, LoadCursorA, GetCapture, GetSystemMetrics, CharUpperA, wsprintfA, MapDialogRect, SetWindowPos, GetWindow, SetWindowContextHelpId, DestroyMenu, GetMessageTime, RemovePropA, UnhookWindowsHookEx, GetMenuCheckMarkDimensions, LoadBitmapA, GetMenuState, ModifyMenuA, SetMenuItemBitmaps, CheckMenuItem, EnableMenuItem, GetFocus, GetNextDlgTabItem, GetMessageA, TranslateMessage, DispatchMessageA, GetActiveWindow, GetKeyState, CallNextHookEx, ValidateRect, IsWindowVisible, PeekMessageA, GetCursorPos, SetWindowsHookExA, GetParent, GetLastActivePopup, IsWindowEnabled, GetWindowLongA, EnableWindow, SetCursor, SendMessageA, PostQuitMessage, PostMessageA, MessageBoxA, DrawFocusRect, UnregisterClassA, HideCaret, ShowCaret, ExcludeUpdateRgn, DefDlgProcA, IsWindowUnicode
> GDI32.dll: GetDeviceCaps, GetViewportExtEx, GetWindowExtEx, CreateSolidBrush, PtVisible, RectVisible, TextOutA, ExtTextOutA, Escape, GetObjectA, GetTextColor, GetBkColor, DPtoLP, LPtoDP, GetMapMode, PatBlt, CreateDIBitmap, CreateCompatibleDC, BitBlt, GetTextExtentPointA, IntersectClipRect, GetClipBox, ScaleWindowExtEx, SetWindowExtEx, SetViewportExtEx, OffsetViewportOrgEx, ScaleViewportExtEx, SetMapMode, SetTextColor, SetViewportOrgEx, SetBkColor, SetBkMode, SelectObject, RestoreDC, GetStockObject, DeleteDC, SaveDC, CreateBitmap, DeleteObject
> comdlg32.dll: GetFileTitleA
> WINSPOOL.DRV: ClosePrinter, DocumentPropertiesA, OpenPrinterA
> ADVAPI32.dll: RegCreateKeyExA, RegCloseKey, RegOpenKeyExA, RegSetValueExA
> COMCTL32.dll: -
> oledlg.dll: -
> ole32.dll: CoFreeUnusedLibraries, OleUninitialize, OleInitialize, CoTaskMemFree, CreateILockBytesOnHGlobal, StgCreateDocfileOnILockBytes, CoGetClassObject, CLSIDFromString, CLSIDFromProgID, StgOpenStorageOnILockBytes, CoRegisterMessageFilter, CoRevokeClassObject, OleFlushClipboard, OleIsCurrentClipboard, CoTaskMemAlloc
> OLEPRO32.DLL: -
> OLEAUT32.dll: -, -, -, -, -, -, -, -, -

( 0 exports )

I hope this will help. Keep the good job, and again thank you very much for your help.

11

You’re welcome.
Yes, it looks like most of the detections were generic or heuristic, which are more prone to false detection.

Shouldn’t be long before it is corrected in the next VPS update.

12

Ok, so the VPS dated 2008-08-19 doesn’t complain about the setup.exe. Thanks. But now I have another problem with avast chest.

I restored the file from the chest, and according to the chest manual (help), the file shouldn’t be in the chest anymore. Well, maybe technically the file is not in the chest, but the row pointing to it is still there in the list.

So maybe someone could doublecheck what it is suppose to happen? If the file is listed in the chest, is that mean that is still in the chest? Or this is just a list of whatever was/is there at any point of time?

How do I suppose to know the difference between a row (file) that is still in the chest, and one that is just listed but its issue was already resolved?

13

A copy of the file is retained in the chest after restoration, check that the file is back in the original location and delete the one in the chest.

Contrary to the help file I have found the above to be correct, a copy is retained (just tested that) on restoration.

Personally I feel that this is the best way to do it as if there is a problem restoring the file to its original location, auto deletion from the chest could mean you have no copy of the file at all. Better to confirm it is in the original location before deleting the copy in the chest.

14

DavidR, once again thanks. I would like to comment about your answer.

First, the same way Avast can make several checks, deletions, move files and so on, it should be able to check if the file was restored correctly. Moreover, if by any chance there was a problem restoring it, Avast should be able to simply give a message about it, offer to open the folder, and leave the file in the chest. In case the folder isn’t there anymore, then the error message itself should enable the user to copy the path to the original location. This should help the user to open the (parent) folder in windows explorer for troubleshooting purpose. Another option should be Avast offering to copy the file to another location just from the error message.

Moreover, Avast could offer to open the folder where the file was restored just after the restoration process ends. This should be optional, as a question message after the restoration process or sth alike (I am also thinking about somebody with several files to restore, where 1 message for each file could be somehow annoying). In other words, Avast should give the user some indication of the success or failure of the restoration process, and from there also give some available options, including “cancel”. As it is now, the user doesn’t really know what happened, if the restoration was successful, or if he should take some action.

Opening the original location or the alternative location where the file was copied is very important, in case the chest would really delete the row with the information about the file. Suppose for a moment that Avast was really deleting the row in the chest as the help manual says. If the file was restored to some long-path location for example, maybe the user will get into some trouble to find it. This is, IMO, the most important reason to leave the row there in the chest, at least as information, instead of deleting it automatically and immediately.

So I guess part of this post could be taken as feature suggestions. Conservatively, the real behaviour of Avast, leaving the row in the chest, is welcome. But if this is the expected behaviour, the help manual should be corrected. In its current state, this difference between the help manual and the real behaviour just confuses the user, as I got confused when I suppose sth strange was happening.

Finally, I would like to suggest that the row in the chest would be copied automatically to some log. The row in the chest would disappear when the user manually deletes it, and a “history” category (left pane) in the chest would allow the user to see the previous deleted row while differentiate it from a current actual real row in the chest. A row in this “history” category would be just informative text (log), i.e. it doesn’t include the real file, so HD space is not wasted.

Since you have more experience using the forum, please feel free to copy any of these suggestions to the appropriate forum’s category. Thank you, and to all others that are helping other users like me.

15

Would you rather take the risk of the loss of a file, reported or otherwise, I know I wouldn’t, computers are fickle things.

To avoid confusion I don’t work for Alwil but an an avast user just like yourself with no power over how avast works. I’m merely reporting what happens on my system to confirm what happened with you, regardless of what was said in the help file and why ‘I think’ avast may do it that way.

There is a Sticky Topic for features/suggestions for upcoming major updates in the avast 4 Home/Pro forum. I’m not a forum moderator so have no power to move/modify topics.

16

DavidR, maybe I wasn’t clear. As I said in my previous post:

“the real behaviour of Avast, leaving the row in the chest, is welcome”

“If the file was restored to some long-path location for example, maybe the user will get into some trouble to find it; or he could leave the task for some time and want to continue it later. This is, IMO, the most important reason to leave the row there in the chest, at least as information, instead of deleting it automatically and immediately.”

So, DavidR, I agree with you, but as I said before:

“But if this is the expected behaviour, the help manual should be corrected. In its current state, this difference between the help manual and the real behaviour just confuses the user, as I got confused when I supposed sth strange was happening.”

Moreover, I made some suggestions to improve, whether the devs will choose to continue the current chest’s behaviour or any other one.

About posting a feature request, anyone can copy this text and post it as a feature suggestion. The mods could move the topic, but it wasn’t really a feature suggestion one - not originally though. So anyone - yes, including me, yourself and/or the mods - could just copy the appropriate text to a new topic in the appropriate category or sticky, or just point some link there to this topic. I was just saying I wouldn’t mind anyone else doing it. Mods, be my guess :slight_smile: And thank you.