Re: Strip -- and hack/crack security
Re: Strip -- and hack/crack security
- Subject: Re: Strip -- and hack/crack security
- From: "Andy O'Meara" <email@hidden>
- Date: Mon, 06 Feb 2006 17:57:26 -0500
- Thread-topic: Strip -- and hack/crack security
While we¹re talking about stripping, let¹s talk about hacking/cracking
security....
Can anyone confirm that there¹s no further stripping (or symbol removal)
such that hacking/cracking is deterred to the most extent possible? Our
software has had a lot of success with our various layers of internal
hack/crack detection (eg, checksums on strings and consts at runtime), and
CodeWarrior was good for doing pretty hard-core stripping that gave me a
nice warm fuzzy (namely, exhaustive symbol/name stripping and iterative dead
code stripping).
For the folks here that make end-user software that think that their pirate
userbase is an insignificant number, think again. Try googling for your
software title, ³crack² or ³serial² and sit back. Sure, there¹s lot of red
herrings out there just out to deliver malware payload, but you¹ll be
surprised how great of lengths the pirate/hacker/cracker community will go
to. And if you¹re still not convinced, fire up eDonkey2000, wait an hour
for it to settle in and then search for your software. Granted, if your
software is something a typical pirate/kid is not going to use, then you
don¹t have much to worry about (and you can consider yourself fortunate).
Anyway, the status of our software is that we¹re about to enter beta testing
for our Universal binary (we still only currently ship a ppc binary built by
CodeWarrior). I¹d love to hear from a couple heavy hitters here if there¹s
any other stripping or binary post-processing that can be done so that Joe
Cracker has the hardest time possible doing a stacktrace, etc.
One feature of CW that¹s missing from gcc/ld that I do have some strong
concerns about is smart dead code stripping. Suppose you app uses some
homebrew encryption stuff (but only uses the decrypt stuff):
// main.cpp
void myDecryptProc( ... );
void myEncryptProc( ... );
void main() {
...
myDecryptProc( ... );
...
}
// my_crypt_utils.cpp
void myDecryptProc( ... ) {
...
}
void myEncryptProc( ... ) {
...
}
CodeWarrior's linker was smart enough to strip myEncryptProc() completely
from the binary, but if you compile the above and remove the myEncryptProc()
definition in Xcode, ld complains that its undefined (so I'm pretty sure
that ld is dumb enough to put myEncryptProc's definition into the binary).
In other words, if I let ld include myEncryptProc's definition in the binary
I ship, then any cracker worth his salt can trivially extract the binary for
myEncryptProc() and put it in a shiny new utility or serial gen.
This is why I've been frustrated at gcc/ld's lack of smart link
support--it's a severe piracy/crack liability.
Thanks in advance,
Andy
On 2/6/06 5:00 PM, "Bryan Pietrzak" <email@hidden> wrote:
> I find some of the "relevant" project settings a bit confusing.
>
> Goal:
>
> - I want my deployment app to be small (not 166 MB like it is now, more like
> the 6 MB it was with CodeWarrior).
> - I want crash logs to have symbols to aid in debugging crash reports from
> users
>
> So I search for strip (XCode 2.2) and see a bunch of options and some seem
> almost to conflict with each other.
>
> I'm curious if what I am doing is correct...
>
> Dead Code Stripping. I have this checked ON (* see below regarding gfull)
> Don't Dead-strip inits and terms. OFF. Is that ok? Wouldn't I want them
> stripped if not used anywhere else?
> Deployment Postprocessing. ON
> Strip Linked Product. ON
> Use Separate Strip. OFF
> Strip Style. Debugging symbols.
> Additional Strip Flags. <<blank>
> Strip Debug Symbols During Copy. ON
> UNSTRIPPED_PRODUCT. Set to NO
>
> Since Dead Code Striping says to be sure to use gfull, I search for gfull and
> find...
>
> Level of Debug Symbols. I change it to All Symbols (gfull) as instructed.
>
> And my binary is still 166 MB. What am i doing wrong?
>
>
> edit... Hmm, I just did a clean build and now it's 9.5 MB. So that's good. But
> I'd like confirmation that what I've done above is correct :)
>
> Bryan
>
>
>
> On Sep 29, 2005, at 12:07 PM, Chris Espinosa wrote:
>
>> On Sep 29, 2005, at 1:48 AM, Gerriet M. Denkmann wrote:
>>
>>> How can I induce Xcode (2.0) to automatically strip the result of a
>>> Deployment build?
>>>
>>
>> Check the "Deployment Postprocessing" and "Strip Linked Product" checkboxes
>> in the target's Deployment configuration, and make sure
>>
>> http://developer.apple.com/releasenotes/DeveloperTools/Xcode/XcodeBuildSettin
>> gs.html
>>
>> * DEPLOYMENT_POSTPROCESSING
>> * If this setting is turned on, then the product will be processed for
>> deployment and release purposes rather than for development and debugging
>> purposes. As a result, the following operations will be performed on the
>> built product:
>>> * If STRIP_INSTALLED_PRODUCT is YES, then the produced binary will be
>>> stripped.
>>> * Copy Files and Shell Script build phases set to ³only run when installing²
>>> will be processed.
>>> * The owner, group and mode of the produced files will be changed according
>>> to the relevant build settings.
>> * When performing an xcodebuild using the install build action, this setting
>> will be set to YES for the duration of the build.
>> In general, you can do the following to answer such questions:
>>
>> 1) Choose "Edit Active Target" from the Project menu
>> 2) Choose "All Configurations" and "All Settings from the popups in the Build
>> tab
>> 3) Enter a keyword, such as "strip", into the search bubble
>>
>> All relevant project settings will be shown. If you select one, the
>> explanatory text at the bottom of the inspector describes what the setting
>> does. This is a pretty good way to figure out answers like this.
>
>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Xcode-users mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
| References: | |
| | >Re: Strip (From: Bryan Pietrzak <email@hidden>) |