Intercepting/Redirecting Library Calls in Linux

When using third-party applications, sometimes the performance or even the way as a given library behaves does not meet the user demands.

Instead of dwelling through the source code in case of being open-source, it is possible to redirect the call of a given library to a custom version.

Linux makes this very easy through the LD_PRELOAD environment variable. Pointing LD_PRELOAD to a shared library, causes it to be loaded before any other library, including the C runtime. To intercept a call from a given library the shared library pointed by LD_PRELOAD must override the implementation of that method call.

$ export LD_PRELOAD=/home/user/workspace/newLib/lib.so

Example:

Original method called by App X, located in libX.so:

 int sqrAndDiv(int val, int div){  
      return val * val / div;   
 }  

Now, you see that the implementation has a major flaw, it does not give an error if div == 0, therefore you want to create a better version of srtAndDiv:

 int sqrtAndDiv(int val, int div){  
      if(div == 0){  
           std::cerr << "Div by Zero" << std::endl;  
           abort();  
      }  
      return val * val / div;  
 }  

Compile it as a shared library, using -shared and -fPIC flags if using gcc/g++, set LD_PRELOAD pointing to the .so and when you run App X, it will print an error when dividing by zero and abort execution.

Finally, let's imagine that the library is well implemented and does what the user wants it to do, and the user just wants to measure time or do some other operation:

 int sqrtAndDiv(int val, int div){  
   //do stuff, (e.g. measuring execution time)  
   static int (*ofp)(int val, int div) = 0;  
   ofp = (int (*)(int val, int div)) dlsym(RTLD_NEXT, "sqrtAndDiv");  
   int ret = (*ofp)(val, div);  
   //do stuff  
   return ret;  
 }  

The dlsym function basically just calls the next library after the current one, with a function that corresponds to the prototype (flag RTLD_NEXT). If RTLD_DEFAULT was used it would call the first library with the function.

Regarding the overhead of redirecting the call, in current kernels, if there are zero arguments or they're passed by reference,  it's in the order of nanoseconds. If the arguments are passed by value, then there's the overhead of copying them. 

Overriding Default Firefox Components - JavaScript

Introduction
Sometimes we want to add new features to Firefox. For that we can create simple Firefox extensions.
But in certain cases, we want to override a feature of Firefox with our own code to achieve our purposes.
In this post we will cover how to implement our own firefox component and install it, overriding the behavior implemented by default. The use case that will be used will be the creation of a password manager which always returns the same username-password pair. This component will be implemented in javascript, but a following post will give the same behavior in C++.
I start by introducing some concepts, but if you only want to read code jump to the code section or download the code.

Add-ons Nomenclature
The nomenclature for Firefox can be confusing but here is a summary:
Add-on : Anything that can be added to firefox
Extensions: A piece of code that can be used to expand the firefox features
Plugin : A shared library used to display a specific type not supported by default (e.g:flash)
Component : A piece (old or new) of the Firefox with a well-defined interface. The focus of this post.

Understanding Components
Firefox is a very good example of software architecture. One main focus of Firefox has been the uncoupling between different modules of Firefox and their implementation which is achieved by having an interface definition for these modules, and an implementation of this interface. Together, an implementation and its interface, are a component.
The main advantage of this approach is to be able to re-implement the behavior of any of these components without breaking the software, allowing a component to be replaced, almost in runtime, by a component with the same interface.
Other advantage is that since these modules have a well defined interface and goal, they can be re-used for other applications. That's why, when learning how to program for Firefox, you are also learning to program for Thunderbird, because Mozilla re-uses!

The technology used to achieve this uncoupling is Cross Platform Component Object Model (XPCOM).
On XPCOM the interfaces are defined in cross platform interface description language (XPIDL), defining the methods provided by the module including its parameters and return values.
The XPIDL file specifies:
Contract Name: Defines the name of the interface
Contract ID (UUID) : Defines an ID for the interface. Must be unique and change everytime the interface is changed

