daemon1 wrote:If you're good in analyzing, you don't have to make wrong guesses
How can you say this, when you've just spent weeks on an animation format?
You know as well as I do, you will make guesses, and they will be wrong. Even if you have a limited set of possibilities, it's like using A* to pathfind - you can make good steps based on heuristics but you're still going to end up traversing nodes that you didn't need to because you didn't understand how to get where you were going when you started out. You've wasted time because you didn't collect the necessary data to start efficiently.
daemon1 wrote:I disagree. I'm looking at this from a different angle. Let me just mention that my first assembler was a PDP system in late 1980's. Then 8080. I had to write my own disassembler for that, because there was no one on a particular platform, and I wanted to disassemble games for that. Then was 8086 and so on. I have almost 30 years of experience in both data analyzing and disassembling.
You've been at this for even longer than I have. I got my first gamedev contract about 20 years ago, but have only been active in reverse engineering for maybe 10-15 years. But you could say that after 30 years, if relatively simple things still take weeks or months, it could be a problem with the methodology, or you just don't care about utilizing your time effectively. Sorry, I do respect the aspect of "fun", because there isn't much other reason to do this crap if it isn't fun for you in some way, but I also don't find it fun to have to tackle a single problem for weeks at a time unless the complexity or scale of that problem truly warrants it. When a format has many different facets that are taking that time justifiably, or I'm exploring something for new hardware that I'm not familiar with, then sure, great, that will take more time and give me new knowledge in the process. But instead of getting caught up on details like "which bit is signifying which packing format, how many bits are used in this mode, how many fraction/exponent bits are used for this custom floating point encoding, blah blah blah", save yourself all that time guessing and narrowing down your search potentials and just read the disassembly. Once you get into actual decryption or more elaborate forms of compression, this holds 200 times stronger.
Disassembling anything modern is certainly a lot different than it was 10, and I can only imagine 30, years ago. The difference in volume alone is staggering, and it requires many different methodologies to achieve efficiency.
Rather than solving a puzzle versus using a badly-organized book, at this level, it's blindly throwing A* at a nice uniform node grid when you have a starting node right in front of you that begins a perfectly visible linked list leading straight to your destination. The difference between being good or bad at reading through and understanding disassembly is the difference between going from one node to the next instantly or getting stuck at each node examining lots of useless pointers. It's a skill on its own that gets you faster, less frustrating results once honed properly.
daemon1 wrote:There are lots of tricks and methods in data analyzing. If you only disassemble, you'll never know these techniques, and will have no experience in using them. So analyzing does actually help. And not only for one case. And it doesn't depend on knowing common norms or well-documented things. When I first analyzed game archive, I had no idea how they're usually made, and that's why it was interesting to me. When I first analyzed sound files, I had no idea about adpcm codecs or usual segmenting/frame types. And that's why it was again very interesting to analyze.
Once you have the answer through either approach, maybe you've learned something new. But probably not. I haven't learned something new in reversing games in many, many years. I tend to learn all the new approaches and techniques that relate to game data through actual development instead. But it's certainly interesting to learn new things when you come across them. Using disassembly doesn't detract from this in the slightest, and it gives you better insight into otherwise-flawed assumptions you're going to make when you're first understanding data. Traditional "analysis" in the sense that you mean it leaves the door wide open for misinterpretation that happens to line up with your dataset. I think what you're missing here is that in the context of videogame data, you typically can't do anything very meaningful with reverse engineered data without understanding it anyway. Because you already have so much of this knowledge that your analysis and intuition is entirely contingent upon, maybe you've lost sight of how you acquired a lot of it, or made the mistake of thinking the way you acquired it was the only way to acquire it.
daemon1 wrote:Not to mention that personally for me, disassembling is like instead of solving the puzzle, you're trying to find the answer in a big and badly organized book. That's not interesting. No fun. Every time I'm forced to use disassembly I feel disappointed.
The book is very well organized, but if you aren't practiced in understanding how to effectively parse it to get the information you want, it will appear badly organized. This is rather speaking to my point. Again, if time/efficiency isn't important to you, then sure, take whatever approach you want. But when you start out, it's really undeniably easier to just stare at your hex editor and step through your process of elimination than it is to get down in the dirt and learn how to navigate a big sea of disassembled code.
I'm carrying on here because I think it's pretty important for beginners to take that step. Most of the people here don't take it, which prevents them from expanding into more areas of reverse engineering. I don't see a point to limiting yourself to a little puzzle-solving sandbox. It might provide you with some sense of fun and reward for a while, but keep it up for 5 or 10 years, and after a while it will just be depressing when you look back and realize you could've been building other useful skills alongside your efforts that entire time. You're advocating a methodology that will have that very result for beginners because they'll just stare at and "analyze" data as you're advocating, until they hit their fateful wall, and retreat back into the sandbox.
This is probably central to our disagreement, where you're looking at the methodology you "like" and that works for you, I'm looking at the methodology that provides the greatest extra-activity benefit and time efficacy. In practice, I rarely need to take the debugging & disassembly route, but it's pretty nice to have the option, and have it actually be a time-effective one at that. To me you sound like one of those people that says "I hate debuggers, I only use printf" because they haven't learned how to use a debugger.
Good talk! I wonder if anyone will ever find any of this useful.
