jaclaz Posted November 27, 2006 Posted November 27, 2006 Possible idea:Tiny HexerYes, I came exactly at the same conclusion , I am having a look at it.....By the way, out of topic, but not much, another idea came to my mind, I'll just throw it in "as is" :what about a "superfloppy" image with the 6 XP floppy disks combined into one?I already tried - actually with the 4 Win2k floppies - and it does not work if the device is formatted as "hard disk" (with MBR - it asks for the $WIN_NT$.~BT folder), but I was at home on my wife laptop and missed some tools to work with image files and partitions, so I will try again as I find some time.The test I did, combining the first two floppies in a 2.88 image did work until it asked for the 3rd floppy, so, it may work with a bigger one, 5.76 for 2K and 8.64 for XP .Try sed, the stream editor.It doesn't seem it has direct disk access, and if one has to copy sectors to file to process them, I would prefer gsar, which I know better.But maybe I missed something, what would they be the advantages of sed over gsar in this?jaclaz
porear Posted November 27, 2006 Posted November 27, 2006 what about a "superfloppy" imageThat sounds way too easy - now where is the fun in that? Just kidding. The problem I have had with that type of approach has always been that once the text mode setup has finished loading (the part that is on the floppies) that I cannot get the installation to continue since it asks for the CD. This occurs even if I have the CD tag files on whatever medium I am trying to install from. I am sure this could be solved, I just have not yet been able to do it.Regarding the Tiny Hexer approach, I think it is possible, but it will require another step: the file names on the disk are in 8.3 format, so to search for them, our match list will first have to be modified.Looking at the installation files, I do not believe any have names longer than 8 characters, but some have less. On disk, these shorter names are padded with spaces (0x20) at the end, e.g. boot.ini becomes BOOT INI (four spaces between boot and ini)Unfortunately some of the shorter deleted files have the same name with different extensions, so we cannot just search for åclui, we must search foråCLUI CH_ (three spaces in between for all of these)åCLUI DL_åCLUI HL_Simple enough, just another step.
jaclaz Posted November 27, 2006 Posted November 27, 2006 (edited) Looking at the installation files, I do not believe any have names longer than 8 characters, but some have less.Yes, I can confirm that, the files are strictly compliant to 8.3 rules.Unfortunately some of the shorter deleted files have the same name with different extensions, so we cannot just search for åclui, we must search foråCLUI CH_ (three spaces in between for all of these)åCLUI DL_åCLUI HL_Simple enough, just another step.Yes, the procedure to create the list of "pairs" must take care of this, but it is not difficult to make a batch to process the output of a DIR :@ECHO OFFSETLOCAL ENABLEEXTENSIONSSETLOCAL ENABLEDELAYEDEXPANSIONFOR /F %%A IN ('dir /B') DO CALL :ADJLEN %%AGOTO :EOF:ADJLENSET /A counter=0SET /A length=0SET filename=%~n1SET fileext=%~x1:loop1Set /A counter=%counter%+1Set filelen=!filename:~0,%counter%!IF NOT %filelen%==%filename% SET length=%counter%&goto :Loop1IF NOT %counter%==8 set filename=%filename%#&goto :Loop1REM ECHO %counter% %filelen%REM pauseECHO %filename%%fileext:~1,4% %~nx1GOTO :EOF(please note that there is a [TAB] between "ECHO %filename%%fileext:~1,4%" and "%~nx1")Sample output of the above:is3#####cmd is3.cmdis3a####cmd is3a.cmdchange##cmd change.cmdchange2#cmd change2.cmdcartellacmd cartella.cmdErlev###cmd Erlev.cmdcolours2txt colours2.txttestcopycmd testcopy.cmdChoice##exe Choice.exedirvmc##cmd dirvmc.cmdAUTOEXECBAT AUTOEXEC.BATCONFIG##SYS CONFIG.SYSpadnamescmd padnames.cmdtemp####txt temp.txttstcopy2cmd tstcopy2.cmdpadname2cmd padname2.cmdOnce we have our list with all its ###, a simple binary search and replace would make it in the format required.jaclaz Edited November 27, 2006 by jaclaz
porear Posted November 27, 2006 Posted November 27, 2006 (edited) but it is not difficult to make a batch to process the output of a DIR :Maybe not for you! hehe Very well done, sir. Works perfectly. I made a couple of very minor tweaks.IF NOT %counter%==8 set filename=%filename%#&goto :Loop1I believe the #s actually need to be spaces (0x20). This next one threw me for a while. It was very strange, but the batch file made it through most of the directory then crashed. Turns out it didn't like the file "notepad.ch_" because when it parsed the name, it was literally translating the first three letters "not" as a NOT. I used some quotes and its works great.IF NOT "%filelen%"=="%filename%" SET length=%counter% &goto :loop1I have been looking at Tiny Hexer scripting capabilities, and unless I am mistaken, "search" does not seem to be a scriptable function It is available in WinHex scripting capabilities, but not in the free version.We really just need a way now to obtain the hex offset of all of the file name locations. It still seems like with that additional piece of data this would be a suitable task for a batch that employs dsfi. We would not even need to rewrite the entire file name, only go to the offset where each name is located and rewrite the first 'å' byte.I found a tool that sounded suited for this athttp://pjwalczak.com/scaven/index.phpbut alas it wouldn't see my USB disk, and the input file is limited to 512 bytes (our list is 26K). I've written the author but wouldn't consider this a very probable solution.This tool, NT_SS is even more perfect, but carries a $50 tag. Its functionality is exactly what I am seeking.http://www.dmares.com/maresware/html/nt_ss.htmI am attaching replace.txt. It has the deleted name on disk, the first character that was replaced for each name, the original name on disk, and the original file names.replace.txt Edited November 28, 2006 by porear
jaclaz Posted November 28, 2006 Posted November 28, 2006 (edited) Turns out it didn't like the file "notepad.ch_" because when it parsed the name, it was literally translating the first three letters "not" as a NOT. I used some quotes and its works great.LOL! This is the typical example of how one can introduce a bug in less than 20 lines! I would have never thought about "reserved" words that are subsets of filenames ....I believe the #s actually need to be spaces (0x20).Yes, I just put the # as they are more visible than spaces.I found a tool that sounded suited for this athttp://pjwalczak.com/scaven/index.phpI too had a look at scaven, but it is a DOS app, and while with the appropriate driver it would be possible to get it access a USB stick, it won't work in Win32 .There MUST be somewhere an utility capable of doing that, all it takes is to find it........usually when you search for something else you will find it.Look at what I found while searching for this utility, a very good "GHOST like" app, buried inside the innards of Sourceforge:http://sourceforge.net/projects/nfgdump/jaclaz Edited November 28, 2006 by jaclaz
jaclaz Posted November 28, 2006 Posted November 28, 2006 UPDATE!Maybe, just maybe, I have found the right tool, though it is DOS/WIN9x/ME only:RECOVER Fixed/Floppy Disk v2.2 http://www.bestdiskrecovery.com/index.html#rfd1612Helps recover files from HDD / Floppy on which Deltree was run if user can edit and change, in the file that contains the folder (directory) obtained from disk, the deleted entry marker (E5) at start of filename to the filename's first character. This is the only feature that requires a hex editor.Adding a menu entry to the Grub4dos menu will be needed, chainloading a IO.SYS on root of stick, and one will need to boot to this entry to "regenerate" the stick, but it could work.OS files can be extracted directly from XP files, see this:http://www.911cd.net/forums//index.php?sho...c=16745&hl=I am still looking into writing a batch script to use findpart getsect/putsect functions with gsar, the thing that concerns me is the time of execution, and, talking about direct accessing a harddisk/stick, I need to test it on a non-production PC, so it will take a few days.....jaclaz
porear Posted November 28, 2006 Posted November 28, 2006 (edited) I had seen (and even downloaded) RFD but passed it over. Maybe I need to look at it more carefully. It looks like it isn't free. EDIT The 1.4 version is free.You are right, we could regenerate from the XP installation back to the disk. Another option might be to simply have a second copy of all the deleted files on the disk and copy them back over each time, but I was hoping to avoid fragmentation. The deleted files total about 144 MB, which still take some time to copy on a USB, but it isn't unbearable.So far the closest I have found to what I have been looking for is NT_SS mentioned previouslyMy best hits have come when searching for "physical disk search" and "hard disk forensics"This search for disk offsets only has to occur once, so (as you also have ascertained) we still have flexibility for the environment the search runs in. Even a GUI app that spits out a text report would do the trick...UPDATE: I took your suggestion of chainloading IO.SYS on the stick in GRUB. I was able to run Scaven! Not sure yet how fast it is. The main limitation with this approach is that the input file of search strings can only be 512 bytes - and our list is 40K. It could be split into 70 separate files and run by batch, but this seems a bit impractical. Edited November 28, 2006 by porear
thuun derboy Posted December 2, 2006 Posted December 2, 2006 (edited) thx to jaclaz for pointing me here...I too am trying to setup XP from USB (without PE or DOS assistance).Searching just now I found THIS.It's called 'Flashboot' and is buried in side the nlite addon. I can't say more but will test it out later and see what's up. It has an option to convert a bootable iso image to a bootable USB device.Perhaps this combined with 'SetupSourceDevice' altered in txtsetup.sif will work, who knows. I do have a feeling the answer to this one is more obvious than one might think. I would like to think grub isn't required for this task. --upd--flashboot is shareware and only makes boot disks out of isolinux and floppy based images, oh well, the search is on again. Edited December 2, 2006 by thuun derboy
ilko_t Posted December 7, 2006 Posted December 7, 2006 (edited) Hi guys, first of all you did great job so far , following your posts I beleive you are on the right way and it is doable and I think we are one step closer.Changing this line( actually only removing the 1 at the end of the row) it managed to keep most of the files during TXT portion of the setup. I tracked the changes comparing the folder contents of \$WIN_NT$.~LS\i386 before and after TXT setup using BeyondCompare 2 and found that most of the files were deleted if in [sourceDisksFiles] the file was listed as logonui.exe = 100,,,,,,,2,0,0 . I couldn't find clear explanation of all switches and decided to experiment. Removed the 1 and more than 200MB in files were not deleted, compared to the option with the 1 present.Original txtsetup.sif:[sourceDisksNames.x86]1 = %cdname%,%cdtagfilei%,,\i3862 = "%cd2name%","%cd2tagfilei%",,\cmpnents\tabletpc\i3863 = "%cd2name%","%cd2tagfilei%",,\cmpnents\mediactr\i3864 = "%cd2name%","%cd2tagfilei%",,\cmpnents\netfx\i386100 = %spcdname%,%spcdtagfilei%,,\i386,1New txtsetup.sif:[sourceDisksNames.x86]1 = %cdname%,%cdtagfilei%,,\i3862 = "%cd2name%","%cd2tagfilei%",,\cmpnents\tabletpc\i3863 = "%cd2name%","%cd2tagfilei%",,\cmpnents\mediactr\i3864 = "%cd2name%","%cd2tagfilei%",,\cmpnents\netfx\i386100 = %spcdname%,%spcdtagfilei%,,\i386Now much fewer files are being deleted, some of them :snmpapi.dll = 100,,,,,,,2,0,0,,1,2sniffpol.dll = 100,,,,,,,21,0,0snmpcon.chm = 1,,,,,,,21,0,0,snmpconcepts.chmsnmpsnap.hlp = 1,,,,,,,21,0,0SOFTKBD.DLL = 100,,,,,,,127,0,0softpub.dll = 1,,,,,,,2,0,0,,1,2XPBalln.wav = 1,,,,,,,26,0,0,%XPBalln%I will try to remove the second 0 for some files and will report the results. A full list of the deleted files is attached, as well as txtsetup.sif.I hope there is someone who could explain or give another clue what else needs to be changed in txtsetup.sif.Meanwhile I will make a full list of all files deleted, with their options in txtsetup.sif.Once we make it not to delete files during TXT mode we need to find a way to prevent the 2 folders $WIN_NT$.~XX not to be deleted from the USB stick at the end of the GUI mode, it completely deletes the 2 folders at the stage "removing any temorary files used..." and if one removes the stick after, say "registering components" stage, SETUP won't complain about missing files or media, tested it already. May be a script renaming the 2 folders? But how to launch this script right after "creating start menu...." or "registering components..." stages? Some information about setup parameters can be found on this site, I will be digging in it next days:http://www.osronline.com/ddkx/install/inf-format_0icy.htmTXTSetup_deleted_files1.7z Edited December 7, 2006 by ilko_t
jaclaz Posted December 7, 2006 Posted December 7, 2006 @ilko_tWelcome to the game! Interesting results.....keep 'em coming.On the other side, I now have a still VERY preliinary (read as ALPHA, i.e. don't even think of using it on a large drive) batch file that uses FINDPART to get the address of the sectors one needs to backup.http://www.partitionsupport.com/utilities.htmIt still needs to be refined, bettered, and possibly corrected, but it works OK, on small drives.I had to re-start from scratch a couple of times because I was using the wrong FINDPART commands, and I kinda got carried away (as often happens to me) and wrote something a bit more "wide" than what really needed, but there is always time to "reduce" it back.The search is limited at the moment for just a few directories.Please try it and let me know if it gives problems.jaclazsavesect.zip
ilko_t Posted December 8, 2006 Posted December 8, 2006 Well, no luck so far, actually I was wrong thinking that the magic "1" changes anything, the mistake was that as a lazy man a few times I used hibernate during the tests and windows probably reported the deleted files as present.I tried different options in txtsetip.sif and winnt.sif, tried to change source paths and so on, but no luck. I rather think deletion is hard coded and because $WIN_NT$.~LS folder is considered as temp folder files in it would be deleted on a few stages. I also tried to leave $WIN_NT$.~BT required during TXT setup and replace $WIN_NT$.~LS with the original I386, also tried to point setup to look for I386 changing options in the 2 sif files, but it only goes to the format stage, tries to format and says something like "setup cannot continue, low memory or corrupted files on the CD". Playing with SetupSourcePath = "\" in [setupData] section in txtsetup.sif didn't help, or I didn't find the right one. I am giving up for now using this method, I'd rather spend time on booting from SDI image or a quick way to recover the deleted files. At the end of the day having pico, nano etc. PE gives much greater flexibility.Next days I will have a look at the above mentioned tools and script. Thanks for your participation again.
porear Posted December 9, 2006 Posted December 9, 2006 Hello, ilko_t. Welcome and thanks for the efforts.Sorry I've had a short lapse on this, life's been busy - we're expecting a baby! Thanks for the code jaclaz. My batch script skills are lacking what is required for this task. I had been considering throwing together some pseudo-code for what was needed, but looks like you have it covered. The basic idea is to traverse the FAT and record the on-disk address pointed to of the first byte of each file entry (the first character of each file name).I tried the batch, but was unable to get it to work for me. I know I am most probably not using it properly I do have FindPart in the same directory as savesect.cmd.I ran the batch from a command line in Windows. I tried both Physical disk 1 (my hard disk) and Physical disk 2 (USB stick), with output redirected to 1.txt and 2.txt respectively. These files are attached, as are the screen outputs for each run in screen1.txt and screen2.txt.I tried also booting to DOS on the stick and running the batch there. I'm using DOS 7.1 from Win98, and COMMAND.COM does not recognize .cmd files. I changed it to a .bat, but it still won't run. It skips accepting input when asking for "YES" to confirm reading the boot disk, and immediately displays "LABEL NOT FOUND". I am assuming this is from a GOTO LABEL in the batch script. I've played with imaging the USB drive, then using gsar to search the image for the file names to provide the offset addresses. It works, but it finds 3 occurrences of each so we'd have to determine which is the one we want. It takes about 30 secs per file, which is actually pretty fast, but will take over a day for all 3000 files. This only has to be done once, but it's still extremely inefficient. A batch to process a list of all the file names would be needed too.Since the files are on disk in alphabetical order, the search could be shortened by starting subsequent searches at the sector where the last match occurred. Unfortuantely, gsar does not accept a file offset from which to begin a search. I am sure other utilities could be found that would.screen1.txtscreen2.txt1.txt2.txt
jaclaz Posted December 10, 2006 Posted December 10, 2006 @porear1) no, the batch won't work in anything but 2K/XP2) it will probably only work on FAT16 formatted volumes3) and it assumes that the drive has only one primary partition starting at CHS 0/1/1, unless you supply on command line a different start address4) as is, it is meant to be "interactive", no redirecting to a file will work on this version5) there is no real "checks" for consistency made yet, so if the drive is not "properly formatted" it will probably failTry using just findpart directly as this (provided that the stick is \.\\PHYSICALDRIVE2):findpart findfat 2I am attaching the output of findpart findfat 3 (I am working on a virtual drive that is \.\\PHYSICALDRIVE3 and the corresponding output of savesect.cmd.Since my batch "filters" in a rather "dummy" way the output of findpart commands, it is VERY possible, if the output of findpart changes, that the batch fails.The other findpart command savesect issues is (on the drive 2):findpart chsdir 2 0 1 1and I am attaching part of it's output on my drive 3 too.If you use directly findpart commands they can be redirected allright.jaclazssect3.txtfpartchs3.txtfpartff3.txt
porear Posted December 12, 2006 Posted December 12, 2006 Progress. uuuuuuuggggggh I was using the wrong version of findpart - I had the DOS version. I've been able to run the batch, the first part for finding the FATs and ROOT seems to work fine. The directory entries part of the code did not work for me, I have not began to troubleshoot yet. My output is attached. Thanks!
Recommended Posts