Phoenix Protector 1.0.0.1
Today, I released the first version of my Phoenix Protector. Basically, it's an obfuscator for .NET assemblies and has all common obfuscation features it's supposed to have. For the technical information, you can visit the product's page. Here, I intend to talk a little bit about the background of this product.
Last year, I wrote an online protection system for .NET assemblies. I did it, because the company I was working with wanted it to be online for licensing reasons (I've never liked the idea). Thus, I had to develop the internal structure to be able to communicate with the online asp.net interface. Unfortunately, the project was abandoned because of reasons that weren't technical but internal. Not even in an abrupt way, I wondered for months what was happening. Eventually, last September (after I completed some other work for another company) I decided to close the project offically. I had a lot of valuable code to release but wasn't given a chance to. So, I decided to write a new protection in a completely new way. Discarding the online structure brought a lot of work. First, I had to threw away the licensing system, which was implemented through RSA2048: very secure, but the key generation process was way to slow for users. I could've reduced the keys strength, but the whole licensing system was implemented to work with a server anyway.
So, I wrote a Win32 interface, threw away some features, put new ones in it and made it work with the framework 2.0 (the 3.0 doesn't introduce changes which affect protections). Finally, in the last period of time, I tested it throughout on Windows Vista x64. Seems strange, but the x64 framework differs a bit from the x86 one, and on Vista some obfuscators don't work at all (I don't make names). I, too, had a little problem with my Phoenix Protector, but I fixed it in a couple of days.
At the beginning of November, I decided to see if it was possible to implement the native linking, a feature that, as I have already stated in an article, relies entirely on the global assembly cache. In 10 days of work I had some working results. However, I decided not to implement it. It had too many problems and was not reliable or, at least, I thought that making it work in most cases would take too much maintainance work. I don't want to say it's impossible. Simply that it didn't make too much sense to me. Moreover, on Windows Vista it would require any .NET software to work with admin privileges (at least for the first execution) and I didn't want to (nor could) force every asp.net programmer to run protected code under these conditions. It goes without saying that it needed the x86 framework even on x64 systems, but that's a requirement every serious native protection for .NET implies (even my old one) for working on every windows system. I don't know if many people are aware that most protections that claim to secure the .NET code through native code are really unsecure. Before all the dumpers for .NET protections came out (including my one), I used to scan the process memory with a hex editor looking for PEs and that's what .NET dumpers do (ok, to be honest, there's another method which hooks entries in the mscoree). Once the assembly was dumped, one had the original .NET code with all its names etc. I wonder how many companies rely on these solutions.
Anyway, I might add a licensing system with native protection in the next releases of this project, but right now my main concern was to have a good working obfuscator that every .NET programmer could use no matter what kind of solution he is working on.
Last year, I wrote an online protection system for .NET assemblies. I did it, because the company I was working with wanted it to be online for licensing reasons (I've never liked the idea). Thus, I had to develop the internal structure to be able to communicate with the online asp.net interface. Unfortunately, the project was abandoned because of reasons that weren't technical but internal. Not even in an abrupt way, I wondered for months what was happening. Eventually, last September (after I completed some other work for another company) I decided to close the project offically. I had a lot of valuable code to release but wasn't given a chance to. So, I decided to write a new protection in a completely new way. Discarding the online structure brought a lot of work. First, I had to threw away the licensing system, which was implemented through RSA2048: very secure, but the key generation process was way to slow for users. I could've reduced the keys strength, but the whole licensing system was implemented to work with a server anyway.
So, I wrote a Win32 interface, threw away some features, put new ones in it and made it work with the framework 2.0 (the 3.0 doesn't introduce changes which affect protections). Finally, in the last period of time, I tested it throughout on Windows Vista x64. Seems strange, but the x64 framework differs a bit from the x86 one, and on Vista some obfuscators don't work at all (I don't make names). I, too, had a little problem with my Phoenix Protector, but I fixed it in a couple of days.
At the beginning of November, I decided to see if it was possible to implement the native linking, a feature that, as I have already stated in an article, relies entirely on the global assembly cache. In 10 days of work I had some working results. However, I decided not to implement it. It had too many problems and was not reliable or, at least, I thought that making it work in most cases would take too much maintainance work. I don't want to say it's impossible. Simply that it didn't make too much sense to me. Moreover, on Windows Vista it would require any .NET software to work with admin privileges (at least for the first execution) and I didn't want to (nor could) force every asp.net programmer to run protected code under these conditions. It goes without saying that it needed the x86 framework even on x64 systems, but that's a requirement every serious native protection for .NET implies (even my old one) for working on every windows system. I don't know if many people are aware that most protections that claim to secure the .NET code through native code are really unsecure. Before all the dumpers for .NET protections came out (including my one), I used to scan the process memory with a hex editor looking for PEs and that's what .NET dumpers do (ok, to be honest, there's another method which hooks entries in the mscoree). Once the assembly was dumped, one had the original .NET code with all its names etc. I wonder how many companies rely on these solutions.
Anyway, I might add a licensing system with native protection in the next releases of this project, but right now my main concern was to have a good working obfuscator that every .NET programmer could use no matter what kind of solution he is working on.
posted by Ntoskrnl at 5:02 PM
0 comments
