6 ms·

> Assembler is a bijective mapping to object code, so of course a disassembly of object code is a derivative work of that code This is already wrong. Assembly

> Assembler is a bijective mapping to object code, so of course a disassembly of object code is a derivative work of that code This is already wrong. Assembly is not a bijective mapping. Different dissassemblers will generate different representations and even for the same assembler there is usually more than one way to generate exactly the same machine code. Therefore your completely artificial distinction of dissassembly and decompilation breaks down. > You can take a program that was written in C and compiled to x86-64 object code, and then decompile it into Rust or into Haskell or any other language. You don't have to decompile it into C. And, perhaps surprisingly, this alternate decompilation will still be just as likely as the C decompilation, to produce the original object code when compiled! This is exactly the same Your "Rust" program would still be a copy (or at best, a derivative work) of the copyrighted program and therefore a violation to distribute it without permission. It is ridiculous to think that because I have machine translated a GPL C program into Zig/C++/Rust/whatever I can now freely distribute the translation under the terms of the "Do What The Fuck You Want To Public License". With such a ridiculous interpretation of copyright law, why even bother with the GPL? Quick, someone tell rms! And obviously courts agree it is ridiculous, see e.g. Atari vs Nintendo 1992: "Even though the [10NES] program was written for a different chip and in a different programming language, these similarities suggested that the Atari program was not an independent creation, but an unauthorized copy."

