Visual guide to understanding garbage collection algorithms!
Design Patterns: Elements of Reusable Object-Oriented Software is a software engineering book describing recurring solutions to common problems in software design. The book’s authors are Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides with a foreword by Grady Booch. The book is divided into two parts, with the first two chapters exploring the capabilities and pitfalls of object-oriented programming, and the remaining chapters describing 23 classic software design patterns. The book includes examples in C++ and Smalltalk.
Amazon Link for the book: http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented-ebook/dp/B000SEIBB8
I’ve been reading about OO (and non-OO) design patterns, and have found the “Gang of Four” Design Patterns book referenced again and again in my readings. I’ve found some websites that have implemented these patterns (with source) in Delphi / Object-Pascal, which is my preferred native OO language:
I look this up about every couple weeks, so I’m posting it here for posterity. In order to nicely format Data::Dumper output…
I almost always set
$Data::Dumper::Indent = 1; $Data::Dumper::Sortkeys = 1;
Data::Dumper. The first statement makes the output more compact and much more readable when your data structure is several levels deep. The second statement makes it easier to scan the output and quickly find the keys you are most interested in.
If the data structure contains binary data or embedded tabs/newlines, also consider
$Data::Dumper::Useqq = 1;
which will output a suitable readable representation for that data.
Much more in the perldoc.
x64_dbg is a very powerful open-source 32 and 64-bit assembler/debugger for Windows. The UI is reminiscent of OllyDbg with some additions that are clearly inspired by IDA Pro.
I’m looking forward to using this tool in place of OllyDbg, especially for 64-bit related RE tasks.
iSecPartners has released on GitHub a “cheat-sheet” for auditing high-value applications. It’s well worth a read.
This list is intended to be a list of additional or more technical things to look for when auditing extremely high value applications. The applications may involve operational security for involved actors (such as law enforcement research), extremely valuable transactions (such as a Stock Trading Application), societal issues that could open users to physical harassment (such as a Gay Dating Application), or technologies designed to be used by journalists operating inside repressive countries.
It is an advanced list – meaning entry level issues such as application logic bypasses, common web vulnerabilities such as XSS and SQLi, or lower level vulnerabilities such as memory corruption are explicitly not covered. It is assumed that the reader is aware of these and similar vulnerabilities and is well trained in their search, exploitation, and remediation.
A good example of the type of analysis to strive for can be shown in Jacob Appelbaum’s analysis of UltraSurf:https://media.torproject.org/misc/2012-04-16-ultrasurf-analysis.pdf
From Trail of Bits, they are offering a free online CTF and penetration testing course. Lots of great material from a well respected organization.
Chromium engineers have provided excellent clarification on compatibility issues between Google Chrome v35+ and EMET 4.1
The specific issue we have encountered with Chromium compiled using VS 2013 relates to tail-call optimizations in wrapper functions for Windows APIs. By using jmp to enter the Windows API call from the wrapper, the Visual Studio compiler avoids an additional call/ret pair, and the API would return directly into the wrapper function’s caller rather than the wrapper function itself.
However, EMET protects various ‘critical’ Windows APIs against an exploit technique known as Return-Oriented Programming (ROP), and one of these protections is incompatible with tail-call optimization. EMET’s code checks that the return address from the API call is immediately preceded by a call to that API, since in ROP exploits this will typically not be the case but in normal function calls it will.
The tail-call optimization violates EMET’s assumption and causes a false positive result for exploit detection.
The Chrome security team does not generally recommend the use of EMET with Chromium because it has negative performance impact and adds little security benefit in most situations. The most effective anti-exploit techniques that EMET provides are already built into Chromium or superseded by stronger mitigations.