IDAQ: The result of 7 months at Hex-Rays

It is not a mistery that Hex-Rays is preparing for the IDA 6.0 beta program. In this post I’ll write a bit about my personal, behind the scenes, experience with the project.

It took me 7 months to port/rewrite the old VCL GUI of IDA Pro. The new GUI, as it had been already anticipated months ago on the official blog, is Qt based.

The main difficulties I have faced were mostly not of technical nature, although it was a complex task, but psychological ones. It took a lot of patience and it was very difficult every morning to go to work and to have to see an unfinished product with the old GUI reminding myself how much was still to do.

What follows is a rough roadmap of my work, I’ll mention only the milestones and not the hundreds of smaller parts. It has to be noted that at least for what concerns the docking I wrote most of it before joining Hex-Rays to accelerate the development of the actual GUI once in the company. While Qt has a docking system, it is not as advanced as the one used by the VCL GUI, which is a commercial control. So, I wrote a docking system myself in order to offer all the advanced features the old GUI had.

January: first impact with the code. Took me a week to grasp the initial concepts to start. Basically at the end of the month I could display disassembly and graph mode of a file. Also, hints, graph overview and disassembly arrows were implemented.

February: implemented chooser and forms (which I actually completely changed internally, that’s why I had to improve them again later on to obtain better backwards compatibility).

March: marathon month. Implemented every day one or more dialogs/views such as: hex view, cpu regs view, enum view, struct view, options, navigation band, colors, etc. etc. More than 30, some very easy, some advanced controls such as the hex view or the cpu regs view.

April: two weeks to finish the docking and smaller things.

May: two weeks to implement the desktop part (the ability to save/restore layouts and options) and smaller things.

June: fixes, help system and improved the forms implementation.

July: Hundreds of fixes for the beta.

While there will be still bugs to fix, I consider the project as completed and I wrote this post to close a chapter for myself.

My first month at Hex-Rays

At the beginning of September I started looking for a job. I actually wanted a job to work from remote. Despite the fact that I got several offers, all of them required relocation. So in the end I saw the Hex-Rays hiring announcement on Woodmann and sent out my résumé. From all the relocations, Belgium was the nearest and best connected one and of course it’s a very good job.

The first month at Hex-Rays has been tough on all fronts. Mainly because of the relocation and getting used to work in an office. Now work is proceeding well, but the rest is still difficult. Having one day of sun here in Belgium would help, by the way.

Musil wrote in his life’s work that modern man is spending his life always increasing his level of expertise, remaining with a millimeter of specialistic knowledge which only few people in the world could really understand. The others, talking about his millimeter would only say stupid things and he himself can’t move from his own millimeter without running into the same problem.
I think I found my millimeter in the IT world. However, I can’t stand still on it. I always keep moving with exasperated restlessness.

I have written in the last 2 years at least 5 programs of bigger size which are almost complete, but as I’m now working at Hex-Rays they will have to wait. When I was writing mostly software on my own I did it almost entirely to be active in something. Now that I’m working on IDA every day I feel that my need of being active is fulfilled and I don’t feel the need to write more code when I’m at home. Instead, I feel the need of art.

Why haven’t I tried producing art instead of programming already? Because I have always been capable of judging my own work objectively and I know when the time is not right.

What’s the difference between programming and art? Both need experience. The difference is that one can build one’s technical experience alone in one’s room, without the help of events, social interaction, etc. In a technical field it is possible to make the time needed for experience advance faster. Viceversa, in one’s reflections about life one has to actually follow the time of his own life.

I feel that something is changing about that.

Busy & Qt 4.6

I apologize if in the last time I couldn’t answer to emails without many days of delay, but I’m incredibly busy in my real life.
There is some important news I can’t yet talk about but will soon.

Also, yesterday the new Qt 4.6 has come out. For Windows developers good news: the sdk come with gcc 4.4 with patches for phonon, in case you don’t want to use Visual Studio (like myself). Among the new features: animation and state machine frameworks, multi-touch support, symbian support. Also many improvements in Qt Creator.

P.S. I wanted to publish this post several days ago, but pressed Save Draft instead of Publish.

Server Bug: Reupload

Today I received the following email from my hosting provider:

[…] Security is our highest priority and the last years we have taken dramatic measures to build the most secure hosting environment around.

Unfortunately we have however been affected by the Linux kernel vulnerability (CVE-2009-2692) for a 24 hour period. Due to our architecture this exploit did not compromise personal data and all customer records are safe.

After updating the kernel on our systems we scanned all customer accounts and found that your index was removed. Therefore we kindly ask you to check your webpage and reupload your index page if it is missing.

We sincerely apologize for this incident and will take measures to ensure to prevent such incidents in the future.

The index pages of both rcecafe and ntcore were missing in fact. For precaution I reuploaded both pages completely.

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.

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.