Re: Crash reporter starting stack trace
Re: Crash reporter starting stack trace
- Subject: Re: Crash reporter starting stack trace
- From: Arnab Ganguly <email@hidden>
- Date: Sun, 18 Oct 2009 17:09:48 +0530
Hi All,
Sorry to bother you again. It would be nice if you can clarify this.
See how this is different from PowerPC ? In case of PowerPC I am able to see system framework symbols are getting resolved correctly and the mechanism we follow is passing the address from the client to server where server contains the binary loaded with symbols and it is resolved. Is that ASLR was not there in case of PowerPC and it came to 10.5 Mac OS X for which somehow the mapping was working correctly on the address ?
Also how does ASLR is enabled from Xcode ?
Very much appreciated for all help.
Thanks in advance.
-A
On Thu, Oct 8, 2009 at 5:59 PM, Arnab Ganguly
<email@hidden> wrote:
Hi All,
Thanks for all your inputs.I have checked the Xcode project settings.But there generate Position Dependent Code is unchecked.Is there anything else do I need to check ?
My further observation looks like the system dynamic libraries, system frameworks names are coming incorrect but the frameworks developed by us names comes correctly.
Any inputs would be very much appreciated.
-A
On Oct 6, 2009, at 10:25 AM, Arnab Ganguly <email@hidden> wrote:
Hi All,
Some inputs required. When an application crashes, what is the
starting stack address Crashreporter gets as?
Whatever is in the %esp/%rbp within the thread state struucture for
each thread at the time the mach crash exception is thrown.
We developed a similar crash app but when we compare the stack trace
with the Crashreporter's there is a mismatch with initial stack
addresses but after some traces it matches. Specially the traces
very much internal to the system dynamic libraries doesn't
match.Addresses related to Application it matches.
Any inputs or pointers would be great help.
I told you this before...
That's because libraries are loaded at different locations on
different machines and you still are not taking this into account with
your crash report architecture, where you send the data back to your
server for symbolication. Unless you save off specific task address
space mapping locations for each, as part of the information you send
back to your server, then your server will have different base
addresses for the libraries and frameworks and therefore be unable to
decode them properly.
PS: It works for your main app only because you have not enabled ASLR
for your app; if it is a network client or server, your app is likely
vulnerable to buffer overflow and other attacks based on the fixed
location of your code. Such an attack would work cookie-cutter fashion
everywhere your software is deployed. By varying the address where
it's loaded, you make it so an attack that works against one machine
won't (statistically speaking) work against others. Admittedly,
varying the location where system libraries are loaded is only
protection if your app doesn't always load a vtable pointing at
framework entry points into the same location on every machine, so
that the same call sites exist everywhere (it kind of defeats the
purpose if you do that in fact).
-- Terry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden