jaclaz

This: can be *almost anything* See the results of searching here: http://flashboot.ru/index.php?name=iflash most probably it is a "valid" VID/PID from TRANSCEND that can have "under the bonnet" *any* controller This: is *unknown*, the 0324 is OCZ, just like the 8564 above is Transcend, it is probable that it is an SMI chip as well (like the 090C/1000), but cannot say. jaclaz

Well, if the chipset does not support AHCI you won't have any "real benefit" from running the disk as SATA vs. PATA. BUT you may want (if you are into experimenting) to try UNIATA : http://alter.org.ua/en/soft/win/uni_ata/ jaclaz

Yes, this is correct. An "untouched" (up to XP/2003) NT will use "orthodox" traditional Cylinder alignment, i.e. first partition will start at 0/1/1 (LBA 63) and end at n/254/63, and subsequent ones will start at x/0/1 and end at y/254/63, in practice, any non first primary partition will be a multiple of 1x255x63=16,065 sectors or 8,225,280 bytes and can be enlarged or shrinked in 8,225,280 steps, first partition (which has the first "hidden" MBR track) as well as logical volumes (that have the "hidden" EPBR track) will satisfy equation SIZE=n*255*63-63 (but still enlarged or shrinked with the same "step" size). Starting from Vista an untouched system first partition will start at 0/32/33 or LBA 2048 and then it will try to mantain a size that is multiple of 4 Kb or 8 sectors. So in the case of a single whole partition, usually there is a difference a the start (the 2048-63=1985 sectors) BUT since the "old" paradigm created some "never used" space at the end of the disk (since NO modern disk is a multiple of 16065) and the "new" one has not this "limit" some space could be "stolen" from this ending previously never used space. It is possible, but it's anyway strange. I will have to do some tests, but AFAICR when *any* "FDISK" like Windows NT program (disk management, diskpart, text mode setup) accesses a disk and finds it without the 55AA magic bytes it writes to it, besides the 55AA also the disk signature (the disk signature is written ANYWAY if missing when the device is accessed/mounted, if missing) AND the MBR CODE. This is what happens in disk management when you get the question "Do you want to initialize this disk?" If any of the said programs ALREADY find the magic bytes 55AA they will IGNORE the MBR CODE and leave bytes 0÷440 of the MBR untouched. So a nice, possible explanation, is that somehow the "install winpe" is somehow "triggered" by the need to detect the USB and in this process it finds the disk without the 55AA and writes just those two bytes, and subsequent accesses, seeing that the disk is seemingly already initialized, skips the MBR CODE "install" step. jaclaz

You do know that it is RISKY business? You do know that it may make the stick inaccessible (if you do the wrong things with such a powerful tool)? You are "TheSeeker", I am "The Finder", there must be a reason . Try with the SMI only first: http://flashboot.ru/index.php?name=Files&op=cat&id=10 You'd better go there through google translate: http://translate.google.com/translate?u=http%3A%2F%2Fflashboot.ru%2Findex.php%3Fname%3DFiles%26op%3Dcat%26id%3D10&sl=ru&tl=en In this particular case the answer is not 42 but rather 320. The 0409:0058 doesn't sound "right". (it is a Vid/Pid for a USB hub) Is what you posted the output of chipgenius? http://reboot.pro/4661/ If not try again with it. jaclaz

