We just cleared it up that the MSDN version has the certificate or whatever CLEARED and the WZOR version has it SET and yet you come and post this? Why? WHY? Are you on a mission to confuse people or what is it? What you wrote is WRONG.
Technically correct, probably. Indeed, it seems likely that there is some sort of signature on the WZOR ISO. Probably intended to track the leak or some such. It would further seem that WZOR walked right into that. But any implications for all of *that* are for them to work out. And I wish them the best of luck! What matters most to us users, at least right now, would be any difference in the installed system. So I just did a quick check on the contents of install.wim and the files inside are a binary match between the WZOR and MSDN WIMs. This does not of course guarantee there isn't something funky going on at a deeper level, but it certainly is most welcome as I was not looking forward to doing a re-install so soon...
That's good to know. I was too quick to discard my WZOR copy so I couldn't check further what exactly was different.
This should clear it up: MSDN VS WZT Here is a tip hover your mouse over the thumbnail file name is displayed, save target as and you download the file MSDN.jpg or WZT.JPG
I think you are missing a critical attribute of a cryptographically secure hash algorithm like SHA1. Algorithms like SHA1 were specifically designed with the goal of making it impossible for someone to intentionally craft a non-identical file with the same hash value (called a "hash collision") as the original file. If it were possible for someone to intentionally craft a file that had the same SHA1 hash as the "real" MSDN version while being not 100% identical to the "real" MSDN version, that would be a huge deal as it would mean that SHA1 had just been broken and is now useless for cryptographic purposes.... eg. that would effectively make https/ssl broken as most certs use sha1 hashes.
Once you patch the WZT file, its checksum will be the same as the legit one on msdn because both files are then identical.
As good a guess as any, but apart from possibly id'g leaks, what are these 32-byte fingerprints for, anyway? I don't think they've crossed my radar before. Earlier, mictlan referred to it as a "digital signing," though when we normally talk about signing files, the result is visible in a tab when looking at the properties of the file. That's not the case with the install.wim. Here's a screenshot of the leaked install.wim, in case anyone's curious: Yes, thanks for confirming. Excellent thread all around.
#70 No we can't claim that would be true if you read this post h**p://forums.mydigitallife.net/threads/36136-WZT-to-MSDN-Windows-8-Enterprise-Edition-(DELTA)?p=616592&viewfull=1#post616592 I already knew it when people in this thread were talking about missing files. Maybe not that big deal with a missing Eula file but everyone knows it can break the Hash if we use different command switches, script content or anything else that differ, even a missing file.
Guys, how did you make xdelta work?? I've installed both Microsoft's Visual C++ 2010 redistributables (32 bit and 64 bit) but for the life of me I cannot get this damned thing to work!! xdelta3.0z.x86-64.exe gives me this error: And xdelta3-3.0.2-x86-32.exe gives me another error: The command line I'm using is the one recommended here: xdelta -d -s source.iso xdeltapatch destination.iso I'm running Windows 8 enterprise x64.
Ok, I'm giving up this crappy xdelta thing. It doesn't even work!! Which Hex Editor are you using to open such a huge file?? XVI32 just hangs trying to load the entire file into memory!! (just another crappy program, it seems! )
I'm using WZOR's leaked iso with sha-1 73DF20A98D8CDF52E70FBFFECBEBA63F2A242322 The patch I'm using is the one attached to the first post of this thread. I've installed HxD and it opens the file instantly! Yay! However, I don't know the address of those bytes. Does anyone know their address? Or is it a unique string that can be searched?? Edit: Nevermind, I've searched the string and it seems to be unique. I've changed all the bytes to zeros. Going to test the SHA-1 to see if it's correct. Crossing fingers!
for me it worked instantly and without problems, the error you posted: xdelta3: target window checksum mismatch: XD3_INVALID_INPUT usually means you are trying to apply a patch on wrong source eg: you can not apply the Enterprise X64 patch to 32-bit source nor the pro version (either 64 or 32-bit)
Got it!! New SHA-1: 4eadfe83e736621234c63e8465986f0af6aa3c82 Thanks a million, guys. I've avoided wasting a few gigabytes of precious bandwidth today!!