Remotesoft's Salamander 1.1.6.0 (Native Compiling)

The version (taken from the rscoree.dll) of the Salamander is some months old: I didn't bother to try a new version. However, the things I'm going to say are still valid.

This is no reversing article (you do know reversing is illegal, right?). I'm not going to debug, disassemble or do any other thing to other people's code. The only code I'm going to show is my own code. That's legal, alright?

Let's spend two words about this protection. It's quite famous because on the homepage it says explicitly that the protection compiles MSIL into native x86 code. Also, on a lot of forums it's being advised because of this feature. To obtain a demo of this protection isn't so easy: you have to do it through mail exchange. The protected exe I have (a simple hello world .NET windows application) is provided with the protection's dll: rscoree.dll. I haven't touched the dll, because it would violate the rights of Remotesoft.

If I open my protected executable with ildasm I can see that there's no way to disassemble the original methods, just as Remotesoft's homepage says. In fact, the result of this operation is something like this:

When I looked at the exe with the CFF Explorer I noticed that it contained a section more than regular .NET assemblies. Moreover, the #US (Unicode Strings used in the application) stream was empty.

I executed the application, opened the process with WinHex, went to the additional section of data and saw this:

That's my original #US stream... Strange enough.  A few bytes after the original #US stream I saw this:

Uhm 13 30 01... Seems to be the first dword of a fat header method, the next dword is the size of the code and the signature dword is null. The code ends with the return opcode 2A. I linked the RVA of a method of my exe to this code and opened ildasm. The disassembled code is:

Ok this is the code of my original Main. That's VERY strange. I thought: maybe I find the other methods as well... But the section didn't contain other code... I had something in mind and decided (of course) to give it a try: I was already very skeptical about the native code. I took the biggest method of my executable:

And extracted the first opcodes, this doesn't mean all the bytes, keep in mind that tokens change when an assembly is recompiled by the reflection. I wanted to search for the opcodes in the process memory using as wildcard for the tokens bytes 3F (the default wildcard of WinHex). So the hex string I typed in WinHex was:

02733F3F3F3F7D3F3F3F3F02283F3F3F3F027B3F3F3F3F1F0C1F10733F3F3F3F

And it took me to:

I copied and disassembled it (just to make absolutely sure):

Ok, this is really the MSIL code of my method, no mistakes. The ldstr instructions show an invalid token because I haven't fixed the #US stream, but this is not important. To be accurate I searched even for the code of the last method left:

Same procedure:

723F3F3F3F283F3F3F3F262A

Takes us to:

And that's it. Now we have the MSIL code of all methods. Where's the Native Code? I don't want to imply that the Remotesoft's linker is a schwindle, but this assembly raises some reasonable doubts, in my opinion. I won't dig into the criteria used by the protection to displace the code in memory, this wouldn't be right. I honestly hope for the costumers of this product that I'm wrong (which is possible: maybe Remotesoft applied the wrong protection to this assembly, who knows..), otherwise they paid (much) for something that is not real. Moreover, the protected code is totally alike to the original, so every common code obfuscator would protect MSIL code better than this. Maybe Remotesoft will clarify this situation.

Epilogue:

The Remotesoft programmer (Huihong) posted this message on my blog:

Hello,

Please email your assembly to me, and I will take a look. MSIL instructions should not be found from memory. It seems the protected code is from some of my debug builds, where IL code is embedded within the assembly for debugging purpose.

I will post a sample, and you are welcome to try to get the IL code. I gurantee that you won't find any IL code, with everything compiled down to x86 code.

Huihong

He provided a new exe and the same version of the dll. And now it did make sense: the new exe was totally different from the old one, it didn't have a section more and even the imports were different. The IL code is not present, since the dll simply puts a ngen created native image in the assembly cache (no reversing, just Filemon). With the .NET Framework 1 I managed to do the same (and it did surprise me that others didn't do the same because it's quite easy), the problem is that with the version 2 of the framework native images changed: they have more sections and contain the MetaData and the MSIL code of the original assembly. If the new native images work even after removing the IL code I don't know, I have still to test this. So in a few words, the code protection offered by the Salamander on what regards native images of the first version of the framework is very good, since those images don't seem to me to contain any IL code. What happens with 2.0 images I have no idea. The license protection should be quite good as long as you don't have the decrypted native image. The string protection is quite easy to break once decrypted. Also, Huihong asked if maybe I had the instructions of the old assembly cached before in memory, but this is not possible, because the original exe was given to me (it wasn't really my exe) only after I saw the first method in memory. So I guess it was just an honest mistake on both sides. Anyway, I'd like to thank Huihong for his courtesy in clarifying this whole thing.

Daniel Pistelli