> Reverse engineering is a very broad term, but generally involves analysis of decompiled source, no?
Not necessarily. If you are reverse-engineering a file format for the purposes of reading and writing files compatible with the software, oftentimes you start by using the software to generate multiple files with small changes. Your analysis is limited to the output generated by the software, not the actual software itself (you treat the software as a black box).
> The only definition of "reverse engineering software" that I use is this
That's the definition of decompiling not reverse engineering. The original IBM BIOS was reverse engineered by two teams: one which read the disassembled binary and wrote a written specification and a second team that took that specification and wrote code.
> The only definition of "reverse engineering software" that I use
Uhm, no, that's far too narrow. Reverse engineering is any kind of introspection into a device in question, designed for obtaining any degree of understanding of its inner functioning.
What you're talking about is called "decompilation", and it's not even among the most useful reverse engineering techniques.
I think there may be a language barrier here. So, this should clear it up:
The only definition of "reverse engineering software" that I use is this -- "Using tools and deep binary analysis to take a compiled binary, and convert it back to source code as close to the original as possible".
It is a very specific definition. I do not mean general "analysis" or vulnerability testing or input manipulation, etc... only attempting to discover source code.
>I'm not even sure if it's a good exercise in programming either. Software development is about doing the things the right way, not exercising in futility.
Reverse engineering is a valuable art that can't be learned just from a canonical reference for "the right way". It cultivates the same skills used in debugging.
> Reverse Engineering is a much broader field than simply in the context of software engineering.
I will not disagree. But I am explicitly talking about reverse engineering as in the original article (i.e. mostly software and to a lesser (but not less important) sense electronics).
I do not know enough details about the other segments that you mention to make deep statements about them. But I am pretty confident in my opinion that the kind of skills that you require for them are really different from those that you need for software/electronics reverse engineering. What I want to say with this: The skills that you need for hacking an XBox (as in the article) do hardly ever transfer to any of your examples (bomb squad detectives, Root cause analysis experts, market/competition research, Prototyping, NTSB agent).
The comment is from one dude in late 2017 - it probably doesn't mean shit.
Like dude is talking about "there is absolutely no way on earth this was written from a clean sheet only from the available public documentation.", but that's not the bar for reverse engineering systems. It is legal (if you do it right anyways) to examine, use, and disassemble software in the process of reverse engineering.
It does not really matter how we are interpreting the term "reverse engineering". What matters is how it was used in the OP article, in the EULAs and the national laws. In the article it was clearly applied to a binary analysis part of pen testing efforts by the Oracle customers, so this is what we should be discussing here.
Not necessarily. If you are reverse-engineering a file format for the purposes of reading and writing files compatible with the software, oftentimes you start by using the software to generate multiple files with small changes. Your analysis is limited to the output generated by the software, not the actual software itself (you treat the software as a black box).
reply