derefr 4y ago
> Different dissassemblers will generate different representations and even for the same assembler there is usually more than one way to generate exactly the same machine code. Apologies, I don't know much about (disassemblers for) modern ISAs; I'm mostly aware of "dumb" assembly languages used in the 70s and 80s, before macro assemblers, instruction modifier prefixes, instructions with opcodes that change based on argument types, etc. In those early assembly languages, the instructions themselves (ignoring labels) are literally just symbolic representations of the opcodes and arguments the machine uses, in a 1:1 mapping. There is precisely one canonical assembly syntax that can be assembled by the system assembler, and it's the same assembly you see in the "system monitor" when you jump to a text section in memory and LIST it. (And, in fact, in these old systems, the "system monitor" and assembler are usually related/sharing code, such that you can modify code in memory from the "system monitor" by specifying a patch in either object-code-bytes or canonical-assembly form.) My argument about bijectivity might not apply to modern assemblers, but it definitely did to whatever assembly language the IBM bootloader was written in. Re: ReactOS, and Re: 10NES... well, just read the Wikipedia abstract for the case you're citing: https://en.wikipedia.org/wiki/Atari_Games_Corp._v._Nintendo_of_America_Inc https://en.wikipedia.org/wiki/Atari_Games_Corp._v._Nintendo_.... > However, the United States Court of Appeals for the Federal Circuit differed from the district court on whether reverse engineering could hypothetically be allowed, declaring that "reverse engineering, untainted by the purloined copy of the 10NES program and necessary to understand 10NES, is a fair use." Thus, Atari was denied the fair use exception to copyright infringement, due to the illicit way they obtained Nintendo's source code. > One month after the decision, a similar ruling in Sega v. Accolade determined that reverse engineering was fair use. Several legal scholars have concluded that the main difference between the cases was that Atari had lied to obtain an unauthorized copy of Nintendo's code. What happened in the 10NES case, and the thing the ReactOS team are trying to avoid, is the team gaining access to a copy of the original IP-holder's source code (to which they have no legitimate right of access.) Doing that would "pollute" the project's legal status, because if such access can be proven, then any work created by the ReactOS team could be claimed to have been created with knowledge of that original Microsoft source code, and would therefore have a presumption of being a derivative work — unless it could be proven in rebuttal that clean-room reimplementation principles were followed. From https://www.lumendatabase.org/topics/15#QID195 https://www.lumendatabase.org/topics/15#QID195: > Courts determine whether or not copying occurred, rather that the independent creation of a program, by comparing the two programs for evidence of copyright infringement. The determination of copyright infringement is done through an analysis of whether there exists a "substantial similarity" between the initial work and the product of the reverse engineering effort. Making such a determination can be quite complicated in the software context since different parts of the computer code may be similar due to the industry standards of the overall structure and user interface of programs as well as their compatibility requirements. In order to prove a claim of copyright infringement, the burden is on the initial work's owner to show that the defendant had access to the original code. The Wiki page goes on to say: > Legal scholars have argued that reverse engineering has since been curtailed by the Digital Millennium Copyright Act of 2000, upsetting the balance established in the Atari and Accolade cases. But to be specific, https://www.lumendatabase.org/topics/15#QID195 https://www.lumendatabase.org/topics/15#QID195: > Circumvention, according to Section 1201(a)(3)(A), means "to descramble a scrambled work, to decrypt an encrypted work, or otherwise to avoid, bypass, remove, deactivate, or impair a technological measure, without the authority of the copyright owner." Reverse engineering, on the other hand, is the scientific method of taking something apart in order to figure out how it works. While not all acts of circumvention require the use of reverse engineering, the reverse engineering of works protected by technological mechanisms requires circumvention. The placement of digital protection systems on copyrighted works essentially fences in the information a reverse engineer seeks to discover about the way the product works. There are no "technological measures" used to protect IP rights (i.e. DRM) in these older works; so no argument about circumvention of such mechanisms pertains to them. The object-code in the ROM is the program, in a readable form, clear as day, sold to the end-user. Only the older arguments about reverse-engineering pertain. Further, guess what "reverse engineering" refers to in the above judgement? Very likely, it didn't refer to "black-box reverse engineering" (which was intentionally impossible in the 10NES case, so the judge here wouldn't have bothered to mention it); but rather something like "decapping the 10NES lockout chip, pulling the 10NES ROM from it, and disassembling that ROM." In other words, the implication here is that not just black-box reverse engineering, but even white-box reverse engineering provides an effective "Chinese wall" to derivative-work status, as long as the original copyrighted work (which is the source code, not the object code) is not accessed by the reverse-engineering team. This case-law has been widely misinterpreted ever since as requiring a higher standard to be met ("clean-room reverse engineering": using knowledge of the original only to implement a specification) — but this higher standard actually only pertains when the reimplementation was informed by knowledge of the original copyrighted work (which is, again, the source code, not the object code — unless the object code "is" the source code, as in the case of the old 1:1-bijective 'canonical assembly' code I mentioned above.) --- Of course, these arguments are all about reverse engineering with a specific pretence: namely, to ensure compatibility for some later-produced novel work that does not itself directly incorporate the reverse-engineered material. These game decompilation projects seemingly cannot be said to be targeting this purpose. Or can they? These projects are clearly informational in nature. On their own, they produce no useful consumable product — they require the original game ROM image in order to output... the original game ROM image. In other words, these projects function as nothing more than a documentation of the original work. Which is an expected and allowed byproduct of the reverse-engineering process. Again, from https://www.lumendatabase.org/topics/15#QID195 https://www.lumendatabase.org/topics/15#QID195 > There have been many attempts by companies over the past two decades to bring claims against software developers for their reverse engineering efforts. Since reverse engineers must make intermediate copies of the original work through the disassembly or decompilation process, the copyright owners of the initial software program have claimed that such a procedure is not covered by Section 117. They have argued that reverse engineering should be considered copyright infringement since some of the retrieved technical data used in the development process includes copyrightable expression. > In Sega v. Accolade, the case most often referred to discussing reverse engineering of computer software, the appellate court determined that reverse engineering is a fair use when "no alternative means of gaining an understanding of those ideas and functional concepts exists." The court considered Accolade's intermediate copying of parts of Sega's video game console during the reverse engineering process in order to make compatible games of minimal significance to the rights in Sega's copyrighted computer code. The court held that forbidding reverse engineering in this context would defeat "the fundamental purpose of the Copyright Act--to encourage the production of original works by protecting the expressive elements of those works while leaving the ideas, facts, and functional concepts in the public domain for others to build on." Which I'll sum up as: you can't take e.g. the Mario 64 decompilation, put your own assets in it, and publish that as a work — that's a derivative work. But you can freely work with the Mario 64 decompilation as an "intermediate copy" to understand Mario 64 while implementing your own clean-room work. The only real question, in my mind, is the legal gray area around how widely one can share/reproduce/distribute such an "intermediate copy for aiding in understanding during a reverse engineering process." If the reversing project is an open community effort, then the "intermediate copy" cannot be kept secret. As far as I'm aware, no case law specific to this subject exists. All we can go on, for now, is the fact that some very litigious companies (e.g. Nintendo) have not yet sued the people doing this. (If you think the problem comes down entirely to distribution of the decompilation, there's a neat solution to that: rather than a repo containing the decompilation per se, one could instead produce and evolve a tool which, on consuming the original ROM image, produces said decompilation, using growingly-complex set of heuristics and edge-case overrides of those heuristics. It'd be a generic decompiler program, just specialized to faithfully decompile and symbolicate a single particular program.)
- AshamedCaptain 4y ago
  > Apologies, I don't know much about (disassemblers for) modern ISAs; I'm mostly aware of "dumb" assembly languages used in the 70s and 80s, before macro assemblers, instruction modifier prefixes, instructions with opcodes that change based on argument types, etc. I was literally thinking about assemblers from the 80s, which are _anything_ but dumb. If anything, it is _todays_ assemblers which may be dumb. Just think how many 8086 assembler kits there were (and are) and whether their syntaxes resemble each other at all. Now single MASM itself and think of how many million ways you have to create a program that builds to the same object code, whether you use macros or not. (Did you use .if or CMP?) > it definitely did to whatever assembly language the IBM bootloader was written in. No. Just no. We have assembly listings of the IBM BIOS. Even the first line of it may be different depending on whether you use DW or DB and still compile to the same machine code. > There are no "technological measures" used to protect IP rights (i.e. DRM) in these older works; This is also wrong, because _there are_. We literally discussed 10NES which is one such method for a console two generations older, and you can see the ones from Paper Mario 64 right in the decompiled source: https://github.com/pmret/papermario/blob/main/src/general_heap_create_obfuscated.c https://github.com/pmret/papermario/blob/main/src/general_he... > Re: ReactOS, and Re: 10NES... [incredibly-long-wall-of-text-that-you-keep-editing-and-moving-from-topic-to-topic-so-that-no-one-has-a-chance-to-interrupt-it-is-really-quite-hypnotic] No one is claiming that reverse engineering is illegal. What is claimed is that decompiling a protected work in full and then distributing that decompilation is definitely illegal. You can definitely decompile for reverse engineering. I have done it as part of my RL work, at least in the EU (which definitely clarifies that you have a right to decompile and _even copy_ the parts that are strictly required for interoperability. Not the entire game). But it is ridiculous to think (and I emphasize: ridiculous) that just because I apply a simple transformation to a protected work I can end up with a non-protected work that is legal for me to distribute without authorization. It would mean the end of copyright for computer programs as we know it. In fact, it is so ridiculous, that even since the act of _compilation_ is also a non-revertible transformation (or in your terms, non-bijective), the actual object code would NOT be subject to copyright ! (Because, despite what you're saying, what is copyrighted is the actual source code, with the object code being a derivate work).

