Microsoft employee Raymond Chen says that an encrypted copy of Microsoft Bob is included on the Windows XP CD to take up space.
But Windows XP doesn't take up the entire CD; there is a lot of free space remaining.
Is the story true?
Skeptics Stack Exchange is a question and answer site for scientific skepticism. It only takes a minute to sign up.Sign up to join this community
The story that Chen claimed it is true. But he was most likely joking. Above all it would be impossible to check because Chen — in this supposed joke story — claims the encryption key was created by just mashing the keyboard.
Also the "slowdown" would be by adding 30 MBytes, which is less than 5% data compared to a full CD.
So just assume Chen made an April Fools joke... in June 2008.
The answer is that only half of MS Bob is on the Windows XP disk.
Raymond Chen gets it wrong in his blog. Dave Plummer, the employee that implemented it, spoke about this on a recent YouTube video. However, even Dave gets it wrong.
OEMBIOS.BIN is the dummy data. There are two versions of it that correspond to the retail and OEM version of Windows XP. Each is only 13 MB, so each are only half of MS Bob. To verify that you have the Bob blob, the code decrypts OEMBIOS.DAT with a hardcoded key and bespoke Feistel cipher routine. Unencrypted, the file is just an INI that indicates which variant of Windows XP that you have, but it also contains a list of 100 hash values. The hash values are for each 1/100th of the 13 MB OEMBIOS.BIN. On boot, winlogon.exe calls into licdll.dll, which picks a random hash from the .DAT and checks the corresponding 131 KB (1/100th of 13 MB) worth of the .BIN.
One motivation for this, as mentioned by Dave Plummer, was to maximize the difference between the retail and OEM disc versions. Without this, the differences would amount to less than a kilobyte. One could theoretically collect and compress all of the required files to produce any OEM variant of the install CD, and have it be just a few KB. Back when piracy was very Usenet centric, pumping up the file sizes would at least cause such a file to span multiple messages (due to Usenet's 15 MB limit.)