Private Frameworks

  • Hi,

    This is probably a stupid beginner question to ask. I am interested in
    writing a framework for some of my code to use between my various
    applications, but I'd like the framework to be private, so other
    developers cannot use it. (For now at least)

    Is there any way to do this besides embedding the code directly into my app?

    Thank you
  • Assuming you're building your framework as part of the same project as
    your actual app, you can simply mark the role of the framework's
    header files as private, and #import them in your app's source using
    relative quoted paths like #import "FrameworkHeaderFile.h", rather
    than the typical #import <FrameworkName/HeaderFile.h> paradigm.

    You're still going to need to link the app to the framework and copy
    the framework into the app bundle's Frameworks directory, but this way
    you won't be copying the headers with it.

    HTH,
    --Kyle Sluder
  • Kyle Sluder wrote:

    > Assuming you're building your framework as part of the same project as
    > your actual app, you can simply mark the role of the framework's
    > header files as private, and #import them in your app's source using
    > relative quoted paths like #import "FrameworkHeaderFile.h", rather
    > than the typical #import <FrameworkName/HeaderFile.h> paradigm.
    >
    > You're still going to need to link the app to the framework and copy
    > the framework into the app bundle's Frameworks directory, but this way
    > you won't be copying the headers with it.

    Note that if your framework contains Objective-C classes, there is
    nothing stopping interested parties from using class-dump (http://www.codethecode.com/projects/class-dump/
    ) to access the class information. In that case, headers help, but are
    not necessary...

    Philippe
  • Am 13.01.2008 um 16:19 schrieb Philippe Casgrain:

    > Kyle Sluder wrote:
    >
    >> Assuming you're building your framework as part of the same project
    >> as
    >> your actual app, you can simply mark the role of the framework's
    >> header files as private, and #import them in your app's source using
    >> relative quoted paths like #import "FrameworkHeaderFile.h", rather
    >> than the typical #import <FrameworkName/HeaderFile.h> paradigm.
    >>
    >> You're still going to need to link the app to the framework and copy
    >> the framework into the app bundle's Frameworks directory, but this
    >> way
    >> you won't be copying the headers with it.
    >
    > Note that if your framework contains Objective-C classes, there is
    > nothing stopping interested parties from using class-dump (http://www.codethecode.com/projects/class-dump/
    > ) to access the class information. In that case, headers help, but
    > are not necessary...

    To protect code at least a bit, you might wish to write C-Code, which
    discloses fewer
    details.
  • On Jan 13, 2008 10:57 AM, Stefan <seaside.ki...> wrote:
    > To protect code at least a bit, you might wish to write C-Code, which
    > discloses fewer
    > details.

    I would consider it a bad engineering decision (to put it mildly) to
    choose a language based on the virtually nonexistent impedance it may
    place on someone's desire to reverse-engineer the library.  If someone
    wants to disassemble your code and figure out what it does, they will,
    regardless of what language you choose.  Choosing C over Objective-C
    gives no advantage in this regard, while sacrificing everything it
    offers.

    --Kyle Sluder
  • Honestly, I can't say I fully agree---having full symbol information for
    every method/function in a program makes reverse-engineering much, much
    simpler.

    However, if it is important to you, you can get a lot of mileage out of
    strategic #defines to rename your classes, methods and categories to
    meaningless names. Obviously you can't do this if you are implementing
    delegate methods or subclassing built-in methods, but you can still
    obscure your tracks relatively well. e.g. imagine a header, included
    everywhere, that did:

    #define MyBigClass _1
    #define MyOtherClass _2
    #define updateMyObject _3
    #define withSomeOtherValue _4
    #define myInfo a0
    #define setMyInfo setA0
    #define otherInfo a1
    #define setOtherInfo setA1

    etc.
    I've never actually done this in ObjC but I've done it with C and had
    good results. I guess the biggest constraint is that you have to still
    honor KVO/KVC naming conventions, etc., so you'll still need "set" in
    front of some names.

    Kyle Sluder wrote:
    > On Jan 13, 2008 10:57 AM, Stefan <seaside.ki...> wrote:
    >
    >> To protect code at least a bit, you might wish to write C-Code, which
    >> discloses fewer
    >> details.
    >>
    >
    > I would consider it a bad engineering decision (to put it mildly) to
    > choose a language based on the virtually nonexistent impedance it may
    > place on someone's desire to reverse-engineer the library.  If someone
    > wants to disassemble your code and figure out what it does, they will,
    > regardless of what language you choose.  Choosing C over Objective-C
    > gives no advantage in this regard, while sacrificing everything it
    > offers.
    >
    > --Kyle Sluder
    >
  • On Jan 13, 2008, at 3:18 PM, John Stiles wrote:

    > Honestly, I can't say I fully agree---having full symbol information
    > for every method/function in a program makes reverse-engineering
    > much, much simpler.
    >
    > However, if it is important to you, you can get a lot of mileage out
    > of strategic #defines to rename your classes, methods and categories
    > to meaningless names. Obviously you can't do this if you are
    > implementing delegate methods or subclassing built-in methods, but
    > you can still obscure your tracks relatively well. e.g. imagine a
    > header, included everywhere, that did:
    >
    > #define MyBigClass _1
    > #define MyOtherClass _2
    > #define updateMyObject _3
    > #define withSomeOtherValue _4
    > #define myInfo a0
    > #define setMyInfo setA0
    > #define otherInfo a1
    > #define setOtherInfo setA1
    >
    > etc.
    > I've never actually done this in ObjC but I've done it with C and
    > had good results. I guess the biggest constraint is that you have to
    > still honor KVO/KVC naming conventions, etc., so you'll still need
    > "set" in front of some names.
    >

    Actually the biggest constraint is that this approach will break your
    nibs, since they refer to the "plain" names (rather than the symbol
    processed names).

    In theory, this could be done at link time (or shortly afterwards),
    since all of these class symbols and selectors end up being an entry
    in the string table.  It seems definitely possible to write a tool to
    find these strings (by walking all the object-c runtime info in the
    executable) and obscure them (so long as your app and frameworks
    obscure the strings the same way, because that's how your app
    ultimately refers to classes in your framework).

    Of course, this would also then need to go into your NIBs and do the
    same thing.  You'd also need a list of things that correspond to other
    external frameworks (which is fairly straightforward to obtain) to
    make sure that you don't obscure selectors like "release" or any of
    the various delegate methods that would be called from the framework.

    There are also cases of "synthesized" selectors that you'd need to
    check for (for example, one pattern of handling validation is to
    prefix the selector with "validate" or "can" and call that method, so
    "doSomething:" becomes "validateDoSomething:").  With a decent set of
    patterns, you could handle these (as well as all the KVO/KVC
    requirements)

    Glenn Andreas                      <gandreas...>
      <http://www.gandreas.com/> wicked fun!
    quadrium | prime : build, mutate, evolve, animate : the next
    generation of fractal art
  • Honestly, unless you are going to obscure the contents of your nibs
    entirely, I am not sure I see a point in trying to hide the
    outlet/action names anyway. If they can open the nib and immediately see
    that the action for the "Register Now" button is really "runFoobar123",
    it's still a little too easy to actually deter anyone :)

    Now, if you're into playing mind games, you can always use setAction and
    setTarget in -awakeFromNib, after the fact, to /redirect/ the actions on
    your most sensitive buttons and controls (or just leave them unwired in
    the nib and always set the actions programmatically). But that's really
    up to you; I'm not sure if the benefit outweighs the extra effort on
    your part .

    glenn andreas wrote:
    >
    > On Jan 13, 2008, at 3:18 PM, John Stiles wrote:
    >
    >> Honestly, I can't say I fully agree---having full symbol information
    >> for every method/function in a program makes reverse-engineering
    >> much, much simpler.
    >>
    >> However, if it is important to you, you can get a lot of mileage out
    >> of strategic #defines to rename your classes, methods and categories
    >> to meaningless names. Obviously you can't do this if you are
    >> implementing delegate methods or subclassing built-in methods, but
    >> you can still obscure your tracks relatively well. e.g. imagine a
    >> header, included everywhere, that did:
    >>
    >> #define MyBigClass _1
    >> #define MyOtherClass _2
    >> #define updateMyObject _3
    >> #define withSomeOtherValue _4
    >> #define myInfo a0
    >> #define setMyInfo setA0
    >> #define otherInfo a1
    >> #define setOtherInfo setA1
    >>
    >> etc.
    >> I've never actually done this in ObjC but I've done it with C and had
    >> good results. I guess the biggest constraint is that you have to
    >> still honor KVO/KVC naming conventions, etc., so you'll still need
    >> "set" in front of some names.
    >>
    >
    > Actually the biggest constraint is that this approach will break your
    > nibs, since they refer to the "plain" names (rather than the symbol
    > processed names).
    >
    > In theory, this could be done at link time (or shortly afterwards),
    > since all of these class symbols and selectors end up being an entry
    > in the string table.  It seems definitely possible to write a tool to
    > find these strings (by walking all the object-c runtime info in the
    > executable) and obscure them (so long as your app and frameworks
    > obscure the strings the same way, because that's how your app
    > ultimately refers to classes in your framework).
    >
    > Of course, this would also then need to go into your NIBs and do the
    > same thing.  You'd also need a list of things that correspond to other
    > external frameworks (which is fairly straightforward to obtain) to
    > make sure that you don't obscure selectors like "release" or any of
    > the various delegate methods that would be called from the framework.
    >
    > There are also cases of "synthesized" selectors that you'd need to
    > check for (for example, one pattern of handling validation is to
    > prefix the selector with "validate" or "can" and call that method, so
    > "doSomething:" becomes "validateDoSomething:").  With a decent set of
    > patterns, you could handle these (as well as all the KVO/KVC
    > requirements)
    >
    >
    >
    > Glenn Andreas                      <gandreas...>
    > <http://www.gandreas.com/> wicked fun!
    > quadrium | prime : build, mutate, evolve, animate : the next
    > generation of fractal art
    >
    >
    >
  • On Jan 13, 2008, at 12:55 AM, Kyle Sluder wrote:

    > Assuming you're building your framework as part of the same project as
    > your actual app, you can simply mark the role of the framework's
    > header files as private, and #import them in your app's source using
    > relative quoted paths like #import "FrameworkHeaderFile.h", rather
    > than the typical #import <FrameworkName/HeaderFile.h> paradigm.

    That's not what the "private" header role is for.  It just determines
    whether, when building a framework, a header is left in the project,
    copied into a framework's PrivateHeaders directory, or copied into a
    framework's Headers directory.

    It doesn't change at all how you import the header.  Specifically,
    *headers that are part of frameworks should always be imported using
    framework notation*.

    Let's say I have a framework Foo where I implement a class Bar.
    Initially Bar is entirely internal to the framework (Bar.h has a
    header role of "project") so I always refer to it as "Bar.h" in
    #import directives.  Then I want to make Bar available to my own apps
    that use this framework, so I change its header role to "private".  At
    the same time I do this, I will *fix up* all references to "Bar.h" to
    actually use <Foo/Bar.h> so it's always used consistency.

    If I want to ship my app with my framework embedded, after the Copy
    Files build phase that embeds it, I'll just have a Run Shell Script
    build phase that deletes all PrivateHeaders directories.

    > You're still going to need to link the app to the framework and copy
    > the framework into the app bundle's Frameworks directory, but this way
    > you won't be copying the headers with it.

    Private headers are still copied, just to a different directory.  You
    can reference them just like public headers, but they're easy to strip
    out after building when you don't want to publish them outside (say)
    your team.

      -- Chris
  • On Sun, January 13, 2008 16:18, John Stiles wrote:
    > Honestly, I can't say I fully agree---having full symbol information for
    > every method/function in a program makes reverse-engineering much, much
    > simpler.
    >

    NEWS FLASH: no one gives a damn about other peoples code (statistically
    speaking).  I wonder at all these companies and developers who are so
    concerned someone might want to look at their code.  Get over yourselves.
    Your code isn't that interesting, and isn't that good!

    As others have pointed out, if someone really, really wants to crack it,
    they will.  Just look at the iPhone.
  • Typically if someone wants to obscure code, I've found that it's the
    part of the code that is responsible for distinguishing the paying
    users from the demo users. (e.g. shareware registrations, or product
    registration keys, or checking the network to see if other copies of
    the same app are active with the same license key).

    In my experience, this portion of your code will in fact be analyzed
    by someone, and it is in your best interest to make it obscure.

    For other portions of your app, I tend to agree that no one cares.
    Unless money is involved somehow :)

    On Jan 14, 2008, at 4:08 PM, Timothy Reaves wrote:

    > On Sun, January 13, 2008 16:18, John Stiles wrote:
    >> Honestly, I can't say I fully agree---having full symbol
    >> information for
    >> every method/function in a program makes reverse-engineering much,
    >> much
    >> simpler.
    >>
    >
    > NEWS FLASH: no one gives a damn about other peoples code
    > (statistically
    > speaking).  I wonder at all these companies and developers who are so
    > concerned someone might want to look at their code.  Get over
    > yourselves.
    > Your code isn't that interesting, and isn't that good!
    >
    > As others have pointed out, if someone really, really wants to
    > crack it,
    > they will.  Just look at the iPhone.
  • On 15 Jan 2008, at 04:32, Kyle Sluder wrote:

    > On Jan 14, 2008 7:23 PM, John Stiles <JStiles...> wrote:
    >> Typically if someone wants to obscure code, I've found that it's the
    >> part of the code that is responsible for distinguishing the paying
    >> users from the demo users. (e.g. shareware registrations, or product
    >> registration keys, or checking the network to see if other copies of
    >> the same app are active with the same license key).
    >>
    >
    > Obfuscation will never secure your copy protection/licensing code.

    On the contrary, it is the *only* way on current hardware to secure
    your copy protection and/or licensing code.  Without obfuscation, your
    copy protection/licensing code will only hinder casual piracy, and
    only to the extent that casual pirates choose not to frequent piracy
    websites offering cracks.  I put it to you that such websites are in
    practice quite popular...

    > It will only present a fun challenge to anyone who wants to crack it.

    The goal with obfuscation is to make the challenge too hard to be fun,
    which is well within the bounds of possibility.

    Anyway, John Stiles' suggestion of using #define is probably the best
    bet if preventing others from linking (easily) is the desired goal.
    It may well be, though, that simply not including the headers is
    enough to discourage linking with the framework; it really depends on
    what the framework is for.

    On 15 Jan 2008, at 00:08, Timothy Reaves wrote:

    > NEWS FLASH: no one gives a damn about other peoples code
    > (statistically
    > speaking).  I wonder at all these companies and developers who are so
    > concerned someone might want to look at their code.  Get over
    > yourselves.
    > Your code isn't that interesting, and isn't that good!

    The important part of your remark is the "statistically speaking"
    bit.  On the average, what you say is true.  However, there are very
    real situations where some code may have considerable commercial
    value.  People *have* stolen code in the past (e.g. remember Microsoft
    and Stacker), and if there is enough money involved they will
    doubtless continue to do so in the future.

    Also, as John Stiles' rightly says, some people take a pretty
    unhealthy interest in copy protection code.

    Kind regards,

    Alastair.

    --
    http://alastairs-place.net
previous month january 2008 next month
MTWTFSS
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31      
Go to today