derefr 4y ago

> Different dissassemblers will generate different representations and even for the same assembler there is usually more than one way to generate exactly the same machine code. Apologies, I don't know much about (disassemblers for) modern ISAs; I'm mostly aware of "dumb" assembly languages used in the 70s and 80s, before macro assemblers, instruction modifier prefixes, instructions with opcodes that change based on argument types, etc. In those early assembly languages, the instructions themselves (ignoring labels) are literally just symbolic representations of the opcodes and arguments the machine uses, in a 1:1 mapping. There is precisely one canonical assembly syntax that can be assembled by the system assembler, and it's the same assembly you see in the "system monitor" when you jump to a text section in memory and LIST it. (And, in fact, in these old systems, the "system monitor" and assembler are usually related/sharing code, such that you can modify code in memory from the "system monitor" by specifying a patch in either object-code-bytes or canonical-assembly form.) My argument about bijectivity might not apply to modern assemblers, but it definitely did to whatever assembly language the IBM bootloader was written in. Re: ReactOS, and Re: 10NES... well, just read the Wikipedia abstract for the case you're citing: https://en.wikipedia.org/wiki/Atari_Games_Corp._v._Nintendo_of_America_Inc https://en.wikipedia.org/wiki/Atari_Games_Corp._v._Nintendo_.... > However, the United States Court of Appeals for the Federal Circuit differed from the district court on whether reverse engineering could hypothetically be allowed, declaring that "reverse engineering, untainted by the purloined copy of the 10NES program and necessary to understand 10NES, is a fair use." Thus, Atari was denied the fair use exception to copyright infringement, due to the illicit way they obtained Nintendo's source code. > One month after the decision, a similar ruling in Sega v. Accolade determined that reverse engineering was fair use. Several legal scholars have concluded that the main difference between the cases was that Atari had lied to obtain an unauthorized copy of Nintendo's code. What happened in the 10NES case, and the thing the ReactOS team are trying to avoid, is the team gaining access to a copy of the original IP-holder's source code (to which they have no legitimate right of access.) Doing that would "pollute" the project's legal status, because if such access can be proven, then any work created by the ReactOS team could be claimed to have been created with knowledge of that original Microsoft source code, and would therefore have a presumption of being a derivative work — unless it could be proven in rebuttal that clean-room reimplementation principles were followed. From https://www.lumendatabase.org/topics/15#QID195 https://www.lumendatabase.org/topics/15#QID195: > Courts determine whether or not copying occurred, rather that the independent creation of a program, by comparing the two programs for evidence of copyright infringement. The determination of copyright infringement is done through an analysis of whether there exists a "substantial similarity" between the initial work and the product of the reverse engineering effort. Making such a determination can be quite complicated in the software context since different parts of the computer code may be similar due to the industry standards of the overall structure and user interface of programs as well as their compatibility requirements. In order to prove a claim of copyright infringement, the burden is on the initial work's owner to show that the defendant had access to the original code. The Wiki page goes on to say: > Legal scholars have argued that reverse engineering has since been curtailed by the Digital Millennium Copyright Act of 2000, upsetting the balance established in the Atari and Accolade cases. But to be specific, https://www.lumendatabase.org/topics/15#QID195 https://www.lumendatabase.org/topics/15#QID195: > Circumvention, according to Section 1201(a)(3)(A), means "to descramble a scrambled work, to decrypt an encrypted work, or otherwise to avoid, bypass, remove, deactivate, or impair a technological measure, without the authority of the copyright owner." Reverse engineering, on the other hand, is the scientific method of taking something apart in order to figure out how it works. While not all acts of circumvention require the use of reverse engineering, the reverse engineering of works protected by technological mechanisms requires circumvention. The placement of digital protection systems on copyrighted works essentially fences in the information a reverse engineer seeks to discover about the way the product works. There are no "technological measures" used to protect IP rights (i.e. DRM) in these older works; so no argument about circumvention of such mechanisms pertains to them. The object-code in the ROM is the program, in a readable form, clear as day, sold to the end-user. Only the older arguments about reverse-engineering pertain. Further, guess what "reverse engineering" refers to in the above judgement? Very likely, it didn't refer to "black-box reverse engineering" (which was intentionally impossible in the 10NES case, so the judge here wouldn't have bothered to mention it); but rather something like "decapping the 10NES lockout chip, pulling the 10NES ROM from it, and disassembling that ROM." In other words, the implication here is that not just black-box reverse engineering, but even white-box reverse engineering provides an effective "Chinese wall" to derivative-work status, as long as the original copyrighted work (which is the source code, not the object code) is not accessed by the reverse-engineering team. This case-law has been widely misinterpreted ever since as requiring a higher standard to be met ("clean-room reverse engineering": using knowledge of the original only to implement a specification) — but this higher standard actually only pertains when the reimplementation was informed by knowledge of the original copyrighted work (which is, again, the source code, not the object code — unless the object code "is" the source code, as in the case of the old 1:1-bijective 'canonical assembly' code I mentioned above.) --- Of course, these arguments are all about reverse engineering with a specific pretence: namely, to ensure compatibility for some later-produced novel work that does not itself directly incorporate the reverse-engineered material. These game decompilation projects seemingly cannot be said to be targeting this purpose. Or can they? These projects are clearly informational in nature. On their own, they produce no useful consumable product — they require the original game ROM image in order to output... the original game ROM image. In other words, these projects function as nothing more than a documentation of the original work. Which is an expected and allowed byproduct of the reverse-engineering process. Again, from https://www.lumendatabase.org/topics/15#QID195 https://www.lumendatabase.org/topics/15#QID195 > There have been many attempts by companies over the past two decades to bring claims against software developers for their reverse engineering efforts. Since reverse engineers must make intermediate copies of the original work through the disassembly or decompilation process, the copyright owners of the initial software program have claimed that such a procedure is not covered by Section 117. They have argued that reverse engineering should be considered copyright infringement since some of the retrieved technical data used in the development process includes copyrightable expression. > In Sega v. Accolade, the case most often referred to discussing reverse engineering of computer software, the appellate court determined that reverse engineering is a fair use when "no alternative means of gaining an understanding of those ideas and functional concepts exists." The court considered Accolade's intermediate copying of parts of Sega's video game console during the reverse engineering process in order to make compatible games of minimal significance to the rights in Sega's copyrighted computer code. The court held that forbidding reverse engineering in this context would defeat "the fundamental purpose of the Copyright Act--to encourage the production of original works by protecting the expressive elements of those works while leaving the ideas, facts, and functional concepts in the public domain for others to build on." Which I'll sum up as: you can't take e.g. the Mario 64 decompilation, put your own assets in it, and publish that as a work — that's a derivative work. But you can freely work with the Mario 64 decompilation as an "intermediate copy" to understand Mario 64 while implementing your own clean-room work. The only real question, in my mind, is the legal gray area around how widely one can share/reproduce/distribute such an "intermediate copy for aiding in understanding during a reverse engineering process." If the reversing project is an open community effort, then the "intermediate copy" cannot be kept secret. As far as I'm aware, no case law specific to this subject exists. All we can go on, for now, is the fact that some very litigious companies (e.g. Nintendo) have not yet sued the people doing this. (If you think the problem comes down entirely to distribution of the decompilation, there's a neat solution to that: rather than a repo containing the decompilation per se, one could instead produce and evolve a tool which, on consuming the original ROM image, produces said decompilation, using growingly-complex set of heuristics and edge-case overrides of those heuristics. It'd be a generic decompiler program, just specialized to faithfully decompile and symbolicate a single particular program.)