As the name implies, XPCOM is cross platform, enabling it to run in any platform (Windows, Linux, Mac). But other great property provided by XPCOM is that it is also programming language independent, and, as far as I know, you can implement components in javascript, c++ and python.
This brought a big advantage to firefox and a lot of code has been ported from c++ to javascript, turning it into real cross platform code.

Password Manager Architecture on Firefox

The module responsible for handling password management behaviour is nsILoginManager. Its interface can be found here.

In this post, we will not care about re-implementing this module because it already brings some usefull features such as form filling that we would like to keep.
This module delegates the responsibility of password storing and reading to the module nsILoginManagerStorage, which interface can be found here.
This is the module we want to replace!

The nsILoginManagerStorage module must return nsILoginInfo instances, which are "boxes" containing passwords, usernames, etc.

Finally, JavaScript!

Since we are developing a component for an already existing interface, we don't need to create the XPIDL file. If you want, you can consult the nsILoginManagerStorage xpidl in here.

To create our module, we must first create the prototype for our class:

 function SampleLoginManagerStorage() {}  
 SampleLoginManagerStorage.prototype = {  
 .  
 .  
 .  
 }  

Inside this prototype we insert some attributes as follows:

  classDescription: "Sample nsILoginManagerStorage implementation",  
  contractID: "@example.com/login-manager/storage/sample;1",  
  classID: Components.ID("{364a118c-747a-4f6d-ac63-2d2998e5a5c1}"),  
  QueryInterface: XPCOMUtils.generateQI([Ci.nsILoginManagerStorage]),  
  _xpcom_categories: [  
   {  
    category: "login-manager-storage",  
    entry: "nsILoginManagerStorage"  
   }  
  ]  
  var NSGetFactory = XPCOMUtils.generateNSGetFactory([SampleLoginManagerStorage]);  

The important attributes to understand are:

• contractID - the name of the contract of our implementation
• classID - the uuid of our implementation
• QueryInterface - this attributes is setted by calling the generateQI with nsILoginManagerStrorage as argument. This means that the exported interface visible by XPCOM will be the same as the defined on the nsILoginManagerStorage xpidl.
• _xpcom_categories - Tells firefox what components is our module implementing
• NSGetFactory - Is an automatized way to tell Firefox how to build instances of our component.

The only thing that is missing are the methods implementaion, but since this is javascript we can run this without further code and our module will be loaded by Firefox without complaint, although no behavior exists.

Here is an interisting method to add to our code:

  findLogins: function SLMS_findLogins(count, hostname, formSubmitURL, httpRealm) {  
      var loginInfo = Components.classes["@mozilla.org/login-manager/loginInfo;1"]  
         .createInstance(Components.interfaces.nsILoginInfo);  
      loginInfo.init(hostname, formSubmitURL, httpRealm, "batata" , "potato", "email", "pass");  
      count.value = 1;  
      return [loginInfo];  
  }  

This method instantiates a nsILoginInfo object, initiates it with its username and password field as "batata" and "potato", and sets the count as 1, meaning there is only one object being returned.

Firefox Components Packaging and Registering 

To install the components (and any extension) they must be inserted inside a .xpi file, which is a zip file with a diferent name, and must obey to a certain folder structure as described here.

The most important file in our case is the chrome manifest in which we must add:

 component {364a118c-747a-4f6d-ac63-2d2998e5a5c1} components/passwordManager.js  
 contract @example.com/login-manager/storage/sample;1 {364a118c-747a-4f6d-ac63-2d2998e5a5c1}  
 category login-manager-storage nsILoginManagerStorage @example.com/login-manager/storage/sample;1  

1st Line - We are defining a component by its uuid and its source code location.

2nd Line - We are defining a new contract name and its uuid.

3rd Line - We are registering our component as an nsILoginManagerStorage interface implementer.

Conclusions

