3utools Wikipedia

Posted on

Here is a description of the protocol that is used when iTunes requests the SHSH certificate from Apple. For details about what this is used for, please see the main article SHSH.

This is a simple HTTP (POST) request and answer. You can retry this via a Telnet session or similar. The destination host is gs.apple.com and runs on the common port 80. The data is plaintext and not encoded in any way. For details about the HTTP protocol itself, please see RFC2616.

3uTools can automatch available firmwares for iOS devices. Doki doki panic online. IOS flashing in normal mode, DFU mode and recovery mode is supported. One-click jailbreak makes the jailbreak process so simple and reliable. More advanced features, including SHSH backup, baseband upgrade/downgrade etc. All-in-One iOS Helper Brings Useful, Delightful Features. 3uTools 3utools Download online & offline Mange your iphone photos,music,videos and contacts via 3utools app,the best tool for jailbreaking and mange iOS,iphone, ipad and ipod Touch.3utools dmg download free for windows 7,8 and 10 running pc. The lockdown daemon, always running on the iPhone, in charge of monitoring activation status, Carrier Debug status, and FairPlay stuff, amongst other things. For more information, see lockdownd on iPhoneDevWiki. The free windows software 3utools is one of the best software that you can download in your PC or Mac to crack the password of locked iPhone with simple clicks. Dec 07, 2019 New Method 2020 iCloud Activation Unlock Using 3UTOOLS?100% work,iPhone iCloud Unlock iPad/iPod/Apple Watch/ iPhone 4/4s/5/5c/5s/6/6s/6 plus/7/7 plus/8/8 plus/X/XS/XS Max.

  • 1Communication


Reliable communication to the TSS server is best achieved with the following HTTP header configuration:

  • Proxy-Connection: Keep-Alive
  • Pragma: no-cache
  • Content-Type: text/xml; charset='utf-8'

The following curl command demonstrates a command-line request to the server:

Action types

Attached to the http://gs.apple.com/TSS/controller URL is commonly ?action=2, which can be discovered when performing an iTunes restore and observing packets sent with a packet sniffer such as Wireshark. However, values other than 2 may produce different server responses, of which all known value/response pairs have been listed below.

  • ?action=0: Performs a 'Tatsu Signing Server HealthCheck', returning an HTML body of 'Server not ready'. This may be a general ping protocol for ensuring the TSS service is online.
  • ?action=2: Common SHSH protocol. See #Status responses for all known server responses.
  • ?action=3: Functionally the same as ?action=2.
  • ?action=5: Generates respCode and respMsg. This response syntax differs slightly from the SHSH protocol. The name 'cpsn' is referenced.

All unlisted action types appear to respond without HTML content, only status.

Sending data (request)

The request is actually a single XML-encoded property list. It contains a dictionary which describes the target iOS version, restore behavior, etc. Some of the required information can be taken from the BuildManifest.plist. BuildManifest contains some info about the firmware version and 'BuildIdentities' dictionary. Inside it you can find two (or more?) build identities. Each of them contains the information which depends on every type of restore ('Erase' or 'Update'). Some information is device-dependent (ECID, nonce) and is received from the device.

Request property list should have these properties:

  • @APTicket: Optional boolean value. If true, the server adds an APTicket to the request.
  • @BBTicket: Optional boolean value. The same for the BBTicket.
  • @UDID: Optional string value. Just request UDID (ex. D9C1F33D-62E0-4D25-8068-F5F46FE80057).
  • @HostPlatformInfo: Optional string value. 'mac' for OS X client, 'windows' for Windows client (can be everything you want).
  • @Locality: Optional string value. Language used for the error response (ex. 'en_US').
  • @VersionInfo: Optional string value. The version of 'libauthinstall' used (ex. 'libauthinstall-391.'). You can pass any string here.
  • ApBoardID: Integer value. Board ID of the target device. You can take this value from build manifest.
  • ApChipID: Integer value. Chip ID of the target device. You can take this value from build manifest.
  • ApECID: Integer value. ECID of the target device.
  • ApNonce: Data value. The nonce generated by your device.
  • ApProductionMode: Boolean value. Always true (unless your SOC is PROD 0 - Apple only).
  • ApSecurityDomain: Integer value. The use is unknown. You can take this value from build manifest.
  • UniqueBuildID: Optional data value. This is a unique identifier for every build (different even for 'Erase' and 'Update' types of restore). You can take this value from build manifest.

The SHSH request also contains information about files from the IPSW (or restore bundle for PurpleRestore). They can be obtained from the 'build identity' you've chosen in the previous step. Each 'build identity' contains a 'Manifest' dictionary. It's entries look like

3utools Wikipedia Serial

They are just copied to the SHSH request, but the 'Info' dictionary is removed.Example of a SHSH request (.. values are identical, *** values are different per device):


Receiving data (answer)

The response is a simple HTTP POST response, containing 3 values: STATUS, MESSAGE (a description string) and REQUEST_STRING (only if the request was successful). STATUS contains numeric status, MESSAGE contains an error message on error and 'SUCCESS' string on success and REQUEST_STRING contains response property list encoded as XML.

