Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

keychain_dumper is not finding items on iOS 13.5 #52

Closed
davidszili opened this issue Jun 3, 2020 · 47 comments
Closed

keychain_dumper is not finding items on iOS 13.5 #52

davidszili opened this issue Jun 3, 2020 · 47 comments

Comments

@davidszili
Copy link

Hi,

I am wondering if it's only me (maybe a package I have installed that is causing this), but keychain_dumper is not finding items on iOS 13.5. It does not even prompt for a passcode when I run the tool.

# ./keychain_dumper -a
[INFO] No Generic Password Keychain items found.
[HINT] You should unlock your device!
[INFO] No Internet Password Keychain items found.
[HINT] You should unlock your device!
[INFO] No Identity Keychain items found.
[HINT] You should unlock your device!
[INFO] No Certificate Keychain items found.
[HINT] You should unlock your device!
[INFO] No Key Keychain items found.
[HINT] You should unlock your device!
# ls -l /private/var/Keychains/keychain-2.db
-rw-r--r-- 1 _securityd wheel 1732608 Jun  3 01:13 /private/var/Keychains/keychain-2.db

Tried it with:

  • iPhone X and iPad Pro Gen 2
  • both with iOS version 13.5
  • both jailbroken with checkra1n 0.10.2
  • Used the latest-greatest binary from this repo (~12h old ATM)

Can someone please confirm/refute this?

Thanks!

@just4fun20
Copy link

Same here

@ptoomey3
Copy link
Owner

ptoomey3 commented Jun 3, 2020

Can you try the prior binary that was committed before the one today? I don’t have a jailbroken phone these days, so am unable to test things very easily. It built fine, but maybe something failed silently.

@davidszili
Copy link
Author

Hi Patrick,

Thx for the prompt reply. I am happy to help with testing. I just checked the binary version from Sept 2019, and I have the same results on both devices. In fact, I jumped on the new binary yesterday, because of this, but I double-checked to be on the safe side.

I forgot to mention, but I have keychain dumps from April 27 on both devices. I can't remember if I had 13.4 or 13.4.1 on them at the time, but the issue seems to exist only on 13.5 (and I assume 13.5.1, but I have not upgraded yet).

Also, both new and old binary works well on iOS 10.3.3, which is running on an iPhone 5C.

