The ACT module handles NNID accounts. This module behaves very similarly to the 🔗 Wii U implementation (nn::act)

These commands are used generally by most titles, and are also present in act:a.

This service is used mainly by the Nintendo Network ID Settings application accessible in System Settings.

Like the friends sysmodule, the ACT module has support for multiple console accounts. The ACT sysmodule has support for 8 account “slots”, which are 1-indexed numbers (n) referring the to the nth account. This means that up to 8 different console accounts can be used with the ACT sysmodule, unlike the Wii U, which has support for 12. This multi-account functionality is not exposed to users, and the Nintendo Network ID Settings application only ever uses the default account slot.

When the ACT sysmodule is started, it loads the default account slot. The default account can be set using ACTA:SetDefaultAccount.

It is also possible to change the account slot number of an account by using ACTA:SwapAccounts.

Account slot -2 (0xFE) always refers to the currently loaded account.

A “console account” refers to a specific account slot, and may or may not be associated with a Nintendo Network ID (server account). By default, there is only one console account.

More console accounts can be created using ACTA:CreateConsoleAccount, loaded using ACTA:LoadConsoleAccount, unloaded using ACTA:UnloadConsoleAccount, or deleted using ACTA:DeleteConsoleAccount.

A “server account” is essentially a Nintendo Network ID.

Associating a console account with a Nintendo Network ID (server-side) is facilitated by the commands ACTA:BindToNewServerAccount (to create and link an NNID) or ACTA:BindToExistentServerAccount (to log into an existing linked NNID).

Nintendo Network IDs can be transferred to other consoles using ACTA:ReserveTransfer initially, and then ACTA:CompleteTransfer.

NNIDs can be deleted using either ACTA:DeleteServerAccount, ACTA:InactivateAccountDeviceAssociation, ACTA:DeleteAccountDeviceAssociation or ACTA:ReserveServerAccountDeletion.

The ACT sysmodule uses a distinct password management system.

Passwords are not stored in plaintext. Instead, they are hashed using the following algorithm:

void hash_password(void *out_hash, void *input, int input_size, unsigned int num_iterations, unsigned int principal_id) {
    static const unsigned char constant[4] = { 0x02, 0x65, 0x43, 0x46 };

    unsigned char hash_data[8 + 32] = { 0 };
    unsigned int bswap_pid = bswap32(principal_id);

    while ( num_iterations-- ) {
        memcpy(&hash_data[0], &bswap_pid, 4);
        memcpy(&hash_data[4], &constant, 4);
        memcpy(&hash_data[8], input, input_size);

        /* output, input, size */
        sha256(out_hash, hash_data, 8 + input_size);
        input_size = 32;
        input = out_hash;
    }
}

The AccountPasswordHash field in the account data is the result of one iteration of the above algorithm, using the plaintext password as the input. It is generally used to verify the input password in ACTA:LoadConsoleAccount.

This field in the account data is set when ACTA:BindToNewServerAccount, ACTA:BindToExistentServerAccount, or ACTA:UpdateAccountPassword is used.

It is possible to cache the password for an account so the user isn’t asked for it every time. This can be configured in Nintendo Network ID settings or during an NNID login prompt (e.g. in the eShop). The AccountPasswordCache field in the account data is the result of two iterations of the above algorithm, using the plaintext password as the input.

The account password input represents the in-memory input value of the password. It can be thought of as the value that will be autofilled by default in a login form. When the ACT sysmodule is started and the default account is loaded, the AccountPasswordCache is copied to the AccountPasswordInput, allowing automatic login.

However, it is possible to override this value using ACTA:SetAccountPasswordInput. The AccountPasswordInput value set using this command can then be saved to the account password cache by using ACTA:EnableAccountPasswordCache.

The account password cache can be enabled or disabled through ACTA:EnableAccountPasswordCache.

The AccountPasswordInput is always loaded into memory and is not saved to the system save data.

The ACT sysmodule uses two different server types for Nintendo Network accounts.

