Michael Hölzl's blog

SEEK adaptations in RIL for Galaxy S3

mihoelzl — Thu, 22 Aug 2013 13:04:29 +0000

-- updated by Michael Roland on 2013-09-04 17:04 +0200

The project seek-for-android aims to add APIs for Android to communicate with secure elements regardless of their form-factor (e.g. UICC, SD card or embedded SE). The SEEK team published patches for AOSP that influence the telephony framework, the ASSD kernel and the NFC framework. Based on those changes the SmartCard API gives developers the possibility to develop security feature enhanced applications that make use of a secure element.

Samsung included SEEK with support for the UICC and the embedded SE on their Galaxy S3. As a developer you can easily write applications which communicate with the secure element on the UICC or the embedded SE. Unfortunately you can not use the publicly available patch from SEEK to build your own ROM with the SmartCard API and UICC support. While SEEK followed an approach to implement a standardized way to access the UICC through the phone's RIL, Samsung decided to use their own proprietary method for communicating with the UICC-based secure element through the RIL. Therefore, the SEEK implementation for accessing the UICC through the RIL won't work on Samsung's devices.

So, if you want to create your customized ROM for the Galaxy S3 that has SEEK with UICC-access, you have to adapt your ROM's telephony framework to send Samsung's proprietary command strucutres to the RIL. The main difference in Samsung's implementation is that they use OEM_HOOK_RAW requests instead of introducing new commands (SIM_*) for secure element communication. This means you have to adapt the three commands iccOpenChannel, iccCloseChannel and iccExchangeAPDU (which are added by SEEK's UICC patches) in your telephony framework (frameworks/opt/telephony). You can either change the methods in RIL.java or even better overwrite them in the Galaxy S3 specific implementation – SamsungExynos4RIL.java.

Let's start with the adaptions for iccOpenChannel: The main difference of the S3 is that the Samsung RILD implementation does not use specific RIL_REQUEST_SIM_* commands for the secure element access. Instead, you have to use the RIL_REQUEST_OEM_HOOK_RAW request to encapsulate the commands. From what we found, the format of these vendor-specific commands looks like this:

[command class (1 byte)] || [command (1 byte)] || [command length (2 bytes)] || [data (N bytes)]

command class always has the value 21
command is a 1-byte integer identifying the type of request:
- 9 for open channel
- 10 for close channel
- 11 for sending an APDU
- 12 for sending a Case-1 APDU command (no data and no expected response)
command length is a 2-byte integer (MSB first) that contains the length of the whole command including the data field: 4 + N

This means for the iccOpenChannel command we will create a byte array with the values:

> [21] [9] [4 + AID.length] [AID]

In the argument tag of the result parameter we also want to add some information about the type of command so that we are later able to properly decode the response message format. For that purpose we added three constant values to the class:

private static final int EVENT_EXCHANGE_APDU_DONE = 1;
private static final int EVENT_OPEN_CHANNEL_DONE  = 2;
private static final int EVENT_CLOSE_CHANNEL_DONE = 3;

For the iccOpenChannel command, the expected response format is:

< [channel ID length N (1 byte)] [channel ID (N bytes)] [response length M (1 byte)] [response (M bytes)]

channel ID length N is a 1-byte integer that contains the length of the channel ID field in bytes
channel ID is an N-byte integer (LSB first!) that specified the assigend channel ID
response length M is a 1-byte integer that contains the length of the response field
response is a byte array that contains response data received by the UICC in response to opening the channel to the given applet

Finally, this is what our iccOpenChannel method looks like:

@Override
public void iccOpenChannel(String AID, Message result) {
    if(AID == null) {
        AID = "";
    }

    final int aidLength = AID.length() / 2;
    byte[] aidBytes = new byte[aidLength];
    for (int i = 0; i < aidLength; ++i) {
        aidBytes[i] = (byte) Integer.parseInt(AID.substring(2 * i, 2 + 2 * i), 16);
    }

    ByteArrayOutputStream commandByteStream = new ByteArrayOutputStream();
    DataOutputStream commandOutputStream = new DataOutputStream(commandByteStream);
    try {
        commandOutputStream.writeByte(21);
        commandOutputStream.writeByte(9);
        commandOutputStream.writeShort(4 + aidLength);
        commandOutputStream.write(aidBytes);
    } catch (IOException e) {
        Log.e(LOG_TAG, "CMD_OPEN_CHANNEL : open fail", e);
        e.printStackTrace();
    }

    // inform response handler that this is a open channel request
    result.arg1 = EVENT_OPEN_CHANNEL_DONE;

    Log.d(LOG_TAG, "sendRawRequest - open channel: AID: "+ AID);
    invokeOemRilRequestRaw(commandByteStream.toByteArray(), result);
}