According to Wikipedia (https://en.wikipedia.org/wiki/IOS_version_history#iOS_13), there were some changes on 13.5 with Face ID and Passcode:
The unlock process has been simplified for devices with Face ID when users are wearing a face mask.
The passcode field is automatically presented after swiping up from the bottom of the Lock Screen when a user is wearing a face mask.
Also works when authenticating with the App Store, Apple Books, Apple Pay, iTunes, and other apps that support Face ID authentication.

I couldn't find much on this at Apple: https://support.apple.com/en-us/HT211168

@ptoomey3
Copy link
Owner

ptoomey3 commented Jun 3, 2020

@vocaeq emailed me last night noting that iOS seems to have changed how entitlements work and granting a wildcard (*) entitlement no longer seems to work. As a result, it is likely this part of the build process is not doing what we want:

codesign -fs "$(CER)" --entitlements entitlements.xml keychain_dumper

@vocaeq attached the following script to iterate through and find all entitlements on a given system and then grant keychain-dumper those specific entitlements. If folks want to try running it and confirming it work we can integrate support for that into this project. I wonder if we can also just keep a running list of explicit entitlements and grant all the ones we know of during build time such that folks don't always have to run this script before the tool is useable.

#!/bin/bash

mkdir -p /usr/local/bin/

KEYCHAIN_DUMPER_FOLDER=/usr/bin
ENTITLEMENT_PATH=$KEYCHAIN_DUMPER_FOLDER/ent.xml
echo "<?xml version=\"1.0\" encoding=\"UTF-8\"?>" > $ENTITLEMENT_PATH
echo "<!DOCTYPE plist PUBLIC \"-//Apple//DTD PLIST 1.0//EN\" \"http://www.apple.com/DTDs/PropertyList-1.0.dtd\">" >> $ENTITLEMENT_PATH
echo "<plist version=\"1.0\">" >> ENTITLEMENT_PATH
echo "  <dict>" >> $ENTITLEMENT_PATH
echo "    <key>keychain-access-groups</key>" >> $ENTITLEMENT_PATH
echo "    <array>" >> $ENTITLEMENT_PATH

for d in /var/mobile/Containers/Shared/AppGroup/* ; do  
	cd $d ; 
	echo "        <string>$(plutil -MCMMetadataIdentifier .com.apple.mobile_container_manager.metadata.plist)</string>" >> $ENTITLEMENT_PATH ; 
	cd .. ; 
done

# amend app specific application-identifier
for d in /private/var/containers/Bundle/Application/* ; do
	cd $d/*.app/ ;
	executableName=`plutil -CFBundleExecutable Info.plist` ;
	checkingPath=`pwd` ;
	echo "Checking... $checkingPath" ;
	# extract current MachO entitlement to file
	ldid -e "${executableName}" >> ent.xml ;
	applicationIdentifier=$(plutil -application-identifier ent.xml) ;

	echo "        <string>$applicationIdentifier</string>" >> $ENTITLEMENT_PATH ; 

	# clean up
	rm ent.xml ;
	cd ../../ ;
done

echo "    </array>">> $ENTITLEMENT_PATH
echo "    <key>platform-application</key> <true/>">> $ENTITLEMENT_PATH
echo "    <key>com.apple.private.security.no-container</key>  <true/>">> $ENTITLEMENT_PATH
echo "  </dict>">> $ENTITLEMENT_PATH
echo "</plist>">> $ENTITLEMENT_PATH

cd $KEYCHAIN_DUMPER_FOLDER
ldid -Sent.xml keychain_dumper

@just4fun20
Copy link

Most likely due to this flaw in token:
https://threatpost.com/apple-100k-bounty-critical-sign-in-with-apple-flaw/156167/

That's why it doesn't work in 13.5 and up.
Token were accessible in keychain.
They must have changed something.
Even keychaineditor have same issue.

@vocaeq
Copy link
Contributor

vocaeq commented Jun 3, 2020

Me and @ReverseThatApp wrote this script yesterday, haven’t got much time to check if all the keys are being fetched. Managed to get keychaineditor work as well. @just4fun20 I’ve only tested keychaineditor with script, @ReverseThatApp compiled it for me, not sure if he changed something inside.

@just4fun20
Copy link

@vocaeq What should I do to test, and get keychaineditor working?
Thanks in advance

@ReverseThatApp
Copy link

ReverseThatApp commented Jun 3, 2020

I made some changes to keychaineditor to make it work on the latest iOS 13.5.
The idea is to have a postscript generate new entitlement (with @vocaeq) for app-specific rather than using a wildcard as it's not working and use ldid to pseudo sign the executate after installing.
I uploaded the keychaineditor source code here, feel free to have a look and give it a try with pre-packed .deb file: shorturl.at/adEQ3
Feel free to connect and drop me a chat on Twitter :)

@ReverseThatApp
Copy link

@vocaeq What should I do to test, and get keychaineditor working?
Thanks in advance

You can download my changes shorturl.at/adEQ3
Then install pre-packed keychaineditor.deb (I built for arm64).
If you wanna run on arm64e, change these in Makefile:
ARCH_FLAGS = -arch arm64e
TARGET = -target arm64e-apple-ios10

Then from terminal run this command to build: make keychaineditorSwiftc

@just4fun20
Copy link

@ReverseThatApp I will install it directly in the iPhone.
I sent you a dm in twitter.

@vocaeq
Copy link
Contributor

vocaeq commented Jun 4, 2020

@ReverseThatApp told me that old script did not fetch all keys. We modified script a little so it gets all it needs straight from keychain. Make sure sqlite3 is installed. Also I just seen that generic passwords are not show, not sure if it's because there's really no generic password in my keychain or something wrong with script. I assume that "genp" are generic passwords, but I may be wrong.

updateEntitlements.txt

@just4fun20
Copy link

@vocaeq the new updated Entitlements.txt you just provided is the same as before or a different one?
Also when dumping from iPhone sqlite3 is already there.

@just4fun20
Copy link

@vocaeq just to clarify sqlite3 was installed with cydia just to clarify, my bad.

@ReverseThatApp
Copy link

@just4fun20 you can get it installed from Sam Bingner repo

@just4fun20
Copy link

Thanks to @ReverseThatApp and @vocaeq.
Problem is now fixed.
New deb compiled by @ReverseThatApp can be found here: shorturl.at/eoOW5

@ptoomey3
Copy link
Owner

ptoomey3 commented Jun 4, 2020

What would folks appreciate most here? Is it most useful to just bundle the bash script to let folks add entitlements dynamically? Should I add a bunch of baseline entitlements to the default binary?

@vocaeq
Copy link
Contributor

vocaeq commented Jun 5, 2020

I would bundle script as a workaround for now and replace it after finding method that works all the time. But don't include script yet. I found out that it does not fetch generic_passwords, but seems like culprit is one or few of those:
linesToDelete.txt. Later today I'll try which ones are breaking it like * did and update script to delete those lines. For now if you need to dump generic passwords, delete those from entitlements file and sign it again.

@iKingTeam
Copy link

How do I make it work on MacOS Catalina??

@vocaeq
Copy link
Contributor

vocaeq commented Jun 8, 2020

Up to date script fixing issue with not all generic app password being displayed. @ReverseThatApp added skipping permission for apps that may be the cause. If you need any key from those apps, delete them from array and see if keys from generic apps still works. If generic passwords stops working, just add those lines again and re-run the script. @ptoomey3 feel free to add script and modify it as you need. I can't spot any other issue for now.
updateEntitlements.txt

@iKingTeam
Copy link

I made some changes to keychaineditor to make it work on the latest iOS 13.5.
The idea is to have a postscript generate new entitlement (with @vocaeq) for app-specific rather than using a wildcard as it's not working and use ldid to pseudo sign the executate after installing.
I uploaded the keychaineditor source code here, feel free to have a look and give it a try with pre-packed .deb file: shorturl.at/adEQ3
Feel free to connect and drop me a chat on Twitter :)

I have written to you, but you do not answer

@ptoomey3
Copy link
Owner

I updated the README and added the updateEntitlements.sh shell script to the repo. Thanks!

@thiagomagamoc
Copy link

i need run iOS 13.5 lock screen, work?

@seb3point0
Copy link

Device: iPhone 7
System: iOS 13.6.1

@ReverseThatApp Thanks for sharing the updated keychaineditor binary. It appeared to work for me (to some extent) as I was not able to get any output from keychain_dumper. Like the OP, I also get the [INFO] No Generic Password Keychain items found. [HINT] You should unlock your device! error.

When I run keychaineditor, my phone displays an Enter iPhone passcode screen twice, and then an Enter Password dialogue box. I assumed I should enter the device passcode here. The output is a list of keychain items, but the data appears to be encrypted.

  {
    "Access Group" : "[redacted].org.whispersystems.signal",
    "AccessControl" : "Not Applicable",
    "Creation Time" : "Dec 05, 2019, 10:00:39 GMT+1",
    "Data" : "+74VorxZ18x\/uy[redacted]CS4+AKoqdOxc3L",
    "Service" : "GRDBKeyChainService",
    "Modification Time" : "Dec 05, 2019, 10:00:39 GMT+1",
    "Protection" : "kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly",
    "Account" : "GRDBDatabaseCipherKeySpec"
  },

Can you think of what I'm doing wrong which is preventing the password data from being decrypted?

@jitcor
Copy link

jitcor commented Sep 28, 2020

shorturl.at/adEQ3

This address "shorturl.at/adEQ3" cannot be accessed anymore

@jitcor
Copy link

jitcor commented Sep 28, 2020

Device: iPhone 7
System: iOS 13.6.1

@ReverseThatApp Thanks for sharing the updated keychaineditor binary. It appeared to work for me (to some extent) as I was not able to get any output from keychain_dumper. Like the OP, I also get the [INFO] No Generic Password Keychain items found. [HINT] You should unlock your device! error.

When I run keychaineditor, my phone displays an Enter iPhone passcode screen twice, and then an Enter Password dialogue box. I assumed I should enter the device passcode here. The output is a list of keychain items, but the data appears to be encrypted.

  {
    "Access Group" : "[redacted].org.whispersystems.signal",
    "AccessControl" : "Not Applicable",
    "Creation Time" : "Dec 05, 2019, 10:00:39 GMT+1",
    "Data" : "+74VorxZ18x\/uy[redacted]CS4+AKoqdOxc3L",
    "Service" : "GRDBKeyChainService",
    "Modification Time" : "Dec 05, 2019, 10:00:39 GMT+1",
    "Protection" : "kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly",
    "Account" : "GRDBDatabaseCipherKeySpec"
  },

Can you think of what I'm doing wrong which is preventing the password data from being decrypted?

Can you send me the source code of the keychaineditor you downloaded?

@seb3point0
Copy link

It was the one posted here: shorturl.at/eoOW5

Don't think it contained the source, only the binary.

Thanks

@seb3point0
Copy link

Can you send me the source code of the keychaineditor you downloaded?

@ihbing @ReverseThatApp any thoughts?

@seb3point0
Copy link

seb3point0 commented Dec 19, 2020

@vocaeq emailed me last night noting that iOS seems to have changed how entitlements work and granting a wildcard (*) entitlement no longer seems to work. As a result, it is likely this part of the build process is not doing what we want:

codesign -fs "$(CER)" --entitlements entitlements.xml keychain_dumper

@vocaeq attached the following script to iterate through and find all entitlements on a given system and then grant keychain-dumper those specific entitlements. If folks want to try running it and confirming it work we can integrate support for that into this project. I wonder if we can also just keep a running list of explicit entitlements and grant all the ones we know of during build time such that folks don't always have to run this script before the tool is useable.

#!/bin/bash

mkdir -p /usr/local/bin/

KEYCHAIN_DUMPER_FOLDER=/usr/bin
ENTITLEMENT_PATH=$KEYCHAIN_DUMPER_FOLDER/ent.xml
echo "<?xml version=\"1.0\" encoding=\"UTF-8\"?>" > $ENTITLEMENT_PATH
echo "<!DOCTYPE plist PUBLIC \"-//Apple//DTD PLIST 1.0//EN\" \"http://www.apple.com/DTDs/PropertyList-1.0.dtd\">" >> $ENTITLEMENT_PATH
echo "<plist version=\"1.0\">" >> ENTITLEMENT_PATH
echo "  <dict>" >> $ENTITLEMENT_PATH
echo "    <key>keychain-access-groups</key>" >> $ENTITLEMENT_PATH
echo "    <array>" >> $ENTITLEMENT_PATH

for d in /var/mobile/Containers/Shared/AppGroup/* ; do  
	cd $d ; 
	echo "        <string>$(plutil -MCMMetadataIdentifier .com.apple.mobile_container_manager.metadata.plist)</string>" >> $ENTITLEMENT_PATH ; 
	cd .. ; 
done

# amend app specific application-identifier
for d in /private/var/containers/Bundle/Application/* ; do
	cd $d/*.app/ ;
	executableName=`plutil -CFBundleExecutable Info.plist` ;
	checkingPath=`pwd` ;
	echo "Checking... $checkingPath" ;
	# extract current MachO entitlement to file
	ldid -e "${executableName}" >> ent.xml ;
	applicationIdentifier=$(plutil -application-identifier ent.xml) ;

	echo "        <string>$applicationIdentifier</string>" >> $ENTITLEMENT_PATH ; 

	# clean up
	rm ent.xml ;
	cd ../../ ;
done

echo "    </array>">> $ENTITLEMENT_PATH
echo "    <key>platform-application</key> <true/>">> $ENTITLEMENT_PATH
echo "    <key>com.apple.private.security.no-container</key>  <true/>">> $ENTITLEMENT_PATH
echo "  </dict>">> $ENTITLEMENT_PATH
echo "</plist>">> $ENTITLEMENT_PATH

cd $KEYCHAIN_DUMPER_FOLDER
ldid -Sent.xml keychain_dumper

@ptoomey3 @ReverseThatApp I successfully used this script to update entitlements for keychain_dumper and decrypt items the Keychain.

Previously, I had run the updateEntilements.sh script included in the main branch with no success.

From what I can gather, the former builds ent.xml by cycling through apps installed in the AppGroup directory, while the latter builds it by querying items found in the keychain database. Since I had deleted most of the apps on my phone (except for Signal, which was the app for which I was trying to extract the key), the only difference I could tell from the two is that’s one contained many more entitlements than the other.

I also tried keychain_dumper -s and selected the specific entitlement I needed, but this did not manage to decrypt the key.

Do you have any idea why an entitlements file with just a few items would work, while one with many items would fail to decrypt the keychain?

I've started writing a blog post detailing my experience retrieving Signal's database and some clarity would be helpful 🙂 👍

PS: I needed to install plutil from the apt.bingner.com Cydia repo.

@seb3point0
Copy link

seb3point0 commented Dec 19, 2020

After running both scripts on clean versions of the keychain_dumper binary, I noticed that the entitlements generated with the script above adds extra "group" items not present when generated with the original script.

// Original entitlement item
<string>U68MSDN6DR.org.whispersystems.signal</string>

// New entitlement items
<string>group.org.whispersystems.signal.group</string>
<string>group.org.whispersystems.signal.group.staging</string>        

I don't know what these are, but they allowed the Keychain items to be decrypted.

@vocaeq
Copy link
Contributor

vocaeq commented Dec 19, 2020

After running both scripts on clean versions of the keychain_dumper binary, I noticed that the entitlements generated with the script above adds extra "group" items not present when generated with the original script.


// Original entitlement item

<string>U68MSDN6DR.org.whispersystems.signal</string>



// New entitlement items

<string>group.org.whispersystems.signal.group</string>

<string>group.org.whispersystems.signal.group.staging</string>        



I don't know what these are, but they allowed the Keychain items to be decrypted.

Hi! I'll try to modify script to make it working correctly again. Thank you for all the information provided, it'll be really useful. I've also noticed that something really weird is happening is group contains * in its name(developer versions of app usually contains it, not the AppStore ones). Didn't have time to investigate it yet, but I'll definitely try to solve it soon.

So summing up, original script did not add two groups that was necessary to dump all keys right? Also could you check if the one containing so many entitlements didn't contain any * in it? Like groups like this S0M3ENT.* ?

@seb3point0
Copy link

I'm happy to send you the ent.xml files by email if that's helpful. I kept both generated from the original script, and the one above.

Entitlements from the original update script contains

      <string>HK4F2F3G7B.*</string>
      <string>8QRHA24EHD.*</string>

But not in entitlement items generated with the modified script. However, it should be noted that I've deleted every app but the target (Signal) from the phone, which explains why there are so few items.

I also find odd that dumps generated with the original entitlement script dont event show Keychain entries for Signal (although it contains <string>U68MSDN6DR.org.whispersystems.signal</string>).

Let me know if there are any other tests I can do on my side to improve the script!

@seb3point0
Copy link

I wrote a blog post describing how I was able to extract data from the Keychain on iOS 13.6.1. The post is specifically about extracting Signal's database but covers keychain_dumper.

Exporting messages from Signal for iOS: a journey

@vocaeq
Copy link
Contributor

vocaeq commented Jan 4, 2021

Just got back home and read both your messages and article. Pretty nice article!
Going back to issue, tomorrow I'll check issue on iPhone 6s. Although I'm almost sure what's the problem.
In article you mentioned "script included in the repo doesn't take into account the changes in iOS 13.5" which is not true 😅 We've written this script because exactly to make keychain dumper work on 13.5 and above. Script that is here above in a comment is old version of the script that is currently in repo. Difference between them is that script from here enters every single application sandbox and take informations from files residing there - this worked perfectly but was time consuming. I've noticed that all the informations can be dumped from keychain database, so to make it faster me and @ReverseThatApp have modified script to dump info from keychain. What I didn't know is that some developer applications use "HK4F2F3G7B.*" this weird format with asterisk which breaks the entitlements. Don't know why but simply putting * in entitlement completely breaks it. What's even worse is that.*names resides in keychain database even after uninstalling application. That's my theory why script from comment here worked for you.

@vocaeq
Copy link
Contributor

vocaeq commented Jan 5, 2021

Hey @seb2point0
I've modified and hugely simplified the script. Works for me now even with asterisk. Could you also confirm me that it works for you?

#!/bin/bash
#Original keychain_dumper by Patrick Toomey
#Scrpt by @ReverseThatApp and @vocaeq

KEYCHAIN_DUMPER_FOLDER=/usr/bin
if [ ! -d "$KEYCHAIN_DUMPER_FOLDER" ] ; then
  mkdir "$KEYCHAIN_DUMPER_FOLDER" ;
fi

if [ ! -f "$KEYCHAIN_DUMPER_FOLDER/keychain_dumper" ]; then
  echo "The file \"$KEYCHAIN_DUMPER_FOLDER/keychain_dumper\" does not exist. " \
       "Move the binary into the folder \"$KEYCHAIN_DUMPER_FOLDER/\" and run the script again."
  exit 1
fi

# set -e ;

ENTITLEMENT_PATH=$KEYCHAIN_DUMPER_FOLDER/ent.xml
cd $KEYCHAIN_DUMPER_FOLDER
chmod +x ./keychain_dumper
./keychain_dumper -e > ent.xml
ldid -Sent.xml keychain_dumper
rm -rf ./ent.xml
echo "Entitlements updated"

@seb3point0
Copy link

seb3point0 commented Jan 5, 2021

Thanks for the feedback. And apologies for getting some things wrong in the article – I'm not super knowledgeable about how this woks. I'm happy to change it to reflect your explanation here.

What does this script do exactly? It looks like it just extracts the existing entitlements from keychain_dumper and then adds them again with ldid. What am I getting wrong?

Unfortunately, I no longer have access to the phone so I can't test this.

@vocaeq
Copy link
Contributor

vocaeq commented Jan 6, 2021

That's exactly what script is doing. Without entitlements for each applications keychain_dumper is not able to dump keys, but it is still able to dump entitlement's for them. So version from before was dumping entitlement's manually using sqlite3 from keychain database. This is doing same thing, but using keychain_dumper "dump entitlements" functionality and resigning application with dumped entitlements. Something was wrong with script from before, I'm not sure what, but this seems to work fine. I'll try to track that bug down later this weekend. Idea for script from yesterday was actually taken from readme file. I didn't do more than script that. I'm not sure why I didn't notice that functionality before.

@tarbaII
Copy link

tarbaII commented Jan 9, 2021

@vocaeq Hi, is this script supposed to fix keychain_dumper completely on iOS 13.5+? If so, I can test it on my iPhone. It hasn't ever worked for me on iOS 13.5+ and I'm eager for a fix haha

@vocaeq
Copy link
Contributor

vocaeq commented Jan 13, 2021

HI @alyxferrari
Yes it should work correctly. I've confirmed that it works on iPhone 6s on iOS 14.1. If you have any issues, let me know!

@tarbaII
Copy link

tarbaII commented Jan 17, 2021

@vocaeq I wasn't able to dump generic Keychain items, my Internet password Keychain items dumped fine though. I tested keychain_dumper before running your script and nothing worked, it said I should unlock the device (it was unlocked). Then I tried your script and this happened:

Alyxs-iPhone:~ root# cd /usr/bin
Alyxs-iPhone:/usr/bin root# ./keychain_dumper
[INFO] No Generic Password Keychain items found.
[HINT] You should unlock your device!
Internet Password
__________
Server: xxxxxxxxxxxxxx
Account: AccessToken
Entitlement Group: xxxxxxxxxxxxxx
Label: (null)
Accessible Attribute: kSecAttrAccessibleWhenUnlocked, protection level 2 (default)
Keychain Data: xxxxxxxxxxxxxxxxxxx
... (more entries)```

Your script appeared to execute just fine, and I even tried manually executing it line by line in the terminal. I've tried it without any passcode on the device, with just a passcode, and with a passcode and Touch ID enabled, and they all have the same result. Could you help?

@tarbaII
Copy link

tarbaII commented Jan 17, 2021

Not sure why the text afterwards is being included in the 'code' field, sorry about that.

@vocaeq
Copy link
Contributor

vocaeq commented Jan 20, 2021

#!/bin/bash
#Original keychain_dumper by Patrick Toomey
#Scrpt by @ReverseThatApp and @vocaeq

KEYCHAIN_DUMPER_FOLDER=/usr/bin
if [ ! -d "$KEYCHAIN_DUMPER_FOLDER" ] ; then
  mkdir "$KEYCHAIN_DUMPER_FOLDER" ;
fi

if [ ! -f "$KEYCHAIN_DUMPER_FOLDER/keychain_dumper" ]; then
  echo "The file \"$KEYCHAIN_DUMPER_FOLDER/keychain_dumper\" does not exist. " \
       "Move the binary into the folder \"$KEYCHAIN_DUMPER_FOLDER/\" and run the script again."
  exit 1
fi

# set -e ;

ENTITLEMENT_PATH=$KEYCHAIN_DUMPER_FOLDER/ent.xml
cd $KEYCHAIN_DUMPER_FOLDER
chmod +x ./keychain_dumper
./keychain_dumper -e > ent.xml
ldid -Sent.xml keychain_dumper
rm -rf ./ent.xml
echo "Entitlements updated"

If the script from above doesn't work, please try like this:

./keychain_dumper -e > ent.xml

[*] Before ldid check if ent.xml contains any asterisk. If there's at least one group that contains " .* ", use this line from ent.xml

ldid -Sent.xml keychain_dumper

After this it should dump generic keys without a problem. If problem still persists, contact me and I'll try to figure it out.

@akohlsmith
Copy link

What do you mean by "use this line from ent.xml" - you don't say what to use. :-)

@vocaeq
Copy link
Contributor

vocaeq commented Apr 23, 2021

What do you mean by "use this line from ent.xml" - you don't say what to use. :-)

Oh, probably mistake of mine. What i meant was: "remove this line from ent.xml". Any asterisk in group name will break entitlements and you won't be able to dump keys. Not sure why it happens though. Groups with asterisk are created if you install app via xcode or sideload in other way. Those are developer groups IRC.

@Lessica
Copy link

Lessica commented Sep 16, 2022

See static bool sanityCheckClientAccessGroups(SecurityClient* client) at https://opensource.apple.com/source/Security/Security-59754.140.13/OSX/sec/ipc/server_security_helpers.m.auto.html

securityd will not accept keychain-access-groups to contain single "*" character since iOS 13.5.

But there's still one way to make "*" effective again: hook bool SecTaskIsEligiblePlatformBinary(SecTaskRef task, CFArrayRef identifiers) of securityd and return true.

@harabat
Copy link

harabat commented Oct 9, 2022

Hey @vocaeq, letting you know that the script you suggested, including after removing lines with * from ent.xml, don't find all items.

For some reason, the keys for the apps installed on the phone are not found (though, somehow, the keys for apps I have uninstalled years ago are still there, which I will be investigating further, but feels wrong in many ways).

The script by @seb2point0 (https://cight.co/backup-signal-ios-jailbreak/) does work however.

If this helps, here are the outputs for ldid -e /usr/bin/keychain_dumper | grep signal:

  • your script's output:
    <string>U68MSDN6DR.org.whispersystems.signal</string>
    <string>U68MSDN6DR.org.whispersystems.signal</string>
    <string>U68MSDN6DR.org.whispersystems.signal</string>
  • @seb2point0's script output:
    <string>group.org.whispersystems.signal.group.staging</string>
    <string>group.org.whispersystems.signal.group</string>
    <string>U68MSDN6DR.org.whispersystems.signal</string>
    <string>group.org.whispersystems.signal.group.staging</string>
    <string>group.org.whispersystems.signal.group</string>
    <string>U68MSDN6DR.org.whispersystems.signal</string>
    <string>group.org.whispersystems.signal.group.staging</string>
    <string>group.org.whispersystems.signal.group</string>
    <string>U68MSDN6DR.org.whispersystems.signal</string>

The updateEntitlements.sh script currently in the repo doesn't work at all for me.

iPhone 8.4 (SE 1st generation), iOS 14.4

@ptoomey3
Copy link
Owner

The script by @seb2point0 (https://cight.co/backup-signal-ios-jailbreak/) does work however.

If someone wants to open a pull request to provide a script that is most compatible/useful, I'd be happy to include it in the project directly.

@harabat
Copy link

harabat commented Oct 12, 2022

I'll make a PR this weekend @ptoomey3, if no one more capable than me volunteers in the meantime.

EDIT: postponing for a few days, bear with me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests