How 3DS states survive an update

Integrating Azahar meant signing states per installation. We then separated state compatibility from the rest of the app so an app update alone would not close those states.

Version 1.9.0 brought Nintendo 3DS and New Nintendo 3DS through Azahar. Readers import their own decrypted dumps and manage updates and DLC as CIA files. Two sticks and ZL/ZR join the controls, and game text prompts open the device keyboard. Android uses JIT; iOS runs an interpreter.

A 3DS state differs from an in-game save: it reconstructs a running machine inside the core. Letting an arbitrary external file reach that decoder was not an acceptable boundary. On 19 October 2026, the decision was to sign states with a separate key for each installation and authenticate before decoding. Another device or a reinstall cannot open them. In-game saves can still move between devices.

The first identity also included app and compiler changes. Merely changing the shared header to register PS1 could make 3DS resume fail. Refusing an unchanged state on the same device because unrelated app code changed had tied installation protection to the wrong compatibility test.

In 1.10.0, state identity follows the Azahar source and patches, execution platform, JIT configuration and a state-format number. Compiler and unrelated app code are excluded; installation signatures remain. The iPhone states from 1.9.0 have a separate compatibility entry valid only for that same core source. Authentication was not weakened to allow an update.

An app update can now keep resume and states working in the same installation. A change to the core source or state format remains a separate case: save in game first. States still cannot travel freely between devices. The boundary admits authenticated data while keeping ordinary app updates from interrupting play.