Fix for segfaults with empty keys, a couple editions to allow building on iPhone devices. #12
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
added 3 commits
February 11, 2014 11:17
Keys whose length is 0 cause segfaults when requesting the following properties: kSecAttrIsPermanent kSecAttrCanEncrypt kSecAttrCanDecrypt kSecAttrCanDerive kSecAttrCanSign kSecAttrCanVerify kSecAttrCanWrap kSecAttrCanUnwrap This commit insures that only those keys with a kSecAttrKeySizeInBits greater than 0 requests any of the above attributes.
…ly on IOS devices Sign uses the ldid tool to sign the keychain_dumper binary. This allows for signing and running keychain_dumper, even if one does not have a Mac and the codesign tool.
… use $BIN If compiling on the iPhone platform, the -arch option causes gcc to fail. This commit checks the type of the compiling machine using uname -m, and removes the -arch argument if it finds the string "iphone" in the result of said check. Also fix the sign command to use the $BIN path when calling ldid.
| printToStdOut(@"For Key Wrapping: %@\n", CFBooleanGetValue((CFBooleanRef)[keyItem objectForKey:(id)kSecAttrCanWrap]) == true ? @"True" : @"False"); | ||
| printToStdOut(@"For Key Unwrapping: %@\n\n", CFBooleanGetValue((CFBooleanRef)[keyItem objectForKey:(id)kSecAttrCanUnwrap]) == true ? @"True" : @"False"); | ||
| if (keySize) { | ||
| printToStdOut(@"For Encryption: %@\n", CFBooleanGetValue((CFBooleanRef)[keyItem objectForKey:(id)kSecAttrCanEncrypt]) == true ? @"True" : @"False"); |
change single spaces to tabs for new code
|
bump |
|
Sorry for such a late reply. I've not kept up with iOS jailbreaking in recent history. I quickly attempted to see if my original README for compiling still worked, but it appears the instructions are a bit dated. If you would like to help me merge this/update the binary it would be super 🆒 if you could also update the readme so that it is up to date with the current build tool locations/etc. If you don't have the time I may eventually get around to getting this built, but it could be some time. |
Closed
ptoomey3
approved these changes
Mar 24, 2018
|
Ill get this merged after fixing some merge conflict. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Didn't include my keychain_dumper binary in last commit. Figured it was better to have original author compile and release.
I'm going to add printing of private/public? keys, I'll send that along as well to take or leave.
I hope this is useful.
Appologies for any code style issues, if there are any.