Hacker News Reader

Comment by llmblockchain | Hacker News Reader

I never thought of reversing as something you pick up a book for. Everything I learned was through application from a young age.

1. Learning how to use Cheat Engine to scan video game process memory and modify games.

2. Learned how to read/replay packets in an MMO to try an cheat.

3. Learned how to craft DLLs, hooks and inject them in processes.

4. Learned how create patches for executables to solve some crackme challenges.

5. Mess with real world software that requires a license key, to suddenly not require a license key (or accept any key).

6. Mess with binary formats to try an reverse how game saves worked to.. you guessed it, cheat.

7. Get a real job and make money with the skills and knowledge I acquired.

View on HN

Same. I learned reverse engineering by staring at CE/IDA for entirely too many hours as a kid, which means whenever someone asks me for advice on how to learn reverse engineering I don't really have any good answers :)

I think in reality it's the type of thing you do just have to try and spend some time on. The OP tutorial comes across as very sparse, both trying to cover too much and also not really teaching reverse engineering skills more than most people would be able to pick up in a few hours of messing around. beginners.re in contrast is massive, but also much more in-depth and goes step-by-step; on the other hand crackmes are probably better hands on challenges to try.

Wow, did you really have access to IDA as a kid? Even with adult money it seems expensive to me.

Everyone pirated IDA as a young reverse engineer, that's just a rite of passage.

Numega's SoftIce for me, but I always preferred interactive exploration over static disassembly.

Disassembling a large binary would get you a massive text file that was painful to navigate - and often times I'd find that the code I was interested in removing "Invalid license key" (ahem) would be stored in some unrelated DLL.

So for me setting breakpoints on MessageBoxEx, and similar things, was by far the quickest and easiest way to go.

Most people used a cracked old version of IDA. I actually just used the freeware version, which was ancient and didn't come with any decompiler. Which was definitely difficult, and people having access to Ghidra for free these days is definitely a lot better!

Going straight for reverse-engineering is doable, but it's significantly harder without some engineering background, either formal or self-taught.

I have an ongoing reverse-engineering project for a video game and I ended up getting in contact with a self-taught modder of the game, who doesn't know how to program. He learned more in a couple of evening Discord calls with me showing him around the reverse-engineered Ghidra project, explaining the basics of computer program engineering as we went, than he did flipping bits with Cheat Engine.

He then proceeded to recreate a fairly ambitious mod that was showcased in a Youtube video 15 years ago but never released, something that was bugging him for years but was unable to recreate. I steered him throughout, but by seeing how the pieces fit together he then managed to do the same mod on the sequel (which was never done before) all by himself.

Experience with engineering gives you perspective when reverse-engineering.

I don't think this is true, or at least I'm not convinced by a single anecdote. The majority of good reverse engineers I know picked up reverse engineering first and programming second (and a lot of them are still frankly not great programmers), and likewise I know plenty of good programmers who would be completely lost reverse engineering. Reverse engineering is a very different skillset than programming.

While I am reverse-engineering a video game by myself, I'm not really part of the reverse-engineering scene, so this one anecdote is really the only data point I have about "mentoring" someone, if it even counts. I fall into the category of people who picked up programming first and then reverse-engineering second. I don't know what I'm worth compared to other reverse-engineers and my signature technique is extremely fringe. I don't really have a reference point of what's normal or not.

That being said, I believe that there's a large skillset overlap between comparable reverse-engineering and programming activities. Knowing various programming patterns and architectures is helpful for making sense of (de)compiled code during static analysis. Being knee-deep in the bowels of a misbehaving program armed with GDB and you're getting a taste of dynamic analysis. Throw in some missing debugging symbols or advanced optimization work and you'll pick up some assembly on the way.

In my eyes, the only real difference is the mindset. On one side you're building software, on the other you're deconstructing it. Maybe I've been at it in the trenches for so long that I can't tell the difference anymore.

I agree with you both to some extent. It's all anecdotal though, really.

I think a fair point is that there are common idioms that you need to learn one way or another. Whether that is formal training or intuition or just plain force of will, you need to come to understand the meaning of what you are looking at and not just what the individual instructions are doing.