AshamedCaptain 4y ago
> Apologies, I don't know much about (disassemblers for) modern ISAs; I'm mostly aware of "dumb" assembly languages used in the 70s and 80s, before macro assemblers, instruction modifier prefixes, instructions with opcodes that change based on argument types, etc. I was literally thinking about assemblers from the 80s, which are _anything_ but dumb. If anything, it is _todays_ assemblers which may be dumb. Just think how many 8086 assembler kits there were (and are) and whether their syntaxes resemble each other at all. Now single MASM itself and think of how many million ways you have to create a program that builds to the same object code, whether you use macros or not. (Did you use .if or CMP?) > it definitely did to whatever assembly language the IBM bootloader was written in. No. Just no. We have assembly listings of the IBM BIOS. Even the first line of it may be different depending on whether you use DW or DB and still compile to the same machine code. > There are no "technological measures" used to protect IP rights (i.e. DRM) in these older works; This is also wrong, because _there are_. We literally discussed 10NES which is one such method for a console two generations older, and you can see the ones from Paper Mario 64 right in the decompiled source: https://github.com/pmret/papermario/blob/main/src/general_heap_create_obfuscated.c https://github.com/pmret/papermario/blob/main/src/general_he... > Re: ReactOS, and Re: 10NES... [incredibly-long-wall-of-text-that-you-keep-editing-and-moving-from-topic-to-topic-so-that-no-one-has-a-chance-to-interrupt-it-is-really-quite-hypnotic] No one is claiming that reverse engineering is illegal. What is claimed is that decompiling a protected work in full and then distributing that decompilation is definitely illegal. You can definitely decompile for reverse engineering. I have done it as part of my RL work, at least in the EU (which definitely clarifies that you have a right to decompile and _even copy_ the parts that are strictly required for interoperability. Not the entire game). But it is ridiculous to think (and I emphasize: ridiculous) that just because I apply a simple transformation to a protected work I can end up with a non-protected work that is legal for me to distribute without authorization. It would mean the end of copyright for computer programs as we know it. In fact, it is so ridiculous, that even since the act of _compilation_ is also a non-revertible transformation (or in your terms, non-bijective), the actual object code would NOT be subject to copyright ! (Because, despite what you're saying, what is copyrighted is the actual source code, with the object code being a derivate work).