Re: Thwarting classdump, etc.
Re: Thwarting classdump, etc.
- Subject: Re: Thwarting classdump, etc.
- From: Bob Ippolito <email@hidden>
- Date: Wed, 29 Jun 2005 16:23:03 -1000
On Jun 29, 2005, at 11:01 AM, Annard Brouwer wrote:
On 29 Jun 2005, at 22:40, Dave Hersey wrote:
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.
Regardless of what language it's written in, people will be able to
look at how your app talks to the kext. They could write another
kext, hook into the app, run it under an ICE, etc. Trying to make
this harder is a lost cause. It could even backfire, if the
"protection" looks interesting enough, someone might break it just to
see how it was done, and of course they'd have to share their findings.
If your project would really attract the wrong people to "break in"
your code, there's nothing you can do about it. Other than doing a
sophisticated checksum over the binaries and hide that value in
multiple places in your code somewhere to see if it has been
tampered with. Determined people will get into your code no matter
what. Since the system is able to run it, they can do it. There
were many heated discussions about this in the Java camp. But also
look at games and other programs that try to prevent people from
cracking it (in vain).
In one project we chose to do the "sensitive work" in C and the
rest in Java. If you choose to use this hybrid route that may be
the best trade-off...
That sounds silly, the mindshare that C has among people with reverse
engineering experience probably makes C code MORE likely to be picked
apart, not less.
-bob
_______________________________________________
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