mach_inject in Mavericks is broken #5

Open
gdonelli opened this Issue Jun 15, 2013 · 16 comments

Projects

None yet

7 participants

@gdonelli

I have tried to run various examples of code_inject in Mavericks but they result in the target process crashing with the following stack:

Thread 6 Crashed:
0 libsystem_c.dylib 0x00007fff8e68c505 __xvprintf + 106

I am opening an issue hoping we can figure out a solution.

@rentzsch
Owner

Thanks for the report. Patches welcome since currently I can't chase this down myself.

@gdonelli

It looks like it might have to do something with the remote stack size.
This seems to fix the issue:

change:
mach_inject.c: 240 | remoteStack -= 4;

into:
mach_inject.c: 240 | remoteStack -= 8;

It seems to work in both Mavericks and Mountain Lion now.
Will test more

@rentzsch
Owner

Hmm, now I'm wondering if it's a stack alignment issue.

@stackbear stackbear referenced this issue in zerodivisi0n/FinderMenu Aug 16, 2013
Closed

Failure on MacOSX 10.9 #7

@gdonelli

Still works well in Beta 6.

@CirrusThink

Same issue here; will try the modification to see if the patch corrects issue, I wonder if this then breaks Lion

@kunalparmar

When I build on OS X 10.9 with the change suggested by @gdonelli , it works fine. But when I build on OS X 10.8.5, I still get the crash. I'm using Xcode 5 for the build on both OSes. Anyone else see this?

@gdonelli

@kunalparmar, it works fine in 18.5 for me. Question: Do you get a crash in 10.8 only with my patch? or also with the default settings (ie that is master)?

@bafnaparag

@kunalparmar it works fine in 10.7 , 10.8 and 10.9 with @gdonelli patch.

@kunalparmar

@gdonelli, @bafnaparag: I had a setup issue; this works!

The comment for line 240 says - "increase the stack, since we're simulating a CALL instruction, which normally pushes return address on the stack". As far I understood, the CALL instruction depends on the processor and not the OS. Can you explain why the stack adjustment is needed for 10.9?

Everything works as before on previous OS releases as well. Is it because the return address is unused?

Thanks in advance for your help!

@gdonelli

I am speculating in a 64bit architecture we should have data aligned by 64bit ie 8 bytes. No idea what mavericks changes, but it is not unlikely for Apple to change the memory alignment algorithms to improve code security.

@gdonelli

Works fine in GM, would you consider pull request @rentzsch?

@rentzsch
Owner

@gdonelli sure, toss me a Pull Request

@gdonelli

@rentzsch Here it is, let me know if you have any problem with it. Thank you!

@nomadali

The patch does not fix the injection crash for me on Mavericks. Is it working for everyone ?

This is the crash signature:

Date/Time: 2013-10-29 12:23:45.952 -0400
OS Version: Mac OS X 10.9 (13A603)
Report Version: 11
Anonymous UUID: 3B3748ED-1C82-86BD-C5F6-896BEB2678AF

Sleep/Wake UUID: 3DEAF856-00DB-4FC6-AEF6-1369674F698A

Crashed Thread: 13

Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: EXC_I386_GPFLT

Thread 13 Crashed:
0 libsystem_c.dylib 0x00007fff93ec4541 __xvprintf + 106

@nomadali

Please ignore my comment. Works like a charm. My test was wrong.

@khalhorik

Hi,

Sorry for my english, I'm french.
Am I the only one who still has the problem?
I'm on Mountain Lion 10.8.3 (I reverted from Mavericks, with a TimeMachine backup).
Even after updating mach_inject, my Finder still crashes.
I checked other apps :
- Google Drive crashes when activating overlays
- Dropbox seems to work, and their overlays are visible

I tried to use the mach_inject_bundle_stub.bundle from Dropbox.app with a simple injector (not sure if this is a good idea),
but without success.

When I try to inject a bundle, mach_inject_bundle_pid returns "err_none" but the Finder crashes immediatly.
I uploaded my crash log there: http://dl.free.fr/getfile.pl?file=/GcssYZps

Thanks in advance, and great job for this very useful tool :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment