iOS 10.2 beta new manifest encryption

[Louti]

Hello,

Thanks for this wonderful code all you you managed to write. I'm calling for your help as I work on a program that uses iOS backups. Since iOS 10.2, they changed the way backup encryption work (if you enabled it with a password)

The keybag has now 3 new entries in its header, namely "DPWT", "DPIC", "DPSL".

DPWT is equal to 1 (WT = Weight? Wrap Type?) DPSL is a salt of a 20 bytes length DPIC is a iteration count (i guess) of 10'000'000 (I think it is related to this : http://ftp.ripe.net/rfc/authors/rfc8018.txt, search for 10,000,000)

As for what DP stands for, I'd go for either Data Protection, or Derivated Password, ... not sure.

Now when you try to unwrap the keys contained inside the backup with only the password derived with PBKDF2 it fails, so I think they added an extra layer of security.

I tried many and many combination, and if you want you can access here a script in python that do the tests and shows my tries here

Another addition is that the Manifest.db is fully encrypted, and a new entry has appeared in Manifest.plist which is "manifiestKey", of 44 bytes. However the first four bytes never changes (04 00 00 00) even between devices, so I suggest we can drop it and use the last 40 bytes as a wrapped key.

Again I'm free if you have any questions regarding this.

[horrorho]

Thank you for your detailed thoughts. Unfortunately I've largely stopped working on this project due to time constraints. I still don't own an iPhone so it's a bit tricky for me to test with iOS 10.

I'll try and take some time out to go over your script in more detail over the weekend. It may ultimately require us to reverse engineer binaries to see exactly what's going on under the hood, something I hate doing.

[Louti]

Thanks for the quick update ! I ll try to snap the binaries with Xcode as the JB is not out yet. But maybe iCloud for windows already supports it.

I can give you the two manifests files if you need them

[horrorho]

I should have some time over the following week to examine this issue in more detail. Whether it's a trivial fix or a not remains to be seen.

I've had a look at your script but I would like more information. If you would kindly replace the following two files with their gist equivalents.

InflatableDonkey-master/src/main/java/com/github/horrorho/inflatabledonkey/cloud/clients/KeyBagClient.java https://gist.github.com/horrorho/0e94c0cee40e8ef9773233dba6423b50

InflatableDonkey-master/src/main/java/com/github/horrorho/inflatabledonkey/data/backup/KeyBagFactory.java https://gist.github.com/horrorho/4867ceaf71690ea98576a8910715f329

Recompile and run. It may dump out up to three error statements for each key bag it attempts to acquire. The first will contain the raw server response with encrypted fields. The second/ third will contain the decrypted key bag data/ secret which is passed to our key bag decoder. I need to see this data in it's entirety. In isolation this data cannot be used to retrieve iCloud contents but feel free to email me the results at [email protected] if you are uncomfortable about posting the results here.

[Louti]

Hello,

I do not really use Inflatable Donkey, but I've seen it's a pretty active project regarding backups. My program is in C++, just ask me the files you need exactly (do you need Manifest.plist & Manifest.db?) I can upload them and send them to you!

[horrorho]

The InflatableDonkey modifications above should largely isolate the unadulterated key bag data and allow me to examine it. If instead you want to provide the raw protobuf key bag server response and the decrypted 'keybagData' and 'secret' field data then that's fine.

The manifest issue is more involved and I don't think I have the time to devote to it at present. However it may benefit from the elucidation of the key bag problem as both involve an unidentified key unwrap mechanism.

[Louti]

Hello,

Can you tell me if this is good : http://pastebin.com/Ya9fEn2T (there are some of my debug code first so don't bother it)

By the way how where you able to debug backup with Windows binaries, does iCloud for windows downloads backups ? How could you run the code ?

Thanks :)

[horrorho]

Thank you.

It appears that InflatableDonkey has failed to handle the protected key bag record properly. The fields "Keybag" and "secret" have not been successfully decrypted. Let's try and fix this first. I've just pushed a new build that should solve this, assuming it's the same issue as #36.

