Je kan informatie over je locatie aan je Tweets toevoegen, bijvoorbeeld je stad of exacte locatie, via het web en applicaties van derden. Je kan altijd de locatiegeschiedenis van je Tweets verwijderen. Meer informatie
Otherwise, in some sense, the audience has to be an RE to understand the explanation. Then, why do they need the RE to begin with? If an RE can tear apart the most complex, obfuscated malware, but can’t make its operation understandable then that RE is just a puzzle solver. (2/3)
There aren’t a whole lot of us, so we can’t expect the folks who read or listen to our output to understand in the way we do. Frankly, it’s the most challenging part of this gig and why cons like @reconmtl are so nice. You can remove the filter and be with your own kind (3/3)pic.twitter.com/UNxpdYrHHl
it helps to follow the Alexiou Principle http://thedigitalstandard.blogspot.com/2009/06/alexiou-principle.html … 1. What question are you trying to answer? 2. What data do you need to answer that question? 3. How do you extract that data? 4. What does that data tell you? i.e. IMHO client's Qs drive the RE, not the analyst
Definitely agree. There's an added benefit. Keeping the client's Q in mind can also be more efficient because you know what patterns to look for. Like if the client wants to understand the C2 capabilities, then look for functions with a large decision tree and a nearby recv, etc.
I think the easiest part of RE is you don’t need to know lot of programing language but the hardest is you must understan the code deeply
I’d argue that for higher level languages like C++/Go or complicated programs, understanding built-in language data structures (or program structures generally) becomes important. PL understanding helps you get to that deep understanding more readily.
Agreed. Especially with OO languages like C++ or obj-c you will be lost with anything complicated if you don’t understand how structures and constructs of the language translate into assembly
And doing RE these days have been more fulfilling after I've learned so much from tackling other stuff, not just assembly. Somehow, analyzing other languages (JS, etc.) helped me become faster and more efficient in translating code into high-level information.
I've transitioned (several years ago) from just PE malware RE into also doing analysis of non-PE. I've learned so much since, and never regretted the move. What I love about it is that they're all complementary w/ each other, which in the end produces better reports.
I include sections in my reports: executive summary, deep technical for RE folks, parseable IOC section for Intel folks, and so on... This was based on my experience doing Pentests earlier, because you never know who will read reports and it should be tailored to cover the most.
#BlueTeam reporting: RE folks are one of the keys to Our success. The deep in the weeds stuff you can extract from the freaking bowels of obfuscated code & to do that translation into usable intelligence, is amazing. We rely on you folks 
Twitter is mogelijk overbelast of ondervindt een tijdelijke onderbreking. Probeer het opnieuw of bekijk de Twitter-status voor meer informatie.
