UNACEV2.DLL: Broken.Executable FOUND

My ClamWin Antivirus Portable found Broken.Executable while scanning memory
What’s this? 8)

Scan started: Tue Feb 20 15:21:03 2007

*** Scanning Programs in Computer Memory ***

*** Scanned 43 processes - 433 modules ***

*** Computer Memory Scan Completed ***

C:\Program Files\Alwil Software\Avast4\UNACEV2.DLL: Broken.Executable FOUND

– summary –

Known viruses: 90299

Engine version: 0.88.7

Scanned directories: 0

Scanned files: 476

Infected files: 1

Data scanned: 163.11 MB

Time: 122.215 sec (2 m 2 s)


Completed


Thanx
Regards

There’s nothing wrong with unacev2.dll in avast! - so I guess it’s an incorrect report from ClamWin.

Here’s a little information from the ClamWin forum

http://forums.clamwin.com/viewtopic.php?t=513

Broken.Executable is not a virus, it indicates an exectable file which does not conform to Windows Portable Exectable specifications. You can safely turn detect broken executables feature off.

http://forums.clamwin.com/viewtopic.php?t=709&highlight=broken+executable

... it detects that the file has broken PE (executable file) structure, which can be normal.

Usually we advise not to enable “Detect Broken Executables” option just for the sake of it. Tha’s why it was placed in the advanced section

Well, I was trying to say that unacev2.dll is used by avast! - and the operating system doesn’t seem to have any problems loading it. So, its structure probably isn’t really corrupted.

We patched unacev2.dll so it doesn’t display any warning message boxes when it unpacks old 1.x archive versions – but checksum value (inside PE header) is valid.

The file might be marked as suspicious or corrupted, because I’ve noticed Virtual Size for PE sections equals to zero. It should be greater than or equals to SizeOfRawData value, right Igor? .bss sections (and others) are used to have SizeOfRawData = 0, VirtualSize >> 0 and other changes…

Well, I admit it’s strange, but it’s OK for the OS.
When VirtualSize is 0, the value of the physical size is used instead.

In other words the Virtual Size or Total size of the section when loaded into memory, if the value is greater than Size of Raw Data, the section is zero-padded. This field is valid only for the executable images and should be set to 0 for object files. Now Size Of Raw Data of the section which is the object file or the size of the initialized data on the disk which is the image files. For executable image, this must be a multiple of File Alignment from the optional header. If this is less than VirtualSize the remainder of the section is zero filled. Why? Because this field is rounded while the VirtualSize field is not, it is possible for this to be greater than VirtualSize as well. When a section contains only uninitialized data, this field should be 0…

Well, the reality is slightly more complicated than the specs :wink:
Anyway, as I said - when VirtualSize of a section is 0, the value of the physical size is used instead (for VirtualSize).

clamav report
http://www.chillitickets.com/images/forum/smile_sad.gif

LibClamAV debug: Section 3
LibClamAV debug: Section name: .bss
LibClamAV debug: VirtualSize: 0
LibClamAV debug: VirtualAddress: 0x12000
LibClamAV debug: SizeOfRawData: 215552
LibClamAV debug: PointerToRawData: 0x0 (0)
LibClamAV debug: Section’s memory is writeable
LibClamAV debug: ------------------------------------
LibClamAV debug: Possibly broken PE file - Section 3 out of file (Offset@ 0, Rsize 215552, Total filesize 75776)
o:\UNACEV2.DLL: Broken.Executable FOUND

it says, SizeOfRawData (= section size) is out of file; the file is not compressed internally and it seems the value is probably invalid. The file is from the latest WinACE archive, according to author’s words it was compiled with Watcom compiler, maybe we could fix it to the next version. BSS section is used to hold uninitialized variables or common storage.