Status responses

    • The request was sent successfully, and a response was returned.
  • STATUS=8&MESSAGE=An internal error occurred.
    • A key contained an unknown name.
  • STATUS=69&MESSAGE=This device isn't eligible for the requested build.
  • STATUS=83&MESSAGE=An internal error occurred.
    • A key was assigned an invalid value type.
  • STATUS=92&MESSAGE=An internal error occurred.
    • The request contained more than 65536 bytes.
  • STATUS=93&MESSAGE=An internal error occurred.
    • The request contained less than 10 bytes.
  • STATUS=94&MESSAGE=This device isn't eligible for the requested build.
    • The specified build is either unsigned or nonexistent.
  • STATUS=98&MESSAGE=An internal error occurred.
    • The XML/PList identification tag is missing or the start of the tag is malformed.
  • STATUS=100&MESSAGE=An internal error occurred.
    • A general XML error was found: the XML/PList version is nonexistent or not '1.0', the end of the XML/PList identification tag is malformed, an unknown or empty tag was found, the root <plist> tag is missing, no keys were found, a value tag contained an invalid type, an unescaped ampersand character was found, two consecutive dash characters were found in a comment, or a tag was found without its counterpart.
  • STATUS=103&MESSAGE=An internal error occurred.
    • Multiple '@' characters were found at the beginning of a key name.
  • STATUS=128&MESSAGE=An internal error occurred.
  • STATUS=131&MESSAGE=An internal error occurred.
    • TBD: Something to do with @APTicket?
  • STATUS=132&MESSAGE=An internal error occurred.
  • STATUS=133&MESSAGE=An internal error occurred.
    • The BbGoldCertId key is missing in a Baseband install.
  • STATUS=511&MESSAGE=No data in the request
  • STATUS=551&MESSAGE=Error occured while importing config packet with cpsn:
  • STATUS=5000&MESSAGE=Invalid Option!


  • Interestingly, if all you're interested in is the ServerVersion (and a SUCCESS response), sending any one valid Ap-prefixed key will do, like so:
  • In regards to fuzzing and malformed data, the server (as of 2.1.0, at least) seems to have no bounds checking for the ApNonce, or even checking to see if the ApNonce exists. Because the APTicket changes even when specifying an invalid-sized nonce, it is assumed nonces too short are padded while nonces too large are ignored past the 16th character.
  • Most textual characters between tags are ignored. For example, inserting non-bracket text (excluding XML special characters, such as '&') after a <dict> and before the following <key> will have no effect.
  • A version string in the XML/Plist identification tag is required, or a STATUS=100 internal error message will result. Any encoding string provided is ignored and defaulted to (presumably) 'UTF-8'.

3utools Wikipedia Gratis

  • The DOCTYPE tag is completely ignored. As such, specifying any non-PList DTD has no effect.

Other parameters / open questions

3utools Wikipedia

Some parameters could have other values. Not all details are known.

  • ApSecurityDomain: Meaning? (Related to SDOM tag)
  • Trusted: What is this for?
  • Full description of the above values for UniqueBuildID, Digest, PartialDigest and BuildString.


The PartialDigest is structured like so:

The img3 is first stripped of it's code signature (if present) and then passed through SHA1Update. SHA1ResultPartial is then performed. It is purposely not the final resulting SHA1. The reason for this being, when TSS processes the PartialDigest, it performs one more SHA1Update on the hash to include the ECID before doing SHA1Final and creating the SHSH blob.

Code for SHA1ResultPartial:

Code for tss_strip_img3_signature:


Digest is the SHA1 of the stripped img3. They are used instead of PartialDigests for the APTicket since the ticket is already personalized for the ECID and all other tags.

Retrieved from 'https://www.theiphonewiki.com/w/index.php?title=SHSH_Protocol&oldid=102241'

Reverse engineering the commonly used 3utools software to make it more open and learn about it.


3utools is amazingly great software for managing iOS devices.
Not only does it show you a lot information about hardware integrity of your devices, it also helps you fix problems and jailbreak them.
3utools is not opensource but has an API for most of their functionality.
For the freedom of development I wanted to see if this API can be reused by developers as that would make the life of security researchers easier.

The Research

3utools Wikipedia

3utools has the ability to specify a proxy in the settings.
Since the traffic of 3utools is encrypted via TLS, I am using fiddler with its own CA certificate.
After launching fiddler I simply set the proxy server in the settings to be localhost with port 8888, which is what fiddler runs on.
Burpsuite is also possible the same way which is amazing for debugging API calls and reproducing / interacting with API calls.

First 0-day vulnerability reported

Without even using any research tools like burpsuite and fiddler I expected that most of the content loaded in 3utools is actually just a webpage with a lot of javascript, this due to the delays in rendering certain userinterface graphics because that could mean and turned out to be loaded over the network.

3utools was vulnerable to a low-risk cross site scripting vulnerability which I found by simply entering '<script>alert(1)</script>' in almost any of the input fields a user could access in the software.With that I also found the domain where their UI is located at.

Without further interruption or waiting, I immediately reported the vulnerability to 3utools and it got patched the same day.
However, I did not get any bounty. After all 3utools is free software anyway.

Amazing infrastructure

3utools seems to have amazing infrastructure.
They have a persitant file storage server where they store almost any iOS firmware related files, such as developer dmgs and jailbreaks.
This makes their service faster than Apple's and able to download files even when Apple's servers are down.
What is where and where is what is yet to be found out, but at least I discovered that when clicking the 'view screen' button you can see that the corresponding developer dmg image is downloaded for your device and mounted.
Probably because they use the 'screenshotr' xpc service to get the live screen.
For developers and researchers this means it is amazingly easy to quickly download the developer dmg from their servers as they are all named logically.

Aside the filestorage they also have a REST json API with one can retrieve information about firmware.
One can ask the API to only give jailbreakable or jailbreakable and signed firmware or just any firmware for specific devices and OS versions.
Great feature if you ask me, again for developers and researchers a good way to automate their work a few more.

NOTE FOR DEVELOPERS: You can see the full documentation being developed when clicking the 'wiki' here on GitHub.

TLDR:Reverse engineering 3utools pays off and the first vulnerability has been fixed.
Developers and researchers benefit from 3utools rest API and filestorage.