The iccCloseChannel method looks similiar. The only difference is that instead of the AID we pass the channel ID:

> [21] [10] [4 + 4 = 8 (channel ID is a 4-byte integer)] [channel ID (4 bytes, MSB first)]

Except for the special case of the channel ID zero, where we pass no channel ID at all:

> [21] [10] [4]

@Override
public void iccCloseChannel(int channel, Message result) {
    ByteArrayOutputStream commandByteStream = new ByteArrayOutputStream();
    DataOutputStream commandOutputStream = new DataOutputStream(commandByteStream);
    try {
        commandOutputStream.writeByte(21);
        commandOutputStream.writeByte(10);
        if (channel != 0) {
            commandOutputStream.writeShort(8);
            commandOutputStream.writeInt(channel);
        } else {
            commandOutputStream.writeShort(4);
        }
    } catch (IOException e) {
        Log.e(LOG_TAG, "CMD_CLOSE_CHANNEL : close fail", e);
    }

    // inform response handler that this is a close channel request
    result.arg1 = EVENT_CLOSE_CHANNEL_DONE;

    Log.d(LOG_TAG, "sendRawRequest - close channel "+ channel);
    invokeOemRilRequestRaw(commandByteStream.toByteArray(), result);
}

The iccExchangeAPDU command looks more complex but is basically just a set of data fields composed from the RIL_REQUEST_OEM_HOOK_RAW command structure and the transmitted APDU command. For a given APDU command (note that extended APDUs are not supported)

[cla (1 byte)] [ins (= command) (1 byte)] [p1 (1 byte)] [p2 (1 byte)] [[Lc (1 byte)] [data (Lc bytes)]] [Le (1 byte)]

the resulting iccExchangeAPDU command looks like:

> [21] [11] [4 + 9 + databytes.length] [cla] [command] [p1] [p2] [p3] [channel ID (4 bytes, MSB first)] [databytes]

Where p3 is either the command data length Lc and databytes is the concatenation of data and the expected response data length Le (if applicable) or p3 is the expected response data length Le and the databytes field is empty. For a Case-1 APDU, the a seperate command without those two fields is used:

> [21] [12] [4 + 8 = 12] [cla] [command] [p1] [p2] [channel ID (4 bytes, MSB first)]

The response to the iccExchangeAPDU command has the format of a response APDU according to ISO/IEC 7816-4:

< [response data (N bytes, optional)] [sw1] [sw2]

@Override
public void iccExchangeAPDU(int cla, int command, int channel,
                            int p1, int p2, int p3, String data,
                            Message result) {
    ByteArrayOutputStream commandByteStream = new ByteArrayOutputStream();
    DataOutputStream commandOutputStream = new DataOutputStream(commandByteStream);
    try {
        commandOutputStream.writeByte(21);

        int commandLength = 12;
        if (p3 == -1) {
            commandOutputStream.writeByte(12);
        } else {
            commandOutputStream.writeByte(11);
            ++commandLength;
        }

        byte[] dataBytes = null;
        if (data != null) {
            commandLength += data.length() / 2;

            dataBytes = new byte[data.length() / 2];
            for (int i = 0; i < dataBytes.length; ++i) {
                dataBytes[i] = (byte) Integer.parseInt(data.substring(2 * i, 2 + 2 * i), 16);
            }
        }

        commandOutputStream.writeShort(commandLength);
        commandOutputStream.writeByte(cla);
        commandOutputStream.writeByte(command);
        commandOutputStream.writeByte(p1);
        commandOutputStream.writeByte(p2);
        if (p3 != -1) {
            commandOutputStream.writeByte(p3);
        }
        commandOutputStream.writeInt(channel);
        if (dataBytes != null) {
            commandOutputStream.write(dataBytes);
        }
    } catch (IOException e) {
        Log.e(LOG_TAG, "CMD_ECHANGE_APDU: send failed - ", e);
    }

    Log.e(LOG_TAG, ": sendRawRequest - iccExchangeAPDU: "
                   + "Channel 0x" + Integer.toHexString(channel) + ": "
                   + " 0x" + Integer.toHexString(cla)
                   + " 0x" + Integer.toHexString(command)
                   + " 0x" + Integer.toHexString(p1)
                   + " 0x" + Integer.toHexString(p2)
                   + " 0x" + Integer.toHexString(p3)
    );

    // inform response handler that this is a exchange APDU request
    result.arg1 = EVENT_EXCHANGE_APDU_DONE;
    invokeOemRilRequestRaw(commandByteStream.toByteArray(), result);
}

