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.
Probably closer to "mutation analysis". (or "creative tampering"?) Someone smarter than I am could probably reverse engineer while doing less of that, but I've found that it can be effective when knowledge of a system is poor. (and there's urgency that warrants it over traditional learning)
Yes, I have used it at my previous job (recently got fired) and it was really helpful. Of course, you need physical access to the application to make this work, e.g. it's much harder to do for some oddly behaving REST Api.
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.