nitro322

I'm sure you can find a thorough description of this process by searching the forum, but the short answer (off the top of my head) is that you first need to unpack the downloaded installer by running it, copying the installer files out of %PROGRAMFILES%\Adobe\Reader\Setup, existing the downloaded installer, then using standard Windows Installer switches on the .msi installer. In my case, my installation command looks like this: msiexec.exe /package "Adobe Reader 7.0.8.msi" /quiet /norestart ALLUSERS=2 Like I said, though, searc the forums and you can get much more detailed information, including links to pre-packaged silent installers.

Is there any reason you cannot use Automatic Updates for this? I understand the desire to disable the "automatic" part of it and require approval before installing anything (I do the same on my systems), but as a patch delivery mechanism it really works quite well. On my system, I have Automatic Updates set to notify me about updates, but NOT to automatically download or install them. I then run a command in my GuiRunOnce script that forces Windows to check for any updates using Automatic Updates immediately after installation is complete. I then browse through the updates available, select the ones I want, and tell it to install. It actually works very well. You can force Windows to check for updates using the following command (assuming that Automatc Updates is running): start /wait wuauclt /detectnow You can force Automatic Updates into notification-only mode with the following registry settings: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update] "AUOptions"=dword:00000002 "AUState"=dword:00000002 "ScheduledInstallDay"=dword:00000000 "ScheduledInstallTime"=dword:00000003 I know this doesn't exactly answer your question, but I hope it helps out.

There have been several reports of false-positives by anti-virus scanners over the last few months. Apparently it's been an issue with a lot of other AutoIt-based applications as well. In response they've put up a rather useful sticky post about this on the AutoIt forums. In addition to explaining the cause of the issue, they also provide links to to varios AV vendor feedback forms. If you encounter a false-positive by your AV product, I suggest using these links to notify your vendor that they made a mistake, and to request that the fix it in their next definition update. If this happens to UniExtract.exe in particular, you may want to to send them a link to my website (which contains the source code) and ask them to verify it themselves. This should help reduce the amount of false positives that people are reporting. Of course, if you haven't had to deal with any false positives yet, then feed free to ignore this post.

I found a couple programs that can supposedly do this, but one requires perl, and the other require python. I did find one other Windows GUI program that is supposed to be capable of this, but I didn't download it because it requires registration, which also means it likely isn't freely redistributable. This is the first time I'd ever heard of this. Unfortunately, though, I was unable to figure out any way to extract the files. This is also a new one for me. I've been able to determine that it's compressed using the same algorithm used by Microsoft's compress.exe and expand.exe (I forget the name, but it's common old format), so I can decompress the file, but I still can't figure out any way to extract the files out of the archive. I found a couple programs for Linux and Amiga that can do it, and a couple shareware programs for Windows, but nothing free. This is an old version of NSIS (Nullsoft installer) that is not supported. There is no technical way to extract files from these installers, as far as I'm aware.

Yeah, this is a false positive. Unfortunately, this seems to be a rather common thing, as AV vendors apparently don't understand that UPX is not used only by virus writers. You can refer back to posts 123-150 or so of this thread for more details about this. No guarantees, but I'll be happy to take a look at it. Can you please post a direct download link?

Please see post 259 for an answer to this question. That's not a bad idea - I'll add that to my list of options to explore for the next version.

Excellent! I've posted a link to it from my website. Thanks, Clippit.

I'll look into the other issues you reported when I get a chance. It actually does remember the last folder under NT. I tested and verified that it behaves as you say under 9x, though. I don't know how easy this would be to workaround without digging through the code, but it may just be a limitation of Windows 9x. Hmm... I just verified this as well. I've actually never noticed this before, but according to the AutoIt docs is seems to be another 9x limitation: Under Windows XP/2003 Windows will ajust the size of the opened combo. On other Windows versions you must define this size with the "height" parameter if the default value is not BIG enough to contain at least one line. Again, I'll take a look at this when I get a chance and see if I can work around it without wasting too much time. Thanks for the bug reports.

Both the c1pher.com download site and the legroom.net main site are currently up. I rebooted the legroom.net server around 2:00am this morning for a kernel upgrade, but it was only down for a few minutes. c1pher.com runs on a managed hosting provider, and I have not received any report of downtime on this server. Can you please check again? If you're still having problems with either site, please let me know.

Great! I'm glad you figured this out. Now that you mention it, I remember having trouble with this myself quite a while back. I ended up deleting the AutoRun value and just creating a hotkey shortcut to cmd.exe instead that drops me into the correct directory. It's been so long ago, though, that I'd completely forgotten about it. I can pretty easily fix this in future versions. The /d option for cmd.exe will disable the AutoRun value, which should solve the problem. Thanks for letting me know about this.

I just updated Universal Extractor to version 1.3.1. This is primarily a bugfix release for version 1.3, focusing on improved 7-zip support, improved "default" checks for unknown .exe files, and Windows 9x compatability. I also made a few other small tweaks and fixes. As usual, full details can be found in the ChangeLog. I updated the first post to reflect the new version.

Sounds interesting. I'll check that out when I start working on the next version.

Ok, I gotcha. That'd actually be pretty cool, but pretty darn difficult to implement. I don't think this is something I would/could ever do, but I'd certainly be interested if anyone else takes a crack at it.

Nah. There are already far better programs available that do this better than anything I could write. Besides, it seems to me that most people would prefer to stick with just one or two formats for archiving, in which case something that can support 27 methods of archiving really wouldn't do any good. The reason Universal Extractor is so useful is because it lets you handle content from other users, which is out of your control. Content that you create yourself is within your control, and therefore you can use your own preferred format and compression utility. Just out of curiosity, though, does anyone else see value in this? Am I missing the mark here? Edit: Woo-hoo! I'm a full-fledged "Member" now. And it only took 22 months. B)

