Siri Validation Data and Access Token

Well Apple did some changes this week in the Siri protocol let analyse them

1. Apple sends a set activation token that is ignored by most devices using Spire, including the 4s
This doesn't affect much devices except that sometimes when they connect to other servers they need to delete the assistant.plist. Why? I gues because it wasn't activated before or something like that. Need more time to analyze the packets and find out why! (I was currently focused on the Validation expiration system)

2.The validation expiration

  • Some time before when a device used invalid or expired 4s data and made a request to guzzoni servers, Guzzoni replied with Validation Expired or command Failed.
    This made it easy for proxies to detect these relies and set the invalid 4s key as expired!
  • Apple changed the above method, in my opinion due to similar to DDOS attacks behavior when the Validation data where invalid!
    Now Guzzoni wont reply back to packets that have invalid or expired validation thus making it hard to detect invalid keys.

I made a work around this and i can find witch keys have expired with the help of packet analysis!
Lets see how this works: 

1. A device makes a request with a valid key. 
  • Apple sends the activation token
  • The proxy server detects the token and increases the total activation tokens for this key by one
2. A device makes a request with an invalid key

  • Apple wont send the activation token
  • The proxy server detects a finishspeech (waiting for recognition) request without an activation token, and increases the finishspeech requests for this key by one
3. When the Finishspeech requests are more than the sensitivity nubmer (5) and NO activation token is recieved then the key is marked as expired! 

In short, if a key is used and apple wont reply back after some tries (sensitivity) then the key is marked as expired. 
Its a complicated algo and this is a very short description of how this works!



Siri Protocol Exploit for multiple key generation

Requires JailBroken iPhone4s. 
This is a rally simple exploit.


Every time an iDevice uses Siri for the first time or creates a new assistant in apple database, guzzoni replies with a property validityDuration  that tells for how long the generated validation data from the iDevice are valid.
Default reply on this by apple is: 90000 sec = 25h!!!

So response from apple is:

    "\x02\b N\xF7\x88o\t!\xEE\xE4w\x83\x1AH\x1E\x81\x00\x00\x00@\xEA\xE2\x17\x1F!\xD4\xF6%-\xB7\x0FRr\x8D\x1D\x9D\xDF\xE1@&=\x96\xEDkf(\xC6f\xA4\xDBl\xA5oE\xD1\x13\xE9G\xFEj\xA0\x83\xDF\xDB\xCE\xDA\x0F\xFE'\xB7p9\x8Egz\x14\xEA\xC0\xD3[t\xBCW\xE1\x01\xF0R]\xED\xF1\t\x87]5\xE9\x9Da{\xCC\x0F\x12z\xCF\xA9Y\x00\x00\x006\x05\x03\x8A\xC2\xD6w\xA6\xF5\xD8*4\\\xB8\xA2\xB2\xE7\x0F\x12O; \x95luD\x83:\xA3\xAC,,,.\x81\xF9\xE2i\xD6\xED\xCC\x9Ee9\xADuN\x83F[\x06\xC2\x8D2\xB2",

And we just change the validityDuration to whatever we please

This will force the 4S to regenerate its validation data every time it uses siri after the above elapsed time.

This can also probably (I haven't tested it!) be done by editing the assistant.plist on the 4S and setting the time to an expired point, eg 5 hours before, but may generate only one key. Repeat as pleased

Updated in TLP source here... 
And experimental source here...

The Three Little Pigs Authentication System

The Three Little Pigs Experimental Authentication System and Ban Protection ;-)

source on the experimental branch:

The above bubble diagram explains how the authentication system works internally when the private mode is ON!!!

The authentication is based upon Appleid and contact card. This means that the user must have a apple iCloud id, and also must be using his contact card for Siri and have a clean assistant.plist

So lets see how the authentication system of The Three Little Pigs works in simple...
  • There are 2 categories of Clients: New and Old! 
  • When a new client connects his apple account id number, name, nickname and appledbid are inserted in the clients table in the database. By default the status of the client is set to invalid thus denying access!
    That's all for new clients. In other words the are just inserted to database (becoming old Client) and access is denied! 
  • When an Old Client connects , the server checks if the Client is valid or not and denies or grants access to that user. 
How to use this? Right now there is no webgui for this and you will have to use phpmyAdmin or navicat in order to manually connect to the database set. A webinterface will be published soon when the beta is finished!

-----How to Use the Authentication Feature-----
  • Step 1: Setup the server as normal and don't forget to put private mode to "ON" on the config.yml
  • Step 2: Give the certificates and host to any people you like and dont worry if they share that. You can also put other protection methods on that like, passwords, udid etc. 
  • Step 3: By now people will be trying to connect but with no luck and you will have the Client table populated with many records. Now you need to get in contact with the person that wants access, browse thought the database records, find his name or nickname, set him to valid='True' and done. If you can find the person, maybe he has the same name with some other and he doesnt have a unique nicknacme ask him to put one in his contact card, the one that he has put in Siri Settings for Siri to use. The record will be updated and thus you will be able to recognize that person on the database.Remeber each client is unique based upon appleid so don't worry about duplicate names etc
Info: Every client creates one or more Assistants in the assistant Table.
Every Assistant is linked to a client and has info on what device the client uses! :-)

Enjoy and keep in mind that this is a Alpha version of auth. Contact me for any problems in GITHUB  not in twitter etc because 140 characters cant hold the log :-)

----The banning system and ban protection - Happy hour---

Lets talk a little on the banning system. 

After working some time on public servers like I ve found out several interesting things. Lets take it from start:

  • When a new device uses Siri for the first time, the first thing that happen is to create a record in Apple Siri DB, containing an Assistintid and speechID (unique for every user). This I call creation of Assistnt objects.This also happens when a user changes the Spire Host or deletes the /var/mobile/Library/Preferences/ 
  • If you notice the devices that have never used Siri, or cant connect to a Server don't have the Assistantid and speechId in /var/mobile/Library/Preferences/ . These devices are not setup!  
  • In order to create these records in Apple Siri Db the older devices use 4S validation data to get approved by Apple to connect to the servers! But there is a limit by apple on that.
  • Eg. a 4S key can allow up to 15 simultaneous Assistant object creation. Then Apple replies with commandFailed, thus blocking new, or not setup devices to connect. (Also there is a weekly/dayly limit of ~=50 assistants or more)
  • If you have the ban protection on in the TLP config.yml then when this happens, the key used for that is marked as banned because it cannot support any more not setup devices.
  • When marked as banned this key is still used for processing speech packets but not used for new devices.
  • After some time these keys become unbanned by apple, and thus again allowing of more new or non setup devices to create assistant objects. This is where the happy hour setting comes in place.
  • The happy hour setting waits for 6 hours (or what you please) and then sets all non expired keys to unbanned! This allows again new or non setup devices to make requests for assistant object creation until apple banns them again.

So as far as banning is concerned and people that think that they got their 4S phones banned: ONE WORD: They are not banned but cannot create any more assistants because they are juiced out!
Keep the 4S key not shared for a while or turn on the banning system in the config.yml (default is ON)

Thank you,

Jimmy Kane