Re: Thwarting classdump, etc.
Re: Thwarting classdump, etc.
- Subject: Re: Thwarting classdump, etc.
- From: Dave Hersey <email@hidden>
- Date: Wed, 29 Jun 2005 16:40:30 -0400
On 6/29/05 12:53 AM, "email@hidden" <email@hidden> wrote:
>> Thanks. I thought there were also ways with Objective C to register classes
>> at runtime, so that there was basically nothing useful to dump otherwise.
>> That's what I was originally looking for. Is anyone doing that?
>
> Yes, you can define new classes at runtime using, say, C/C++
> functions. But it's not a trivial thing to do, and as others have
> said it's still dead easy for anyone to look at your classes while
> your program is running.
>
> If you explain why it is you want to do this, perhaps an alternative
> method can be suggested.
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
_______________________________________________
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