IMPORTANT Update on 15 August 2009:
1) I thought it might be good to actually post a link to my next hack: how to actually fool Windows Resource Protection from detecting this change. With that, Windows won’t have a clue you modified shell32.dll, and you can use the same procedure if you modify any other file. This has the benefit of not having to turn off WRP or never using it – it’s actually quite useful if you get a corrupt file. And with the hack, if your new file gets corrupted, it’ll actually restore it to your CHANGED one. I did this a few days after this post, but didn’t think to update this post. With this, I also removed some of the older thoughts on how to get around it – not only because one is a bad idea, quite very bad, but because the post I am linking to is quite simply a much better method. Note: I still haven’t had an update on shell32.dll, however I can say that no updates otherwise have failed. Everything is running perfectly stable, also.
2) I saw some typos or other things, including a letter ‘o’ in hex dump where it obviously should be a zero.
3) Why I didn’t put in the offset of the file to begin with I don’t know. However, thinking about it – I won’t put it in, either. And here’s why: if someone has a different version or they actually have a hacked version (even if it’s a resource moved/removed or changed), it is possible it’ll be a different size. In that case, the offset has the possibility of being different. So, it is best to search for the code (in hex) since then you’re sure you’re in the right spot – especially since the code I specify is only in the file one time.
4) I do actually use this at this time. It is stable. But it isn’t for everyone. It does involve some potentially risky tasks. And if you don’t take care of your system, it could be quite bad. Do proceed with that in mind. I think the most interesting part, for me, even, is the concept and procedure itself – not what it does (though, what it does is quite useful to me, I must admit).
The now updated post is what is below:
So, Microsoft thought it’d be a good idea to make Windows Vista’s default CD/DVD/BD burning option as ‘Live File System’. This allows one to close session and as I understand it, write to write-once discs even more than once. Okay, what’s the big deal then, that seems fine, right ? Well, no, not for everyone. The problem is 1) compatibility with earlier versions of Windows, and quite possibly other operating systems (read: not Windows); and 2) everytime you close the session, you lose valuable disc space.
Now, Microsoft decided to not only make it default, but also made the other option – called ‘Mastered’ – HIDDEN. You actually have to click on a button to show formatting options. Ok, so they put the option in at least. But the fact of the matter is, when you see Next and only a link, it’s almost like fine print. You sometimes just click Next without thinking about it. Then it’s too late and for some (like me) it’s a wasted disc. Sigh.
The other problem: there is no way to change the default. Or well, that’s what everyone says. I decided, and perhaps this makes me crazy (but hey – I lost too many dvds due to a horrible design decision), to see if I can find a way around it. And after about two weeks of fighting it, I realized what was giving me trouble. The trouble ? It’s related to a system modification but I’m on 64 bit Vista which has Windows on Windows 64 [WOW64] and I forgot it and was thinking of only 64-bit instructions (as opposed to 64 AND 32). Not to mention other stupid similar things.
Now, I must warn you that this involves modifying a system file, so if you feel uncomfortable with that (or like to blame others for making a mistake – no matter whose fault it is – while doing something that can be risky), do one of:
1) Test it in a Virtual Machine install (or similar).
2) Backup / System restore (system restore point is enough)
3) Don’t do it and just read it for background (or don’t read at all).
The file (or two files if you’re on 64-bit Vista) ? shell32.dll
On Vista 64 you have to modify the 32 bit version (under \Windows\SySWOW64) and 64 bit version (under \Windows\system32). On Vista 32, you only have to modify the 32 bit version (under \Windows\system32) since obviously there is no 64-bit version. So when I give instructions to do this, you need to adjust which location you’re doing this from. Also, don’t be a moron like me and forget that you have to do both places in 64-bit Vista and not modify only one. Reason being is, if you replace say 64-bit on the 32 bit version, your 32 bit version programs will have a bloody fit! (Ie fail to load properly, and for good reason: they can’t find what they need in shell32.dll as it’s completely different locations – because of size difference in file – and thus nothing will be found). It took me several days to realize what I was doing.
And that’s even when I saw the file size difference. Not sure what in the world I was thinking.
Also, there is one possible alternative to this solution; however, I came up with this one after the initial one did not work for me very well (basically, mastered option
does nothing in advance so I bypass the prepare disc dialog box, as opposed to changing which option is selected). I will mention it at the end of this post.
Note that I actually modified two areas of code, but in hindsight I believe only the first one is necessary. I may try it later. But for now I’m just pleased I figured this out.
I vowed I would never program under Windows (only Unix/Linux and others), but somehow I broke it due to this issue, and I have even wondered about continuing it, and re-learning assembly.
Like I said, unfortunately you must modify a system file; I looked in the file for registry entries related to this problem, but there is none that changes selection. However, I did realize that one registry entry that already exists (under Current Media which is a dynamic key and is under the drive the media is in in the HKEY_CURRENT_USER tree – ‘Software\Microsoft\Windows\CurrentVersion\Explorer\CD Burning\Drives’. Under Drives is one or more keys, one for each cd/dvd/blu ray drive you have. Find the correct one and if a disc is in it, there will be another key called ‘Current Media’. But the problem is: when you take out a disc, the key (Current Media) disappears and so the value is deleted. Thus, for it to work, you’d actually have to temporarily modify registry before burning. And if you can remember to do that, you might as well remember to just change it to Mastered. So, what do we do ? It’s actually very simple in theory:
We modify one instruction in shell32.dll, which makes the dword value (Blank Disc to be precise) as 0, instead of 1. It’ll always be 0. Whether it’s blank or not. In the case it’s been burnt, you’ll simply open the drive and the files will be there. In the case it is actually empty, you’re taken to the drive and anything you copy/paste there will be put in the temporary burn folder. Then to burn just right click in the directory and click on Burn to Disc. Yes, I tested this and it works fine for me. Hopefully for anyone who is interested in trying, it works for them too.
So, what instruction are we modifying ?
32-bit version looks like:
mov [ebp-220h], 1
It needs to be:
mov [ebp-220h], 0
Yes, you’ll need a hex editor – CFF Explorer is not only free and a resource editor, it’s also a hex editor AND it’s 64 bit compatible, which means you don’t have
to worry about it truncating 64 bit files – something that some editors will do unless you ‘expand’ it first. So I would recommend this one if you don’t have another one
that you know will work right (I can tell you that WinHex will not work on 64 bit for sure, and the free version has a limit on file size it can save anyway. And I believe I’ve even encountered some supposedly 64-bit compatible programs that don’t work right unless you expand. And even then it’s possible it won’t. (Or, I did something wrong – either way, CFF Explorer is a good option) So, if you have Vista 64, may be safe and just grab CFF Explorer.
In hex the above looks like:
C7 85 E0 FD FF FF 01 00 00 00
and the new bytes should be the same, except the 01 should be 00.
But, DON’T just search for those bytes and change the first match, because it’s quite possible there is more than one match of those exact bytes, and you could be changing something that should be not changed at all. Okay, in fairness – I probably shouldn’t even change what I’m writing about – however, it was a very interesting, fun learning exercise. And I’m fed up with losing dvds. Interestingly enough, in the beginning of this project, I actually tried various things and probably ended up wasting 10-15 CDs. However, very well worth it to me, not only because it got me back into assembly language, but also it was fun problem to solve. :)
But back to the subject. We actually need to find quite a bit more bytes, to make absolute sure we have the right place and bytes to change.
Search for the following (there should only be one match in the entire file – this is important!):
C7 85 E0 FD FF FF 01 00 00 00 6A 04 8D 85 E0 FD FF FF 50 6A 04 57 68 A8
34 8F 76 53 FF D6 8B 85 E4 FD FF FF 6A 04 89 85 D4 FD FF FF 8D 85 D4 FD
FF FF 50 6A 04 57 68 38 65 91 76 53 FF D6
(in CFF Explorer you will have to remove spaces to find the sequence but I’m leaving them separated for clarity).
What that code basically translates to:
Put the vararious data in registers (or variable if you prefer) and then call the Windows function RegSetValueExW (ie set Blank Disc to 1).
We want it 0. So change the 01 in C7 85 E0 FD FF FF 01 to 00. Now I also did another modification and while I don’t think it’s necessary, just in case it is I will give it to you.
Search for the byte sequence:
6A 04 8D 45 F8 50 6A 04 53 68 A8 34 8F 76 FF 75 D4 FF D6
And change it to:
6A 04 90 90 6A 00 6A 04 53 68 A8 34 8F 76 FF 75 04 FF D6
Save the file somewhere where you will remember which version (if running 64-bit Vista) it is. Then, if you run 32-bit Windows you can replace it (one way is booting into safe mode, right clicking on the file in system32 and click on Properties. Then Security -> Advanced -> Owners and then take ownership. Then you should be able to rename it (as a backup) or delete it if you really want to.
If you run 64-bit Windows, you’ll need to edit the 64-bit file too, and may as well replace both versions (same procedure except 64-bit is in system32 and 32-bit is in syswow64) at the same time.
Ok, for the 64 bit version we have, naturally, 64 bit instuctions, to worry about. New registers and stuff.
So in the 64-bit version we’re looking for this code (does same thing as 32 bit, but in 64-bit programming instead):
mov [rsp+40h], 1
But again – we have to make sure we’re at the right instance of this instruction. Find these bytes:
C7 44 24 40 01 00 00 00 EB 00 BF 04 00 00 00 48
8D 44 24 40 48 8D 15 C7 7A 3C 00 45 33 C0 48 8B
CB 44 8B CF 89 7C 24 28 44 89 44 24 20 FF 15 97
52 3C 00
Change the first occurrence of 01 to 00.
Second change (the one I don’t believe is necessary but haven’t tested without it).
Find the following bytes:
48 8D 44 24 38 48 8D 15 B2 80 25 00 45 8B
CE 45 33 C0 48 8B CB 44 89 74 24 28 44 89
44 24 20 FF 15 81 58 25 00
and change the
48 89 44 24 20
to
44 89 44 24 20
Now you can simply replace the files in the system directory.
A couple more things, however:
SFC, Windows tool to check system files integrity, WILL report issues. There actually shouldn’t be any issues (if I wrote this up right and you followed correctly), but I would guess it reports a violation due to different checksum. One option is to never run sfc. I have a better option though. A couple days after I wrote this, I set out to fool Windows Resource Protection (WRP) and it was far more simple than actually figuring out this change to shell32.dll. Read all about it here.
Something I said before that is a possibility, I did try. It is bad. It’ll not only corrupt the backup, if I remember right it also prevents WRP from working properly, on the file. And as I noted above, with the new(er) procedure, if you actually modify the file and it works, and then something happens to the modified version, you can actually have Windows restore the MODIFIED version. The bad suggestion was:
Or lastly, you can delete the file (I think) from the cache directories, which is under \windows\Winsxs in Vista. Not directly under it mind you, but in several sub directories.
Again: don’t do that. It’s not the same as dllcache in previous versions of Windows.
With respect to updates: I haven’t had a problem yet and everything is rock solid. But shell32.dll has not been modified yet, either, so I don’t know if Windows update will actually replace, or just patch (my fear is: replace) but only time will tell. I should know because I don’t for see myself buying Windows 7. Yes, it’s a lot better in every way than Vista but … money.
As for the other possible solution I mentioned:
DLL files have resources. If you get a resource editor (again CFF Explorer can do this), you can edit these resources. Inside uifile 48, you’ll see some duixml output.
Note that the formatting is very important. But: if you look carefully, you’ll see that udf (which is resource string 13593 which points to the text Live File System – the exact same text you’ll see when you use Windows Vista’s prepare disc dialog) has selected=”true”. It is possible that you may be able to rearrange it so that udf is changed to mastered, the resource string is changed to 13594 (for mastered text), or in other words: swap the order so that mastered is selected. One problem I had with this is: even when I tried that, it seems BOTH were selected, as if they both had selected=”true”. So, this, along with the stupidity of me writing 64 bit file to 32 bit file, made me think of the solution I gave above (far more fun to me anyway!).
If it does work however, when you fix that mistake, it would be probably easier and safer. Also less likely to be changed in an update, though again I don’t know how Microsoft handles updates on system files (I hope patching but who am I to say for sure ? – it’s an executable so quite possible it’s replaced).
Other than that, you might want to make sure the file is the exact same size, as I did. But that shouldn’t be a problem with my above solution.
For my fellow sticklers out there: yes, technically ‘mastered’ is not selected by default, despite the title of my entry; however, as far as I know, mastered option basically just prepares the burn directory, and gives you the option of Burn to disc, which is exactly what my solution does.
By the way: if for some reason the instructions do not exist, then, first and foremost (and obvious) do not edit the file. And secondly, you can use a disassembler (IDA Free come to mind as one possibility) to find the right area. What you’re looking for is that instruction (mov) I pasted in close proximity to the RegSetValueExW call, as well as it being the one related to ‘Blank Disc’ registry dword value.
One more thing: should you happen to want to use ‘Live File System’ and you have used this hack of mine, it’s still possible without modifying anything. Simply run this in a cmd prompt or even in the run dialog:
rundll32.exe c:\windows\system32\shell32.dll,PrepareDiscForBurnRunDll F:
where F: is your dvd drive. It’ll open up the window and you can do whatever you need :)
Until next time…
- Cody