Since 23/08/2022 Nintendo is validating the parameters used to generate the f parameter are generated strictly as they would be in Nintendo's official app:

• The token/id_token/naIdToken parameter is the Nintendo Account id_token from https://accounts.nintendo.com/connect/1.0.0/api/token for Coral authentication (Account/Login/Account/GetToken), and the Coral access token from Account/Login/Account/GetToken for web service authentication (Game/GetWebServiceToken).
• The timestamp parameter is the current timestamp. On iOS this is in seconds, and on Android this is in milliseconds.
  • The timestamp parameter in the request body should be a JSON number, not a string (on both platforms), although the API will currently accept either.
• The request_id/requestId parameter is a random (v4) UUID. On iOS this is uppercase hex, and on Android this is lowercase hex, although Nintendo don't appear to be checking this currently.

What changed on 23/08/2022 is that Nintendo appears to be somehow checking the timestamp property does actually match the time that the f parameter was generated (with only ~1s difference allowed). This means the get_audio_h/2 functions must get the system time itself and encode it in the returned f parameter somehow. If this doesn't match a 9599 Unexpected error. message will be returned (not 9403 Invalid token.?).

Just changing the client to get the timestamp in milliseconds before sending it to imink/flapg will allow authentication attempts to succeed, but only if the client's time (plus request latency) exactly matches the time on the Android device. So, the proper solution is to not send the timestamp to the API and instead have the API use and return the timestamp on the Android device with the resulting f parameter.

• The imink API has been updated to make the timestamp parameter optional.

  Documentation: https://github.com/JoneWang/imink/wiki/imink-API-Documentation

  samuel nxapi % curl -i --header 'Content-Type: application/json' \
  > --data '{"hash_method": "1", "token": "test"}' \
  > 'https://api.imink.app/f'
  
  HTTP/2 200 
  server: nginx
  date: Wed, 24 Aug 2022 22:30:45 GMT
  content-type: application/json; charset=utf-8
  content-length: 180
  strict-transport-security: max-age=15724800; includeSubdomains
  
  {
    "f": "0576fc5f46c933c80455df0bce790dcdc78b0fa698bd12ec2dcab684336c38dfd22d1db1d76f9130369e917e85cb1c",
    "timestamp": 1661380244671,
    "request_id": "f3c12c1e-0f76-40ec-b153-37375e0bbe7d"
  }
  

• nxapi's custom server using Frida has already been updated to make the timestamp parameter optional. You can run this by building nxapi from source.

  Documentation: https://github.com/samuelthomas2774/nxapi/blob/main/docs/cli.md#znca-api-server

  samuel nxapi % curl -i --header 'Content-Type: application/json' \
  > --data '{"hash_method": "1", "token": "test", "request_id": "test"}' \
  > 'http://[::1]:8080/api/znca/f'
  
  HTTP/1.1 200 OK
  X-Powered-By: Express
  Server: nxapi 1.3.0-223faab (main) android-znca-api-frida
  X-Android-Build-Type: user
  X-Android-Release: 8.0.0
  X-Android-Platform-Version: 26
  X-znca-Platform: Android
  X-znca-Version: 2.2.0
  X-znca-Build: 2832
  Content-Type: application/json
  Date: Wed, 24 Aug 2022 09:42:49 GMT
  Connection: keep-alive
  Keep-Alive: timeout=5
  Content-Length: 124
  
  {
    "f": "8b1d192127bf357a008046eddb4d0bbd0fe6c3c9381e8fb84d2ee7f8a445c0086547e13144ce8814bb6180bfd0",
    "timestamp": 1661334167921
  }
  

• The flapg API has also been updated and is now compatible with the imink API. The API is now available at https://flapg.com/ika/api/login-main. Client authentication is no longer required.

  https://twitter.com/NexusMine/status/1563728086322929665

  samuel nxapi % curl -i --header 'Content-Type: application/json' \
  > --data '{"hash_method": "1", "token": "test"}' \
  > 'https://flapg.com/ika/api/login-main'
  
  HTTP/2 200 
  server: nginx/1.19.2
  date: Thu, 01 Sep 2022 12:27:06 GMT
  content-type: application/json; charset=utf-8
  content-length: 179
  strict-transport-security: max-age=31536000;
  
  {
    "f": "a343c9e95bf87ffea3225a941f0acc0b3941d58b7b501000c2a47a13d20a201c30040155409bd7e6300241d4",
    "timestamp": 1662035226888,
    "request_id": "1a61446a-ba0f-4f37-a305-984971e2fadf"
  }
  

imink and nxapi both have fully compatible APIs when used as documented, however nxapi's server will only return parameters that were not included in the request and were generated by the server, while imink will always return the timestamp and request_id. If the timestamp is submitted to imink it must be a numeric string, while nxapi will accept either a string (not required to be numeric) or a number. nsotokengen has also been updated and is fully compatible with the imink API.

f-generation changes 24/05/2023

(These changes were actually introduced in 2.4.0, but Nintendo wasn't validating clients were setting them properly when generating f until now.)

• Step2 F-token generation appears to be broken with 2.5.1 imink-app/f-API#3
• Automatic token generation is broken (9403: Invalid token.) frozenpandaman/s3s#125
• Error: No idToken2 found spacemeowx2/s3si.ts#69
• Unhandled Exception in Script (FIXED) MCMi460/NSO-RPC#74

Since 2.4.0 the native gen_audio_h/2 functions make calls in the Java VM to retrieve data used to generate f, however Nintendo continued to accept tokens generated with these functions not returning the correct data. (libvoip did not change in 2.5.1, but did in 2.5.0.)

It is also possible that libvoip is able to detect code injection. Calling init while Frida is loaded now appears to cause generated tokens to be rejected, even when they are only generated by using the app normally.

The following methods need to be modified to return the correct data: (This is not a complete list of the methods called by libvoip when generating f tokens.)

Coral authentication (gen_audio_h/hash method 1)

• com.nintendo.coral.core.entity.NAUser/c returns the user's Nintendo Account ID
• com.nintendo.nx.nasdk.m/d returns the Nintendo Account id_token (the same token passed to gen_audio_h as the first argument)

Web service authentication (gen_audio_h2/hash method 2)

• com.nintendo.coral.core.network.e/b returns the Coral token (the same token passed to gen_audio_h2 as the first argument)
• za.h/v returns an instance of com.nintendo.coral.core.entity.CoralUser, with the a field set to the Coral user ID (other fields are not used)
• com.nintendo.coral.core.entity.NAUser/c returns the user's Nintendo Account ID

(Example of patching these using Frida: https://github.com/samuelthomas2774/nxapi-znca-api/blob/09adae38e3ae0425ae7d7478ecb62840f9b802c4/src/android-frida-server/frida-script.cts#L157.)

I think I've got f generation working properly, but:

• For coral tokens (hash method 1) the f-generation server now needs the Nintendo Account ID. This can be extracted from the id_token that's already sent, so clients won't need to be updated.
• For web services tokens (hash method 2) the f-generation server needs the Nintendo Account ID and Coral user ID. The Coral user ID can also just be read from the id_token, but the Nintendo Account ID can't and clients will need to be updated to send it.

Nintendo isn't validating the Nintendo Account ID (yet?) so all current clients can still get web service tokens without being updated, but Nintendo might be able to just update the server to check it is set properly.

I'm updating my API to accept na_id (hash method 1/2) and coral_user_id (only 2) values being sent separately for both methods. (I would recommend clients are updated to send these values so they don't have to rely on the server reading them from the JWT/Nintendo not checking one of them.)