Downloading now. I'll see what I can do with it. 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. This is a known issue with overzealous virus scanners. Check posts 123-150 or so of this thread. 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. Thanks, will look into it. 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.

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.

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. 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. 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. 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. I can't get it to work, either. NSIS support is not at all complete; this looks like one of the unsupported types. 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?

Will keep it in mind. Thanks. Oops. Fixed now, thanks for pointing it out. The reason it was still downloading v1.3 is because I created symlinks on the server to redirect requests for all older versions to the new version. Looks like that helped out this time. Excellent. I was going to post and ask you to try again with this version, but I see you didn't waste any time testing it out. Glad it's working for you. How often do you have to terminate UniExtract.exe manually? If this you need to do this on a regular basis, then there's a bug somewhere that should be fixed. Please share any details you can about this. Hmm... few suggestions: Can you send me a link to download that specific NSIS package? I can tell you for sure if it's supported or not. Can you try extracting the AutoIt installer? This one is definitely supported. Please let me know what happens. What happens if you try extracting a simply Zip file? You also mentioned that you're running Windows 98. To be honest, I've never testing this on anything prior to Windows 2000, so I don't know if or how well it works on older 9x-based systems. Has anyone else on the board tried using it under Windows 98? Can you share you experience?

I just released version 1.3. I updated the first post in this thread to include the changes, as well as link to the downloads and official site. Enjoy!

Good suggestions, freeko. I started looking into this, and here are my initial thoughts: EML - These files do not behave the same way as regular MHT files. The most noticeable difference is that they contain two separate boundaries, one nested within the other, which really wreaks havoc with my script. I started playing around with this and implementing some preliminary ideas, but right now it looks like this will take too much work to support properly without enough payoff. If this proves to be a popular request I may add it to a future version, but I'm going to hold off for now. One other issue is that there are apparently different standards for .eml files. The .eml files saved by Thudnerbird, for example, are standard mbox files, drastically different than these (which, I presume, were created with Outlook Express). IMF - I've never heard of this before, but if it's nothing more than a renamed cab file, then support is simple. It'll be included in 1.3. db & dbx - I don't really know what to do with this. What are .db and .dbx files? From the description on the sites you linked to I'm guessing they're Outlook Express files, but I really don't know for sure. If they are, what exactly would you want to do with them? IE, how does this fit in with Universal Extractor's stated purpose of being able to extract files from archives and installers?

FYI: I've released the final version of extractMHT. I will include it in Universal Extractor, but if anyone wants a standalone copy for any reason they can download it from that link.

hp38guser, this looks like it might contain some good stuff, but a large list of random executables with no descriptions is a bit difficult to work with. Are there any particular apps in that list that you think would be a good fit for Universal Extractor? If so, please suggest them and I'll investigate. Thanks.

Thanks to those that volunteered to help out. I'm going to respond with a PM containing the link to the download shortly. Here's the ChangeLog for 1.3 beta: Added support for UHARC archives Added support for KGB archives Added support for MHTML (.mht) files Added support for Wise for Windows Installer files Added support for InstallShield 3.x archives (.z, .1, and .lib) Added support for decompressing UPX and ASpack files Added additional support for MSI files Added additional scanning options for PEiD Added external database support for PEiD Fixed support for Microsoft hotfixes Fixed miscellaneous typos Updated PEiD to 0.94 Updated 7-zip to 4.42 (still using 4.40 nsis.dll) 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 Wise and InstallShield filetype detection to yield more accurate results The most important features that need testing are Wise, MSI, and InstallShield installers. I changed quite a bit in those sections, so it's important that they get tested against as many different types of installers as possible to make sure I didn't break anything. I'm also, of course, interested in any other feedback you could provide concerning the beta. Does support for the various new archive types work as expected? Etc. I'd really appreciate it if you could get your testing results back to me by the end of the weekend. If you don't find any problems at all, please let me know that as well. I'm going to try to prepare the final version for posting early next week. Thanks!

Ok, I've made some fairly substantial changes so far, particular regarding PEiD usage and InstallShield and Wise support, so I think I'm going to go ahead and release version 1.3 sooner rather than later, and push back the rest of the changes to the next version. However, before I do a public release, I'd like to have a couple people beta test it to make sure I didn't do anything stupid with some of the changes I've made. If you're interested, and you're actually willing to help test and send me feedback, please send me a PM. I'm going to spend a bit more time working on this tonight to polish it up, but the beta should be ready to go by tomorrow. Assuming all goes well, I'll probably release the final version after the weekend. Note: This will be a very short beta. Don't look at it simply as an opportunity to get the program early. Please only PM me if you truly want to help. Otherwise, just hold off a few more days to download the final version. I want to make sure everything's in tip-top shape before I publish it. So, if you're interested, please let me know. I'm going to clean up the ChangeLog and post it, so everyone knows what changes were made and need the most testing. Thanks.

Thanks, freeko. Just to clarify earlier comments, these files can also carry a .z extension in addition .1 and .lib, correct?