ilko_t

Would samples only from XP format (right click on drive and format) and PEtoUSB be enough? I already have most of the files needed, just need to do it with F6 written prior to format. PEtoUSB formats only AFAIK in FAT16 or FAT16x, would that be enough too? When stick is formatted by it boots every time, no matter when boot files are copied, or whether Hitachi driver is used or not (PEtoUSB senses the difference). Meanwhile- any ideas about

@jaclaz About binifix4.cmd- used it from winnt.sif I see the proper massages, answer YES to replace original boot.ini with boot.txt and get "the system cannot find the file specified. Could not find c:\windows\system32\boot.txt.", boot.txt is in root and looks ok, with all needed entries. About boot sectors- still having issues after winnt32 is run and files put on stick. Using Hitachi driver and format stick from XP no matter FAT16 or 32, copy ntldr, boot.ini and ntdetect.com - boots ok to boot.ini Run winnt32 with parameters to put files directly on stick- cannot boot stick at all, no matter FAT16 or 32, nor if boot files copied before or after winnt32. Interestingly, yesterday I managed somehow to make it working this way using FAT32, and the same routine, no flipping idea what it wants. Could try reverting bootsectors, but am tired of this. Format stick with PEtoUSB- no matter seen as fixed or removable, use the very same procedure to prepare stick, both boot files copied before or after winnt32 and all work great. MBR seems the same, geometry reported by PTEDIT32 is the same in all cases, bootsector changes the same way as when formated by XP and Hitachi driver used, but this time I get NO hangs at boot Anyway, will not keep trying format from XP, PEtoUSB does the job for me. Another question- any idea what could be the variable path for the USB stick during GUI part? I'd like not to copy boot_ren.cmd, undoren.cmd and binifix.cmd to system32 and edit txtsetup.sif, but rather put then on stick and call them directly from the relevant entries in winnt.sif. Could be done easily if the same letter is assigned to USB stick, but to make it universal variable path would be nice. @silacomalley- thanks for tip, I' ve been using Hitachi microdrive driver for a long time, never got permanent results about stick bootability, PEtoUSB and HP format tool always worked fine for me. ilko

You got me There could have been a format between snapshotting, however I am pritty sure the copies I have were made before and after Winnt32, which changes something in bootsectors. I am interested why and what actually was changed, as this affects sometime stick's bootability. I still cannot recreate the results every time. There must be something wrong I am doing between steps. Once I get everything working fine, next time stick won't boot at all, using the very same procedure. It could be the way I select boot files to copied, or have to fill the stick with FF, no idea yet. Will carry on tomorrow figuring out what's happening. Why winnt32 changes bootsector? And what exactly it changes, please as for novice in this field? Please ignore serials

I've been playing with winnt32 parameters to make the install easier. Here are some results: 1. Stick formated in FAT16, Hitachi driver used 2. Copy from XP SP2 ntldr, ntdetect.com, setupldr.bin and the custom boot.ini to the stick BEFORE anything else. 3. From I386 folder run /makelocalsource:all instructs Winnt32 to copy all additional folders as described in DOSNET.SIF. Could be useful to edit it in order to include/exclude files/folders to automate the process. /unattend:winnt.sif - useful when you have custom winnt.sif, if the needed answers are included Winnt32 carries out the process without a single prompt. If used the whole [unattended] section must be deleted afterwards, otherwise TEXT Setup will attempt to install on USB stick and recovery console won't be given as option. /syspart:U /tempdrive:U prepares the drive given for next stage and copies all necessary files and folders. NTLDR gets replaced by SETUPLDR.BIN, renamed to NTLDR. The custom BOOT.INI gets backed up as BOOT.BAK and a new one, including entries from the old is written: BOOT.INI before Winnt32 is launched [Boot Loader] Timeout=30 Default=multi(0)disk(0)rdisk(1)partition(1)\WINDOWS [Operating Systems] multi(0)disk(0)rdisk(1)partition(1)\WINDOWS="GUI Setup" /FASTDETECT BOOT.INI after Winnt32: [Boot Loader] Timeout=5 Default=C:\$WIN_NT$.~BT\BOOTSECT.DAT [Operating Systems] multi(0)disk(0)rdisk(1)partition(1)\WINDOWS="GUI Setup" /FASTDETECT C:\$WIN_NT$.~BT\BOOTSECT.DAT="Microsoft Windows XP Professional Setup" BOOTSECT.DAT is not created in C:\$WIN_NT$.~BT\, nor the folder is, nor in U:\$WIN_NT$.~BT\, TXT Mode will be launched by the renamed SETUPLDR.BIN anyway. Why it creates this entry is still unknown for me, may be for the GUI part, but when BOOTSECT.DAT will be created...? Perhaps during TEXT mode? Hard to test that as stick will be write-protected. Winnt32 also changes the bootsector on USB stick, however stick is still bootable. Copies of bootsectors before Winnt32 and after are attached, for stick formated in XP with FAT16 and FAT32. Jaclaz, please, will you have a look what was changed, and if you have an explanation why. I'll be testing the new BINIFIX tomorrow, thanks for it. NTLDR (the renamed setupldr.bin one) must be rewritten with normal NTLDR in order to use boot.ini. txtsetup.sif is put on root by Winnt32, no need to manually copy it. 4.Used Jaclaz's makeBS.cmd to add a new entry in boot.ini and get a patched for SETUPLDR.BIN boot sector. No issues at all. Please don't forget to put a new copy of NTLDR on root, replacing the renamed setupldr.bin. Also setupldr.bin MUST be copied on stick right after format, or it may not be visible for the boot sector. In this way I believe would be much easier to perform preparation, even at some point by a script, as not too much is to be changed/added. Sorry if I made it too detailed, trying to be as much informative as possible. ilko FAT16_FIXED_XP.zip FAT32_FIXED_XP.zip