Otherwise, it's a similar idea to saying, "nobody needs to learn how to read music because look how great Jimi Hendrix was and he couldn't".

Right, I'm not saying that learning software engineering wouldn't help. I'm specifically pushing back against "it's significantly harder without some engineering background", since a lot of good reverse engineers I know still don't have a good software engineering background. Being able to identify program constructs and idioms from the programming side instead of the reverse engineer side is definitely one way to do it, but I don't think it's the only way and I'm not sure is even the best way, since a lot of programming details are surprisingly irrelevant for RE so going through a full CS degree program will also spend a lot of time teaching you things you don't need to know for RE.

My point was about relevant engineering background for a particular task. For example, if you're trying to binary patch something, having prior assembly programming experience would help a lot, but knowing the runtime complexity characteristics of various sorting algorithms wouldn't.

I'm not suggesting that aspiring reverse-engineers need to pursue a full-blown CS degree first, but most reverse-engineering activities usually have at least one counterpart engineering activity. You can power through without learning it first, but I'm not convinced that it's easier or faster to learn that way.

As for me, I've spent quite a lot of time doing low-level software engineering beforehand (stuff like OSDev, bare-metal programming and GDB debugging sessions with missing symbols...) and I've picked up on reverse-engineering very quickly I believe, thanks to lots of relevant prior engineering experience. Had I spent my time making cracks and mods instead, I highly doubt I would've been able to later pivot towards software engineering that easily, due to a lack of foundational CS knowledge.

It depends what you mean by "engineering". You need to understand the "memory model" (I don't know the proper term). So that memory has addresses, you can point to them, the stack, registers, etc.

I have met many software developers that have almost no understanding about that stuff. They wouldn't help much when it comes to reverse engineering.

At the end of the day, there's a bunch of knowledge you need to be able to reverse engineer efficiently. It doesn't really matter if you're coming from flipping bits in CE to programming or vice versa, but you need both. Having some around that knows both guiding you is a massive help.

For what it's worth, I also started reverse engineering first and programming second. There were many concepts I knew but didn't know the name of. I remember seeing a weird function where a pointer to an object was passed via ecx. I had no idea that how functions were called was a "calling convention" and that Microsoft called that a __thiscall. But at the end of the day, I did figure out what was going on, I just couldn't tell you what the original c++ code was until years later (when I finally "learned" c++).

Understanding the low level details helps, but another benefit of having engineering experience is being able to empathize with the original engineers.

You entirely underestimate the power of structured learning and reinforcing exercises. While critical reasoning, curiosity, and passion are things that may be difficult to impart, a well-written book can cut hours of trial and error to something suitably reasonable. Notice that there are plenty of books but there are only a handful of "good" books.

Structured learning is great, but I think you're over estimating the power of books. Especially in a domain like reverse engineering. The moment a book is published it's out of date. What worked yesterday doesn't work tomorrow.

I never suggested people learn entirely on their own. I learned in a loosely structured way by reading thousands of forum posts, asking questions on forums, sitting in IRC channels talking to people, etc.

Perhaps, but like I said, there are books and then there are good books. Besides, state of the art might change rapidly but the fundamentals rarely do.

I never thought of cooking as something you pick up a book for.

Damn, you’re so good, can I get an autograph?

there's a book for most things.

everything you listed here could be in a book used to help you gain those skills

if I ever get around to learning reverse engineering, I don't expect a book like this to teach me how to do it. I expect it to inform me of what I don't know that I don't know. For that it seems okay as a starting point.

This is the way.

Although some books greatly help in getting there, I learnt a lot from "Reversing: Secrets of Reverse Engineering" by Eldad Eilam (might be a bit dated now)

> Get a real job and make money with the skills and knowledge I acquired.

Do you mind sharing what kind of job is that?

One word : plastics.

My first job was working at a video surveillance company... My specific job was reversing multiple proprietary video streams, transcoding them and stitching them into a single output stream and sending it to a browser. For example, taking nine 1080p video streams and stitching them into a single 3x3 video stream that totaled 1080p.

It was a chaotic mess of C++.

I did it for a year before joining a startup, and on and on.

It's also how I learnt programming when I was 14! It was so much fun.

Lmao we must be related. U explained my childhood

Reply on news.ycombinator.com