Phoenix Protector 1.6 & Strong Name Signing

Due to the high request, I took 20 minutes of my time and updated the Phoenix Protector, bringing it to the version 1.6. The only addition to this version is the possibility to re-sign assemblies obfuscated by the Phoenix Protector.

The reason why this wasn’t possible in past version of the Phoenix Protector is that the space for the signature was removed from the assembly and the “sn.exe” tool provided by Microsoft isn’t able to re-create that space.

Now, it is possible to tell the Phoenix Protector from the options whether to remove or not the Strong Name Signature when obfuscating an assembly:

By default the Strong Name Signature is not removed.

After obfuscating anassembly, just use to re-sign the “sn.exe” tool this way:

sn.exe -R assembly.exe your_sns.pfx

Qt Internals & Reversing

Today I took a break from the larger article I’m currently writing. To relax, I wrote a smaller article about the Qt framework. I hope you enjoy.

Qt Internals & Reversing

Half of the text of this article comes from my larger paper “Dynamic C++ Proposal”. I decided that it was useful to take the part about Qt internals, put it into another article and extend it by adding a reversing part. Because of its nature, this is not the usual kind of article I write. In fact, I wrote the reversing part in less than a day. So, this is a very easy one. However, I think it is useful for people who need to reverse a Qt application and certainly wouldn’t consider reading my other paper about Dynamic C++, which doesn’t sound like a paper about Qt and, in fact, isn’t a paper about Qt: the paragraph about Qt is only one among many others. Moreover, I haven’t seen serious articles about this subject.

The first thing which needs to be considered when reversing Qt applications is what Qt brought to the C++ language. Events (inside the Qt framework) are just virtual functions, so nothing new there. This is not a C++ reversing guide. What is new in Qt are signals and slots, which rely on the dynamism of the Qt framework.

So, first thing I’m going to show how this dynamism works. The second part focus on reversing and, at that point, I will show how to obtain all the metadata one needs when disassembling a “Q_OBJECT” class.

Small Devices & RCE

I wanted to comment and add some thoughts about the IDA-on-IPhone news I read on woodmann.

Good news for real iPhone fans: we ported IDA to iPhone! It can handle any application and provides the same analysis as on other platforms. It is funny to see IDA on a such small device:

http://hexblog.com/2008/07/ida_on_iphone.html

Ilfak Guilfanov

It’s funny, because in theory the new CFF Explorer will be compilable for mac os (being written in Qt), thus also IPhone. The only problem is the small display of such devices and I’m not sure if there’s a possibility to reduce the needed space, but I’m quite optimistic.

I mention this because the new CFF Explorer will support elf and other formats (lib, object, symbian etc), making it useful also for other systems and it might become part of a new generation of cross platform/device tools. It would be encouraging to know that in the future it will be possible to do reversing stuff on such a small device. The new CFF will also have zoom in/out features for the hex editor, making it very useful on devices with a small (or big) display.

I hope that other programmers will follow the same lead.

The main problem is writing cross platform applications and reorganizing GUIs for small displays.

I want to share something I read on wikipedia some time ago:

Microsoft software is also presented as a “safe” choice for IT managers purchasing software systems. In an internal memo for senior management Microsoft’s head of C++ development, Aaron Contorer, stated:[7]

“The Windows API is so broad, so deep, and so functional that most Independent Software Vendors would be crazy not to use it. And it is so deeply embedded in the source code of many Windows apps that there is a huge switching cost to using a different operating system instead… It is this switching cost that has given the customers the patience to stick with Windows through all our mistakes, our buggy drivers, our high TCO (total cost of ownership), our lack of a sexy vision at times, and many other difficulties […] Customers constantly evaluate other desktop platforms, [but] it would be so much work to move over that they hope we just improve Windows rather than force them to move. In short, without this exclusive franchise called the Windows API, we would have been dead a long time ago.

Companies such as Apple and Microsoft are very conscious of the strategic importance of hard binding applications to their propretary API. That’s why Apple pushes cocoa and Microsoft .NET. They don’t want cross platform development environments (oh and don’t tell me that .NET is cross-platform, before doing so, show me a .NET GUI with more than a button in it on a system which isn’t Windows), because it would make possible for users to switch to another system without losing his tools.

However, “the times they are a changin'”. Nowadays, developers are more conscious about this problem and prefer not to bind their application to only one platform. You can notice this if you pay attention to the names of newer applications. Ten years ago there were lots of windows applications which contained the word “win” in them. Winhex, WinDvd, Winzip, WinRar, WinAce, Winamp etc. etc. etc. Have you noticed that this trend has stopped? It’s interesting, right now a struggle between developers and OS producers is taking place. OS producers want to ever more bind (even more than before) developers to their platform. Why do I say more than before? Well, consider that .NET implements its own languages, you can’t simply share real C++ code with the managed one (yes, you can rely on pinvoke, but not for everything). Well, it’s a bit more complicate than that, I know, but unsafe code is not encouraged in the .NET environment. Meanwhile, Apple pushes Obj-C. I want to know how this ends. Speaking for myself, I refuse to take a side and will stick with my beloved C++ (the real one).

Entry Demonstration

Introduction

This article is the second of a two series of articles about the .NET Framework internals and the protections available for .NET assemblies. This article analyzes more in depth the .NET internals. Thus, the reader should be familiar with the past article, otherwise certain paragraphs of this article may seem obscure. As the JIT inner workings haven’t been analyzed yet, .NET protections are quite naïve nowadays. This situation will rapidly change as soon as the reverse engineering community will focus its attention on this technology. These two articles are aimed to raise the consciousness about the current state of .NET protections and what is possible to achieve but hasn’t been done yet. In particular, the past article about .NET code injection represents, let’s say, the present, whereas the current one about .NET native compiling represents the future. What I’m presenting in these two articles is new at the time I’m writing it, but I expect it to become obsolete in less than a year. Of course, this is obvious as I’m moving the first steps out from current .NET protections in the direction of better ones. But this article isn’t really about protections: exploring the .NET Framework internals can be useful for many purposes. So, talking about protections is just a means to an end.

What is Native Compiling?

Strictly speaking it means converting the MSIL code of a .NET assembly to native machine code and then removing the MSIL code from that assembly, making it impossible to decompile it in a straightforward way. The only existing tool to native compile .NET assemblies is the Salamander.NET linker which relies on native images to do its job. The “native images” (which in this article I called “Native Framework Deployment”) technique is quite distant from .NET internals: one doesn’t need a good knowledge of .NET internals to implement it. But, as the topic is, I might say, quite popular, I’m going to show to the reader how to write his Native Framework Deployment tool if he wishes to. However, the article will go further than that by introducing Native Injection, which means nothing else than taking the JIT’s place. Even though this is not useful for commercial protections (or whatever), it’s a good way to play with JIT internals. I’m also going to introduce Native Decompiling, which is the result of an understanding of .NET internals. I’m also trying to address another topic: .NET Virtual Machine Protections.

Native Images

The internal format of native images is yet undocumented. It also would be quite hard documenting it as it constantly changes. For instance, it completely changed from version 1 to version 2 of the .NET framework. And, as the new framework 3.5 SP1 has been released a few days ago, it changed another time. I’m not sure on what extent it changed in the last version, but one change can be noticed immediately. The original MetaData is now directly available without changing the entry in the .NET directory to the MetaData RVA found in the Native Header. If you do that action, you’ll end up with the native image MetaData which isn’t much interesting. Also, in earlier native images (previous to 3.5 SP1 framework) to obtain the original MSIL code of a method, one had to add the RVA found in the MethodDef table to the Original MSIL Code RVA entry in the native header. This is no longer necessary as the MethodDef RVA entry now points directly to the method’s MSIL code.