@biohead- I believe your answers are here: http://blogs.msdn.com/astebner/archive/200.../12/464304.aspx http://www.msfn.org/board/index.php?showtopic=31936 Are you using 2 CDs, or a modified one? I have just installed MCE without a hitch from Dell CD (one only). Used If you have other specific folders on your CD make sure you copy them to the appropriate place on the USB stick. If you have custom winnt.sif on the CD use /unattend:winnt.sif switch too, do not forget to delete redundant entries, i.e. the whole [unattended] section. If you have answered the questions me and jaclaz asked you before, you could have saved me a couple of hours @jaclaz- using binifix3.cmd gives me errors, drive letter is set to W, which is not present, script aborts. When you get some spare time could you have a look and also implement the other 2 changes from the post above? ilko edit: ahh silly me, shall I change W with C, or this can be done other way, with variables?

No prob, I'll add the option to keep the "USB Repair" entry in the batch. Just an abstract idea, mind you, but we could make a second batch to "clean" the BOOT.INI from the signature(aabbccdd) and "USB repair" option entries on second boot, i.e. once the user is certain that the procedure worked. You are right, I'll add this check to the batch. Hi guys I am back to my PC and will have some time to test and update the guide. Jaclaz, have you updated the script? @all- what do you think will be easier for novices- make a custom bootsector using jaclaz's script and use only ntldr/boot.ini or the way it was- using Grub4DOS for the TXT part? Regards, ilko

Sorry, I do not undersdtand you. If you mean how to clear up these entries- tick the checkbox next to the above quoted entries, do NOT check all listed entries, check only the ones I quoted, close all explorer/internet explorer windows and click Fix Checked. Thats it. There is no malware presense in your log, what is wrong with the PC?

Log looks clean, you may want to clean these redundant entries: What is wrong with the PC? Why do you suspect malware activity?

From the given link above in driver packs forum, post Nr.3: Have you tried this?

Without the information I asked you for (the 2log files from HiJackThis and SmitFraudFix) I cannot help you any further, scanning with various antivirus/antispyware programs will not help you much with that kind of infections, it'd be just waste of time, beleive me I see and remove them from client's machines at least 2-3 times every week.

The worst part is gone, run SmitFraudFix again in Safe Mode, choose 2 (Clean) and make sure you answer Yes to the question to clean registry entries. Reboot in Normal Mode and post the contents of C:\Rapport.txt (if not there search for it) along with a log from HiJackThis. If SmitFraudFix doesn't fix it this time we will clean the rest manualy.

Restart in Safe Mode, run SmitFraudFix again and choose 2 (Clean), this should take care of it. When finished restart in Normal Mode, run SmitFraudFix again, choose 1 (Scan) post it's log here along with a log from HiJackThis (google for link and hit do a system scan and save a log file), this is to ensure nothing bad has left in the system.

You may copy-paste the log from Notepad here, or use alternative upload server, such as ohshare.com and post the link.

Usually SmitFraudFix is the first program to start with in case of fake security alerts. You need to know what you are doing, if not better post it's log here.

You better apply the reg. file as described here and copy the relevant files to \system32\drivers http://support.microsoft.com/kb/314082 That means you will be able to start your installation as long as its IDE controller has one of the listed HardwareIDs there. The principle for SATA/SCSI controllers is the same- simply adding the HardwareID to CriticalDeviceDatabase with the corresponding service, add the service and it's files where they are supposed to be and you are ready Simply installing SATA/ATA/SCSI adapter via PnP does not include the needed entry in CriticalDeviceDatabase, this is done by the SETUP program. It may start for some IDE controllers without that reg. patch, because many HardwareIDs are already included, but is not guarantied.

Probably I am too late, but for the record- it's not a virus, it's partly corrupted information on the USB stick, I didn't dig deeper to find out what exactly, just backed up the information and reformated it. It happened to me after unsafe removal of the stick couple of times.

If it came up with different name that means something recreates it, you need to scan for other malware in your startup entries with Autoruns and/or HiJackThis. Because the rootkit most likely will hide them from such scanners when active, you better use GMER to restore code if possible and then do the scan for startup entries. Once you figure out all of them delete in one go, files using Pocket Killbox for example and reg. entries with HiJackThis/AutoRuns, do not restart between cleaning as this will recreate some of them. Another idea is to rename HiJackThis to myscan.exe or random name, so the rootkit will not guess that it's running. The antivirus programs you are scanning with are not the most famous with their detection rates, try using them along with Kaspersky (even the online scan) in combination with DrWeb. If you still have troubles please rename HiJackThis and post it's log file here, that's the best thing to start with. Mind you even in safe mode it's very likely some of the malware to be still active. For severe infections manual removal is the only way, do not expect ad-aware or similar tools to do the job for you, this will give you better chances when unknown malware is present. If you are interested here is exceptional presentation from the great Mark Russinovich how to fight malware, including rootkits: http://www.microsoft.com/emea/itsshowtime/...spx?videoid=359

There are a few ongoing threads in driverpacks.net forum, you may want to have a look: http://forum.driverpacks.net/viewtopic.php?id=1682 http://forum.driverpacks.net/viewtopic.php?id=1637

Hi guys, let me remind you this post of mine, which kinda summarizes the options about boot.ini: I'd like to avoid GRUB mapping, now we can also directly invoke setup by modified bootsector, meaning no GRUB at all. If the batch file, which subtracts rdisk value is used wimb is right, this installation won't be seen as available for repair. To include this situation as well may we add an option to the batch script, something like: would you like to include an entry for repair from USB? If yes- leave the original entry with rdisk(z) and may be rename it to something like "only for USB repair, do not use to boot", change the default line to rdisk(z-1), and add the line with rdisk(z-1) under [operating systems]. If no- do not leave the old entry, just use the script we already got. My idea about the choice is to leave boot.ini as simple as possible if one prefers, what do you think? Folder bootfiles is no longer needed. I can't recall and can't recreate the problem when on some installations the bootfiles didn't go to hard disk's first active partition, may be at that setup USB stick was seen as such during that stage of setup, and it placed or tried to place them on stick's root. To be on the safe side then I decided to copy them to hard disk anyway, this may not be necessary. It might have been when mixed SATA/IDE disks were used, now we know how to avoid the issue. For now I think we don't need to copy bootfiles again, also the script we are going to use assumes boot.ini is present on hard disk, which means ntdetect.com and ntldr will be there too. The SATA disks should be no issue if no IDE drive/controller is present or it's disabled. I am away for 2 weeks and as soon as I come back to my PC will make final tests and write an updated guide, I believe what we have gives us now pretty much "universal" way to install and repair XP from USB stick. BTW have anyone tried this guide for USB hard disk? If I am right the USB disk should be seen as fixed, therefore listed first when TXT SETUP searches for disks, if that's the situation then we might need to go back to bootfiles folder or back to the option to create brand new boot.ini and copy ntdetect.com and ntldr, also a backup and later restore of boot.ini on USB disk might be needed. Regards, ilko

Good job . Script could be run at first logon via [GUIRunOnce] along with undoren.cmd, when folders on stick are renamed back to ~LS and ~BT, so it should be OK.

Am I correct? What happens with SATA drives? jaclaz Yep, that's it.About SATA drives- if it is a mixed environment- SATA+ATA, USB stick would be listed fisrt when hard drives are detected by TXT Setup, if one plans to install on ATA when SATA is present, SATA disk must be disconnected or controller disabled, and vice versa, if installation is on SATA and IDE (no matter CD or HD) is present it must be disconnected/controler disabled. This might be BIOS dependant. Therefore SATA/ATA shouldn't matter for script's functionality. ilko

Shame on me , my memory is so short, I even downloaded that script when you posted the link here, but completely forgot about it. Yesterday I was reading wimb's ideas and though "why not try this on Xp from USB?" and it worked. Apologies for the ignorance. I think that should do the trick, we need to change only rdisk, the rest is always OK, however I am not sure what the situation will be on mixed SATA/ATA disks environment. Mind you when preparing the script to think about a situation when another XP exist, and a second copy is being installed. In this case SETUP will preserve the old lines, will change the default line and add a new one under [operating systems], am I right? In this case will you be able to keep the old line(s) and amend just the 2 new lines? I haven't had spare time to experiment with CHKBTINI, will do it as soon as I can, it may be just enough to fix boot.ini when run before the end of GUI part.

Hi porear, welcome back The idea came from this post of yours and wimb's posts in 911cd.net about loading io.sys via boot.ini.Saved a copy of USB stick bootsector with HDHacker, hexedited it and changed NTLDR to STLDR, saved it on stick as bootsect.dat, rename setupldr.bin to stldr, add in boot.ini TXT mode worked just fine, GRUB is no longer needed, unfortunately the new boot.ini on the hard drive gets multi(0)disk(0)rdisk(1)partition(1)\WINDOWS, I was hoping that when started directly by setupldr.bin that may change the order, but no, modification is still needed. Regards, ilko

Here it is: http://www.techspot.com/vb/topic70127.html http://www.bleepingcomputer.com/forums/lof...php/t81560.html

AFAK it was re-released in middle of March.