Re: (semi-OT) hosting plugins that use PACE copy protection
Re: (semi-OT) hosting plugins that use PACE copy protection
- Subject: Re: (semi-OT) hosting plugins that use PACE copy protection
- From: John Johnson <email@hidden>
- Date: Thu, 15 Jul 2010 10:27:49 -0500
> debugging PACE-protected plugins is ... well, how can we say. its interesting.
>
> i'll try to describe what i know as diplomatically as i can. it would
> appear that apple gave PACE certain information on ways to prevent
> code that uses their system from being debuggable. PACE indeed uses
> this information, using some POSIX calls in ways that are entirely
> specific to Darwin. these are intended to make the process
> undebuggable.
You've lost me here. The only thing PACE uses to prevent debugging is the normal ptrace PT_DENY_ATTACH, same thing as Apple's own apps. It also has some checksum functions that read portions of the code in memory to detect if software breakpoints have been placed. Does not stop hardware breakpoints though, obviously, and it only checksums code in the PACE code itself, NOT the plugin's code. This is the extent of their anti-debugging techniques.
> Ok, here's some facts:
> - I'm instantiating from the main thread (everything except audio proc happens in the main thread)
> - I get the same problem whether doing it at startup or when my App is fully loaded with full GUI running
> - in AULab the PACE dialog displays correctly -- the buttons (which, by the way say somthing like "Authorise" and "Quit") are active and you can click them (in my app they are greyed out and you can't click them).
>
> This reminds me a bit of a problem I have hosting Pluggo VSTs (Which I've pretty much given up on)-- their GUIs display (sometimes), but they don't accept any mouse clicks. I wonder if it's possible that my GUI framework is somehow intercepting or filtering windowing events for alien (plugin) windows (Pluggo uses overlays) or whether I need to do something special to get the events to dispatch correctly.
>
> So perhaps this is not a PACE problem afterall, but a more general event dispatch problem. Anyone seen anything like this? Any clues how to debug it? Is there a tool to dump a trace of all Carbon GUI events and their traversal of the Control hierarchy?
To the OP, it does sound like an event dispatch problem... What is the exact method you're using to load the plugins? The PACE window is displayed during loading of the bundle, in on of the constructor functions. So you can trigger the window simply by using dlopen() or NSBundle's -load. Try a fork() followed by dlopen(). There is a tool to dump all GUI events, in a way; it's called DTrace. However, you'll run into the problem that PT_DENY_ATTACH will also block DTrace from running in the program. The only way to bypass this is to install a kernel extension that blocks PT_DENY_ATTACH. Information is available out there on the net somewhere.
Otherwise, the only way I can think of to debug it is to create a separate app that contains JUST your plugin-loading logic, and strip away things and move things around until the buttons aren't disabled anymore... :)
-J _______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden