Simple reversing tip: If you're doing static-reversing, first thing you should __always__ do to help slice out things of relevance is to run a hit-trace (coverage) so you know what code is actually relevant, and what code does __not__ get exercised. It's worth considering analyzing the code that doesn't get exercised. Also, don't be allergic to writing code... Simple things like storing your results in a set and augmenting your function notations or coloring your addresses is such a low-effort power. Think of it like this, how can you quickly find the code that's responsible for parsing input from a socket without having to do any reversing? Collect a set of all of the functions that are executed. That's set #1. Now connect to socket and send some data a couple of times, set2 (or set3 or set4). After union'ing your second set of sets, diff the results from set1. Now you know where the parser starts. There's embedded languages in all debuggers and disassemblers, make sure you use them because you get them for free.
Thank you so much for this. My day to day work is unrelated to cybersec, but all of your mindset tips are very relevant. So thanks, not just for the advice wrt technical approach, but also for the more general approach toward technical tasks that involve a lot of demoralising failure. I'm still developing my cybersec workflows, so I'm also getting a lot out of the technical side too
This is really useful. often these kind of talks and wisdom are missed in other offensive security talks.
Simple reversing tip: If you're doing static-reversing, first thing you should __always__ do to help slice out things of relevance is to run a hit-trace (coverage) so you know what code is actually relevant, and what code does __not__ get exercised. It's worth considering analyzing the code that doesn't get exercised.
Also, don't be allergic to writing code... Simple things like storing your results in a set and augmenting your function notations or coloring your addresses is such a low-effort power. Think of it like this, how can you quickly find the code that's responsible for parsing input from a socket without having to do any reversing? Collect a set of all of the functions that are executed. That's set #1. Now connect to socket and send some data a couple of times, set2 (or set3 or set4). After union'ing your second set of sets, diff the results from set1. Now you know where the parser starts. There's embedded languages in all debuggers and disassemblers, make sure you use them because you get them for free.
Thank you so much for this. My day to day work is unrelated to cybersec, but all of your mindset tips are very relevant. So thanks, not just for the advice wrt technical approach, but also for the more general approach toward technical tasks that involve a lot of demoralising failure. I'm still developing my cybersec workflows, so I'm also getting a lot out of the technical side too