Akiba
[img]http://i.imgur.com/o3RYT4v.png[/img]
- 4,262
- Posts
- 13
- Years
- Age 25
- in a gap
- Seen Apr 10, 2017
Hey all. Sync here. I've been in and out of the hacking scene for about five years now.
I've made several attempts in the past to create a comfortable ecosystem for all ROM hackers. All have failed, because the barriers of entry were too high, the approach was wrong, or I simply did not have enough time to get it up and running to a self-sustaining state.
After much contemplation, I've arrived at a conclusion. We've been doing it all wrong. In the past, I've stressed how our current tooling system is inconsistent, uncooperative, and fragmented. I've tried to solve this by introducing a centralized documentation project (it's still a good read, by the way). But this doesn't reduce the barrier to entry, and without a proper tooling system, could encourage even deeper fragmentation.
The first step to a better ecosystem is organization. I've said this before. The next step is abstraction and simplicity. How complicated are the current tutorials for making hacking tools? How hard do you think it should be to make one?
If you ask me, I'd say it should be this easy:
These several lines of Javascript take care of reading a ROM, writing a byte, and saving it. In other words, we've allowed running indoors on BPRE. Why do we need to go through so much trouble, clicking through wizards and GUI editors, just to do something so simple? These few lines are far less intimidating than an enormous Visual C# tutorial that accomplishes the same thing (and even then, only runs on Windows). Many of these tutorials don't really teach you how to make hacking tools, but rather .NET visual applications. I was fully guilty of committing this as a 13 year-old. As a result, most of the time spent making hacking tools is really spent making visual interfaces, which doesn't really sound like a passionate hacker's job to me. I've seen dozens of people who were really excited about hacking, but didn't know how to work UIs or other things completely unrelated to hacking, and eventually gave up on their precious work. What if we could just have one well-maintained application, that binds together different functionality, written by hackers, for hackers?
Let's talk about the code above. It probably shouldn't even be your job to take care of reading and writing files. So, delegating that task to our manager, let's simplify it to this:
Now, we ship a single function that writes the indoor running byte to a ROM. We don't care where it came from, or what else has been done to it.
But, since lots of small patches are really simple, writing data to offsets, why don't we allow some shortcuts?
Now, we have code that is really DRY and orthogonal.
That thing is a hacking tool. Maybe we shouldn't even call them hacking tools anymore. That would show that we've really matured.
Now, what I've written above will absolutely work (install node/iojs and babel to run!), but it's also just a proof-of-concept demonstration. You might be wondering how it actually runs. Unfortunately, you need a terminal. However, as I mentioned above, we can create and maintain a tool that binds together these "hacking tools," allowing everyone to hack as they always have (in that you all can still click around colorful views).
My purpose is to show that, by only worrying about what we need to worry about when making a hacking tool, we can achieve rich composition. Easily said, we can combine tools, make them work together, improve productivity, and greatly reduce the potential for bugs. We can also then stop worrying about pointless and irrelevant things, and move on to higher-level and more intelligent hacking.
In fact, the ecosystem that I've outlined above introduces possibilities for powerful debugging, testing, and other development practices that we've been missing out on. We even get backups, logs/journals, and revision control for free! I may write a post about that later.
Please consider what I've said, as it really would move the hacking scene forward.
I've made several attempts in the past to create a comfortable ecosystem for all ROM hackers. All have failed, because the barriers of entry were too high, the approach was wrong, or I simply did not have enough time to get it up and running to a self-sustaining state.
After much contemplation, I've arrived at a conclusion. We've been doing it all wrong. In the past, I've stressed how our current tooling system is inconsistent, uncooperative, and fragmented. I've tried to solve this by introducing a centralized documentation project (it's still a good read, by the way). But this doesn't reduce the barrier to entry, and without a proper tooling system, could encourage even deeper fragmentation.
The first step to a better ecosystem is organization. I've said this before. The next step is abstraction and simplicity. How complicated are the current tutorials for making hacking tools? How hard do you think it should be to make one?
If you ask me, I'd say it should be this easy:
Code:
import fs from 'fs';
let file = './BPRE.gba';
let ROM = fs.readFileSync(file);
ROM.writeUInt8(0, 0xbd494);
fs.writeFileSync(file, ROM);These several lines of Javascript take care of reading a ROM, writing a byte, and saving it. In other words, we've allowed running indoors on BPRE. Why do we need to go through so much trouble, clicking through wizards and GUI editors, just to do something so simple? These few lines are far less intimidating than an enormous Visual C# tutorial that accomplishes the same thing (and even then, only runs on Windows). Many of these tutorials don't really teach you how to make hacking tools, but rather .NET visual applications. I was fully guilty of committing this as a 13 year-old. As a result, most of the time spent making hacking tools is really spent making visual interfaces, which doesn't really sound like a passionate hacker's job to me. I've seen dozens of people who were really excited about hacking, but didn't know how to work UIs or other things completely unrelated to hacking, and eventually gave up on their precious work. What if we could just have one well-maintained application, that binds together different functionality, written by hackers, for hackers?
Let's talk about the code above. It probably shouldn't even be your job to take care of reading and writing files. So, delegating that task to our manager, let's simplify it to this:
Code:
export default ROM => {
ROM.writeUInt8(0, 0xbd494);
}Now, we ship a single function that writes the indoor running byte to a ROM. We don't care where it came from, or what else has been done to it.
But, since lots of small patches are really simple, writing data to offsets, why don't we allow some shortcuts?
Code:
export default {
offset: 0xbd494,
data: 0
}Now, we have code that is really DRY and orthogonal.
That thing is a hacking tool. Maybe we shouldn't even call them hacking tools anymore. That would show that we've really matured.
Now, what I've written above will absolutely work (install node/iojs and babel to run!), but it's also just a proof-of-concept demonstration. You might be wondering how it actually runs. Unfortunately, you need a terminal. However, as I mentioned above, we can create and maintain a tool that binds together these "hacking tools," allowing everyone to hack as they always have (in that you all can still click around colorful views).
My purpose is to show that, by only worrying about what we need to worry about when making a hacking tool, we can achieve rich composition. Easily said, we can combine tools, make them work together, improve productivity, and greatly reduce the potential for bugs. We can also then stop worrying about pointless and irrelevant things, and move on to higher-level and more intelligent hacking.
In fact, the ecosystem that I've outlined above introduces possibilities for powerful debugging, testing, and other development practices that we've been missing out on. We even get backups, logs/journals, and revision control for free! I may write a post about that later.
Please consider what I've said, as it really would move the hacking scene forward.
