Doesn't work on OSX El Capitan?

[sheharyarn]

I love keychaindump, I love it so so much. I've used it on Mavericks and Yosemite without any issues, but it's not working on my new macbook running OS X El Capitan. Has something changed in the new update or is it something else?

I get this:

$ sudo ./keychaindump
[*] Searching process 83 heap range 0x7fc891c00000-0x7fc892000000
[-] Requested 4194304 bytes, got 112 bytes
[-] Error (268435459) reading task memory @ 0x7fc891c00000
[*] Searching process 83 heap range 0x7fc893800000-0x7fc893a00000
[-] Requested 2097152 bytes, got 112 bytes
[-] Error (268435459) reading task memory @ 0x7fc893800000
[*] Searching process 83 heap range 0x7fc893a00000-0x7fc893b00000
[-] Requested 1048576 bytes, got 112 bytes
[-] Error (268435459) reading task memory @ 0x7fc893a00000
[*] Searching process 83 heap range 0x7fc893b00000-0x7fc893c00000
[-] Requested 1048576 bytes, got 112 bytes
[-] Error (268435459) reading task memory @ 0x7fc893b00000
[*] Found 0 master key candidates

[magus]

+1

Doesn't work for me either, wondering if disabling SIP will allow it to work again?

https://forums.developer.apple.com/thread/3981

[MarcelWaldvogel]

Here is a version that only re-enables debugging (which – I guess – is enough): http://totalspaces.binaryage.com/elcapitan

csrutil enable --without debug

[Motti-Shneor]

Same here: doesn't work on OS-X 10.11 El-Capitan Running it as root I receive:

[*] Searching process 95 heap range 0x7ff491c00000-0x7ff492000000
[-] Requested 4194304 bytes, got 112 bytes
[-] Error (268435459) reading task memory @ 0x7ff491c00000
[*] Searching process 95 heap range 0x7ff493000000-0x7ff493400000
[-] Requested 4194304 bytes, got 112 bytes
[-] Error (268435459) reading task memory @ 0x7ff493000000
[*] Found 0 master key candidates
Debug$

Seems like

kern_return_t r = vm_read_overwrite(task, start, sz, (vm_address_t)buffer, &read_sz); has been blocked on El-Capitan? or maybe I need to upgrade the program in some way?

Will signing it with an eligible developer certificate change anything?

Maybe the APIs changed, and some work will bring the program back to life? any hint will be greatly appreciated.

[MarcelWaldvogel]

The short-term solution would probably be to copy the keychain file to an older Mac and dump it there.

(Not to say that answering your query would not be great, anyway.)

[juuso]

Yep, SIP/rootless prevents spying on securityd. As far as I know, only Apple has the right entitlements to bypass the restriction, and they don't hand them out to outsiders.

I think turning off SIP is the only reasonable way to resurrect keychaindump. Please correct me if I'm wrong!

[Motti-Shneor]

Actually, I was not that interested in deciphering the key-chain brute-force, because my task is legit — I described it in the discussion part of your original essay (not in the repository).

To make things short -

I need my daemon (running by launchd as root) to connect to our server on clients enterprise machines. Sometimes I need to go through HTTP proxy (hate them, but still, I need to support).

Reading HTTP proxy settings is easy - there’s nice CFNetwork API. I was happy to find the proxy settings are system-wide. However - when the proxy needs to be authenticated (when you type in a user/password pair in the proxy settings panel) then CFNetwork won’t read them for you - they’re on the user’s login key-chain (stored and encrypted per user) which is a little strange, but OK.

Now I have two problems, and lots of wonders…

1. My daemon, when using normal KeyChain APIs - won’t see the user’s keychains, and will find nothing (And I wonder: How do all those system daemons, running as root or other users manage to connect to the internet so nicely? How do they retrieve the proxy credentials?)
2. Even when I run my code from the active user (whose login keychain contains the credentials) I still see that dialog of Allow/Deny/Always Allow my program access to the keychain. (And I wonder: Why Safari, Mail, and all the other Apple apps never show such dialog? How do they get silent access to the keychain? Maybe they don’t? When I press “Always Allow” Where is this “Trust” stored and how? Can I create such trust at installation time, before my daemon starts to run? How?

I know these are many questions, but I really need to do this, and I KNOW for a fact that NSURLSession (higher level networking API) does all this for you - only it doesn’t support general-purpose proprietary format messages - only HTTP messages. Unluckily our server is not HTTP.

Any clue or idea, or direction I could go?

Motti Shneor e-mail: motti.shneor@gmail.com phone: +972-8-9267730 mobile: +972-54-3136621

— Windows is not a virus! A virus is small and efficient. — Jonathan Leffler, Informix

On 12 בספט׳ 2016, at 11:07 לפ׳, Juuso Salonen notifications@github.com wrote:

Yep, SIP/rootless prevents spying on securityd. As far as I know, only Apple has the right entitlements to bypass the restriction, and they don't hand them out to outsiders.

I think turning off SIP is the only reasonable way to resurrect keychaindump. Please correct me if I'm wrong!

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/juuso/keychaindump/issues/9#issuecomment-246276730, or mute the thread https://github.com/notifications/unsubscribe-auth/AChnayvjoAuqT5Qi2UNz7VBUkg3QBD3qks5qpQg0gaJpZM4GIfI2.

[MarcelWaldvogel]

For it's own daemons, e.g. WiFi access, Apple copies the password to the System keychain. That might be the way to go.