Ever been pissed off at the SharePoint code? Banging your head against the wall, trying to figure out why something is not working for you, you’re looking at it with a reflection tool and just want to see what would happen if you change a single line of code?
You don’t have the SharePoint source code, but you still want to fiddle with it and compile your own build? You might have never thought that is possible, but here in this post I will show you how!
This is by far extremely awesome and some seriously fun shit, so enjoy!
(Disclaimer: don’t do this, seriously. Just learn from it. I am sure that reverse engineering is written to be forbidden somewhere. And don’t do this anywhere near a production server.)
STEP 1) Get the Reflexil plugin, either in Reflector or Telerik JustDecompile. It is called “Assembly Editor” and is available as a JustDecompile Plugin. Ever since Red Gate basterdised Reflector I prefer Telerik JustDecompile, it is free and built in Sofia, where I live and where OneBit Software is located.
Once you get all the components in there, load your tool and the assembly that you want to fiddle with.
In my example I modify Microsoft.SharePoint.ApplicationPages.Administration.dll, to make the CA UI show that I have a custom build, but you could easily do this with Microsoft.SharePoint.dll or any other assembly.
STEP 2) Browse through the assembly and find the code you want to modify. If you are tweaking a property, you need to specifically select the getter or setter. The UI will look like below, with many tabs in the Reflexil UI:
Right-click and either choose to edit the instruction, or “Replace all with code” for the fun stuff.
STEP 3) You will end up in an interface looking like the one below. On the left you will see generated code, on the right you will see instruction information. In my example, I replaced return default(string); with return “Radi’s Custom SP Build!”;
Make sure the Compiler version is the one relevant for the assembly, in my case v3.5, and hit Compile. You will get standard compiler errors if you have screwed something up. Otherwise if successful, the Instructions on the right will change as per your modification. That stuff is IL, you might already be familiar.
STEP 4) Go ahead and save your modified assembly. It will prompt you to save it with “Patched” in the filename:
STEP 5) After you save it, Reflexil/Telerik JustDecompiler will tell you some very important stuff about the Strong Name of the assembly. This step is key to get this to work and there’s deep theory about assembly signing coming to play.
Assemblies are usually signed with a key so that they don’t get tampered with in the way I’m doing it. Unless you have the key you can’t modify it and resign it. This is something that Visual Studio does when it builds an assembly.
You can either remove the Strong Name, or register the assembly for verification skipping. This is something you could do with the sn.exe tool, or just through the interface below:
“Register it for verification sipping” requires that “sn.exe” is in the path variable so the tool can call it. It will basically execute:
sn -Vr yourAssembly.dll
I had to add “C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A\bin\NETFX 4.0 Tools\x64” to my Environment PATH variable and restart JustDecompiler. You might want to do this before you edit assemblies so you don’t have to do it again. This is what you will see if sn.exe is not found:
STEP 6) What you should see next is the patched assembly, but the most important part is the PublicKeyToken, it should not be null:
STEP 7) The last step, rename the “Patched” DLL to its original name, then do an IISRESET.
And here she is, the most beautiful SharePoint release ever:
Please comment if you like this post!
