Closed davidszili closed 4 years ago
Same here
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.
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
@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:
@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.
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.
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.
@vocaeq What should I do to test, and get keychaineditor working? Thanks in advance
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 :)
@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
@ReverseThatApp I will install it directly in the iPhone. I sent you a dm in twitter.
@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.
@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.
@vocaeq just to clarify sqlite3 was installed with cydia just to clarify, my bad.
@just4fun20 you can get it installed from Sam Bingner repo
Thanks to @ReverseThatApp and @vocaeq. Problem is now fixed. New deb compiled by @ReverseThatApp can be found here: shorturl.at/eoOW5
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?
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.
How do I make it work on MacOS Catalina??
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
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
I updated the README and added the updateEntitlements.sh
shell script to the repo. Thanks!
i need run iOS 13.5 lock screen, work?
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?
shorturl.at/adEQ3
This address "shorturl.at/adEQ3" cannot be accessed anymore
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 fromkeychain_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 anEnter 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?
It was the one posted here: shorturl.at/eoOW5
Don't think it contained the source, only the binary.
Thanks
Can you send me the source code of the keychaineditor you downloaded?
@ihbing @ReverseThatApp any thoughts?
@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:@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.
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.
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. ?
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!
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
.
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.
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"
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.
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.
@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
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!
@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?
Not sure why the text afterwards is being included in the 'code' field, sorry about that.
#!/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.
What do you mean by "use this line from ent.xml" - you don't say what to use. :-)
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.
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
.
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
:
<string>U68MSDN6DR.org.whispersystems.signal</string>
<string>U68MSDN6DR.org.whispersystems.signal</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>
<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
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.
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.
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.
Tried it with:
Can someone please confirm/refute this?
Thanks!