Universal Extractor

[Camarade_Tux]

I'm having problems extracting latest GOM Player setup; I think this wasn't a problem with version 1.2.1. The program hangs at Extracting files from: 7-Zip Installer pacakage. If I cancel the operation not all files are extracted.

Working with 1.2.

I also wanted to say, 1.3 installer could not be extracted with UniExtract1.2.

And, indeed, 1.3 does not work with this player.

[Hanschke]

here i got an error message:

[nitro322]

It appears that it calls PEiD 3 times (in this particular case; for other files it only calls it once or twice). After that, the error message box appears. Most likely it's a Win9x issue, as the Dependency Walker log reveals missing functions in some modules (log attached below).

PEiD is supposed to be called 3 times if the filetype isn't obvious. UniExtract runs PEiD in three different modes (deep, hardcore, and external), and then takes action based on the results of the three scans (each scan can return different results). This is new behavior in 1.3.

I agree, it's most likely a Windows 98 issue. I have two statements here (please read both fully):

1. I do not and really can not support Windows 9x. I haven't done anything that should explicitely prevent it from working, but I don't have access to any system running Windows 9x, and vendor support for all Windows 9x systems (including security fixes) ended on 06/30/2006. Because of this, any system running Windows 9x really should be upgraded (or migrated to another OS, such as Linux), and as a security professional I cannot justify officially supporting an end-of-life'd OS.

2. With that said, I do understand that some people simple cannot upgrade or migrate to a newer OS, and I have no intention of simply ignoring them. I'll look into this issue when I have the time, and will try to fix the problem if possible. I'll post back once I've had a chance to investigate this further.

The error log location is 'hard coded' to the root of C:\, but different users will have different preferences and disk layouts. Could you include a means for us to change that location, perhaps to any/all of: the Universal Extractor installation directory; or the starting location for the extraction; or the target location for the extraction; or just anywhere the user prefers?

Actually, it's not harcoded to C:, it's hardcoded to the root of your %SYSTEMDRIVE%. This will ensure that the file always gets written, even if Windows is installed on your G: drive. I chose %SYSTEMDRIVE% because out of all of the other possible locations (installation directory, temp directory, etc.) it's the quickest and easiest to get to if you need to view that file. The only other place I can think of that would be even easier would be your desktop, but I hate desktop clutter, so that's not going to happen.

Now, I do intend on reworking this in some way during the next major upgrade. I'm not sure what I want to do with it just yet, but making the location user-selectable seems reasonable. I'll keep it in mind.

I have no idea why, but the issue on 98SE is also on ME.

Yeah, I'd expect as much. I'm sure most of the people on this message board already knows this, but there are substantial difference between 9x-based systems (95, 98, and ME) and NT-based systems (NT, 2000, XP). Most likely either UniExtract or one of its components is calling some function that's only available on NT, so the same error message would appaer regardless of 98 or ME.

That's bad news. Maybe actually building the main exe on a 9x system could fix things. No idea if AutoIt does work on 9x and currently I have no free HDD space to install and test. Could you test it, nitro322, maybe in a virtual machine or something?

AutoIt does work under Windows 9x, but simply compiling it under 9x wouldn't make a difference. As I mentioned previously, there's probably some function call that requires NT, and I'll have to troubleshoot when I get some time.

Universal Extractor fails to extract the installer exe of the new version of yEnc32 (v1.0.7).

I can't get it to work, either. NSIS support is not at all complete; this looks like one of the unsupported types.

here i got an error message:

Based on the description (CAB SFX), this file looks like it should be supported, but I can't say for sure without testing the actual file. Can you provide a download link?

Edited September 18, 2006 by nitro322

[nitro322]

I'm having problems extracting latest GOM Player setup; I think this wasn't a problem with version 1.2.1. The program hangs at Extracting files from: 7-Zip Installer package. If I cancel the operation not all files are extracted.

Unfortunately, this is something of a known problem. The reason why is a bit lengthy, though.

UniExtract needs to do two things with program output - display it, so you know the current status and if there are any problems, and log it, so you can refer to it if there ARE problems. I use a program called tee to do this. I pipe all command output to tee, which essentially splits the data into two streams - one gets echoed to the screen, the other gets saved in the log file.

The problem is that cmd.exe apparently buffers its output. So, if I pass a short stream through tee, it won't be displayed until after execution completes. Alternatively, if I pass a long stream through tee, it won't display any text until the buffer has been exceeded.

So, how does all of this relate to the above problem? What's happening is 7-Zip is pausing for confirmation on something, and waiting for your input. However, because the output is buffered and hasn't been echoed to the console yet, you don't know that it's prompting you, or what it's asking.

I came across this issue while working on 1.3, and put in some workarounds to try to prevent it from occuring, but it's admittedly a hack and not a proper solution. There's bound to be some files out there that will trigger this situation, as you've found out. I have this on my todo list for the next major upgrade, just not sure how to handle it at this point.

In the meantime, I can offer a workaround. These apparent freezes usually occur because 7-Zip is asking for confirmation to replace a file. Some installers store multiple files that get output to the same location (eg, a 32-bit and 64-bit version of the same .exe). Only one gets "installed" during normal operation, but when extracting files from the installer like this the duplicates can overwrite each other. So, to workaround the issue, wait until it looks like 7-Zip is frozen (no new files are being written), then type 'a' into the console and hit enter (no quotes). That should tell it to overwrite any existing files, which should then make it continue extraction.

Warning - This workaround is NOT recommend if extracting to a directory that already contains files. You may accidently overwrite something else. I'd only recommend doing this if you're extracting files to a newly created subdirectory.

[maska]

Thanks for your detailed explanations, typing a in the console resolved the problem.

Btw, same problem occurs with Quintessential Media Player setup but that is resolved too.

[Hanschke]

@nitro322

this is a official ms download. here:

http://download.microsoft.com/download/b/b...lfile-de-de.exe

with /extract it works fine

[clavicle]

Great release after a long time!

Thanks!

[ggf31416]

So, to workaround the issue, wait until it looks like 7-Zip is frozen (no new files are being written), then type 'a' into the console and hit enter (no quotes). That should tell it to overwrite any existing files, which should then make it continue extraction.

Or u - Auto Rename

To nitro322: for 7-zip you can use -aou (auto rename extracting file) or -aot (auto rename existing file).

Edited September 18, 2006 by ggf31416

[Acheron]

I'm getting reports by Kaspersky 2006 that UniExtract.exe and ExttractMHT.exe matching Trojan-Downloader.Win32.Agent.axn signatures.

As I found out, these files are UPX compressed. Unpacking these files does not solve the issue. May I ask why you put UPX compression in? It's totally unneccessary for this program, and it slows down my system as well.

[Luka101]

IsXunpack has no problems with below file however Universal Extractor 1.3 cannot unpack.

http://ftp.ulead.com/pub/Updates/pi11/mdt21_eng.exe

[ggf31416]

I'm getting reports by Kaspersky 2006 that UniExtract.exe and ExttractMHT.exe matching Trojan-Downloader.Win32.Agent.axn signatures.

The false positives seem be fixed now. Kaspersky is having bad luck with the false positives.

As I found out, these files are UPX compressed. Unpacking these files does not solve the issue. May I ask why you put UPX compression in? It's totally unneccessary for this program, and it slows down my system as well.

You should ask that question in the AutoIT forums. AutoIT uses automatically UPX compression when the script is compiled.

[Camarade_Tux]

One quick word about UPX decompression : AutoHotKey uses upx.exe to compress the scripts it compiles. And if you use upx to expand these files, then you can't run them anymore (stupid CRC ?).

[MagicAndre1981]

New Version is out:

1.3, Released: 09/15/2006

Changelog:

Added support for UHARC archives

Added support for KGB archives, including encrypted and self-extracting archives

Added support for MHTML (.mht) files

Added support for Wise for Windows Installer installers

Added support for InstallShield 3.x archives (.z, .1, and .lib)

Added support for decompressing UPX and ASpack files, including .dll files

Added additional support for MSI files

Added additional scanning options for PEiD

Added external database support for PEiD

Added ability to choose context menu items in installer

Added support for compressed files (.??_) to installer

Added command line usage information to installer (run with /?)

Added application-specific support for McAfee SuperDAT updater and CMenu installer

Fixed support for Microsoft hotfixes

Fixed miscellaneous typos

Fixed RPM file association in installer

Fixed miscellaneous file association bugs in installer

Updated PEiD to 0.94

Updated 7-zip to 4.42 (still using 4.40 nsis.dll)

Updated UnRAR to 3.60

Updated Inno Setup unpacking to include embedded files

Updated Inno Setup support to include newer versions

Updated InstallShield support to include support files when using cache option

Updated file scanning to speed up filetype detection

Updated Zip support to include files compressed with bzip2

Updated Zip support to include .wz extension

Updated Microsoft CAB support to include .imf extension

Updated Wise and InstallShield filetype detection to yield more accurate results

Edited September 20, 2006 by MagicAndre1981

[cyberloner]

super software and keep up!

[nitro322]

this is a official ms download. here:

http://download.microsoft.com/download/b/b...lfile-de-de.exe

with /extract it works fine

Downloading now. I'll see what I can do with it.

To nitro322: for 7-zip you can use -aou (auto rename extracting file) or -aot (auto rename existing file).

Those are good suggestions. I'm currently using -aos in some cases (where I knew this could be a problem), but not all. Unless I can figure out a better way of handling this in the next version, I'll probably just switch to using one of these arguments everytime 7z.exe is invoked.

I'm getting reports by Kaspersky 2006 that UniExtract.exe and ExttractMHT.exe matching Trojan-Downloader.Win32.Agent.axn signatures.

This is a known issue with overzealous virus scanners. Check posts 123-150 or so of this thread.

As I found out, these files are UPX compressed. Unpacking these files does not solve the issue. May I ask why you put UPX compression in? It's totally unneccessary for this program, and it slows down my system as well.

That is correct. As ggf31416, this is the default behavior of AutoIt, and to be honest, I prefer this behavior vs. not compressing it. Smaller files are a good thing, and simply not compresing them is not that right answer. Making sure AV vendors get their act together is.

IsXunpack has no problems with below file however Universal Extractor 1.3 cannot unpack.

http://ftp.ulead.com/pub/Updates/pi11/mdt21_eng.exe

Thanks, will look into it.

One quick word about UPX decompression : AutoHotKey uses upx.exe to compress the scripts it compiles. And if you use upx to expand these files, then you can't run them anymore (stupid CRC ?).

Yeah, I've noticed this too with some, but not all, AutoIt scripts. I don't know why this happens, though. Can any UPX/AutoIt/AutoHotkey gurus answer this question? I'm rather curious about this myself.