• 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: Cocoa-dev Digest, Vol 2, Issue 1006
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Cocoa-dev Digest, Vol 2, Issue 1006


  • Subject: Re: Cocoa-dev Digest, Vol 2, Issue 1006
  • From: "Dan S. Camper" <email@hidden>
  • Date: Wed, 29 Jun 2005 17:52:38 -0500

On 6/29/05 12:53 AM, "email@hidden" <email@hidden> wrote:

> Hi Wade,
>
> Thanks for the reply. It was a general question about keeping inner workings
> of an application as private as possible. I realize that someone can
> disassembly a binary, but that's different from running classdump and
> seeingMyVeryExplicitMethodNames and class structure.
>
> I'm concerned that someone who's looked into this more than I have could get
> into my code chain somehow by changing classes that my code relies on, maybe
> by modifying frameworks or something. In that case, even checking my code
> for modification won't help, since the modifications could be made outside
> of my app.
>
> Basically, as much as possible, I need to keep someone from circumventing my
> code or learning too much about how it's doing what it's doing (which leads
> back to circumventing the code). Being able to see the class descriptions is
> like leaving debug symbols in your code, only worse since you're exposing
> dependencies.
>
> This isn't just paranoia--I have a project in mind that needs a very high
> level of protection against anyone "rewiring" some user code that interacts
> with a kext. And, there *are* illicit reasons why they'd want to. As much as
> I'd like to write it in Cocoa, I'm really wondering if that makes the most
> sense because of security issues.
>
> Thanks,
>
> - Dave

Dave,

FWIW, I've explored this possibility to a certain (limited) degree.  We have
a shareware product that people were cracking via an InputManager hack --
bypassing the license checks with posed classes.  Apparently $10 is a little
too steep a price for some.

Anyway, while we couldn't prevent people from injecting posed classes we did
figure out a way to detect it.  It starts with a macro:

#import <objc/objc-class.h>

#define  IS_POSED(x)
     ((((struct objc_class*)NSClassFromString(x))->info & CLS_POSING) ==
     CLS_POSING ? YES : NO)

Then adding this to our license check call:

if (!IS_POSED([self className]) && [self licenseIsJustFineCheck]) ....

let us detect whether or not the class has been overridden with a posed
class.  (BTW, before anyone points out the class->className->class
conversion, this is a slightly contrived example.)  This is just a specific
application of the test, but you may be able to use something like this in
conjunction with other tests to try to validate your app.

DSC

_________________________________________________________________________
Dan S. Camper                                         Borrowed Time, Inc.
Software Thaumaturge                                   http://www.bti.net


 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

  • Prev by Date: NSBitmapImageRep: RGB-data (565 mode)
  • Next by Date: subclass of NSSlider won't call action method
  • Previous by thread: Re: NSBitmapImageRep: RGB-data (565 mode)
  • Next by thread: subclass of NSSlider won't call action method
  • Index(es):
    • Date
    • Thread