Skip to content

Signing process

All Qualcomm devices enforce an authentication mechanism on DSP shared libraries. To enable a DSP library to run on test device, such as an MTP or QRD provided by Qualcomm Inc., take one of the following actions:

This page provides detailed explanations on the last two approaches for which a digital signature is used to enable one or more libraries to run with full privilege on a test device. This page also explains the various concepts that are relevant to authorizing DSP libraries to run on the device.

Signing concepts

The signing process touches on several technical concepts described in this section.

Test device

A test device or debug device, (Mobile Test Platform) MTP or (Qualcomm Reference Design) QRD, is a device on which the debug fuse is present. This fuse is not present on production devices.

You can prototype and test your software on debug devices such as DragonBoards. However, the signing process described on this page does not allow DSP libraries to authenticate successfully on production devices such as OEM phones and tablets. To understand which options are available when working with production devices, see the discussion on system integration.

Digital signing

Signing an object consists of adding a cryptographic signature to it. This signature is later verified by the loader when it loads the modules dynamically.

With test devices, signing an object is accomplished using the signer.py script provided in the Hexagon SDK.

Digital signing is required for modules that require resources or privileges unavailable in the unsigned protection domain (unsigned PD), or on DSPs where unsigned PDs are not supported.

Unsigned PD

An unsigned PD is a limited-rights process in which signature-free dynamic shared libraries can run without requiring a digital signature. It is also called a signature-free protection domain (signature-free PD).

The signature-free dynamic module offload is enabled on the cDSP only, not on other DSPs.

For more details about unsigned PDs, see the system integration page.

Test signature

A test signature (TestSig) is generated based on the serial number of the device. It is a specific signed DSP shared library, which enables DSP shared libraries to run with full privileges on that test device. A device with such a test signature is referred as a signed device.

The TestSig shared object is named testsig-<serial-number>.so, where the serial number is specific to the device on which the test signature will be installed.

Device serial number

The device serial number uniquely identifies a device. It is required to generate a test signature.

Use signer.py

The signer.py script, located under {HEXAGON_SDK_ROOT}/utils/scripts, can automate any of the steps required to sign an entire device or an individual DSP library.

Command line usage

Before using the signer script, set up your SDK environment.

Usage:
    ./signer.py <ACTION> [-T <target>] [-s <serial_num] [-d <domain>] [-LE] [-dest <hlos_destination>] [-t <serial_number>] [-i <input_file>] [-o <output_dir>] [-l] [-64]

ACTION:
    sign, getserial

OPTIONS:
    -T <target>: specify target name
    -s <serial_num>: specify the ADB serial number for the device
    -d <domain>: specify the domain (ADSP/CDSP) on which the getserial application will run to retrieve the serial number
    -LE: specify this option for Ubuntu targets. Default assumes an Android target.
    -dest <destination>: specify the directory (/usr or /data) where to push TestSig. Only for LE.
    -t <serial_number>: specify the serial number for which to generate a signature. This option allows to generate a signature for a device that is not connected or to bypass the retrieval of the device serial number.
    -i <in_file>: specify a shared object to be signed
    -o <out_dir>: specify an output directory in which to generate a signed object. Default is `.`.
    -l or --local: store the TestSig locally and do not push to target
    -64: use the 64-bit getserial binary to retrieve the serial number.

Sign a device

./signer.py sign

Retrieve the device serial number automatically, use it to generate a test signature, and push the test signature on the device.

./signer.py sign -t 0x12345

Same as above, but use the provided serial number to generate a test signature.

./signer.py sign -t 0x12345 -o out_dir

Use the provided serial number to generate a test signature and store it locally in the out_dir folder. This approach can be useful in creating a test signature for a device that is not connected.

NOTE: The option -T can be used to identify and sign the required device if multiple devices are connected simultaneously. However, if multiple devices of the same type are connected, for example if there are two SM8250 devices connected simultaneously, then use -s option to differentiate between the devices based on the ADB serial numbers. The ADB serial number of a device is a string created by ADB to uniquely identify the device by its port number.

adb devices -l
e76a39c6               device product:kona model:Kona_for_arm64 device:kona
f68b78d7               device product:kona model:Kona_for_arm64 device:kona

./signer.py sign -s e76a39c6

Retrieve the serial number of the device with ADB serial number e76a39c6, use it to generate a test signature, and push the test signature on the same device.

Sign a DSP library

./signer.py sign -i myLib.so -o out_dir

Add a digital signature to a shared DSP library (myLib.so), and place the signed library in the out_dir folder.

Retrieve a serial number

./signer.py getserial

Retrieve and display the device serial number.

Additional notes

The signer.py script automates all the signing steps. You might need additional information to execute some of the steps manually.

Serial number

An alternative to using signer.py to retrieve the serial number is to run the following ADB command, which returns the serial number in int format for most devices:

adb shell cat /sys/devices/soc0/serial_number

Install a TestSig

Android

Push the TestSig to one of the default search paths to make it accessible to all the applications. Alternatively, the TestSig can be pushed anywhere under /vendor/lib/rfsa/dsp/ directory and the directory to which the TestSig is pushed can be specified in [A]DSP_LIBRARY_PATH to make it accessible to limited applications. The walkthrough examples follow the convention of pushing the TestSig under a commonly accessible directory:

adb root
adb remount
adb push testsig-0x12345.so /vendor/lib/rfsa/adsp

You only need to execute these steps once until you reflash the Linux image on your device.

Windows Phone

Use TShell to push Testsig onto the device:

putd testsig-0x12345.so C:\Windows\system32\drivers\Driverdata\qualcomm\fastrpc