I am not sure to get what the problem is (I mean Submix8c's one). Can't you just make any partition/volume beyond the 137 Gb limit formatted as NTFS (or simply use the 07 Partition ID in the partition table entries)? jaclaz

This is a mistery, since it came out as working for bphlpt I really have no idea why it does not work for you. Have you actually tried the suggested checks?: jaclaz

This seems like an example of where WMI/WMIC may come useful. Only partially UNrelated: jaclaz

You can find an easier solution here: http://tiny.cc/qs7q4 (send the link to your friend's wife ) Is it a bird, is it a plane? Naaah, it's a roflcopter! ROFL:ROFL:LOL: ____^____ _/ [] \ LOL==_ \ \___________] I I ----------/ jaclaz

Since entries in BOTH partition tables start at LBA 63 I find this highly unprobable. I wonder if your was a random guess, or an educated one..... I mean when the "new" partition alignment thingy is used (and this AFAIK only applies to Vista and 7) it is the start of the partition that is aligned, not it's size, and anyway both sizes do not divide evenly by 4 or 8 jaclaz

That should be: Compatible=IDE Enhanced=SATA Enahnced+SATA=SATA Enhanced+PATA=IDE Enhanced+SATA+PATA= A suffusion of yellow (never seen something like this ) Cannot say HOW/WHY, but from what you post it seems to me like: you installed the thingy in "compatible" mode thus XP has "compatible mode IDE drivers" loaded the BIOS provides at least the IDE Dev ID and - with some settings - ALSO the SATA Dev ID If you run under windows XP the "Intel Chipset Identification utility reports that the ICH7 chipset is still running in IDE emulation mode...." should be normal as actually the driver that were loaded are the IDE ones. Normally, on a XP install (made in IDE compatibility mode) when you switch the BIOS to SATA (or AHCI) you get a (nice ) 0x0000007b BSOD. You may want to experiment along the lines of link given here: Or you may want to try the offline Mass Storage driver injection tool: http://www.911cd.net/forums//index.php?showforum=43 http://www.911cd.net/forums//index.php?showtopic=22523 jaclaz

The "aftermbrfix.bin" is obviously the same as "back1bin" BUT with the CODE in it. The "ide_setup.bin" is "queer" it has the same disk signature BUT it has a slighly larger partition. (976768002 sectors instead of the previous 976751937) Since 976768002 - 976751937=16065 And 1x255x63=16,065 It is a whole cylinder difference. I have no idea why the setting RAID/IDE may make such a difference. jaclaz

Hmm, I guess, as said, that it all depends on the "ghost" (or other software) program settings, and on the amount on actual data on the disk. Let's take an "average" (nowadays) 500 Gb hard disk. Let's do a fork between a "home user" and a "work PC". The home user - on average - will in most cases download to it 1/3 of the Internet , and the disk (and the filesystem) will hold probably 400 Gb or data or so. The work user - on average - will have on it MS office and another couple of programs specific to his/her trade/business to which you can add a year of e-mails, let's say 4 Gb, a few games he/she downloaded to entertain the children when at home and a few "dumps" of adigital camera, in total he will have no more than, say, 80 Gb of data. No matter HOW (in the sense if through a hardware or software approach), with the same tool: A dd-like copy or image will take the same time for both. A dd-like copy BUT skipping unused sectors will take 1/5th or 1/4th the time nedded for the first for the second disk. Just to give you another example, this one: http://www.jharddrive.com/products/hard_drive_duplicator_ninja.html though hardware based allows for different imaging modes, including one for skipping unallocated sectors. Such a thing will be way faster than any software. As always happens, it comes with a string attached: the price tag. jaclaz

Well, the good news are that now you know what things are "wrong" on that USB stick . Good. The BACK1.BIN is (as it was expected BUT NOT as it should be) a perfectly valid MBR with: NO CODE whatsoever Disk SIgnature allright (and the "repetitive" nature of it - A990A990 - is usually a sign hinting that it was automatically created by an "original" MS NT tool) Magic bytes 55AA allright the question remains about HOW/WHY that happened. really unusual. BTW no need to post the other two MBR's, they won't help us in making more light on the issue. jaclaz

What you posted is "crazy". It is partially (for the most part) a valid XP MBR BUT it has some residual of something else "below" a FAT (I presume FAT16, BUT could be FAT32) bootsector Second sector clearly starts with a FAT table "incipit", using F8 which means "fixed disk partiion". In the normal XP MBR there are three "strings": Invalid partition table Error loading operating system Missing operating system The posted MBR have them allright, but they are followed by: Invalid system disk Disk I/O Error Replace the <GARBAGE> (actually valid "DISK SIGNATURE") These three latter strings are present in the "normal" FAT bootsector for DOS (the one invoking IO.SYS, NOT NTLDR). This could happen if the device has been previously formatted as super-floppy as FAT and with a DOS bootsector. One problem is the EB1A90 at offset 0xCA, which is connected with the HP USB Format tool hack: http://reboot.pro/2246/page__st__15 The other one is the 6B2C in the reserved sectors at offset 0x1BC ( right after the disk signature). While it is entirely possible that the EB1A90 is also something that XP Embedded (and conversely POSREADY 2009) may do, the 6B2C are really strange, I would call this a mistery^2 . If you compare the MBR you posted with *any* standard MBR or with the "corrected by MBRFIX" one, you will see the above. Was the MBR sector actually 00ed before this install attempt? What else (which tools) have you used on the device? (in this or in in previous sessions) From which source are you installing? The good (or VERY bad news) on second thought, are: The partition data of the MBR you posted is about a FAT32 partition with UNbalanced CHS/LBA values as follows: 0C-80-0-1-1-124-254-63-63-2013119 size of the partition being (LBA) 2013119x512=1,030,716,928 It means that in an access of juvenile (or senile, cannot say ) dementia you posted the MBR of a (BADLY) partitioned/formatted 1 Gb USB stick instead of the one of the hard disk! Try again.... jaclaz

WHY? WHO are "us"? Do you feel like you can better the code and/or mantain it better than it is currently? Mind you there is NO secret about the app, everything is documented in the Forum posts or can be easily derived from the behaviour of the app, if you feel like you can do a better work on it, why don't you write your own utility (as opposed to PUSHing it's developer to do something)? You already posted about this: It seems like you failed to explain the new features you would like to have (or the Author finds them not useful or they would be so complex to implement for your special case as to break compatibility/reliability of the app). One thing IMHO is suggesting features, another one is PRETENDING to have them added and/or the source code released because of your personal *needs*. Why don't you try explaining AGAIN, this time in more detail: WHAT are the features that you would like added. (with as mcuh EXACT detail as possible) HOW you suggest them to be implemented. (even pseudo-code would do) WHY do you think they may be useful. (like a DETAILed real life example where they can be used) WHICH are the advantages of your proposed solution. Maybe the Author, Ilko_t , could then IF he finds them useful AND IF AND WHEN he has time to add them, decide to implement them. Remember that this is a "hobby" and the Author is NOT obliged with you or anyone else to do anything, let alone releasing the source code of the app, should he wish NOT to do so. Since you deploy 5-10 system per month, you are a Professional (and NOT a home user) maybe you could contact Ilko_t privately and (just an idea - I have no way to know if this is feasible/what Ilko_t may be willing to do) hire him, or substantially donate for the app development. jaclaz