Here is a complete diff containing the necessary changes to get SEEK with UICC access in the Android build for a Samsung Galaxy S3. Most important changes are in the frameworks/opt/telephony and the packages/apps/Phone repository.

Latest futurezone report

mihoelzl — Wed, 07 Aug 2013 09:50:06 +0000

Check out the latest report about our research center at futurezone (in German):

http://futurezone.at/future/16894-fh-hagenberg-forscht-zu-smartphone-sicherheit.php

How to build AOSP Kernel for Galaxy Nexus

mihoelzl — Thu, 01 Aug 2013 13:59:01 +0000

Building an AOSP Kernel Galaxy Nexus GT-I9520 Version 4.2.2

Generate Folder:

generate a folder of you choice on your file system. In This case it is KERNEL_AOSP

Download Sources:

switch into the KERNEL_AOSP folder

git clone https://android.googlesource.com/kernel/omap.git

This will give you a git repository with all actual branches of the omap Kernels.

omap is the corresponding Kernel Source for Maguro Devices (Galaxy Nexus)

After the download you have a omap folder.

Show the branches:

in your KERNEL_AOSP/omap Folder type

git branch -a (shows you all branches)

This will list you a list of all branches available

Hint: after checkout you can look up you actual branch with git branch

Checkout branch:

For the actual JB Version checkout the following branch:

git checkout android-omap-tuna-3.0-jb-mr1.1

After the checkout you have all files available

Preparing the prebuilt GCC:

For Kernel built prebuilt GCC is necessary. If you have already a AOSP Rom Source on your Filesystem you need not to Download it.

Just set the Path:

export PATH=$(pwd)/prebuilts/gcc/linux-x86/arm/arm-eabi-4.6/bin:

(pwd)...Path of you AOSP Rom Source

If you don't have an Android source tree, you can download the prebuilt toolchain from:

git clone https://android.googlesource.com/platform/prebuilts/gcc/linux-x86/arm/ar...

Don't forget to set the Path of where you have downloaded the prebuilt to.

Set some Variables:

export ARCH=arm

export SUBARCH=arm

export CROSS_COMPILE=arm-eabi-

Cleaning the Source

To ensure that you generate a really new Kernel type:

make clean

make mrproper

!!!Do this everytime before starting a new make process!!!

Config

make tuna_defconfig

This prepares the make configuration

make menuconfig

Opens the visaulisation for the def config

Goto General setup ---> Local version-append to kernel release

type in whatever you want to name your Kernel

This text is shown in the about diaglog of the Phone and helps you to find out if the Kernel Source is your custom source.

After this we start the make process:

make -j16 (-jx) the higher the number the more core power is used and will speed up the make

When make is finished you should have the message "Creating zImage successfully"

Flash your Kernel to device:

Go into the folder arm/arch/boot. There you should find the zImage.img file.

Check if the date of the file is correct with the time of building and also if the size is about 4,2MB.

If all thing are OK, we can flash the zImage to the device. Make sure that the device is available

adb devices (if the device is not shown do adb kill-server and adb start-server)

Go into fastboot mode

adb reboot bootloader

Flash it:

fastboot flash zimage zImage (Match Case!!)

Reboot the device:

either you press the START button on your device or you type fastboot reboot

After rebooting the device you should find your Kernel name in the About Phone page!

CONGRATS YOU ARE DONE!

Official introduction of u'smile

mihoelzl — Tue, 25 Jun 2013 10:09:11 +0000

Last week on Friday we had the official introduction event of our research center. Together with several representatives from politics, business and science we discussed about the future of mobile phones and the importance of user-friendly security functionalities.

More information about the successful event in official press releases:

How to flash SuperSmile

mihoelzl — Mon, 06 May 2013 14:45:55 +0000

This is a tutorial on how to install our SuperSmile ROM to your Android device. You can find the ROM for all supported devices (currently S2 and S3) in the downloads section.

Before you flash SuperSmile you should backup all your data. In the process of installing this ROM you will have to make a factory reset with a data wipe. To backup your data you can use tools like "Titanium Backup" or "App Backup&Restore" which will store apps and also app data to your SD card. Just look for them in the Android Play Store.

Requirements for this build:

A custom recovery on your phone (e.g. clockworkmod recovery - tutorial)

Instructions:

Download SuperSmile ROM (download section) and a Google Apps package (available here).
Copy both zip files to your SD Card
Enter Recovery
Do a data wipe/factory reset (Necessary if coming from a different ROM)
Flash the ROM
Flash Google Apps
Restart your phone

That's it! If you have any issues installing the ROM or if you find bugs in our system, just contact us.

How to build SuperNexus for Galaxy S3 on Linux

mihoelzl — Wed, 20 Mar 2013 09:04:00 +0000

SuperNexus is a project that focusses on providing Google Nexus experience on Samsung devices. The ROM is based on AOSP code with slight improvements and optimizations (e.g. battery life time). It is great ROM if you want the basic Google layout without modifications from the operator or manufacturer on your mobile phone.

You can download the prebuilt ROM from xda (http://forum.xda-developers.com/showthread.php?t=2076672). If you want to build it yourself, you will have to checkout the source code from github (https://github.com/SuperNexus) and go through this styp by step tutorial.

If you haven't done this already, you have to initialize your build environment for android source code building. I don't want to describe that again as there is a great tutorial for this on android developer pages:
http://source.android.com/source/initializing.html

The source code which you will have to download is a combination of three source code projects. Fortunately, you won't have to care much about where you download the code from. SuperNexus provides a manifest file which helps you to download all neccessary files:

$ mkdir SuperNexusJB
$ cd SuperNexusJB
$ repo init -u https://github.com/SuperNexus/android_manifest.git -b jellybean
$ repo sync -j8

This can take some time (for me it took around 2 hours depending on the connection).

Now you have the source. First thing you have to do is to set the build environment.

$ . build/envsetup.sh
$ . vendor/supernexus/vendorsetup.sh
$ lunch i9300-userdebug

The last command sets the configurations for the samsung galaxy s3. If you want to build for a different platform you can check the list by typing lunch without parameter.

Unfortunately we did not find a way to reliably retrieve the proprietary drivers for different stock ROM. The location of the driver often changes between versions and therefore the script to extract the binaries will not find all files. The most reliable way to get the drivers is to install SuperNexus on your device first and extract it from there.

Go to the developer page of SuperNexus at xda-developers. There you can download the current otapackage of SuperNexus which you will have to install using ClockWorkMod (Tutorial to install CWM at youtube).

If this is done, connect the Galaxy S3 to your machine and extract the proprietary drivers with the script file that comes with SuperNexus:

$ cd device/samsung/smdk4412-common
$ ./extract-files.sh

Now go back to the root directory and start the build.

$ make update-api
$ make -j#

where # is the number of processors which you want to use for your build. Now you can flash the build with heimdall or you make an otapackage (execute the command "make otapackage") which you can install using ClockWorkMod.

Flashing with heimdall:
Goto your output directory "out/target/product/i9300/". Here you will find all finished images of your build. Bring your Samsung Galaxy S3 in to download mode by pressing the Buttons "Vol. down" + "Power" + "Home Button" for around 15 seconds. Press Volume Up again to come into download mode. Now you can flash your phone with heimdall:

$ sudo heimdall flash --primary-boot boot.img --system system.img --user-data userdata.img

You can adapt your SuperNexus build now. But before you do that you should make a new branch with your repo command:

$ repo start <BRANCHNAME> --all

XDA-developer page of the SuperNexus team: http://forum.xda-developers.com/showthread.php?t=2076672
SuperNexus GitHub page: https://github.com/SuperNexus

How to build an Android Kernel

mihoelzl — Mon, 04 Mar 2013 15:36:35 +0000

Step by step (similar to xda developer page http://forum.xda-developers.com/showthread.php?t=1538580)

http://opensource.samsung.com/
>> Mobile >> Mobile Phone>>
Search for GT-I9300 and download latest JB zip

# sudo apt-get install gcc-arm-linux-gnueabi

download prebuilt toolchain (see http://source.android.com/source/building-kernels.html )
# git clone https://android.googlesource.com/platform/prebuilt

if you get an error like "undefined reference to `wrefresh'", install these packages:
# sudo apt-get install libncurses5 libncurses5-dev

# export ARCH=arm
# export SUBARCH=arm
# export CROSS_COMPILE=<path to toolchain from googlesource>/toolchains/arm-eabi-4.4.3/bin/arm-eabi-

Switch to kernel source directory
# make m0_00_defconfig

//optional for configuration of the kernel
# make menuconfig

# make -j<X> //<X> number of cpu cores

For flashing the new kernel you will need a ramdisk image file from a working build (e.g. nandroid backup or own android source code build). To extract the ramdisk image use the attached perl script (./split_bootimg.pl ) by executing the command:
# perl split_bootimg.pl <boot image file with working ramdisk>

Copy the ramdisk image and your zImage in a separate directory together with the attached mkbootimg binary ./mkbootimg . Combine those files to a new boot.img by executing following command in the newly created directory:
# ./mkbootimg --kernel <zImage> --ramdisk <ramdisk image> --output boot.img

For flashing we used the open source tool heimdall version 1.3.1 for linux_x64 command line http://www.glassechidna.com.au/products/heimdall/ (! using 1.3.2 is not working on galaxy s3!).
First bring the device into download mode by pressing volume down+menu+power key. Then check if heimdall detects the device:
# heimdall detect
you should see the message "Device detected". If the device is not detected ("Failed to detect compatible download-mode device.") try to restart the device and put it into download mode again.

If this is working, flash it!
# heimdall flash --primary-boot boot.img

How to customize your Android boot animation

mihoelzl — Mon, 04 Mar 2013 15:31:02 +0000

This short tutorial helps you to create your own custom boot animation for Android. It requires an existing animation in form of several png files where each file represents one frame. To make an animation in linux you can use one of these editing applications: http://www.cyberciti.biz/faq/top5-linux-video-editing-system-software/. Most of those applications are also able to export to png file series.

Further details on this topic can be found at the xda-developers page: http://forum.xda-developers.com/showthread.php?t=1852621

Write the description of your animation in there. Format:
<width in px> <height in px> <fps>
( (p|c) <no of repeat (0=inf)> <pause in seconds> <folder name> )+

<folder name> ... one of the sub-directories you created in step 2

example file
480 180 10
p 1 0 part0
c 0 0 part1

This example animation consists of three parts and runs on a rate of 10 frames per second. The first part of the animation runs only once at the beginning. Part1 will start afterwards and runs during the complete boot up phase.

Create a uncompressed zip file from all files inside the "bootanimation" directory:
$ zip -r -0 bootanimation.zip desc.txt part0 part1 part2

The animation is located on the system partition under /system/media/bootanimation.zip. To change the existing bootanimation with your newly created zip file you require root access to your device as you will have to remount the system partition (system partition is mounted as a read-only filesystem in the standard configuration). Remount it first as read-write:
$ adb shell
$ su
$ mount -o rw,remount -t yaffs2 /dev/block/mtdblock3 /system

Now you can push it to the device:
$ adb push bootanimation.zip system/media/

5.1 (Optional) Add it to your build system
In certain build systems (cm) you can copy the bootanimation.zip to your source build folder under:
vendor/<vendor>/prebuilt/bootanimations/

Kick-Off meeting

mihoelzl — Mon, 26 Nov 2012 08:02:59 +0000

Last friday was our kick-off meeting in Hagenberg. The whole consortium took part and we had very interesting discussions about the future of our research group.

Security leak in Google Wallet

mihoelzl — Thu, 25 Oct 2012 11:54:54 +0000

Michael Roland, a colleague at the research facilities, found a major security bug in the Google Wallet. With a men in the middle attack an intruder was able to monitor and access credit card transfers. Check out the details on futurezone.

Michael Hölzl's blog

SEEK adaptations in RIL for Galaxy S3

Latest futurezone report

How to build AOSP Kernel for Galaxy Nexus

Official introduction of u'smile

How to flash SuperSmile

How to build SuperNexus for Galaxy S3 on Linux

1. Build Environment

2. Download the code

3. Set the build configuration

4. Get proprietary drivers

5. Build SuperNexus

6. Adapt the build

Links

How to build an Android Kernel

1. Download Kernel source

2. Extract Kernel from zip file

3. Install gcc toolchain for building arm kernels

4. set environment variables

5. configure build for Samsung galaxy S3

6. Start build

7. create boot.img from the new zImage

8. Flash the kernel

How to customize your Android boot animation

1. Create a new directory "bootanimation"

2. Insert the parts of your animation in sub-directories (e.g. part0 part1 ...)

3. Create an empty document named "desc.txt"

4. Zip file

5. Put the bootanimation.zip file to your phone

Kick-Off meeting

Security leak in Google Wallet