By empowering users with the option to take control of their own technology, FLO software provides strong protection against abuse -- developers need to weigh user-hostile decisions against the possibility of a fork.
Unfortunately this isn't really true for large and complex FLOSS, e.g. web browsers. For a lot of the little user-hostile decisions they have taken, it would take me far more time to get the source and all its dependencies, figure out how to correctly build it (which can itself include a nontrivial toolchain with its own effort to set up), find where to make that tiny change I wanted to the source, and recompile and test; than to simply use a debugger to find the right place in the binary to modify directly.
Open-source doesn't necessarily mean easy to take control; and neither does closed source mean the opposite. I've been RE'ing for decades and wish more people knew about this valuable skill, because that's what gives you the true power to take control.
> Unfortunately this isn't really true for large and complex FLOSS, e.g. web browsers.
It is also true for web browsers; all it needs is one developer among the many thousands being able to build and distribute it.
> Open-source doesn't necessarily mean easy to take control
True, it should be more something like: "it won't be easy to use this source by yourself, but if the company decides to discontinue the product, you can still hire some developers to support and continue it, rather than throw in the trash everything you've based on it, which sometimes could mean your entire business". It rather makes hard for others to take away this control, a concept which is wonderfully explained by the GPL license document.
> I've been RE'ing for decades and wish more people knew about this valuable skill, because that's what gives you the true power to take control.
Agree 100% on this, but definitely not easy especially now that pretty much every damn product contains more horsepower and complexity than the Apollo missions computers.
However, if you have books, resources, examples etc. for mere mortals on the subject, I'd love to take a look at them. That topic would probably deserve a post by itself.
>simply use a debugger to find the right place in the binary to modify directly
I reflect back and wonder why the systems I grew up with didn't have this capability built right in, like a keyboard interrupt in DOS that would pause execution and let you dive into the contents of memory, view the stack, or debug the decompiled version of a running program.
Maybe this kind of stuff just wasn't possible in the race to the bottom that was the 80s and 90s PC market, but as a child, I was really confused why I didn't have the tools necessary to "pop the hood" on anything other than BASIC programs—and that's assuming I was using a machine that had BASIC installed.
I'm sure the only thing I would have done with it at the time would have been to cheat at video games, defeat copy protection, and alter game dialog to be extremely crass, but I think it would have been extremely helpful in the development of my adult skill set.
I agree with that. I have firefox cannot update to the latest version nags that I cannot get rid of. Looking at the source takes me down all sorts of false trails, let alone compiling the darn thing. sigh.
On the other hand, it is possible, and great groups of people have for instance de-googled chrome and fixed ubuntu.
doing a small patch on a unsupported piece of software, but that was nearly trivial.
That means you've already started. ;-)
I think it's hard to give recommendations regarding learning of RE in general, as I mainly do it a "scratch an itch" and "learn as you go" type of thing --- whether you need to interface with an unknown file format, change the behaviour of a piece of code, change a message in a UI, automate an aspect of a web app, etc. the exact knowledge you'll need will vary widely. However, in all those circumstances the basic idea is to gather knowledge about the target to get a vague understanding of how it works, and then dive in with the specific tools/knowledge you've gathered.
Unfortunately this isn't really true for large and complex FLOSS, e.g. web browsers. For a lot of the little user-hostile decisions they have taken, it would take me far more time to get the source and all its dependencies, figure out how to correctly build it (which can itself include a nontrivial toolchain with its own effort to set up), find where to make that tiny change I wanted to the source, and recompile and test; than to simply use a debugger to find the right place in the binary to modify directly.
Open-source doesn't necessarily mean easy to take control; and neither does closed source mean the opposite. I've been RE'ing for decades and wish more people knew about this valuable skill, because that's what gives you the true power to take control.