Although I wrote a lot about Firefox in general, overriding a Firefox built in component is as simple as a dozen of lines telling which component we want to replace, and implementing its methods. This process can be used with any other component that you can find useful to replace.
Doing our components in javascript allows use anything that javascript or xpcom already provide, such as writing into files, making http connections, etc.
Although, when in some scenarios it must be necessary to implement the component on another language such as c++ so we can access a specific library. I will focus on this case on my next post.

The working source code can be found in here:
https://github.com/NunoPinheiro/getters-setters/tree/master/firefox-password-manager-javascript

References
Building Firefox Addons -  https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons?redirectlocale=en-US&redirectslug=Addons
XPCOM - https://developer.mozilla.org/en-US/docs/XPCOM

Introduction to Smart Card Development

1 - Introduction
My first tutorial, will be in fact just a little writing about smart card development and the required knowledge to start in this world.
The smart card industry is full of standards and it can be hard to understand the purpose of each technology when searching the web. This post doesn't means to be a full specification of the smart card industry, but is meant to help some people who is in an hurry to understand which are the main concepts and technologies used.

2 - What is a Smart Card?
A smart card is a card which contains a micro-controller embedded, containing the processor, volatile memory (RAM) and non-volatile memory (EPPROM and ROM).
Usually, smart cards are used on security applications (authentication, secure data storage) and can be found on many applications on the current world.
For instance, the Portuguese ID card is a smart card which contains the owner's personal information, and contains public/private key pairs that can be used to authenticate the owner. Probably one of the most used smart card types are the SIM cards used to authenticate with the mobile operator.
The smart cards are physically protected to avoid internal sensitive data being exposed.
The smart cards applications work in a client-server approach where the terminal, the computer connected to the card, is the client.
The main standards for communication and physical properties are defined on the ISO/IEC 7816 parts 1 to 15 (yes, it sounds like a light reading).

3 - Smart Card Technologies
The smart cards market is full of standards and proprietary technologies. This means that, to start developing smart card applications, a lot of technologies must be studied.
The main concerns on smart card development are:
- Programming the smart card - Java Card
- Communicating with the smart card - APDUs (Messages)
- Programming the host application - PCSC
- Installing your applet - Global Platform

3.1 - Programming the smart card
Although the resources are scarce inside a smart card, most of them contain an operating system or at least a runtime environment, abstracting the hardware for the programmer.
One broadly used runtime environment is the Java Card Platform. This platform allow applications to be written in a subset of Java. An Java Card application is called Applet. This platform provides an high portability for the developed applet, being it deployable on different cards from different manufacturers without having to re-write most of the application (you will have to adapt your application in case a card doesn't support some of the card-dependent libraries).
The Java Card platform supports multiple applets being installed on the same card protected by an internal firewall. This is a really good property since we can expect that in the future we will all our applications (pass, id, internet sites authentication) only on one card.

3.2 - Communicating with the smart card
To communicate with the smart card, the terminal must send APDUs (Application Programming Data Unit). These APDUs are byte-based commands sent to the smart card. Understanding the format of the APDUs is important since almost all the libraries to connect to smart cards don't do much more than forwarding the commands created by the application.

The format of these commands is composed by 6 fields:
CLA : 1 byte - The type of the command that you are sending. The byte 0x80 means proprietary command, so if you want to forward commands to your application, this is the byte value you will mostly use on CLA.
INS: 1 byte. This represents the instruction/operation to be performed by the smart card. For instance, you could define in your application to return the public key from a random key pair anytime you receive INS= 0x00
P1 and P2: 1 byte, each. These are parameters that are instruction dependent. for instance, in the previous case of the random key pair, we could tell the card that P1 was the size of the key pair.
Lc: 1 byte. This is the length of data to be sent. Besides the P1 and P2 the card can receive more data on the apdus with an arbitrary size (up to 255 bytes). This byte represents the size of that data.
Data: Lc bytes. This is the data.. Following the example, you could set a password to generate new key pairs, that password could be in this data field.
Le: 1 byte. This is the maximum expected length of the smart card response to your command (in the example, the length of the public key).

As a response, the smart card returns 3 fields:
Data: The data returned by the command.
SW1 and SW2: 1 byte, each. This is the response status from the command. 0x9000 means everything went well, any other response is an error code, meaning you will spend lots of time on google trying to find what the code means.

3.3 - Programming the host application
All this effort programming an applet would be worthless if there was no off-card application connecting to the card.
Programming such an application is very simple.
The industry has made an effort to connect to different smart cards with different card readers, to be homogeneous as possible. The solution is the PC/SC standard(Personal Computer/Smart Card), and implementations, with the same interface, can be found for the major operating systems (Linux, Windows, MAC OS).
Using PC/SC is as simple as: Listing the available readers, connecting to a reader, sending APDUs.
The PC/SC abstracts how to handle different readers/or cards meaning that you can have different readers, different communication channels (contact or contactless cards), even remote cards, without having to concern with their physical level protocols.

3.4 - Installing your applet
This subject is very smart card dependent, but an effort has been made to create standards.
The main standard on applet installation is the Global Platform.
Global Platform defines the apdus used to install applications, creating secure channels to the smart card (only authenticated people can program the smart card), selecting the applet on multi-applet cards, etc.
I really advise downloading the Global Platform card specification to understand most of the errors your applet will return on development phase.
Notice that to debug applets on-card you will probably need card-specific tools.

4 - Warning about smart card development
I consider smart card development being very hard. Most of the technologies i referred (Global Platform, PCSC) are documented on hard to read formal documents and understanding how to do stuff can be painful if you do not have the time to read all these standards and just want to create applets in a short time.
A major warning I have to give about Java Card development is that most of its "How-To" was lost with the Sun forums being removed after the company being bought by Oracle. Most of the answers found on the internet provide links to these forums.

5 - Links
For those who want to start developing with the smart cards, I leave links for more deep information, what they talk about, and what is important to get from these:
PCSC - http://www.pcscworkgroup.com/ - Understanding the PC/SC architecture
Muscle Card /PCSC-lite - http://www.linuxnet.com/ - PCSC implementation for linux
GPShell - http://sourceforge.net/p/globalplatform/wiki/Home/ - Global Platform Compliant shell to comunicate with smart cards
Java Card Book - http://www.amazon.com/Java-Card-Technology-Smart-Cards/dp/0201703297 - I really advise reading this book to learn how to program for java cards
Java Card API - http://www.win.tue.nl/pinpasjc/docs/apis/jc222/ - Really useful when developing to java cards
General - http://0x9000.blogspot.pt/ - This blog can be a nice resource for smart card developers

Hello World

Hi reader, and welcome to my new blog, Getters&Setters.
This first post will be only an intro about me, about the reasons that lead me to writting this blog, and about the contents that you can expect from this blog. So, here we go!

About me:
My name is Nuno Pinheiro. Right now I'm developing my Master Degree thesis at Instituto Superior Técnico (Portugal) being the subject "Secure Password Management with Smart Cards". I'm also a developer at the Fénix Project which is the Management application in my college.

So, why writting this blog?
As I previously told, I am developing my Master thesis on smart cards, this means I have to spend lots of hours on Google searching for information that sometimes is deprecated. I feel that there is a need on the internet for new sites explaining how to do the same stuff nowadays, and unfortunantly I believe my own blog information can turn into deprecated information in some years.
Other reason to create this blog is that in some cases, free/open source software web pages don't contain enough information to start developing with theirs technology.
Since I'm always learning new technologies I believe it is public service to publish my learnings into the web.

Then, which will be the main contents?
This blog main contents will be tutorials which will contain copy-pastable code to use on your own projects with compilable source code.
The main tutorials I'm planning to release, at least in these few months are related to my thesis:
- Firefox Components
- QT & QTDbus (client and server)
- PCSC / MuscleCard
- Java Card & General Smart Cards stuff

I may also release blog posts related to my hobbies and side projects, such as:
- Raspberry Pi
- Arduino
- Android

So, if you are interested in these technologies, follow this blog!
If you are expecting some specific tutorial, please contact me so I can make its release faster.