Naaah, there is NO defense BUT: http://reboot.pro/13177/ BTW your antivirus does a completely different thing, it "snapshots" your current MBR (which is supposed to be "OK") and checks whether it has changed. This is a very reasonable approach but it does a DIFFERENT thing. @jeff.sadowski You apparently missed the "general point" I was trying to make. No matter WHO is the Author of that utility, you cannot reasonably trust him/her nor the validity of his/her whitelist or blacklist. The Author is (generically) the geekstogo thingy: http://www.geekstogo.com/ the actual download address: hxxp://ad13.geekstogo.com/MBRCheck.exe leads to them and the tool is actually recommended on their Forum. Look, something like this will give you a MDA5 of your MBR in a file : (or you can create the 440 byte file and SHA1 it). You do this a few times on the various system you work on, and you quickly have a "database" of "good" MBR codes. When you find a "positive" (i.e. a non-match) you quickly disassemble the MBR code (if there are no signs from where it comes from) and verify that it doesn't do anything "nasty". I have seen in my experience at least 50 of them, without counting localized versions and "strange OEM's" one. I frankly doubt that the mentioned tool has ever seen most of these. Additionally there are at least TWO known tools/approaches, one is MBRFIX and the other is the XP Kansas City Shuffle", that do use some unused byte(s) of a perfectly "kosher" MBR for their use. AND "bootmanagers" like grub4dos normally use some bytes in the MBR to store some needed info, as well as (other example) mbldr and heaven ONLY knows how many more, this will make an impossible to track down number of forks or different checksums. It is the actual "method" of comparing a checksum with a list of known ones that is flawed IMNSHO, as there can be as many different checksums on perfectly "kosher" MBR codes than stars in the sky. Of course if we limit this to original MS Windows, we have just 3 or 4 of them and it makes sense. As said the only usefulness of such a tool is to check for a relatively small number of very common MBR's and switch an alarm on if it is found different, but the times the alarm will be triggered on will be often due to false positives, and as you pointed out, you have not ANY *guarantee* that a malware is (intentionally or by mistake) added to the whitelist nor about the originality of the actual program, so if you are actually preoccupied, write you own tool and verify it yourself (NO other *safe* alternatives). jaclaz

Naah, Wikipedia is the very basic info, mostly for kids . Real developers (besides drinking COKE) : http://uranus.chrysocome.net/coke.htm Talk in some kind of jargon that it will take you a few years to understand, you want an example of developers talk, you should peek on some mailing list, or github examples: https://github.com/tmm1/perftools.rb/pull/24 http://gcc.gnu.org/ml/gcc/2010-03/msg00222.html (and these are the easy to understand ones ) jaclaz

WHY guessing? Wouldn't researching be more reliable? POSIX is a Windows NT subsystem: http://en.wikipedia.org/wiki/POSIX http://en.wikipedia.org/wiki/POSIX#POSIX_for_Windows http://en.wikipedia.org/wiki/Microsoft_POSIX_subsystem This is the "new version" of it: http://en.wikipedia.org/wiki/Windows_Services_for_UNIX (I have NO idea if this latter is 2038 compatible) PERL normally runs in the POSIX subsystem so it tests it (and not the actual NT). Well, actually I have worked on ANY Windows version, starting from 1.0, but NOT in the sense you seem to think the "developer" label has been given to me on MSFN, but I am NOT a developer, at the most I put a couple of lines of batch together (and PUSH "real" developers to do their work ) You must be joking. I am a dinosaur, one of the most advanced videogames I ever played has been (very recently) this one : jaclaz

