Reverse engineering course
github.com
github.com
Secure Software Principles - CSCI 4971, Spring 2010:
http://www.cs.rpi.edu/academics/courses/spring10/csci4971/
Malware Analysis - CSCI 4972/6963, Spring 2013:
http://security.cs.rpi.edu/courses/malware-spring2013/
Advanced Exploitation and Rootkit Development, Spring 2013:
http://security.cs.rpi.edu/~candej2/
Program Obfuscation, Fall 2013:
http://security.cs.rpi.edu/courses/obfuscation-fall2013/syll...
Windows Exploitation, Spring 2014:
http://security.cs.rpi.edu/~gaasem/winexp/IndependentStudy.p...
http://gaasedelen.blogspot.com/2014/02/windows-exploitation-...
Modern Binary Exploitation - CSCI 4968, Spring 2015:
Malware Analysis - CSCI 4976, Fall 2015:
Hardware Reverse Engineering - CSCI 4974, Spring 2014:
http://security.cs.rpi.edu/courses/hwre-spring2014/
And put the full list on Github:
Last August, I took the Advanced Windows Exploitation course from Offensive Security (for the OSEE), and then I followed it up with the awesome Advanced Fuzzing and Crash Analysis course taught by Richard Johnson. Both were incredible courses, but my RE sucks.
I'm looking at the Advanced Browser Exploitation course next, but I'd really like to get better with reversing in order to get more out of these classes.
Anyway, I'm going to save this for later viewing.. very interesting post.
I didn't realize this until later, but I got a skill out of reversing that's actually pretty useful as a software engineer. Granted, I work with JavaScript, but reversing actually taught me how to persevere with debugging. I've been able to fix some bugs that other people couldn't in a reasonable timeframe because I treated the problem like I would when reversing a program; it can be more expedient to perform a process of elimination by disabling or inverting parts of the code, observing what happens, keeping detailed notes on observed behavior, and lead yourself down to the key change you need to make. A lot of people debug problems by trying to look at the code and reason about it while setting breakpoints, but there can be a lot of mental overhead in doing this. When the problem is mysterious, I find that a process of elimination through experimentation can be more effective.
This actually happened recently, where we essentially had an infinite feedback look happening that was obfuscated by a lot of framework code. It's possible that the root cause could have been identified by debugging, but a few people tried to do so but couldn't figure it out. This is because setting a breakpoint somewhere in the process chain didn't reveal anything obvious, and you'd be lucky to actually spot the problem in the application code just by looking at it. I treated the problem like reverse engineering, and did exactly what I described above. It took me a few hours, but I did succeed in narrowing down exactly where in the code things were going wrong.
Sure, someone could have stepped through the app and framework code enough times that they might have figured it out. Perhaps there are also more advanced debugging techniques that none of us were aware of that would have helped. But the mindset of a reverser definitely works.
For Windows debuggers I recommend Windbg, which is free and comes from Microsoft. Using VS for Asm-level debugging is only mildly better than using gdb for it --- i.e. very awkward and not what they were designed for.
IDA is considered the holy grail. A base version is free, but its most popular feature, the disassembler, is $$$. Does debugging and static analysis.
NSA's Ghidra is great too: https://ghidra-sre.org/. last time I checked I don't think it did debugging but they were adding it. It's great for static analysis though, it has a great free disassembler (traditionally IDA's domain).
Cheat Engine is pretty amazing too, despite the goofy name: https://www.cheatengine.org/. It's the best tool for pointer scans imo, but also does debugging and is scriptable. Popular for making video game trainers, but it can be used for anything.
Radare is great and I use it as well, but Ghidra brings a whole lot of new capability and its straight up free.
> Ghidra's existence was originally revealed to the public via WikiLeaks in March 2017
[1]: https://en.m.wikipedia.org/wiki/Old_Red_Cracker [2]: https://en.m.wikipedia.org/wiki/Fravia
I made a PR to correct this example which equated single hexadecimal digits with whole bytes.
Other than that what I read of the course is rather nice, targeted at a mostly beginner audience with some correct insight.
There also some weird insight:
> You can think of computers as trains, they don't stop and only go in a very specific and direct path as designated by the tracks. If there's a child on the tracks it's up to the people controlling the track to divert the train. This is why Windows gives you the Blue Screen of Death (BSOD) when there is a kernel error. If the OS doesn't stop that error, catastrophic damage could occur.
This isn't really wrong, it's just a non-obvious metaphor formulated strangely in my opinion. A BSOD would be more akin to the fully automated train just blowing up in sight of the children or something? It's weird.
https://tuts4you.com/e107_plugins/download/download.php?list...
Purely hands-on. Old school. Use virtual box.
Though, I don't want to study it completely by myself, it gets a bit lonely and there's no accountability. Does anyone want to set up a study group with me?
My background: I know how to reverse Linux binaries, albeit I'm a bit rusty. I followed a course called binary and malware analysis at the Vrije Universiteit Amsterdam, and two other related security courses (shout out to Herbert Bos and his team for giving such an awesome course).
My email is in my profile.
Will email you later.
>Learning your first calling convention is like learning your first programming language. It seems complex and daunting at first, but it's really quite simple.
I will definitely read this as I'm also doing the Reverse Engineering for beginners, as well as getting sidetracked to learn Assembly with Programming From the Ground Up first.
"Reverse Over-Engineering" is a desirable outcome of the Simulator Effect: what game players (and game developers trying to clone the game) do when they use their imagination to extrapolate how a game works, and totally overestimate how much work and modeling the simulator is actually doing, because they filled in the gaps with their imagination and preconceptions and assumptions, instead of realizing how many simplifications and shortcuts and illusions it actually used.
https://www.masterclass.com/classes/will-wright-teaches-game...
>There's a name for what Wright calls "the simulator effect" in the video: apophenia. There's a good GDC video on YouTube where Tynan Sylvester (the creator of RimWorld) talks about using this effect in game design.
https://en.wikipedia.org/wiki/Apophenia
>Apophenia (/æpoʊˈfiːniə/) is the tendency to mistakenly perceive connections and meaning between unrelated things. The term (German: Apophänie) was coined by psychiatrist Klaus Conrad in his 1958 publication on the beginning stages of schizophrenia. He defined it as "unmotivated seeing of connections [accompanied by] a specific feeling of abnormal meaningfulness". He described the early stages of delusional thought as self-referential, over-interpretations of actual sensory perceptions, as opposed to hallucinations.
RimWorld: Contrarian, Ridiculous, and Impossible Game Design Methods
https://www.youtube.com/watch?v=VdqhHKjepiE
5 game design tips from Sims creator Will Wright
https://www.youtube.com/watch?v=scS3f_YSYO0
>Tip 5: On world building. As you know by now, Will's approach to creating games is all about building a coherent and compelling player experience. His games are comprised of layered systems that engage players creatively, and lead to personalized, some times unexpected outcomes. In these types of games, players will often assume that the underlying system is smarter than it actually is. This happens because there's a strong mental model in place, guiding the game design, and enhancing the player's ability to imagine a coherent context that explains all the myriad details and dynamics happening within that game experience.
>Now let's apply this to your project: What mental model are you building, and what story are you causing to unfold between your player's ears? And how does the feature set in your game or product support that story? Once you start approaching your product design that way, you'll be set up to get your customers to buy into the microworld that you're building, and start to imagine that it's richer and more detailed than it actually is.
>I'm working on adding more content, more detail, more examples, and really just more everything. Please give me any and all feedback, I've already followed some advice given in the comments on this post. It's really appreciated
Mechanical RE is equally important for many applications as well.
A few posts up, melvinroest suggested starting a study group for the (Windows-based) course in the original post -- would anyone be interested in doing the same for this Linux-based course?
I am more interested in memory patching and binary modification of software (including games) than malware analysis