Live data from Hacker News

Reverse engineering course

github.com

31–40 of 57 posts

Re: Reverse engineering course

#31
post #15

> If 0x12345678 was loaded into a 64 bit register such as RAX, then RAX refers to 0x12345678, EAX refers to 0x5678, AX refers to 0x78, AH refers to 0x7, AL refers to 0x8. 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:…

I think the author is referring to catastrophic damage in the sense of file/data corruption and loss. In that light a BSOD makes sense as a way to "stop the error" since it halts execution rather than silently continue. I agree that it's strange, though.

Re: Reverse engineering course

#32

RPISEC RE/VR courses (a little scattered due to the passage of time): 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:/…

Forgot this one: Hardware Reverse Engineering - CSCI 4974, Spring 2014: http://security.cs.rpi.edu/courses/hwre-spring2014/ And put the full list on Github: https://github.com/JeremyBlackthorne/RPISEC-Courses

Thank you for putting this together!

Re: Reverse engineering course

#33
Always thought reversing is fun. Back in high school and college I would spend days or weeks trying to reverse random software packages I had installed on my system. It was pretty surprising how, with a few tools like OllyDBG, 90% of the software I attempted to crack was actually crackable. Most of Autodesk's software was ridiculously easy to crack. (Don't worry, I owned all that software already! I was studying animation at the time.)

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.

Re: Reverse engineering course

#35

Hmm, I've been itching to dive into some security thing again (I'm getting into the habit to dedicate 1 to 2 months per year for it, this would be year 4). This person's effort seems so awesome and genuine that I'm up for helping out. 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…

Same here, I’ve been doing RE challenges (most recently, microcorruption.com).

Re: Reverse engineering course

#36

Always thought reversing is fun. Back in high school and college I would spend days or weeks trying to reverse random software packages I had installed on my system. It was pretty surprising how, with a few tools like OllyDBG, 90% of the software I attempted to crack was actually crackable. Most of Autodesk's software was ridiculously easy to crack. (Don't worry, I owned all that software already! I was studying anim…

Someone correct me if I’m wrong but it sounds like you just described “fault injection” or “mutation analysis.”

Re: Reverse engineering course

#38

RPISEC RE/VR courses (a little scattered due to the passage of time): 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:/…

This is great! Do you have other related curated lists that you're willing to share?

Re: Reverse engineering course

#39

This title made me feel nostalgic, and search for +ORC [1] and +Fravia [2]. [1]: https://en.m.wikipedia.org/wiki/Old_Red_Cracker [2]: https://en.m.wikipedia.org/wiki/Fravia

I always feel bad software like SoftIce will never be a thing again. Felt so much power using it.

SoftICE still holds a super special place in my heart, but WinDbg is infinitely more powerful these days than SI ever was, especially if you're using it from another box (or from your host with a Windows guest VM).

Re: Reverse engineering course

#40
post #20

It seems the majority of RE-related stuff these days focuses on malware but the skills are very useful for other things, particularly debugging in general. I didn't specifically learn RE, but since I started long ago with Asm, I guess it came naturally. You can tell the author of this one probably comes from an HLL background because of the "0x" prefixes; those with an Asm background are more likely to use a "h" suff…

For Windows I would rather recommend OllyDbg spiritual successor - x32dbg/x64dbg[1]. It is open source and easily scriptable and extendable. [1] https://x64dbg.com/

I'll take this as an opportunity to plug some other RE tools:

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.

Post reply on HN