Beta release: 1.6.0.4

[PepiMK]

Download: filealyz-1.6.0.4.exe (http://www.spybotupdates.com/files/filealyz-1.6.0.4.exe)

Changes:


Restored support for files > 4 GB (http://forums.spybot.info/project.php?issueid=272) (displayed file size; hex viewers are disabled for now)
Added UPX header information tab (http://forums.spybot.info/project.php?issueid=254)

[stevebow]

Although you mention above that the hex viewers are disabled for now, here they seem to be working fine for me.

Having said that, I have two audio codec .acm files in the System32 directory that FA 1.6.0.4 will not display in either of its hex viewers - the ac3filter.acm and lesser known xbadpcm.acm. Also, there are only 4 tabs appearing for these two files: General, OpenSBI, Security and Hex dump. The General tab just shows a "?" in all fields.

Is there any reason for this? I could put up these files if it would help any.

[PepiMK]

Since you mentioned you are using 64 bit Windows, I suspect a "simple" yet silly problem: Windows' method of accessing the System32 directory.

C:\Windows\System32\ is a different folder on 32 vs. 64 bit. If you use the 64 bit Explorer to call FileAlyzer, it passes the 64 bit path, but the 32 bit FileAlyzer will look up the file in the 32 bit folder.

A workaround would be to use a 32 bit file manager to call FileAlyzer (e.g. the 32 bit version of Windows Explorer as a separate window, or for example Total Commander, my preferred file manager), or call FileAlyzer from the start menu and open the file then.

[Rosenfeld]

I tried on a UPX compressed file, it asked for the external UPX.exe (which I happened to have). I thought from the features description for UPX tab that it is supposed to have its own UPX?

[Rosenfeld]

Corrected version of previous post (most of which somehow got deleted when I tried to post :-)).

Using filealyzer on a UPX compressed file:

First time: clicking yes on do you want to decompress and open for decompressed file as well, it asked for the location of upx.exe (which I happened to have).

Second time: I then closed both filealyzer windows, deleted the uncompressed file generated, repeated: did not ask to locate upx.exe (command window flashed on/off, presumably my upx.exe at work).

Third time: closed both filealyzer windows, deleted the decompressed file, moved my upx.exe to another location: again asked to locate upx.exe.

So Filealyzer remembers the location of the external upx.exeafter it has been told once, but does require it to decompress.

From the description of your http://support.microsoft.com/kb/915092/

I thought it should now have an internal upx decompresser?

[PepiMK]

Did you mean this link?
http://forums.spybot.info/project.php?issueid=254

Right now, our own UPX code is used only to display information about the UPX structure. Since our code has been tested on Windows executables only so far (sufficient for malware detection on Windows OS ;) ), the original upx.exe still has far more capabilities and allows to e.g. extract packed Linux executables as well.

[Rosenfeld]

Oops sorry for the wrong link (must have copied/pasted the wrong tab in IE) and thanks for explanation.

The file I tried it on is ADS Spy (which finds ADS streams). That's a small stand alone utility that runs in Windows.. zipped version attached

[stevebow]

Since you mentioned you are using 64 bit Windows, I suspect a "simple" yet silly problem: Windows' method of accessing the System32 directory.

C:\Windows\System32\ is a different folder on 32 vs. 64 bit. If you use the 64 bit Explorer to call FileAlyzer, it passes the 64 bit path, but the 32 bit FileAlyzer will look up the file in the 32 bit folder.
AIUI, the 64-bit path is System32 and the 32-bit path is SysWOW64?

So despite the fact I am looking at System32 in the 64-bit explorer, 32-bit FA instead looks for the file in SysWOW64, is this correct?

It would explain the problem with those 2 codecs as a copy of them do not exist in SysWOW64. Another "problem" file I came across in System32 is AdobePDF64.dll. A 32-bit version is not present in SysWOW64 either. Which would be silly using that filename anyway.

I guess the answer to this would be a 64-bit version of FA, or? Would a 64-bit version show info for the correct files in both System32 and SysWOW64 under the 64-bit explorer?

A workaround would be to use a 32 bit file manager to call FileAlyzer (e.g. the 32 bit version of Windows Explorer as a separate window, or for example Total Commander, my preferred file manager), or call FileAlyzer from the start menu and open the file then.
Now here's the odd thing. When I call FA from the start menu the file browser will display the contents of SysWOW64 regardless of whether it is looking at System32 or SysWOW64. Eh, what is going on here?

[PepiMK]

That's indeed Microsofts logical implementation of 32 vs. 64 bit - the 32 bit code is in a folder containing 64 in its name :D

That odd thing is "intended": from 32 bit applications, both folders are indeed "the same".

Imagine it this way:
The C:\Windows\SysWow64\ folder alwayws contains the 32 bit DLLs.
The C:\Windows\System32\ changes depending on the architecture of the calling application.

A 64 bit application of FileAlyzer would indeed help there, right :)
That's one point where we're unhappy about using Borland Delphi as our main development environment. The underlying language, Object Pascal, is - in my personal opinion - superior to C thanks to its safer string handling (sloppy string handling in C is one of the major reasons for security exploits in many applications, just watch for string buffer overflows in the news), but it still does not have a 64 bit environment available, though I hope it'll be part of the next release (otherwise I should finally spend some time porting it to a development environment that supports 64 bit, like FreePascal for example).

[stevebow]

Thanks for the clarification.

I do hope Borland release a 64-bit version of their dev environment soon!

Anyway, it looks like it is only a problem concerning the System32 directory. Something to be wary of...

[apetronic]

First of all thanks for a superb tool, i use it daily !! =)

I got a couple of brief question about future releases:
I noticed that you already have added (planned) support for detection rules.
Is there by any chance a API or other scriptbased-function, for developing homegrown plugins/detection/unpacking, planned for later releases (such as your upx-plug with detection/unpacking "all in one")?

And another question about identification of files, is there any possibility to add "dump to user-file/db" with readback to be able identify files in a similar way as eg PEiD. (to be able to add "identify/detect" for eg. bogus UPX-version or proprietary formats used in firmware and such)?

[PepiMK]

The detection rule thing for Spybot is already integrated, see the wiki (http://wiki.spybot.info/index.php/FileAlyzer#FileAlyzer) :)
As for the reverse effect, I've thought about integration the other round: the Spybot-S&D single file scanner as used inside SDFiles.exe; in the variant that prints every and not just the first scan result, this could be used to support any user-definable identification that is possible through advanced file parameters (http://wiki.spybot.info/index.php/Category:Advanced_file_parameters).

Custom packers? Hmmm. The problem right now is that pagkers are identified through code that's doing a lot of other identification stuff as well, and which isn't too extendable (through Extensions.ini only). In fact, we planed to compile UPX support into the main app even.

If you have specific packers you want supported, just let us know a few details. Which would be helpful to establish what would belong into a plugin structure as well.