Owww, come on : jaclaz

I don't get it. That article says that the QIC 40 is supported in Windows 95 (no more, no less). AFAICR the actual Colorado tapes were supported by both Win95 and 98 BUT the actual issue is specific to the QIC 40 model, see here: http://www.cwdixon.com/support/win98_support/backup.htm http://support.microsoft.com/kb/182624/en-us (right info, wrong reference ) in their usual simplicity the good MS guys made the .qic format change a bit between different versions of MSbackup: http://www.fpns.net/willy/msbackup.htm and later the 2K/XP version was completely different. http://support.microsoft.com/kb/305381/en-us So, your best option IMHO is to install a real Windows 95. OR try with a DOS program instead. (I presume some can still be found around) Some ideas may probably be got from this only seemingly unrelated document: http://h20000.www2.hp.com/bc/docs/support/SupportManual/lpg28247/lpg28247.pdf AFAIK the Linux FTAPE program is compatible. http://tldp.org/HOWTO/Ftape-HOWTO-6.html At the time "real" professional tape drives were SCSI, and for them we do still have an excellent proggy: http://www.datman.com/ is your SCSI or the "poorman's" floppy connected one? If this is the case you can try with a DOS program instead. (some can still be found around), like: http://h20000.www2.hp.com/bizsupport/TechSupport/SoftwareDescription.jsp?lang=en&cc=US&swItem=co156en&prodTypeId=12169&prodSeriesId=63951 jaclaz

Most probably it won't even actually crash, it will simply create/display/print/whatever "silly" dates, or, if dates are used for internal calculations, show/etc. "silly" results. jaclaz

Maybe is the same strange approach the WINFLP has/had? Something half-way between Longhorn and XP rather than between XP and Vista (with a touch or two of "XP Embedded") I vaguely remember having setup a couple of them, and they actually used if I recall correctly - in addition to F6 - a .XML file to add specific drivers. I am pretty sure that "basic" "no-dependencies" command line apps should be able to run in the booted Environment, just like they do with a Shift+F10 command prompt on a normal XP setup. All in all, to diagnose all that is needed is a set of copies of the MBR, though it is possible that to take them it is needed to interrupt setup. Something like: would do nicely. jaclaz

Well this confirms my guess that it was completely unlike "normal" (or maybe "Normal" just for you) and adds none of the info that I asked about. It's not really difficult. IF at any time during your "normal" procedure Disk Management is used, there are simply two cases (normally ): It will see that the last two bytes of the MBR are 0000 and will prompt you to initialize the disk, etc., etc. (see above post) It will see that the last two bytes of the MBR are 55AA and will do NOTHING. jaclaz

Tripredacus, IMHO you are failing to test or report correctly. (as you did on the linked thread). As soon as a DIsk (I mean completely 00ed disk) is opened in Disk Management, the Disk Management should ask you to "Initialize" the disk. When you click YES, this normally results in three DIFFERENT sets of writes to the disk first sector: the MBR CODE the Disk Signature the "magic bytes" signature 55AA Then when you create a partition on the disk, (let's for the sake of simplicity that you create a Primary partition) a single entry is written to the disk first sector: a partition table entry (or if you prefer MBR data) Then when you set the partition as "Active" or "Bootable", a single byte is written to the first byte of the partition table entry: 80 (still part of the MBR data) In other words, if before trying doing other things/different tests, you would simply 00 out frst sector of the disk and repeat the same exact steps you did here: possibly better describing them in more detail AND making a copy of said first sector after each subsequent "stage" of that procedure, we may have something to work on. Particularly if you could better describe the actual install procedure you are doing: AFAIK there is NOTHING like a "normal" Setup, what you are probably doing is to boot a PE of some kind (possibly a 2.x or a 3.x) and from it install the actual PosReady from it's .iso. (but this are mainly my guesses ) jaclaz

This seem to me "good enough": http://www.f2ko.de/programs.php?lang=en&pid=b2e But we also have an IDE for batch files : http://sourceforge.net/projects/batchcompiler/ And also a new thingy , Visualbatch : http://visualbatch.sourceforge.net/ The good ol' way: http://www.ericphelps.com/batch/samples/obfuscating.txt jaclaz