π₯ #AdventOfReversing 1/24 π₯
Get dirty as soon as possible. Don't fall into thinking you are not ready. Sure, you will be confused by many things at first. That's fine! I used to confuse sections and segments when I started. Keep pushing, and things will become clear naturally.
π₯ #AdventOfReversing 2/24 π₯
Get used to (re)name *everything* in your disassembler. You might be able to mentally track data across registers and memory for small crackmes w/ easy control flow, but this does not scale at all. Unclutter your mind. Make your life easier.
π₯ #AdventOfReversing 3/24 π₯
You really want to have some programming foundations, but which languages? I mostly agree with this post by @MalwareTechBlog:
π Python
ποΈ C
βοΈ ASM (different flavors: x86(-64) desktop, ARM mobile...)
π₯ #AdventOfReversing 4/24 π₯
Learn to script on top of (at least one) dedicated #API's from your #RE tools, like @HexRaysSA's IDAPython or @radareorg's r2pipe. Being able to combine different functionalities and automating for custom analysis needs will really make a difference.
π₯ #AdventOfReversing 5/24 π₯
Make sure to review the calling conventions for the arch/platform you are dealing with. Yes, many RE tools can identify/label them, but it will make your life easier when quickly skimming through code routines or when in a constrained environment.
π₯ #AdventOfReversing 6/24 π₯
Get used to take notes ποΈ during your #reversing sessions. They are invaluable in many scenarios, for example:
- In a future, be able to catch up with previous work.
- Easily get others to help you.
- Use it as a draft for a work report/blog post.
π₯ #AdventOfReversing 7/24 π₯
My friend @joxeankoret once told me: "Obsession works quite better than books". I'm not suggesting to ditch mental health, and there are great books. But putting the hours in stuff you're deeply interested will boost your skills better than any book.
π₯ #AdventOfReversing 8/24 π₯
Don't get stuck on beginner stuff you feel comfortable with. Try new (hard) things that challenge your skills. Push your limits: go play w/ remote kernel debugging of Windows drivers, bang yourself against custom obfuscation, VMs, bizarre anti-RE...
π₯ #AdventOfReversing 9/24 π₯
Ask for help. It's normal and totally fine not to know everything. Talk to colleagues. Many tools have public discussion/support channels. But please, make sure to google first, be clear and concise. Be respectful w/ yourself and other people's time.
π₯ #AdventOfReversing 10/24 π₯
Don't cold read ASM line by line unless strictly necessary.
- Learn to recognize C-like constructs.
- Understand data and control flow through function calls, x-refs, use of OS APIs...
- Leverage graph views like call graphs and control-flow graphs.
π₯ #AdventOfReversing 11/24 π₯
Following up on yesterday's tip (and as @daeken pointed out recently as well): gather as much knowledge as possible w/o having to cold read ASM. Make educated guesses that guide you. These will get better w/ experience and save you tons on time.
@daeken π₯ #AdventOfReversing 12/24 π₯
Know your tools. Take your time to master *at least one* RE framework (IDA, r2/Cutter, Ghidra, Binja). It's cool (and I'd say advisable) to experiment, but you really want a comfort-zone toolbox, which might evolve through time, to get work done.
@daeken π₯ #AdventOfReversing 13/24 π₯
Decompilers are cool and extremely useful in many scenarios. But they are not bullet-proof, specially when a huge amount of obfuscation and anti-re techniques are placed. Use them wisely and save time, but don't let them be your only asset.
π₯ #AdventOfReversing 14/24 π₯
Know your environment. Take your time to learn how the OS (and possibly frameworks, e.g. graphics) you are dealing with works: executable format, loading process, syscalls, common libraries and API calls, threading management...
π₯ #AdventOfReversing 15/24 π₯
Related to previous one, seriously read the docs. Wasting hours w/ some win APIs that are documented or attempting to defeat linux ptrace-based antidbg w/o looking at ptrace man page, makes no sense. It seems obvious, but might not be for newcomers.
π₯ #AdventOfReversing 16/24 π₯
You might face frustration and despair at some times. That's totally normal. Take a walk, play some game, talk to a friend and even step back for a couple days. Take care of yourself and prevent burn out. I should apply this more to myself as well.
π₯ #AdventOfReversing 17/24 π₯
Think of what are you looking for and which questions do you need to answer. Define a clear #goal in mind before fruitlessly wandering through random assembly. E.g.
π #CTF: where is/could be the flag?
π #malware: what should/must the #IR address?
π₯ #AdventOfReversing 18/24 π₯
Doesn't only apply to #RE, but to learning any skill: set goals on the mid-long term to keep you motivated, but daily focus on process (practice 2h) vs specifics (solve that crackme).
π₯ #AdventOfReversing 19/24 π₯
In several #RE scenarios it's crucial to identify custom implementations of #crypto algorithms, mostly by locating known constants. In #IDA you can use findcrypt. You also have #yara crypto rules that will work everywhere. github.com/Yara-Rules/rulβ¦
β’ β’ β’
Missing some Tweet in this thread? You can try to
force a refresh
TL;DR Cool stuff and great contribution, but tarnished by some omissions that make it seem to have a bigger impact and general applicability than it really has, imho.
A thread π§΅
First things first. I don't consider myself an expert, but I'm quite familiar with academic literature regarding MBA (de)obfuscation. This paper constitutes great research, provides a novel proof and offers promising results.
That being said, I think it is necessary to point out some omissions, limitations and/or formal inaccuracies that might not be obvious if one is not familiar with MBA literature. I'll use excerpts from my thesis (
π’Just published my Maths & CS BSc thesis:
π"Code deobfuscation by program synthesis-aided simplification of Mixed Boolean-Arithmetic expressions".
Serves as an intro/review to:
- Code (de)obfuscation
- MBA expressions
- Program synthesis
First @radareorg r2syntia prototype was developed in the context of this work. Now it has already been slightly improved and it is being updated and maintained here, in case you are interested: github.com/arnaugamez/r2sβ¦
There is nothing really new (a part form r2syntia) but I would be glad if this "synthesis" work (pun intended) serves as a first step into the field of code (de)obfuscation and motivates the study of MBA expressions and program synthesis to help in further low-level research.