If I could kindly ask you to grab the latest version of InflatableDonkey, re-apply the above steps and let me know the result.

If this doesn't work I'll need to further clarify the information present in the keybag and also the secret code.

Unless it's changed in the latest Windows build, there is no code to download backups directly or handle iOS data protection. The older data protection code is unchanged from iOS 8 and was a straight port. The newer AES-XTS algorithms I managed to elucidate without resorting to reversing iOS binaries.

[Louti]

Hello,

I write you here since I'll communicate you the account details for testing. I tested but I'm not sure of the results, so here is an account for testing with an iOS 10.2 beta 3 password :

Horrorho edit: details removed.

You can use it like you want since there's nothing personal in there

Tell me if I can be of any help !

On Tue, Nov 15, 2016 at 7:13 AM, horrorho [email protected] wrote:

Thank you.

It appears that InflatableDonkey has failed to handle the protected key bag record properly. The fields "Keybag" and "secret" have not been successfully decrypted. Let's try and fix this first. I've just pushed a new build that should solve this, assuming it's the same issue as #36 https://github.com/horrorho/InflatableDonkey/issues/36.

If I could kindly ask you to grab the latest version of InflatableDonkey, re-apply the above steps https://github.com/horrorho/InflatableDonkey/issues/41#issuecomment-260139314 and let me know the result.

If this doesn't work I'll need to further clarify the information present in the keybag and also the secret code.

Unless it's changed in the latest Windows build, there is no code to download backups directly or handle iOS data protection. The older data protection code is unchanged from iOS 8 and was a straight port. The newer AES-XTS algorithms I managed to reverse without resorting to reversing iOS binaries.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/horrorho/InflatableDonkey/issues/41#issuecomment-260556610, or mute the thread https://github.com/notifications/unsubscribe-auth/ALYr1nXcKzcfEIIydinlovRUBRfPtBmtks5q-U2FgaJpZM4KsrIC .

[horrorho]

Thank you. In future you can email more sensitive information at [email protected]. I've taken the liberty of editing your response.

I'll certainly take a look at the backup most probably after work.

[horrorho]

Ok. I've managed to download your iPad backup. There was a minor issue that I've patched #44. However the device itself is iOS 9.1 and not 10.2 beta so I cannot replicate the issues you describe.

You can either try the earlier steps with the new build that I've just pushed. However this may fail again as the issue may be rooted further up the chain.

As an alternative I need more details regarding the key bag data. More specifically:

• The "secret" field/ passcode.
• The "keybagData" or all of the header data and one full set of protection class data.

As it stands I only have a partial and idiosyncratically described set of .bin files. Ideally they should be named as they appear in the key bag for me to grab a semantic handle on them e.g: wpky.bin, pbky.bin etc.

Please feel free to ask for further clarification. Also understand that I'm not an iOS security expert so I can't give you any promises as to what I can manage.

N.B. I've deleted your backup data from my Linux box. If you would kindly change the password to the iCloud account.

[Louti]

Hello,

This is really weird. I made the account this morning and only used it onto an iOS 10.2 beta device.

I think that the device still sends old backup to CK, since it's maybe not compatible with newer backups.

Here you go with the keybag file (taken from our backup program, CTS) : https://we.tl/ca8l7RDwZF

On Tue, Nov 15, 2016 at 12:39 PM, horrorho [email protected] wrote:

Ok. I've managed to download your iPad backup. There was a minor issue that I've patched #44 https://github.com/horrorho/InflatableDonkey/issues/44. However the device itself is iOS 9.1 and not 10.2 beta so I cannot replicate the issues you describe.

You can either try the earlier steps https://github.com/horrorho/InflatableDonkey/issues/41#issuecomment-260139314 with the new build that I've just pushed. However this may fail again as the issue may be rooted further up the chain.

As an alternative I need more details regarding the key bag data. More specifically:

• The "secret" field/ passcode.
• The "keybagData" or all of the header data and one full set of protection class data.

As it stands I only have a partial and idiosyncratically described set of .bin files. Ideally they should be named as they appear in the key bag for me to grab a semantic handle on them e.g: wpky.bin, pbky.bin etc.

Please feel free to ask for further clarification. Also understand that I'm not an iOS security expert so I can't give you any promises as to what I can manage.

N.B. I've deleted your backup data from my Linux box. If you would kindly change the password to the iCloud account.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/horrorho/InflatableDonkey/issues/41#issuecomment-260619438, or mute the thread https://github.com/notifications/unsubscribe-auth/ALYr1o8Qxv6leTTqxnFAf2B624PiiBARks5q-ZoEgaJpZM4KsrIC .

[Louti]

Oh the password is 1234

On Tue, Nov 15, 2016 at 12:43 PM, Louka Outrebon [email protected] wrote:

Hello,

This is really weird. I made the account this morning and only used it onto an iOS 10.2 beta device.

I think that the device still sends old backup to CK, since it's maybe not compatible with newer backups.

Here you go with the keybag file (taken from our backup program, CTS)

On Tue, Nov 15, 2016 at 12:39 PM, horrorho [email protected] wrote:

Ok. I've managed to download your iPad backup. There was a minor issue that I've patched #44 https://github.com/horrorho/InflatableDonkey/issues/44. However the device itself is iOS 9.1 and not 10.2 beta so I cannot replicate the issues you describe.

You can either try the earlier steps https://github.com/horrorho/InflatableDonkey/issues/41#issuecomment-260139314 with the new build that I've just pushed. However this may fail again as the issue may be rooted further up the chain.

As an alternative I need more details regarding the key bag data. More specifically:

• The "secret" field/ passcode.
• The "keybagData" or all of the header data and one full set of protection class data.

As it stands I only have a partial and idiosyncratically described set of .bin files. Ideally they should be named as they appear in the key bag for me to grab a semantic handle on them e.g: wpky.bin, pbky.bin etc.

Please feel free to ask for further clarification. Also understand that I'm not an iOS security expert so I can't give you any promises as to what I can manage.

N.B. I've deleted your backup data from my Linux box. If you would kindly change the password to the iCloud account.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/horrorho/InflatableDonkey/issues/41#issuecomment-260619438, or mute the thread https://github.com/notifications/unsubscribe-auth/ALYr1o8Qxv6leTTqxnFAf2B624PiiBARks5q-ZoEgaJpZM4KsrIC .

[horrorho]

Thank you. However there should also be a "secret" passcode key.

To clarify further, if we examine your data from http://pastebin.com/Ya9fEn2T:

The "keybagData" here should correspond to the key bag data, i.e. https://we.tl/ca8l7RDwZF. Line 391.

   recordField {
    identifier {
      name: "keybagData"
    }
    value {
      type: 20
      bytesValue: "\003\244Q\000;F\354\220j\317\...

However there should also be a "secret" passcode. Line 400.

  recordField {
    identifier {
      name: "secret"
    }
    value {
      type: 20
      bytesValue: "\003\244Q\000|\273\337\227\...

Do you have this "secret" passcode available? This is what we would normally plug into the key derivation function in some manner. As it stands we use it as a password for PBKDF2.

[codegoddesskh]

@Louti is working on decrypting an iTunes local backup made with iOS 10.2 beta 1, 2, or 3. I'm fairly sure the structure hasn't been reflected in the iCloud keybags sadly!

Did you get anywhere with the new key derivation algorithm @Louti ?

[Louti]

As it looks, it was indeed not reflected in the iCloud key bags.

I could not find the new derivation algorithm yet. Guys at http://www.iphonebackupextractor.com/ were able to find it since they have a working program with iOS 10.2 betas.

What's odd is that they added a new salt and an iteration counter of 10'000'000. This can't be PBKFD2 since it takes at least 3mins to derivate a key with a really good processor (http://www.iphonebackupextractor.com/fr/blog/2016/nov/10/ios-102-encryption-fully-supported/).

Any input / ideas would be interesting

[horrorho]

@Louti What language are you using to process these 10 million rounds of PBKDF2?

[Louti]

I tried in python, and C++. C++ will take at best rates 30 seconds.

[horrorho]

@Louti I still wouldn't discount PBKDF2 entirely. In fact it sounds like this is Apple's intention. The reason for the high iteration count is to limit brute forcing attempts. The Python time is incomparable to a hardware optimised solution. Apple hardware accelerates numerous cryptographic functions as indeed does modern Intel hardware.

Unfortunately I can't offer too much assistance. I tend to just 'cheat' and pull apart binaries to see what's going on. I often feel that InflatableDonkey was largely an exercise in reverse engineering binaries.

[horrorho]

@codegoddesskh @Louti I think I've figured it out based on the new information that you've provided. Up till now I've been trying to replicate the issue in iCloud key bags rather than approach it from an iTunes perspective. I'll test it further and detail the algorithm/ push a gist after work.

Based on @Louti's key bag data. Header:

VERS:00000003
TYPE:00000001
UUID:af540c6691e840458d820ef4ab89edd8
HMCK:00000000000000000000000000000000000000000000000000000000000000000000000000000000

WRAP:00000000
SALT:bdedebcad0579e8bbdf320d5e5870abc06a9c114
ITER:00002710

DPWT:00000001
DPIC:00989680
DPSL:848e0847540b0de58f1bfcb9e2f651bff3c3b4bc

Class 1. Wrapped key:

UUID:2ded92900a3b4d15b573ad10e2073938
CLAS:00000001
WRAP:00000002
KTYP:00000000
WPKY:f74fd78cefe0816f93f4ee7ea738ff08bc4c029c8a33700f00788ea6c8569ce34fc99f2a1f6f9573

Class 1. KEK/ unwrapped key:

KEK: 7322191fe5075d67265dc3233f4e63f8c9b75c787aa8041632482bb9e02135db
KEY: 5651b31b24a32ce61fa00a1b667c1c9faf50876a292384246da49f8412d1a2a9

[Louti]

I'm gonna test right know thanks for looking into it.

Could you just point me on how you got those ? (No need for code can be some very rough pseudo code)

[Louti]

Ahhhhhhhhhhhhhhhhh it worked.

Tell me it's not like : key1 = pbkdf2(password, dpsalt, dpic) kek = pbkdf2(key1, salt, iter)

[horrorho]

As you might expect, particularly in retrospect, Apple simply introduced a new step. It appears to be a double application of PBKDF2 (with the introduction of SHA256):

byte[] kek = PBKDF2.generate(new SHA256Digest(), passcode, dpsl, dpic, KEK_BITLENGTH);
byte[] kek2 = PBKDF2.generate(new SHA1Digest(), kek, salt, iter, KEK_BITLENGTH);
Optional<byte[]> key = RFC3394Wrap.unwrapAES(kek2, wpky);

int KEK_BITLENGTH = 256

I've only tested it on a single key.

[Louti]

AHHHHHHHHHHHHHHHHHHHHH.

I did not try the combination of the two.

[Louti]

Thanks a thousand times!

[michaljirman]

@horrorho @Louti Thanks! I can also confirm it works. Btw did you just guess it or reverse engineer it from iTunes binaries?

[Louti]

As you can see in the first python script this is a really hide and seek game, but I did not try like I should :'(

[Louti]

http://pastebin.com/3hP7SZ5E here if you want to take a look.

[horrorho]

@Louti You're welcome (a thousand times :smiley_cat:)! I'm just glad I was able to help. I'll examine your updated script after work in more detail. I'll also update InflatableDonkey's key bag code.

@Jirmi Educated guesses and not reversed (thankfully).

[michaljirman]

@Louti have you managed to decrypt the manifest.db file now?

[Louti]

Yes

There's a new entry in manifest.plist called manifestkey. With the help of the keybag you can then decipher the manifest.db