 |
| Register | Login | |||||
 |
Main
| Memberlist
| Active users
| Calendar
| Chat
| Online users Ranks | FAQ | ACS | Stats | Color Chart | Search | Photo album |
|
| | ||
|
| Register | Login | |||||
|
Main
| Memberlist
| Active users
| Calendar
| Chat
| Online users Ranks | FAQ | ACS | Stats | Color Chart | Search | Photo album |
|
| | ||
| 0 users currently in ROM Hacking. |
| User | Post |
| FreeDOS + Posts: 285/1312 |
Alright if possible, mind getting back onto topic...? there's probably no lawyers here and we're just going to go around in circles. |
| LocalH Posts: 42/65 |
Disassembly of a specific game engine is nothing close to plagiarism. You're trying to gain insight into how that specific game engine works, and for purposes of hacking that game engine you don't want to write a whole other engine based on the concepts found in the disassembled engine, you want to use the exact same engine that you've disassembled. |
| FreeDOS + Posts: 282/1312 |
You were talking about reading the code and writing "new" code based directly off of the original. I was talking about one or more people reading the disassembly and clearly documenting it. Then other people read the documentation and implement completely new code. |
| MathOnNapkins Posts: 249/1106 |
So uh... did you have a change of heart, b/c last I heard you wanted to "plagiarize" Lunar Magic. 
Either way, the case study is irrelevant to what we're discussing. Ripping someone off to make money on a book is one thing, distributing information on a piece of software without taking credit of authorship of that software seems a bit different. The intent is to communicate information to tinkerers, not the actual software. Without the data, the code is pretty much useless. By that logic, ram address listings as well as offset lists would also be illegal. What I've got is the software side, the other side is the data side. |
| FreeDOS + Posts: 278/1312 |
A case study of plagiarism
Sure photocopying the book of the plagiarising author won't reproduce the original book, but it doesn't change the legality. |
| MathOnNapkins Posts: 248/1106 |
Well here's the thing I'm unsure of. My disassembly is not reassembleable by any current tools, b/c it's more like a transcribed format. Furthermore, it's not the same as distributing a rom b/c it contains almost none of the data, only code. |
| FreeDOS + Posts: 275/1312 |
But at the point of copyright expiration, it'd also be legal to freely distribute the compiled program too  |
| Ailure Posts: 810/2602 |
I belive I have the SMB source code somewhere, dissassembled and commented. Never tried to compile it though.
And well, it will be legal to distribute disassembled copies of programs in the future, but you have to wait 70 years or so.  |
| FreeDOS + Posts: 273/1312 |
Not everyone knows that they are illegal. Essentially, by distributing a disassembly, you're also distributing the ROM, provided someone can re-assemble the code (which they probably can within 10 seconds of googling) |
| MathOnNapkins Posts: 243/1106 |
So if these things are illegal, then why is stuff like Snowbro's disassembly of Metroid hosted to the public by metroid database? Should they be notified of a potential legal issue? I myself have a full disassembly of Zelda 3, but I'm not quite sure if I should distribute it freely. |
| FreeDOS + Posts: 272/1312 |
So it's pretty much a cruder clean room disassembly. |
| LocalH Posts: 41/65 |
Originally posted by Parasyte + Which is where the concept found here would come into play - it's a link to the instructions included with an Amiga Kickstart 1.2 disassembly. Basically, the comments were distributed, but not the actual disassembly, which was derived from a user-supplied ROM.
|
| Gavin Posts: 120/181 |
Originally posted by LocalH Originally posted by Parasyte + Yes and yes. This is the exact solution that _Hyde_ used to create full NES rom disassemblies with his respective disassembler and NES emulator, SmartRENES and aNESe. Although his emulator lacks full mapper support and I'm not sure how far along both projects currently are, from what I remember it worked well. Run the emulator that produces the label files, then load the automatically generated label files into his disassembler. Like magic. |
| Parasyte + Posts: 9/53 |
Not entirely. The DMCA has some problems with distributing certain source codes within the US, and there are even worse laws against exporting certain source codes from the country. However, there is nothing (to my limited knowledge of the situation) against programs designed to generate such source codes. |
| HyperHacker Posts: 1088/5072 |
Would it be legal to distribute a complete SMW disassembly, though? |
| Parasyte + Posts: 8/53 |
It already handles stack manipulation with recursion. Jump tables containing additional data would be a special case. You would have to keep track of the path taken to reach the jump instruction in question so that it could be traced over more than once (in hopes of getting a different index) Same for indirect jumps which access RAM. Who knows how many pointers could be loaded into the location? Perhaps a label logger could be used to help find all of the tables used to set it.
Otherwise, there's not much left to do until it is "fully functioning". |
| LocalH Posts: 39/65 |
Perhaps one could combine a logging emulator backend with a comprehensive disassembler frontend? It's still going to be a lot of manual work, but this will at least aid in discerning code from data and making sure that the code is properly disassembled based on it's context. For example, if a particular opcode is ambiguous, one could merely enter a mode where the ROM is executed until said opcode is encountered, and then you have context. But definitely, one should aim to catch as much as possible with the disassembler, leaving the emulator to fill in the holes. |
| MathOnNapkins Posts: 236/1106 |
(it can't dereference indirect jumps that pull a pointer out of RAM yet)
This is something that has plagued me for a long time. I don't see how it could ever be achieved accurately unless you were logging it via an emulator. That doesn't even take into account things like PEA and RTS x 2, which can be used like JSR and RTS. I've also seen Jump Tables that occur directly after a JSL instruction. i.e. the JSL does not return directly to the next piece of code. Example: LDA $55 ; This would be the index of the routine to use. JSL tableloader ; tableloader would use the value of A as an index to set up a JML ; to the routines in example_table (which immediately follows the JSL in the binary!) example_table: dw routine1 dw routine2 dw routine3 dw routine4 I've also seen jump tables that were "interlaced." In particular I had three different subroutines pulling pointers from one block of data. It was laid out like this: example2_table: ; routinex_y means that x is the routine retrieving the pointer, and y is the designation ; of which pointer it is relative to routine x. dw routine1_1, routine2_1, routine3_1 dw routine1_2, routine2_2, routine3_2 dw routine1_3, routine2_3, routine3_3 So given the flexbility of the 65816 to execute code I'd really like to hear more about how you plan to map out these types of behaviors. (indirect jumps, stack manipulation, and interlacing) |
| Parasyte + Posts: 7/53 |
I agree.
I have been writing a recompiler to service that very need. (I have not worked on it in about a year or longer, but it is mostly functional.) Long story short, it's a disassembler which intelligently follows code flow using recursion in an attempt to seperate code from data, as well as watching the register sizes. Though very incomplete, it has very great success locating jump tables and following those pointers. A lot is still missing, such as label logging and indirect jumps (it can't dereference indirect jumps that pull a pointer out of RAM yet) but it's functional enough for a proof of concept. Any way, getting a 'clean' disassembly that can be recompiled is the easy part. The hard part is documenting all of the code to figure out what does what. And no one has released a completed version of the easy part, to my knowledge. |
| LocalH Posts: 38/65 |
I still say that there should be an effort to disassemble SMW itself - while ROM editors are nice, there will always be things that you can do with a disassembly but not with an editor. Also, rather than having one single comprehensive editor, I feel that it may be better to create a suite of tools that work together (and that also have the possibility of use with non-SMW games). On top of that, one could have an editor frontend that brings all the tools together to produce the final result. For example, SonED 2 doesn't work with ROM images, but rather split data which can be reinserted to the ROM once edited. And it's quite simple to generate the split data if you have an unmodified ROM. This is also where a disassembly would increase flexibility, as you don't have to worry so much about shifting data around and modifying pointers, all you do is reference the binary within the source, and all pointers are handled correctly when assembling.
Unfortunately, my knowledge is primarily of the Genesis, so I wouldn't be able to assist with such an effort. But, as I said, Sonic hacking improved by leaps and bounds once we started disassembling the games. |
| This is a long thread. Click here to view it. | |
