• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: [Slightly OT] Copy protecting an AU
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Slightly OT] Copy protecting an AU


  • Subject: Re: [Slightly OT] Copy protecting an AU
  • From: Brian Willoughby <email@hidden>
  • Date: Sat, 8 May 2010 05:46:59 -0700


On May 8, 2010, at 04:19, tahome izwah wrote:
Also, since our products are Cocoa based stripping symbols doesn't do
much as the Cocoa classes still carry a lot of information in them
that makes it possible for hackers to reverse engineer the code to
remove protection. Are there any tools to obfuscate (or preferably
remove) class information from NSObject subclasses?


I am fairly certain that you cannot change or remove the ObjC class information because it is required by the ObjC runtime to dynamically load your object classes into the host application. In other words, your AU Cocoa GUI code probably won't work if you change even the slightest thing in the ObjC segment.

However, if all of your protection code is compiled into common methods like -init or +initialize, then hackers may not have any clues as to where to look, other than if they disassemble everything. But this does seem to rule out an ObjC-based protection library product, because that would just be like sending up flags saying "crack me!" Note that I have seen commercial licensing/ protection libraries that did just this, although I have no numbers on how often it failed.

On a related note, you could protect only the audio engine, which is generally C++, and I suppose you can strip symbols there to your heart's desire (my knowledge of C++ is thinner than my knowledge of ObjC, so apologies if I'm wrong and C++ needs its symbols at runtime, too). I think this approach would fit with the AU spec for handling protection or other licensing checks in ::Initialize(). In other words, you probably shouldn't be handling protection in your Cocoa UI anyway, except to display an alert somewhere in the UI where the user can see it. The problem here is that some audio-based licensing (periodic silence, noise bursts, etc.) is bad for demonstrating your plugin, but I think there is a clear distinction between how to disable a demo version versus how to disable a completely unlicensed version. I would think that it would be acceptable to go to complete silence for an unlicensed AU, but I could be wrong.

In any case, I think other people are already doing a good job of answering your question. I really only wanted to say that I think stripping ObjC symbols is probably a dead end.

Brian Willoughby
Sound Consulting

_______________________________________________
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


References: 
 >[Slightly OT] Copy protecting an AU (From: tahome izwah <email@hidden>)

  • Prev by Date: Re: [Slightly OT] Copy protecting an AU
  • Next by Date: Re: Coreaudio-api Digest, Vol 7, Issue 159
  • Previous by thread: Re: [Slightly OT] Copy protecting an AU
  • Next by thread: Re: Coreaudio-api Digest, Vol 7, Issue 159
  • Index(es):
    • Date
    • Thread