Samsung Pay is a new application that is integrated in the new line of Samsung galaxy devices to make payments. This app implements two different packages. One, the front-end: spay package that is the app by itself, and spayfw is the framework for tokenization/controller processes. In this entry, I will write only about this framework: spayfw, and I will keep adding info during the year.
First, let’s take a quick look at the AndroidManifest.xml of Spayfw package:
There are important restrictions to be aware about this package. This manifest differs from the Spay package in different ways. Now, you can start asking questions about the security policies.
Now that we have an idea what kind of protection Spayfw is implementing, we can start looking into the reverse side of the package; I will go through the jar content that I consider interesting and valuable. However at the end, I will attach the two jar files that I used for this article.
We need to understand that the tokenization process could differ depending of which company is related the physical credit card, for example, master card, American express, Visa, etc. Each company has its section in this framework:
So each ramification has its own ways to handle the information. So at this point, we were able to extract the smali code to grep information if we need to, but also we have a jar file; ready to explore it in gui mode. Let’s analyze americanexpress.sdkmodulelib module:
These two images look similar, but they are different. At this time, I used at least four different jar “generators” to compare the code. In these examples, I used dex2jar(left) and enjarify(right). This is important because some code could differ between each jar. So having multiple choices to generate jars is adequate.
So the first folder: APDU, what is APDU? it is the Application Protocol Data Unit. This unit is in charge of the communication between the smart card and the POS terminal reader generally using tags.
(Source: https://www.blackhat.com/docs/us-15/materials/us-15-Fillmore-Crash-Pay-How-To-Own-And-Clone-Contactless-Payment-Devices-wp.pdf)
If you are asking yourself, what kind of tags and how they look like? Basically they are commands to establish a communication and share information between card and reader. In blue, we have the tags; the name of the variables could give us an idea how APDU uses that specific tag. APDU tags/EMV tags in the pictures.
At this point, we know that each card needs tags, those tags implement APDU to make a communication with the card and reader. So the framework gives us a lot of information about its tags and the process.
Are you thinking about how they establish a connection? Let’s take a look at session.class:
Session class will help to establish a connection. With tags and a session, those sessions need a controller: a session manager. At this point, I will introduce another element: IMPL.
What is IMPL? No, it is not “it’s my puta life.” IMPL means “implementation” and you will see it a lot in the code:
IMPL is the core process for that specific task.
Now, the util folder. The util ramification contains “utilities” some of them are very interesting.
The “Constants” section is used in many classes, and I already added a pic of it. But now I will analyze TIDUtil and TrustedAppImpl classes.
In the TIDUtil class, we can find important info relating about the cryptogram. Be careful Samsung could say that this is not the algorithm that they are implementing. ATController is important; it controls everything related with that specific company from connections, authentications, tokenization process, server requests to transactions.
With this, I finished the first general structural section; I will write more in the next days about interesting stuff: Authentication framework, some databases structures, interfaces, tokenization classes, CNCC commands, device certificates, Magic numbers, DRK Manager, JSON structures, fraudulent alerts, NFC Cryptogram and many other things. Stay tuned!
Sal.
Salvador Mendoza 