tag:blogger.com,1999:blog-1835624775440216518.post3144523887097507781..comments2024-03-20T08:48:44.977-04:00Comments on Neil's Computer Blog: Heap Debugging TricksNeil Sikkahttp://www.blogger.com/profile/09709856046012286983noreply@blogger.comBlogger3125tag:blogger.com,1999:blog-1835624775440216518.post-35315541567261575512015-02-03T19:16:42.219-05:002015-02-03T19:16:42.219-05:00Many of the magazines provide great working opport...Many of the magazines provide great working opportunity to the writers of various different levels. Also to other people connected with that media.essay papershttp://superior-essay-paper.com/noreply@blogger.comtag:blogger.com,1999:blog-1835624775440216518.post-4197378972523146062013-11-22T02:38:28.844-05:002013-11-22T02:38:28.844-05:00@an_animal asks:
@neilsikka can you explain in mo...@an_animal asks:<br /><br />@neilsikka can you explain in more details the last 2 commands for windbg breakpoints? thanks!<br /><br />Caller Based Conditional Breakpoint:<br />Only break at a certain instruction if this instruction is executed AND another specified function is on the call stack. For example, if funcA and funcB call funcC, this breakpoint allows the user to break in funcC only if funcC was directly/indirectly called by funcA. This is useful if funcB calls funcC 100,000,000 times and funcA calls funcC 1 time, and funcC is only of interest when it is called directly/indirectly by funcA. Instead of dealing with the breakpoint in funcC being hit 100,000,000 times, this type of breakpoint only breaks 1 time. This is an often scenario when breaking in constructors/destructors when analyzing Use After Free vulnerabilities.<br /><br />Register Watching Breakpoint:<br />In this scenario, breakpoints are usually useful on entering a destructor or exiting a constructor because in both cases, it is very likely for the Use After Freed object to be pointed to by one of the registers. Every time the breakpoint is hit, print the CPU registers with the 'r' command, and automatically continue execution. If there is too much output, log windbg output to a file. At crash time, the offending memory dereference will be displayed in the Access Violation message. Go through the log and search for this address, and it should be in one of the registers on entry/exit of the destructor/constructor. The number of times this breakpoint was hit before the offending object was destroyed/allocated should be constant across multiple runs (assuming the program crashes the same way every time). The next time the program is run, it is known how many times the breakpoint has to be hit before it destroys/constructs the offending object, allowing the analyst to predict and get a live debugging session with the object being freed/allocated in real time.Neil Sikkahttps://www.blogger.com/profile/09709856046012286983noreply@blogger.comtag:blogger.com,1999:blog-1835624775440216518.post-55202318531293212332013-07-31T12:41:06.521-04:002013-07-31T12:41:06.521-04:00very useful one as lot of use after free these day...very useful one as lot of use after free these days.abhijit mohantahttps://www.blogger.com/profile/15468578612316161510noreply@blogger.com