jaclaz

It would be very uncommon, but of course everything is possible. jaclaz

While we are at it, I would cite, from the mouth of the wolf http://technet.microsoft.com/en-us/library/dd448557(v=ws.10).aspx Not that the "other good guys" have a much different opinion : http://support.apple.com/kb/PH11198 though they are actually telling lies (or partial truths) : https://scottlinux.com/2012/04/19/os-x-firewall-not-stealth/ jaclaz

@puntoMX Sure . They are listed in order of "less tools/materials needed". For #1 you ONLY need the PC and the tools (if any are needed) to open the case. For #2 you need the above and a new/known to be working cable For #3 you need besides the above (possibly more) tools to remove the disk from the case For #4 you need another PC with a suitable bus (IDE or SATA) the tools to open that other case or a suitable USB adapter. For the added #5 you need still more tools (that nowadays mean normally a teeny-tiny Torx screwdriver, smaller than the ones that come in common "generic" kits), and, as you pointed out, it makes sense only if the disk is not spinning. In my experience a non-spinning disk will usually be anyway detected by BIOS, as well as one with (for whatever reasons) insulation between the PCB and either the heads or motor contacts, though with the "PCB generic name" or with a string of "garbage characters". jaclaz

Actually it is seemingly the SAME one that ALREADY went on here :: http://www.msfn.org/board/topic/163539-are-ms-updates-for-xp-really-necessary/ The only "news" are seemingly that Kelsellenenvian has an "incredibly simplistic view" on the matter and that noone here is qualified to give security advice, and that the fact that we are giving it is dangerous. No doubts about the dangerousness of giving security advice , some doubts on how people become qualified for giving it compare with the reknown expert Armand Gracious http://www.msfn.org/board/topic/127283-experts-say/ , but the point is obviously that noone is actually doing anything more than expressing one's own opinions on the matter. jaclaz

Whenever something is beyond one's capabilities or knowledge , there is often anyway a solution, which is - obviously - cheating[1]! As a teaser , please find attached a copy of fdboot.img, the Freedos 1.0 boot floppy available at http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.0/fdboot.img transformed to have CRC32 of 0xFFFFFFFF and VALID using CRC.EXE. jaclaz [1] By definition in love and war (and MS computing) ALL is fair, or, if you prefer, "Improvise, Adapt, Overcome" fdbootCRCFF.7z

Additionally. What EXACT make/model is the PC? What EXACT make/model is the hard disk? jaclaz

NOT "similar", but you can get a 8.1 ISO through this: http://windows.microsoft.com/en-us/windows-8/upgrade-product-key-only http://winsupersite.com/windows-8/windows-81-tip-download-windows-81-iso-windows-8-product-key The only issue AFAIK is that the stupid thingy will download the version that MS finds suitable for the connected machine, i.e. you won't get the x64 version if connected through a machine running 32 bit or viceversa. jaclaz

Why don't you try it yourself? It is a rather straightforward experiment. For your convenience, find in the attachment two very small files, "random filled", both having a CRC32 of 0xFFFFFFFF. jaclaz 2xFFFFFFFF.7z

Sure, if the idea is to recreate something you need to have the "original", and see which dates/times AND timezones were used originally. So, once you have the "original", it would be easier to make a copy of it than re-creatng it from scratch, hence the utter futility of the operation. But once you have "one" original, and put together a "building method", the amount of information needed to re-create "another" original (WHY? ) lessen dramatically. I mean, once you have a proper building method, even if you don' t know the actual timezone but you have (besides ALL the actual original files and the date attributed to them by the -t switch) the SHA1 or MD5 of the original, you only have to go through a finite number of iterations to get a valid SHA1/MD5 by changing the mentioned byte. jaclaz

A good idea would be to run a program *like* the good ol' SequoiaView to check what actually occupies the space: http://www.portablefreeware.com/?id=402 Also knowing the size of the disk and of the partition hosting your system would help. jaclaz

OK, let's clear some possibly wrong guesses. That message comes from the BIOS. (last character in the above is a full stop or period) It means that the BIOS cannot detect the hard disk at all. Possible causes of such message are: bad/unseated data cable <- more common than you might expect bad/unseated power cable <- quite rare bad (aged) PSU (i.e. simply not providing at boot time enough power on either the +5 V or +12 V rails <- also more common than you might expect failed soldering of the connectors (on either the motherboard or the disk drive PCB) <- rare, but it happens another bad (cold) soldering (on either the motherboard or the disk drive PCB) <- also rare another defect of *some kind* (on either the motherboard or the disk drive PCB) corruption of the BIOS <- very rare Other <- you never knowThe FIRST thing to try is: disconnect and reconnect the cables (both data and power) from the hard disk, and, in the case of the data connector also on the motherboard sideThe SECOND thing to try is: replace the data cable with another one surely workingThe THIRD thing to try is: disassemble the hard disk from that PC and - holding it in your hand while powering up the machine, feel if it's spinning up.The FOURTH thing to try is: try it in on another PC, either by directly connecting it to the internal connectors or using a USB adapter@Briansurvivedwindowsme Until you will have performed the above four tests and reported results, there is nothing that we can advise you. Please also post the EXACT make/model of the hard disk drive. jaclaz

Yes and No. The CRC32 hash of a .iso made with the -x switch is 0xFFFFFFFF, including BOTH (actually all 4 of them) the values of ExclCRC and AutoCRC. If you prefer the the CRC32 hash of the WHOLE iso is 0xFFFFFFFF. It is clear (or clear enough) that the 4 bytes of the AutoCRC value (last four bytes of the .iso) are an integral part of this calculation leading to 0XFFFFFFFF, and that this 4 bytes value is the - as defined above - *whatever needed to have "normal CRC32" of EVERYTHING before this value and included this value result in 0xFFFFFFFF*. The hackcrc32 app you mentioned is not seeemingly working in the same way, or it uses a different algorithm. If you actually try it (on a .iso stripped of the last 4 bytes) you will find out that it fails to produce a 4 byte value identical to the one that the -x produced, it instead produces an 8 byte value that, once appended to the .iso makes it having a value of "normal" CRC32 of 0xFFFFFFFF, but obviously this .iso results as CORRUPT in the MS CRC.EXE. The algorithm (whatever it is) that CRC.EXE uses is seemingly "better" than the one used in the hackcrc32 tool, in the sense that manages to provide always a 4 bytes value. The guess (which remains a guess) is that the algorithm used by the -x switch and by the CRC.EXE, *somehow* makes use of the 4 bytes value of ExclCRC and my guess (which is as good as anyone else) is that the actual "correction" to the "normal" CRC32 happens making use of both the 4 bytes value of ExclCRC and of the 4 bytes of the AutoCRC, as an example, let's say that the value in ExclCRC is the hash of all sectors (or bytes, or words, or whatever) up to a given address and that of AutoCRC is that of some other area(s) + the "complement" between this value and the final value of 0xFFFFFFFF. IF this is the case, the calculation of the actual value of AutoCRC is based NOT on the whole image, but rather on an area (or *whatever* ) "starting" from the value of ExclCRC. jaclaz

@bphlpt There are a number of people that - for whatever reason - think that it is "cool" to recreate an "original" .iso. Example: http://forums.mydigitallife.info/threads/54441-Restored-each-Windows-ME-version-files-to-ISO-by-CDIMAGE-2-39 Since the MD5 and SHA1 hashes of a number of original CD's/iso's have been published, these people attempt to re-build these images in such a way that they verify these hashing methods, besides the CRC32 one (which in the case of a number of .iso's is "corrected" by the use of the -x option, i.e. AutoCRC). This makes NO sense whatever under any practical point of view (as - as you correctly stated - a "collector" would want an original CD), i.e. the activity is totally futile, still it is well among what freedom allows , as no human being or living creature is actually hurt in the process of pursuing this (again, apparently senseless) goal. A more sensible goal is obviously, as I initially stated, to create a .iso capable of installing the OS (which is - or should be - the ONLY actual goal of an install CD/.iso). BUT, the sheer moment in which someone comes here, BTW slipping on a chocolate covered banana: http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/put-down-the-chocolate-covered-banana.html and states something like: Because it is impossible to restore Windows 2000 (SP0 / SP1) without CDIMAGE 2.27. something must be done: http://www.imdb.com/title/tt0031971/quotes?item=qt0178026 in order to find out if the statement is accurate and if the (futile) goal is actually impossible to reach using another method or - as normally happens - it is perfectly possible. If you prefer, I am completely indifferent to the activity of recreating "original" CD's/.iso's, but sensible to the declared impossibility of the feat. jaclaz

Yep , that one is another one containing only partial (and partially wrong ) info. The idea is to (hopefully) get complete and correct info INSTEAD. Points are: there is not a sector with the ExclCRC and AutoCRC values appended to the ISO file but TWO sectors, one "inserted" after the directory structure and one appended to the end of the .iso [1]the "scope" of the AutoCRC value is "clear" and surely represents *whatever needed to have "normal CRC32" of EVERYTHING before this value and included this value result in 0xFFFFFFFF* the "scope" of the ExclCRC can only be guessed as *area to exclude from the calculation* but there are no real "proofs" that this guess is correct how exactly the ExclCRC val is used and calculated is to be found the CRC.EXE changes it's behaviour and can provide THREE types of output, if a valid AutoCRC value is found as last four bytes of the file that value is printed and the file is considered VALID, if a non valid AutoCRC value is found as last four bytes of the file that value is printed and the file is considered CORRUPT, if NO AutoCRC "label" is found in the last few bytes of the file the "normal" CRC32 is printedjaclaz [1] I already verified that if the file is truncated after the inserted sector this initial part by itself will give a CRC32 of 0xFFFFFFFF

Sure it is not. "%%B" in that case would be only "grub" as you have delims set to [sPACE] and tokens set to 1 and 2. Try with tokens=1,* <- the idea of giving you a reference is that you study the syntax, so that you can make changes yourself, but not "random" ones. Also you need quotes on both sides, like IF /I "%%B"=="grub for dos" GOTO :out jaclaz

Because it is needed to have "local reference time" correct in sector 16, absolute offset 0x833D. http://alumnus.caltech.edu/~pje/iso9660.html No, this sets the files folders timestamp AND the Volume timestamp BUT NOT the timezone ("offset from Greenwich Mean Time" see above). You mean that you don't trust my word for it? There is NO "signature stuff" in a 2K CD AFAIK, only in the NT 4.x ones. (the referenced post on BetaArchive is about NT 4.00 and CDIMAGE 2.28). jaclaz

To finalize this thread, I checked. The additional sector is inserted at the end of the "file/directory records" and before the first actual file/directory contents. Still remains to be understood what the "ExclCRC" data refers to. I'll see if I can find an explanation. jaclaz

To finalize this thread, I had some time to make a few tests. As expected, it is perfectly possible to recreate one of those images. There are two things that were not mentioned here or in the references AFAIK/AFAICR. It seems like there is the need to: set the machine time zone to "Pacific Standard" with Daylight savings disableduse besides the "normal" -nt -o -x switches, also the additional switch -y6The latter one is "strange" as: So, besides the "queer" usage of an obsolete version of the tool, there is also the "strange" choice of the -y6 switch. In practice without it a file/directory entry is not written at the end of a sector if the record ends exactly on last byte of the sector and thus the entry is shifted to the beginning of the new sector. jaclaz

And, in case after all grub4dos will be used, this might come handy: http://reboot.pro/topic/18783-release-cateditg4b-script-to-write-hex-values/ as a reference. jaclaz

@submix8c JFYI, some reference: http://www.911cd.net/forums//index.php?showtopic=17504 gsar may be a valid replacement (it is GPL and redistributable): http://home.online.no/~tjaberg/ and as well hexalter: http://kuwanger.net/misc/hexalter.shtml if the addresses are known. But these are still "third party" . jaclaz

But it's on the Wayback Machine alright: https://web.archive.org/web/20110601035232/http://emergency.cdc.gov/socialmedia/zombies_blog.asp BTW, proof that bureaucracy is very important even in case of zombie apocalypse: http://www.fema.gov/blog/2011-05-19/cdc-preparedness-101-zombie-apocalypse Zombie traffic police patrols are reknown to be very strict about driving without a driving license or failing to carry proof of identity . jaclaz

Normally (i.e. if the cause of the BSY is the original problem) all data remains accessible "as before". IF the cause of the BSY is another, the data recoverable may vary. But the answer to your question is "something else", what happens when you issue that command through terminal is that "user partition (data) is regenerated", i.e. the part of the disk that is accessible to the user is reset to "usable". That "partition" is at a completely different level (much lower) than the "partition" you see in (say) Disk Manager, it is the partitioning of the disk between "Seagate's Data" and "User Data". If you prefer, usually (say 95% or more of cases ) after the disk has been unbricked, it will appear exactly as it was before, though in some instances it happened that partition based recovery was needed (and was rather easily accomplished ), example: http://www.msfn.org/board/topic/145574-seagate-750gb-one-partition-is-raw-after-bsy-fix/ in an even minor number of cases, partition recovery was not possible or only partially possible , examples: http://www.msfn.org/board/topic/157671-need-help-with-data-recovery-on-hdd/ http://www.msfn.org/board/topic/157688-still-no-partition-on-seagate-after-successful-unbrick/ http://www.msfn.org/board/topic/170881-seagate-720011-malediction/ There is no real way to know in advance as we don't have a way to diagnose the actual cause of the problem. jaclaz

I was not trying to put anyone off , simply pointing out how I would approach the same problem. There is a degree of uncertainty in: and in the replies that may be provided by helping members , such as: I believe that if someone is going to put together a customized XP installation disk, he/she would also need to test it (several times) in a VM, so that making before an additional VM with the "unmodified" installation to have a quick and accurate comparison is a simple way, besides answering those questions, to troubleshoot issues (if any) with the modded installation by comparing it with the non-modded one. I reserve the right to fail to understand something and saying it, however. jaclaz

I really don't understand. Set up a VM (*any* will do). Get a XP "Gold" (SP0) or SP1a or SP2 source or SP3 source. Slipstream to it SP3 (if not already at SP3). Install it to the VM. Check the version of anything. I mean, besides whether the replies that you will get may or may not be accurate, what if you forget one app (or you cannot get a reply for it)? Having such a described VM install handy will allow you to quickly boot it up and check whenever you have a doubt. jaclaz

There is no way (with native commands) to modify a binary file if not using DEBUG. Something that I would not advise to my worst enemy. Anyway: http://thestarman.pcministry.com/asm/debug/debug2.htm Since you will be doing a multiboot CD/DVD, IF I would decide to not use one of the many suitable command line third party tools I personally would use grub4dos as bootmanager and use it also to patch SETUPLDR.BIN, but it would add yet another layer of complexity (if the complexity of the *whatever* you are putting together would not have been enough ). Or go back to the tradition and use BCDW, that if I recall correctly has a specific function for patching the setupldr.bin on-the-fly. jaclaz