See below how these types are determined by default. These types can also be overridden using ACTA:SetHostServerSettings, ACTA:SetDefaultHostServerSettings, ACTA:SetHostServerSettingsStr, and ACTA:SetDefaultHostServerSettingsStr.

The base URL for the Nintendo Network Account Server (NNAS) is: 🔗 https://[]account.nintendo.net.

This is used to determine the NNAS subdomain used for the account server.

Values beyond 4 are considered invalid.

By default, ACT uses the letter value from FRDU:GetServerTypes to determine the correct NNAS subdomain when a Nintendo Network ID is created.

ACT uses the same Server Types as the friends sysmodule as the NfsType.

A small subset of these types are used in ACTA:SetHostServerSettings, ACTA:SetDefaultHostServerSettings, ACTA:SetHostServerSettingsStr, and ACTA:SetDefaultHostServerSettingsStr:

By default, ACT uses FRDU:GetServerTypes to obtain the correct NFS (Nintendo Friend Server) environment to create Nintendo Network IDs.

This is necessary to ensure proper online play functionality, because the friends server account is tied to the Nintendo Network ID when one is linked.

The ACT service generates UUIDs for accounts and for the console in general.

All UUIDs generated by the service are 🔗 RFC9562 Version 1 UUIDs.

In general, the following 48-bit node data is used.

These are just standard 🔗 RFC9562 Version 1 UUIDs with the above node data.

These UUIDs are specific to the title that requested them to be generated, specifically, using the unique ID portion of the title ID of that title.

The following technique is used internally to generate these UUIDs:

- Generate or use an existing regular UUID the with the above mentioned node data (regular_uuid)

- hash = SHA256 ( byte-swapped unique ID (thus, big endian) + 095E273A + 48-bit node data from regular_uuid )

- output_uuid = regular_uuid[0:9] + hash[10] | 0x1 + hash[11:16]

In addition to NEX tokens for gameserver authentication in combination with Nintendo Network, app developers have the ability to use their own independent services. For authenticating with such services through Nintendo Network, the service’s client ID is used to request a token from the account server.

There are two versions of independent service tokens.

These are more basic, consisting of only a base64 token. These can be requested and cached using ACTU:AcquireIndependentServiceToken, retrieved either immediately after requesting them using ACTU:GetIndependentServiceToken or from an internal cache using ACTU:GetCachedIndependentServiceToken.

V2 indpendent service tokens include more fields like an IV, signature, and account server environment compared to V1 tokens.

They can be requested and cached using ACTU:AcquireIndependentServiceTokenV2, retrieved either immediately after requesting them using ACTU:GetIndependentServiceTokenV2 or from an internal cache using ACTU:GetCachedIndependentServiceTokenV2.

Data blocks can be accessed from specific commands depending on the data that is requested. These follow a similar order to the Wii U 🔗 ACTInfoTypes.

This is the Mii format used in ACT commands.

Represents the device information for the console linked to the NNID.

Data returned from ACTU:AcquireEula and ACTU:AcquireEulaList uses a special format.

X offset refers to an offset to a NULL-terminated ASCII string value for X within the full EULA data blob (see below).

This is the full data blob retrieved using ACTU:GetAsyncResult. Each EULA list entry is appended at the very end of the previous one. The end offset in the header can be used to get to subsequent EULA list entries.

With each request, ACT-sysmodule specifies request-header “X-Nintendo-Device-Model”. This is the only *dedicated* request-header that’s contains anything Old3DS/New3DS specific. This was implemented with 9.0.0-X, and presumably 8.1.0-0_New3DS. The value is from a string initialized during ACT-sysmodule startup. The value-string is the codename string for all 5 of the model values from Cfg:GetSystemModel. When the output from GetSystemModel is >=5(switch statement default case), it runs this: “len = snprintf(outstr, outmaxsize, “3DS-%u”, model);”

ACT module uses a RootCertChain for all HTTPS requests, the only trusted root CA is default CertID 0x3.

Even though ACT-sysmodule uses ptm:s, it doesn’t use CheckNew3DS at all.

Category:Services