Jump to content

Queue

Member
  • Posts

    162
  • Joined

  • Last visited

  • Donations

    0.00 USD 
  • Country

    United States

About Queue

Queue's Achievements

1

Reputation

  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 1.0.60.0 (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 1.2.0.57 (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 1.3.67.0, 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 1.2.0.57 to 1.3.67.0, but for now I just wanted to report that there may be an issue with version 1.0.60.0 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
×
×
  • Create New...