Analysis of the Duqu Trojan worm by Kaspersky Labs

This summary is not available. Please click here to view the post.

How libffi actually works?

I came across this libffi when I thought of working on js-ctypes. Though my contribution remained very close to nil, I got to know about this fantastic new thing libffi. But I did not understand how it actually worked when I first read. I just got a high overview and assumed that the library abstracts out several things that I need not worry about when making calls across different programming languages. I just followed the usage instructions and started looking at the js-ctypes code. That was sufficient to understand the js-ctypes code. But today when I was once again going through the README, I actually came across one line that made things a little more clearer. The first paragraph in "What is libffi?" tells it all. Its the calling conventions that this library exploits. I had written a post about calling conventions some time back. As mentioned in the readme file, its the calling convention whcih is the guiding light for the compiler. So when generating the binary code, thecompiler will assume will that the arguments that are being passed to that function will be available in some place and also it knows about a place where the return value will be kept, so that the code from the calling function will know where to look for it.

Now we know that the ultimate binary code that we get after compilation is the machine code. So it is basically a set of machine supported instructions. These instructions are certainly not as sophisticated as those available in the C - like the functions. So what do these functions transalte to? Nothing but a jump of IP(instruction pointer) to an address where the binary code of that function is. Inside this code, the arguments passed are accessed by referencing some memory location. During compilation the compiler will not know the precise memory locations (obviously). But the compiler has to put in some address there when generating the code. How does it decides on the memory location? This is where the calling conventions come into picture. The compiler follows these standard steps. Since its the compiler who is generating the code for both calling a function, where arguments are sent, and the code of the called function, where those args are received, the compiler will be knowing where it has put the arguments and hence generate code to use the data in those locations. From this point of view, the main(or is it the only one) condition for the binary code of a function to work properly is to have its arguments in the memory locations it thinks they are in and and the end place back the return value in the right location. And from what I have understood till now, it is this point that libffi exploits.

When we are forwarding calls from an interpreted language, like JS, to some binary code generated from a compiled language, like C, there are two things to be done:

0. As discussed earlier, whatever arguments are passed from JS are to be placed in the right locations and later take the return value and give it back to JS.
1. Type conversions -- The types used by JS are not understood by C. So someone should rise up to the occasion and map these JS types to their C counterparts and vice-versa.

The first of these is taken care by libffi. But the second one is very context specific and totally depends on the interpreted language. It does not make sense to just have a catalog of type convertors for every interpreted language on this earth. So these two steps were separated and spread out as two interacting layers between the binary code and the interpreted language code. libffi now takes care of the calling convention part and making sure the binary code runs and gives back the results. And the job of type conversion is the job of another layer which is specific to the interpreted language which wants to call into the binary code. And hence we have these different type converting layers for different interpreted languages: ctypes for python, js-ctypes for JS (and probably some more exist). Well with this renewed and clearer understanding I hope to actually contribute to js-ctypes.

Happy calling (with conventions) ;-)

JS-CTYPES Status

Mark Finkles Weblog » JS-CTYPES Status

This was what mfinkle recently talked about js-ctypes. As he said because of the hectic FF3 schedule the devs at mozilla were pretty busy and hence nothing could be done. I being a lazy bot, also did not do anything. In the blog post above, Mark talks about the struct support (which I told that I would be doing). Now I exhibited my initial enthusiasm by writing up a doc, which was not really useful (its here ). After that nothing much happened except for a small bug fix.

Now that mfinkle has rekindled the interest I will also try and contribute. The struct support is still pending and I will start getting XPCOM code exchanging struct information with libffi. After that we can look at the other interface of JS exchanging structs with XPCOM to finally complete the loop. In the mean time I am also looking at embedding mozilla. Will put up a post about that very soon.


Again, Get ready to use deadly binaries in your JS code. JS-ctypes is soon going to be here.. ;-)

VS2005 has a feature (supposedly) called "Copy Local"

VS2005 and .NET users are pretty familiar with the way the IDE makes the job so easy and keeps us away from all the build related things like references, linking and all that stuff. But in many cases this might actually be far from desired behavior. One such that recently took away some of my time was the "Copy Local" attribute on the references. This is a boolean property on the references added to a project. If this is set to true, then when the project is built the assemblies added as references as copied to the 'bin" folder of that project. Depending on the build, its either the "Debug" or the "Release" folder. With this, in future whenever the project is built, the DLLs in the bin directory are used, unless you change your references. This will cause a problem when one of the referred assembly is updated and you expect the new behavior, but get the old one instead.

Example, You would have added an assembly, E:\assemblies\MyAssembly.dll as a reference. Now when you want to update the assembly you typically replace the old MyAssembly.dll with the new DLL in the above mentioned location. And then you expect your project to reflect the new assembly, but it does not do that because "Copy Local" being true would have lead to the old DLL being copied to the bin folder of the project and though you updated the DLL in its original location, the reference was pointing to the DLL copied to the bin directory.

So watch out for this Feature. From what I know, this feature can be serialized in the assembly itself. Though this might be a good feature for applications which will use the same DLLs for a long time, this is clearly a bad choice for people who are writing small test applications to test their DLLs. Because with every new build the DLL version changes and yet the references point to the old one.

.NET GAC --- CompileTime v/s Runtime synchronization

GAC - Global Assembly Cache is just a run-time thing.

People familiar with .NET will surely know about GAC. Its just a one stop for any application running on the .NET framework to look for the assemblies (DLLs). When ever we run any .NET application, the framework will look for the referenced assemblies in the GAC. Note that even the version number of the DLL must match. If the application was compiled with an assembly 'A' of version 1.0 and you currently have anything, but 1.0, the application will not run. It needs exactly what it was compiled with. And the best part is that multiple versions can co-exist in the GAC

But this GAC look up happens only at the run-time. In Visual Studio, we will add the required assemblies for a project under the project references. These references will be pointing to the locations where the assemblies are present on the file-system and may be remote locations in case of web references. When we build the project the compiler will look at these locations and not in the GAC. Now if you are referencing an older assembly but we have a newer version in the GAC, then the project will compile but not run. Because at run-time the framework will look for the older assembly but does not find it in the GAC. So be sure of updating your references when your assembly of a particular version in the GAC is updated or replaced by an assembly of a different version.

This problem becomes still more evident and a little tricky when we are using an assembly(say assembly 'A') which again depends on another assembly (say assembly 'B'). And in such a case the problem can become evident even before compilation itself(If the assembly 'B' is related to designer of the Visual Studio). Say assembly A-1.0 was built using assembly B-1.0. Now when we use assembly 'A' by adding it as a reference to our project we are using assembly 'A-1.0' that was built using assembly 'B-1.0'. 'B' does not come into picture during compilation at all. When we build our project and run it, the framework looks for 'A-1.0' and finds out that it needs 'B-1.0' and finds both in GAC and runs the application. Here as 'B' does not come into picture during compilation, it is sufficient if we have it GAC, where as 'A-1.0' has to be at some location on the file system (either local or remote).

Now if 'B' in the GAC is updated, i.e 'B-1.0' is replaced by something like 'B-1.1', and you try to run the previously built application, it fails. Though the assembly referred by you , 'A-1.0' has not changed, the assembly 'B' which is necessary for 'A' has changed. So at runtime the .NET framework will search GAC and the current-folder for 'B-1.0' and as it would not be found, the application fails.

There are a couple of other posts about GAC and references in VS2005. Look out for those.

Registering and UnRegistering a DLL - Two ways

There are 2 ways to register a DLL.
Any DLL registration happens through the windows tool Regsvr32.exe present in C:\Windows\System32\

• The HARD-way: Using the above tool directly from command line. This is the obvious geekish way. This actually turns out to be simple after some practice. The command would be as per the following specification:

Regsvr32 [/u] [/s] [/n] [/i[:cmdline]] dllname
/s - Silent; display no message boxes
/u - Unregister server
/i - Call DllInstall passing it an optional [cmdline];
     when used with /u calls dll uninstall
/n - do not call DllRegisterServer; this option must
     be used with /i

• The EASY-way: Right-click on the DLL you want to register and open it with the above tool. Again the tool resides in C:\Windows\System32\. Thats it. The DLL if proper would be registered and error messages if any would be shown in an alert box.

I do not yet know of a easy way for unregistering a DLL. So for that command line is the way.