.method public hidebysig virtual instance void
B(class ['Microsoft.Licensing.Utils2.0']Microsoft.Licensing.Utils.Xml.IXmlDataNode A_0) cil managed
{
// Code size       33 (0x21)
.maxstack  8
IL_0000:  ldarg.0
IL_0001:  ldarg.1
IL_0002:  ldstr      "ps:IncludeRules"
IL_0007:  ldc.i4.1
IL_0008:  call       instance void class Microsoft1Licensing1Runtime210GE::A(class ['Microsoft.Licensing.Utils2.0']Microsoft.Licensing.Utils.Xml.IXmlDataNode,
string,
valuetype Microsoft.Licensing.CodeRules.CodeRuleType)
IL_000d:  ldarg.0
IL_000e:  ldarg.1
IL_000f:  ldstr      "ps:ExcludeRules"
IL_0014:  ldc.i4.2
IL_0015:  call       instance void class Microsoft1Licensing1Runtime210GE::A(class ['Microsoft.Licensing.Utils2.0']Microsoft.Licensing.Utils.Xml.IXmlDataNode,
string,
valuetype Microsoft.Licensing.CodeRules.CodeRuleType)
IL_001a:  ldarg.0
IL_001b:  call       instance void class Microsoft1Licensing1Runtime210GE::E()
IL_0020:  ret
} // end of method Microsoft1Licensing1Runtime210GE::B

Native Framework Deployment

The name I gave to this sort of protection may appear a bit strange, but it will appear quite obvious as soon as I have explained how it actually works. As already said, there’s no protection system other than the Salamander Linker which removes the MSIL and ships only native machine code. And, in order to do that, the Salamander Linker relies on native images generated by ngen. The Salamander Linker offers a downloadable demonstration on its home page and we will take a look at that without, of course, analyzing its code, as I don’t intend to violate any licensing terms it may imply. In this paragraph I’m going to show how it is technically quite easy to write a Native Framework Deployment tool, but I doubt that the reader will want to write one after reading this. Don’t get me wrong, the Salamander Linker absolutely holds its promise and actually removes the MSIL code from one’s application, but the method used faces many problems and in my opinion is not a real solution.

Goodbye Visual C++

Seems the new CFF Explorer will be compiled with GCC. More than one reason for that. Visual Studio 2008 doesn’t support anymore Windows 98 and NT4 without giving an explanation. The incompatibility is due to a major operating system version inside the Optional Header of the PE and to the fact that the C runtime library makes some unsupported calls. I could of course patch the whole thing and manage to make it run on those operating systems, but why should I? This is not my job. It should be Microsoft’s job to offer an alternative compiling method which provides backward compatibility. What angers me is that Microsoft not only doesn’t care about backward compatibility, they don’t even bother explaining why they had to remove the support for those operating system. The GCC (Mingw) runtime makes it possible to even compile Qt programs for Windows 98 (which is possible with VC++ 2005 too, but it forces me to use an older compiler). And, as I might not be interested so much in Windows 98, I really am interested in providing compatibility with NT4. Or, at least, if it doesn’t offer backward compatibility I want it to be for a better reason than the C runtime. I’m sick and tired of these decisions Microsoft imposes. Just like the XP support which soon will end (actually I haven’t understood if it ends this month or in April 2009). As I understood for OEMs it ends this month. Anyway, I managed to compile the CFF’s kernel with GCC and also fixed lots of errors signalled by that compiler. Another good reason to use GCC is that it’s cross platform, meaning that a port would be much easier. The only drawback of Mingw is that it has a very small (and not up-to-date) Windows SDK, but I’m not interested in that, especially for the CFF Explorer which should become 100% platform independent. At the moment I reached 97% platform independency. My only complaint is directed to the ansi C library. My goodness, you can’t do anything with the IO functions it provides. I’m grateful that they were so kind to provide 64bit support for files: fseek64, ftello64 etc. But there are lots of things missing. For instance, I am unable to truncate a file… In a normal world that would be: FILE *f = fopen(..); ftruncate(f, len);. No, that’s not possible at all in ansi C. That really bothers me, because it forces me to write platform dependent code for my basic programming interface.

EDIT: Seems the new QFile of Qt 4.4 implements the resize method for files and that would do just fine.