Update drillresults.py #3
Conversation
|
Thanks for the fix. I'm in the process of getting our more recent code pushed out here (procedural stuff, not technical), should be days not weeks until that happens -- once that's done we can revisit this request. |
|
|
||
| try: | ||
| crashid['exceptions'][exceptionnum]['pcmodule'] = pc_in_mapped_address(reporttext, instraddr) | ||
| except: |
There was a problem hiding this comment.
This shouldn't catch all exceptions, it should be more specific.
Also, it's not clear whether the core problem is here or in the pc_in_mapped_address() function.
|
So I just updated the develop branch this morning -- the code in there is about 2 years newer than the stuff in the master branch. We've made a lot of changes including a significant refactoring of drillresults into an analyzer that runs inline during a campaign. The line in question has moved to certfuzz.analyzers.drillresults.testcasebundle_base line 159: But it's not clear from your description what exception you're catching. Is it something thrown from within pc_in_mapped_address or maybe a keyerror on self.details? (If the latter, which key is missing?) Most of that might not matter given the below: At the moment, the msec file you put in Issue #2 no longer appears to cause a crash. (The new code fails to recognize the faulting address and returns gracefully.) As a result I'm going to close this one out since the crashing behavior is no longer an issue. However it's just skipping over that case as not interesting (when in fact it is, since it's an AV on EIP). I'll create a separate issue to track the fact that drillresults' logic is missing the interestingness of this case. That's a distinct issue from the crashing behavior. |
I found a small bug in drillresults.py which will cause it to crash if certain crash reports are read. (See Issue #2 )
I've implemented a small "Try / Except" patch which will allow the script to continue on and which will print out the offending crash report so it can be removed manually.