search

KJCracks / Clutch

Fast iOS executable dumper
3.69k stars 647 forks source link

Cydia repo and CI #191

Open stek29 opened 7 years ago

stek29 commented 7 years ago

It'd be nice to have a repo with always fresh Clutch in it, and I think Travis or any other CI/GitHub hook can be used for it.

Here's a sample script I'm using currently for automated build of deb (it's overloaded with tmpdir usage, and it doesn't check if iOS SDK is patched) Manuals for dpkg-scanpackages and pushing to gh-pages from travis are not hard to find.

But I'd also suggest to make a separate repo for it to avoid polluting git with those binaries (I guess rewriting history would be fine too)

Tatsh commented 6 years ago

We've had issues with signing before for some reason sometimes requiring the user to rename the binary to kill cache or to resign on their device. It happens randomly.

stek29 commented 6 years ago

"Killed: 9" ?

Tatsh commented 6 years ago

Yes.

stek29 commented 6 years ago

Yeah, that's known issue and from what I've heard (from Siguza) it's caused by code signing. Removing the binary and then putting new one should probably work.

Tatsh commented 6 years ago

Yeah and that's not a good solution for the average user.

What could be done is a custom script in the Debian package prior to installation to actually write zeros 2 times or so over the old binary and then delete and write the new binary, and resign it with ldid. I have not tested this theory out. I just usually rename the binary to clutch2 and start using it again.

The real question is how to properly kill the kernel signing cache. I think it's changed significantly since iOS 9.

stek29 commented 6 years ago

idk why but I just got notification for this thread.

It's not about writing zeroes -- there are "generation"s on each vnode's signature in ubc. When some file is executed, it's code signature is parsed, and current generation is saved.

Then, when you change the file, parsed signature stays in ubc, and it's not parsed again. However, if current generation isn't equal to one on that vnode's cache, it gets re-parsed.

So, there are two ways: Either create a new vnode for the binary (i.e. remove it and create again), or somehow bump generation number.

Interestingly, AMFI's user client provides an API for that -- see this gist

So, in theory running that file should flush caches, and it only needs to be root iirc (no special entitlements). However, in practice it didn't work on first try, and it was 6am so I didn't bother to check it and just went to sleep. And I never got to it again.