Resources | Resources |



Signing dynamic modules

Most Brew MP applications comprise the following files:

  • Application Module (.mod) file - the executable application
  • Module Information file (.mif) - includes the privileges an application is granted
  • Resource file (.bar) - (optional) contains application resources
  • Signature file (.sig)

The .mod, and .mif are together signed to generate the .sig using an application signing key that is trusted by the root. The .sig file contains the digital signature that Brew MP validates before executing the application.

There are two types of signatures that Brew MP allows, Code Signatures and Developer Enablement Signatures.

Code signatures

Code signatures (sometimes called production signatures) are for code that is completed, tested, and authorized to run on many devices. Code signatures ensure code integrity by enabling the device to detect any modification of the code. If an application is modified (even 1 bit) after signing, the signature is no longer valid and Brew MP will not execute the code. Code signatures do not expire and may be run on any device that has the necessary root certificate configuration.

Developer enablement signatures

Developer Enablement Signatures enable the application developer to execute code for which they do not have a code signature during the testing phase of development. Instead of being specific to a single module, developer enablement signatures are tied to a specific device via an available unique identifier such as the IMEI or ESN. Developer enablement signatures are valid only for a finite amount of time, typically between 1 and 6 months. With a developer enablement signature issued under a root certificate that is enabled on a device, you can run any dynamic module. In other words, you need only one developer enablement signature to execute any application on the device. Unlike code signatures, developer enablement signatures do not verify the integrity of the code. Instead, they enable a developer to rapidly test an application (code) during the development process without the need to generate a new signature after each code change.

Developer enablement signatures for multiple hardware IDs may also be generated, and hardware IDs can be listed individually, as a range, or as a list of ranges. This makes it possible to use one test signature across many devices, and is especially suited to a team development environment.