Yet another thing I am focusing on this year is security and programming best practices.
So this morning I have been putting together an example (that is not yet ready for publication - should be this week), but now it is almost 2pm and I really need to get some other things done today ... so here is a quick summery of what the title of this entry is refering to (and what the final write up will go into detail on):
- Create a utility library that does what you want it to do (works really nice if you use interfaces as much as possible)
- Compile that dll
- Create another project that will use said library
- DO NOT REFERENCE THE LIBRARY, but instead add it to your new project and give it whatever name you wish
- Set the properties to treat the library as an embedded resource
- Write the code to pull the library out of the manifest as resource stream
- Write your code that uses the library
Here is the code that loads an assembly from a resource file in my simple example:
128 private void btnDynamic_Click(object sender, System.EventArgs e)
129 {
130 Assembly assembly;
131 Type t;
132
133 // Get the stream of the resource file
134 using (Stream stream = Assembly.GetExecutingAssembly().GetManifestResourceStream("DynamicLoadAssembly.Resources"))
135 {
136 // get the length
137 int length = (int)stream.Length;
138
139 // set up the buffer
140 byte[] buffer = new byte[length];
141
142 // move the contents of the stream to the buffer
143 stream.Read(buffer,0, length);
144
145 // load the resource bytes into an assembly
146 assembly = Assembly.Load(buffer);
147
148 // get a specific type out of the assembly to use
149 t = assembly.GetType("ExternalAssembly.MessageBox", true);
150 }
151 // set up the message to send
152 object[] message = new object[] { txtMessage.Text };
153
154 // call the method on the class (using a static so the instance I am passing is null)
155 object s = t.GetMethod("GetMessage").Invoke(null, message);
156
157 // Show the message that is coming out of the external dll
158 MessageBox.Show(Convert.ToString(s));
159 }
Before reading on, let me explain that I am not a security expert and still have a lot to learn (hence my playing around with this stuff) so take my opinion as just that (my opinion) and please feel free to point out where I am wrong (got to learn somehow!).
Why would you want to do this? If your library class has some important logic in it, you might want to obfuscate it so it is a little harder to read (a lot harder usually), then if you take that .dll and encrypt it (or not) and put it in a resource file.
What good does it really do? Currently it would stop people from reading your code in Reflector orIldasm and slow down a determined reverser, but that is probably about it.
Seems to me, outside of writing your own execution engine (which isn't going to happen, unless you can do something with hosting?) there isn't a foolproof solution against reverse engieering - since you always have the memory representation that can be dumped and analyzed ... so obfuscating and other things that slow down down reverse engineers seems to be the most cost effective for typical release software ... what do you think?