Monday, January 28, 2013

Remove write/edit protection/enforcement from Microsoft word document from code.


This is not a kind of solution that I usually like bragging about the whole day. However as I couldn't find anything as such in the internet, I thought it would be nicer to add one more scarce resource to be available in the internet, if in case somebody else is looking for it.

Problem: How to remove a password from password enforced word document using c# code(or may be any other code) when you already have a password. Before getting in to the solution let's see what kind of password protection/enforcement I'm talking about.

To enforce write/edit protection in a word document you can simply follow the following steps.
  1. Create a new word document.
  2. Go to Review ribbon tab.
  3. Click on Protect Document.
  4. Check the Formatting restrictions if you want users not to be able to apply extra formatting on the document.
  5. Check the Allow only this type of editing in the document if you want users to be able to apply certain kind of changes to the document. To do so select the kind of changes you want to allow the user.
  6. Click on Yes, Start Enforcing Protection button.
  7. Save and close.



Disclaimer: Please note that this is not a cracking, not even closer to something that can be called cracking.

Solution:

public void RemovePasswordFromDocument(string documentPath, string password)
        {
            var app = new Application();
            app.Visible = true;
            object originalFile = documentPath;
            object oFalse = false;
            object missingObject = Missing.Value;
            try
            {
                object generatedPwd = password;
                var doc = app.Documents.Open(ref originalFile,
                                             ref missingObject, ref oFalse,
                                             ref missingObject,
                                             ref generatedPwd, ref generatedPwd,
                                             ref missingObject,
                                             ref generatedPwd, ref generatedPwd);

                if (doc.ProtectionType != WdProtectionType.wdNoProtection)
                {
                    doc.Unprotect(ref generatedPwd);
                }

                doc.Save();

            }
            finally
            {
                app.Documents.Close(ref oFalse, ref missingObject,
                                    ref missingObject);

                app.Quit(ref oFalse, ref oFalse, ref oFalse);
            }

        }

That's it. Code is pretty straightforward. Only thing you need to keep in mind is that your project needs to reference two assemblies Microsoft.Office.Interop.Word.dll and office.dll and these are something that are installed when you install Microsoft office application itself. So no worries.

Monday, January 7, 2013

Thought on Preview of Immutable Collections

Did you ever think of having immutable collection in your .net code - a collection that is really thread-safe and gurantees no other thread will ever change it while one thread is sort of reading it? I thought ReadOnlyCollection<T> and ConcurrentBag<T> were to my rescue, but surprisingly they aren’t.

Early this morning while having my regular cup of coffee “keep me updated” time, I came across this news "Preview of Immutable Collections Released on NuGet". Well apparently this immutable collection is something to think about, and not surprisingly Microsoft is already on it. I’m assuming that you are already familiar with the “immutable” concept in .net. If not you can take string as an example. String is one of a kind immutable collection of char, which means whenever you add or remove a character from a string object you get a new one. The state of immutable objects cannot be changed. When you do so, you get a new object instead. The older one is still intact. For more explaination you can always refer to wiki.

Immutable collections behave in a similar way. If you have grabbed the concept of immutability(getting a different one after changing the original), then you surely must be thinking that this thing is going to cost you some memory and for a huge list- millions of byte. On the contrary, immutable list are stored as immutable binary tree structures instead of flat arrays. This has a huge benefit as the new list returned after changes share the same memory space with the original immutable list.

So what if you want your list to be mutable for an instance, make the necessary changes-addition and removal of the list items and then return back the immutable list once again. This is going to save you some overhead. Bingo....Immutable lists do have a method called ToBuilder() that gives you it’s corresponding Builder class similar to StringBuilder. You can then mutate the collection, and use ToImmutable() function of the builder to return Immutable list again. The concept is very much similar to String and StringBuilder, so won’t be that hard to get used to it.

Immutable collection seem to be worth trying out. Haven’t done any benchmarking test on it yet, but hopefully somebody will come up with it one day. :) . Do check it out, but make sure you read this post by Eric Lippert as well.