Jump to content


  • Posts

  • Joined

  • Last visited

  • Donations

    0.00 USD 
  • Country

    United States

Everything posted by Queue

  1. Adding some info to this slightly aged thread; I haven't posted here in forever, but after a week of headaches I wanted to share my results for any other 9x users with some form of SiI3112/3512 SATA card. Ok, so here's the setup: I've had a SiI3512 chipset SATA card in my 98SE computer for something like 3 years. It handles a single 500 GB Western Digital hard drive. Up until today, it had firmware 4.3.84 (RAID-capable firmware) and I was using driver version (the highest version of 9x-compatible drivers that went with the RAID firmware). I had over 300 GB of data on the drive, and no problems. Then I made a decent sized data backup, adding another 45 GB to the drive. The file transfer was successful. But there was a problem: reading some of the newly written files off the drive would error, and then massive (apparent) file name corruption would occur. Visually, it looked like the >127 GB issue where you wind up with corrupt folder and file names. Obviously this was terrifying (I have a backup of all the data, but still, terrifying). I ctrl+alt+deleted twice to do a soft reboot. Once back in Windows, the drive appeared unharmed. Files were there, file names were correct, etc. However, if I tried to read some of the new files, the problem would occur again, and it required a Windows restart to fix. I couldn't restart Windows properly (or shutdown) without a hang (while I could before this recent addition of 45 GB of data). I was then busy, seeing as this was Thanksgiving week, so I avoided aggravating the problem by adding or deleting files on said drive. During any free time, I scoured the internet for what information I could find about the SiI3512 chipset, particularly pertaining to 9x (which of course was basically all from MSFN). After mulling it over, sifting through driver .inf's to check for 9x entries, and making certain the 3512 and 3112 firmware was interchangeable, I did the following: - Flash the firmware to version 4.2.84 (this is the non-RAID equivalent to the firmware I had been using). - Use driver version (these drivers are 3 years older than the drivers I'd used previously, and the non-RAID version). This appears to have fixed my problem. I can read any of the new 45 GB of files without triggering a failure, and notably they all appear to have been written without error. All other files on the drive that I've checked have been fine. I switched to the non-RAID firmware because I wasn't ever going to use the RAID feature and the non-RAID firmware has a shorter delay during system boot (so I boot 2 seconds faster, woo). I switched to an ancient version of the drivers simply because when you search the Silicon Image website for SiI3x12 Win9x drivers, it specifically only shows that one driver version. The non-RAID drivers that match the RAID drivers I was previously using would be version, and they should load under 9x, but seeing as I just got the problem to go away, I haven't tested any other non-RAID drivers yet. I may feel adventurous next week and try all drivers between and including to, but for now I just wanted to report that there may be an issue with version of the RAID-capable drivers on Win9x. Keep in mind that driver version numbers are a mess for the SiI3x12 chipset: the RAID and non-RAID drivers have different numbering, and the Silicon Image driver listings and numberings have typos. Queue
  2. Give FastCopy a whirl then: http://ipmsg.org/tools/fastcopy.html.en Queue
  3. Whoops, my mistake. I was totally wrong about the ''CWD'' and I was over-simplifying when I said the path environment variable. The folders in that list generally are in your path environment variable as well, so rather than name them out I was lazy. Queue Edit - http://msdn.microsoft.com/en-us/library/ms682586(v=VS.85).aspx
  4. Okie dokey. Dencorso, I know the fix for XP+ has been out for like a month, that's what I meant: not that they've had time to make one, that it's been a month since the fix has been available. The fix I made is similar to the one linked early-ish in the LNK exploit thread, but I wrote it in MASM assembly, and haven't tested it rigorously to make sure its solid. Seeing as it's code used by Explorer for every LNK file, I want it to be perfect, hence why I haven't even made it (the fix) available for testing yet. I kinda threw it on the back-burner anyway since 9x hasn't been nor will be targeted for attack using it, but this thread reminded me about it. Queue
  5. This ''exploit'' (which arguably isn't one, unless I've been reading the wrong things) isn't exploitable in a ''drive-by'' fashion through web browsing. All this issue is is the order that Windows searches for DLLs when an executable wants to load one (aka DLLs that are dynamically linked and loaded when you execute an EXE). Generally, the working directory is where an EXE checks first for a DLL, then it goes through the folders listed in your path environment variable. Windows 9x is actually less vulnerable to this than the NT line; it tends to be more strict with ''known'' DLLs so that they're only loaded out of your system folders (DirectX DLL wrappers are far more finnicky on 9x than NT, for example). The ''exploit'' is to set the working directory for a given EXE to a folder that contains a malicious version of a DLL that EXE wants (you can do this with a shortcut with a modified ''Start in'' entry, for example), or to simply throw a malicious DLL in the folder with the EXE. This is expected Windows functionality, so to call it a vulnerability seems pretty asinine (and I'm guilty of doing this earlier in this paragraph). Really, the gist of this is: anywhere that this can be exploited, you could just as easily have a malicious executable, so why go through the trouble of hiding the malicious code in a DLL? The people that are vulnerable are going to fall prey to either situation. Speaking of vulnerabilities, no one seemed to act on that LNK vulnerability (which is actually a vulnerability), and XP+ has had plenty of time to get patched up, so I guess a 9x proof-of-concept is due now. wsxedcrfv, I'll probably just release an even more stripped down version of what I showed you (as in, with no empty space allocated that makes hex editing in a new target DLL easier). What are MSFN's rules about disclosing a proof-of-concept for the purpose of getting a fix hammered out? Queue
  6. It's no bug, it's so you can't post a super long ''word'' that would cause your post to be super wide. Any ''word'' longer than a certain length gets spaces inserted so it will wrap down a line. This is a common mechanism in lots of forum and comment posting systems on the internet. Queue
  7. Try FRAPS again. In its configuration menu, it has a checkbox labeled: ''Include framerate on screen captures'' Are you sure that's unchecked? Queue
  8. Have you tried just pressing the PrintScreen key, then loading up Paint and pasting in the image? And are you sure the game doesn't have its own screenshot hotkey? Sorry that I don't have any utilities to recommend, but all the games I play I can either take my own screenshots with PrintScreen, or the game has its own screenshot functon. =/ Queue
  9. The IPv4 address space can handle 4,294,967,296 addresses. Do you really think a single desktop computer will ever connect to that many unique addresses in its lifetime, let alone within the period of time such addresses would need to be cached? Queue
  10. If you're on dial-up the dial-up ISP could probably do the IPv6/IPv4 translation. Alternatively, a gateway that does the actual dial-up connection and understands IPv6 could do the translation for IPv4 machines connected to it. Queue
  11. http://www.12oClocker.com is where Iconize is from. Minimizer-XP seems to have been discontinued by its author, so this is basically it: http://www.softpedia.com/progDownload/Minimizer-XP-Download-19922.html Queue
  12. Minimizing to the tray isn't an inherent capability of Windows, it's something that has to be done by a program itself. Like you saw, there are a handful of utilities that allow minimizing other programs to the system tray, but the utility that manages minimizing other windows to the tray has to be running to enable that, and generally they themselves are going to have a tray icon so you can access their functions. The two that I've used on 98SE (and other versions of Windows) are Minimizer-XP and Iconize, but I doubt either is exactly what you're looking for and bet you've tried at least one of those already, if not both. Queue
  13. Alt + Print Screen works on 98SE, I use it all the time. Just have the window you want the image of selected, press the key combination, open something like Paint, and paste. Both Print Screen and Alt + Print Screen can be limited / impaired by some sort of resource limitations under various circumstances. Queue
  14. Without KernelEX, LnkIconShim is not applicable to 98. I'll get around to releasing my solution eventually, it just hasn't been very high priority for me to finish things up considering the small attack surface for 9x (for this exploit), lack of interest in attacking 9x and the general misinformation concerning 9x's vulnerability to the LNK exploit. Queue
  15. Neat, dencorso's first post was apparently in this thread. Kind've a weird thread to necromancy (and with a double-post no less), but whatever. Queue
  16. That's essentially the solution I have in the works, however, instead of discarding all control panel shortcuts, I'm simply validating them and only discarding ones that aren't literally pointing to a control panel applet in a proper location. I don't intend to make a 64-bit version however (but Microsoft should be covering all 64-bit versions of Windows anyhow). Pointing exploit shortcuts at some sort of warning icon is a good idea (and caches an icon for that shortcut leading to less icon retrieval attempts). I haven't found any vulnerabilities in PIF processing, but that doesn't mean there aren't any. I'd be curious if they're simply axing them too just to be on the safe side. wsxedcrfv, I can assure you 98SE is vulnerable, and I didn't have to convert a unicode shortcut to ansi, so you may be mucking something up during said conversion. When I made the initial control panel shortcut on XP, it was ansi-only when Windows created it (now I'm curious as to why); I didn't have to make ANY modifications other than changing the target of the shortcut. Luckily, actually abusing the flaw on 98SE is much more difficult since you can't use \\?\ paths to refer to a specific device (nor can you use relative paths). A control panel shortcut generated by 98SE doesn't automatically trigger the flaw without modification. Most control panel shortcuts generated by Vista don't contain a path whatsoever (they seem to refer to default control panel applets by index number or something). You can also simply mark a shortcut as read-only and 98SE won't modify it (instead of using read-only media to protect the file). Queue
  17. The Shell Item ID structure is only part of the LNK file spec; if, for the master LNK flags, the first bit is set (01), then the LNK file contains a Shell Item ID structure, which is necessary for code execution. I've never gotten a unicode path within a Shell Item ID structure to work on 98SE. So, more info: - You have to literally see an exploit shortcut for it to execute a DLL; if the LNK file is hidden and you don't have hidden files shown, or if the exploit shortcut is one file among many and if you need to scroll down in Explorer before you see it, it won't execute automatically (unless you show hidden files, or scroll down until you can see the file). This limits the capability of using 20+ LNK files, one for each drive letter, as in most cases many would be down far enough where you'd have to scroll down to see them. - Vista (and presumably 7) doesn't allow a shortcut to point to another shortcut. This isn't very important, just interesting. It will simply ignore and consider invalid such shortcuts. - The \\?\ path to a given flash drive is formatted very differently between XP and Vista/7, so to use such an approach requires a different shortcut file per version of Windows. This still means ~2 instead of 20+. I suspect malware that's out there uses such a method. I think I have a solution that works on all versions of Windows, that fixes this exploitable flaw, but I have more testing to do before I say any more. The gist of it is replacing the LNK file shell handler with one that filters out illegitimate control panel shortcut icon calls. At the very least I aim for it to be a solid fix for 9x and 2k; I expect Microsoft to fix things for XP, Vista and 7. Queue
  18. So, I've gotten one ''relative path'' setup working, but I've only tested it on XP (SP3, not that it matters) and 98SE so far, and it only works on XP. I specify the file path as \\?\STORAGE#RemovableMedia-etc. (it's a long identifying string). It has a device ID number embedded in the path, so it's specific to a given USB drive, definitely doesn't work on 9x, and I'm not positive the format doesn't change for newer versions of Windows (I'll get around to testing that Wednesday). It isn't machine specific though; I've tested it on multiple XP machines. One problem is the \\?\ path is used as the working path for any execution calls, so child processes (spawned by the executed DLL) have issues if they can't cope with that sort of path format. If I can come up with a simple way of converting the long \\?\ path to a normal drive letter in the DLL, then it'll be a more useful mechanism. Edit - A shortcut that references the exploit shortcut will also trigger the DLL to be executed, but a folder with its icon set as the exploit shortcut (via desktop.ini) won't trigger it nor will a drive's icon set to the exploit shortcut (via autorun.inf). So far I haven't found any real danger from this (shortcut pointing at shortcut), it's just interesting. Queue
  19. The exploit itself is a barely modified LNK file. It's not malformed or anything and not taking advantage of buffer overflows, errors in parsing, etc. It's simply a a poor design that is being exploited. It has to be a DLL, but it doesn't have to be specially crafted. The LNK file calls the DLL's main entry procedure (often called DllMain, but the name isn't relevant). For my test, my DLL file simply makes an API call to MessageBox in its DllMain procedure to spit out a message box to show it's been triggered. Also, it doesn't have to be named .DLL, it can have any extension, it just must be a normal DLL file. As to the third question, no clue why it's so stupid of a mechanism. - Something interesting, if you've seen any info about the original news of this exploit, the example showed 4 LNK files; my best guess is you can't use relative paths to access your DLL file so there are 4 LNK files targeting the 4 most common drive letters for a flash drive. If you start the file location with a backslash (\filename.dll) instead of a drive letter, it accesses the root of C drive (presumably your Windows drive) regardless of where the LNK file is. If I figure out a way to use a relative path for this exploit, I'll let you guys know. Currently, short of putting 20+ LNK files on the root of the flash drive, I'm not sure if there's a simple way to deal with variable drive letters. Queue
  20. First off, all you need is a VM. Keeping a separate computer just for 9x would be a waste. A VirtualPC 2007 98SE VM (in saved state) opens in 5 to 10 seconds. Secondly, you wouldn't need to write a separate version of the malware if you just follow reasonable programming practices when you write it in the first place. I'm not talking about something tied to the inner-workings of the OS like a rootkit to hide the malware, but the part of the malware that harvests info, etc. Alternatively, if you've been a bad guy for a while, you'd have old 9x malware that you wrote long ago that you can just bundle in. So, I've recreated the exploit LNK myself (the proof-of-concept had been made on a French install of Windows and the file path was unicode). After recreating the LNK file with an ANSI file path, I was able to get the exploit to work on 98SE, so 98SE is vulnerable as well. Demented fun-fact: on XP, the DLL is automatically executed 3 times when the exploit is triggered; only 2 times on 98SE. Queue
  21. Conversely, if all it takes is to throw an extra LNK file in and it expands your targets to include a group that will never have the vulnerability patched, the ROI might be acceptable. The most successful malware campaigns don't rely on a single exploit, but leverage as many as possible, including many that have been patched to try and catch unpatched systems. Queue
  22. It's using a rootkit to hide the files after the .LNK exploit has already been used to install the rootkit. The rootkit is just the payload and has no bearing on if the .LNK exploit works. So far, I haven't gotten the .LNK exploit to work on 98SE, so I'm thinking either 98SE isn't vulnerable, or the malformed .LNK file has to be made differently to affect 98SE. Edit - I did further testing and can confirm with certainty that the example exploit does not affect 98SE. That's not to say some other malformed .LNK file couldn't affect 98SE, but the flaw that's out there isn't a risk for 9x. I built my own DLL file to test with as the one included with the proof-of-concept won't function on Windows versions below 5 (9x is version 4) regardless. Edit - It's also worth noting that the exploit has to reference a DLL. A renamed executable won't work. Queue
  23. It looks like to test you'd put the shortcut and dll file in your C: drive's root folder, then browse to said folder. I haven't scrutinized dll.dll so don't know what it is (and I didn't test it). I tried copying calc.exe to C:\ and renaming it dll.dll and then using the shortcut, but on my 98SE machine, this didn't lead to code execution. I'll try on XP and Win7 later. From what I recall when I was messing with the shortcut file format a few months ago, the shortcut file looks like it might be a newer format than 9x uses, as in, the exploit may rely upon features added to shortcut parsing after 9x. Queue
  24. I know nothing about KEx versions older than 4.0. Based on what you said ISN'T there, would make sense for it to be an older version. Queue
  25. Registry entry at: HKLM\Software\KernelEx From what I recall, installing Flash 10 is slightly more involved than general use of KernelEx. For most programs, you simply right click their EXE, go to the Compatibility tab (which will only be there if KernelEx is installed), and uncheck ''Disable KernelEx extensions for this program'' and it's good to go. You rarely need to set a compatibility mode. Queue
  • Create New...