[HN Gopher] Reverse Engineering for Everyone
___________________________________________________________________
Reverse Engineering for Everyone
Author : udev4096
Score : 340 points
Date : 2024-07-25 14:41 UTC (8 hours ago)
(HTM) web link (0xinfection.github.io)
(TXT) w3m dump (0xinfection.github.io)
| andrewmcwatters wrote:
| Hmm, yeah I don't know. This reads like a lot of fluff or
| immediately unimportant stuff.
|
| Reverse engineering in the real world takes a few forms, some of
| which the write takes on too briefly towards the end of the
| material. Applied reverse engineer is usually modifying an
| existing piece of software so: * .dll/lib
| injection * signature scanning and patching *
| packet interception and rewriting * mitm HTTP(s) calls
|
| These are just a few places where you see reverse engineering
| used, usually to modify existing software.
|
| I'm curious if there's any reading out there that covers this
| stuff from the meat and potatoes and less of this CS 101 stuff.
|
| I've done all of the above, and you can usually learn about this
| stuff from some different forums on the web, but I don't know of
| any good bibles on the subject matter.
| darby_nine wrote:
| > I'm curious if there's any reading out there that covers this
| stuff from the meat and potatoes
|
| In my experience using radare2 to peek at the code is pretty
| much the meat and potatoes of reverse engineering binaries and
| far from "CS 101 stuff". You certainly don't need to modify a
| binary to MITM an API or inspect/alter packets or inject code
| via dynamic loading; nor is it the most convenient or clean or
| easy to maintain way to do so.
|
| Secondly, this is a shockingly dismissive attitude for such a
| _large_ resource. It took me a few minutes to just read through
| the table of contents.
| andrewmcwatters wrote:
| Just because it's large doesn't mean it's relevant: using
| radare2, IDA Pro, or some other tool doesn't mean you're
| going to be able to do anything besides look at a binary.
|
| I mean, you said you read the table of contents, yeah? Doing
| the same thing across different CPU architectures isn't doing
| something at length, it's just doing the same thing over and
| over again in rhymes.
|
| In practice, yeah, people in the wild are absolutely
| modifying binaries, injecting, stubbing .dlls and redirecting
| calls, or creating proxy servers that alter payloads, for
| sure.
|
| Learning how to compile a program isn't exactly reverse
| engineering worthy content to write about.
| darby_nine wrote:
| > Just because it's large doesn't mean it's relevant: using
| radare2, IDA Pro, or some other tool doesn't mean you're
| going to be able to do anything besides look at a binary.
|
| Looking at a binary is like 99% of the work, though. Or at
| least looking at some secondary form of it (e.g. assembly,
| decompilation, etc). Tools are absolutely critical to the
| work.
|
| > people in the wild are absolutely modifying binaries,
| injecting, stubbing .dlls and redirecting calls, or
| creating proxy servers that alter payloads, for sure
|
| I would call modifying a binary "cracking" it but it's been
| a few decades since I was involved in that scene. I also
| think that the topic is large enough to warrant multiple
| focuses--to me, at least, writing a MITM server is much
| more trivial than extracting a private key from a binary
| (or a running process) that makes that MITM server
| functionally useful.
|
| > Learning how to compile a program isn't exactly reverse
| engineering worthy content to write about.
|
| That's a disingenuous characterization of most of the
| content here. Coding at the instruction level requires a
| different way of reading and writing code than you're
| otherwise exposed to. Most programmers aren't used to
| handling bits directly, and certainly not to the extent
| that it rewards you at the instruction level for learning
| and knowing. With the tools here you can, in fact, sit down
| and inspect the license verification function of a piece of
| software (although I'm not sure how much that's true or
| beneficial these days with code-signing etc).
|
| EDIT: Or you could do what I did and work with as, `otool`,
| and a hex editor, and learn extremely slowly & painfully
| why custom-built reverse engineering tools are so valuable
| to learn.
|
| There's always more to learn, of course, but that's no
| reason to belittle what you've already learned and other
| people still have yet to learn.
| andrewmcwatters wrote:
| Yeah, I'm sure what I'm saying probably comes off as
| belittling, but that's not my intent. It's just more
| productive to understand who the audience is. The author
| write "free PDF" content with Guy Fawkes mask header
| images in the README.mds.
|
| If you're going to target script kiddies, at least show
| them how to Hello, World! from a DLL_PROCESS_ATTACH, and
| then teach them sigscanning.
| acureau wrote:
| I disagree, learning how to compile a program is a prime
| example of something you'd want in a book about reverse
| engineering "for everyone". A book which focuses only on
| specific methods of changing software behavior would be
| useful only to those who know how to understand said
| software. In fact the term "reverse engineering" itself
| does not imply modification at all.
| jonpalmisc wrote:
| Resources exist, but are only so helpful IMO.
|
| One can't necessarily build an airplane after watching a
| documentary on it.
|
| Even if there was some "bible" on it, reverse engineering is
| one of those things that you have to put the reps in for to get
| good at it and actually develop understanding.
|
| The "bible" is tackling reverse-engineering related projects
| independently over the course of months/years and picking up
| knowledge along the way.
|
| Starting with something like cracking software (and making
| increasingly-advanced cracks) is always my advice for
| beginners.
| boricj wrote:
| Applied reverse-engineering is all about bending the rules of
| engineering. Because of this, I think it can be learned through
| experience, but I doubt it can be taught through theory (or at
| least not in an effective manner). At its core, it's about
| spotting metapatterns to gain an understanding of a program and
| applying leverage to affect it. That's more art than science,
| no matter how much tooling you throw at it.
|
| Honestly, I think the most effective way to learn about how to
| reverse-engineer something is to learn engineering at the same
| layer first and then start tinkering. If you want to binary
| patch a program, learn assembly. If you want to inject a .dll,
| learn how to write and use dynamic libraries. If you want to
| MITM a REST API, learn how to call a REST API. Because once you
| know the rules well, you can start breaking them and see
| exactly how much you can get away with.
|
| I wrote a series of articles on reverse-engineering on my blog,
| about studying and modifying a program that outputs an ASCII
| table, mostly because I needed a way to introduce delinking as
| a technique. I would not say it's good, but it starts with how
| to build the case study and then it handholds the reader
| through the meat and potatoes.
| palata wrote:
| > I wrote a series of articles on reverse-engineering on my
| blog, about studying and modifying a program that outputs an
| ASCII table,
|
| Would you mind sharing the links? I would be interested!
| boricj wrote:
| You can find the table of contents for the series there:
| https://boricj.net/reverse-
| engineering/2023/05/01/introducti...
|
| I expect that you'll be mostly interested in parts 2
| through 6. Part 1 explains how a toolchain works in general
| (so mostly CS 101 stuff as the OP put it). Parts 7 to 10
| demonstrates the delinking technique by easing into it, a
| technique which is as powerful as it is esoteric, but
| probably not what you're looking for in a beginner's guide.
| xkcd-sucks wrote:
| > places where you see reverse engineering used, usually to
| modify existing software.
|
| funnily enough I have a team reverse engineering binary data
| formats, which is often more easily accomplished by other means
| + only dropping down to the disassembly/decompilation where
| absolutely necessary. and which as far as I am aware never
| involves binary patching
|
| but yeah about the article it seems like if you know this much
| about assembly / chips etc. to be able to read it, then general
| problem solving ability should be able to cover most of the
| article's content
| bitwrangler wrote:
| It seems like a high-level overview, good for somebody new to the
| topic.
|
| It also linked to this resource, which was more in depth...
| https://github.com/mytechnotalent/Reverse-Engineering
|
| EDIT: Whoops... it looks like it mostly links back to the
| original article.
| amiga386 wrote:
| I'd like to add that reverse engineering can also be done without
| any peeking at the thing you're trying to reverse-engineer.
|
| Andrew Tridgell explaining how he reverse engineered Microsoft's
| SMB protocol with the "French cafe technique":
| https://www.samba.org/ftp/tridge/misc/french_cafe.txt
|
| Tridge also reverse engineered BitKeeper, the proprietary
| software that Linus foolishly used to host Linux kernel
| development for a while. He noticed that if you telnet to the
| BitKeeper address:port rather than use its proprietary client,
| you can type "help" and it then spits out a list of commands to
| try...
|
| You can then interrogate the repository with these commands and
| get a complete understanding of all the internal data structures,
| without ever using the proprietary software, let alone having to
| disassemble it.
|
| The fact that Tridge did this reverse-engineering led BitKeeper's
| owner, Larry McVoy, to rescind the Linux community's use of his
| software, so Linus wrote git.
| actionfromafar wrote:
| So Andrew saved us not only once, but twice!
|
| It goes to show that yes, you need someone to score, but you
| also need someone to make that critical pass of the ball.
| tsujamin wrote:
| An undergrad highlight for me was hearing the bitkeeper/git
| story from Tridge one afternoon that he happened to be in the
| faculty lunch room :)
| llmblockchain wrote:
| 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.
| solidalbo12 wrote:
| Lmao we must be related. U explained my childhood
| boricj wrote:
| 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.
| chc4 wrote:
| 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.
| boricj wrote:
| 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.
| chc4 wrote:
| 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.
| exe34 wrote:
| 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.
| dvngnt_ wrote:
| there's a book for most things.
|
| everything you listed here could be in a book used to help you
| gain those skills
| tarruda wrote:
| > Get a real job and make money with the skills and knowledge I
| acquired.
|
| Do you mind sharing what kind of job is that?
| tonetegeatinst wrote:
| Book links are not working for me, did you get the HN hug of
| death?
| armitron wrote:
| I found so many mistakes, badly understood concepts and entirely
| wrong explanations just reading for 5 minutes, that I can't
| possibly recommend this. It's obviously written by amateurs /
| people with minimal experience of the domain.
|
| Much better resources are Eldad Eilam's "Secrets of Reverse
| Engineering", for Windows "Practical Reverse Engineering" and for
| the absolute basics, Patterson's "Computer Organization and
| Design".
| imhoguy wrote:
| Reverse engineering Java is cool as well, especially fishy
| Android apps which control some appliances via byzantine
| Bluetooth protocols.
| svag wrote:
| This brought back memories when I was reading reversing tutorials
| from searchlores.org and fravia.com...
|
| It's in web archive now,
| https://web.archive.org/web/20191201105759/http://search.lor...
| parsonch wrote:
| Neat, I know the guy that wrote this guide! Glad to see it made
| it onto HN, if you have any specific feedback I can pass it
| along.
___________________________________________________________________
(page generated 2024-07-25 23:00 UTC)