Take-Two takes legal action against reverse engineered re3 & reVC projects

header-grand-theft-auto-gta-iii-vice-city-codigo-ingenieria-inversa-reclamo-dmca-rechazado.jpg

Back in February 19th, 2021, Take-Two sent DMCA notices to the reverse engineered projects re3 and reVC, (hosted on GitHub). After the takedowns, the project leaders filed a counter-claim, effectively restoring the projects and their whole repositories.

Today, September 2nd, 2021, Take-Two has taken legal action in the state of California, USA, claiming the projects and whole repositories are infringing on the copyrights of their games, Grad Theft Auto III & Grand Theft Auto: Vice City.
Not only is Take-Two suing the main repositories, but also against forks and derivative work (and the devs behind them) that sent the counter-claim back in February, like the PS Vita & Nintendo Switch forks.

The resolution of this case might be one of the biggest legal battles of recent years in terms of gaming, homebrew, hacking and reverse engineering, as other projects that have flourished under reverse engineered premises could be affected in the event of Take-Two winning the case.

:arrow: Source
 

Prb

Well-Known Member
Member
Joined
Nov 10, 2020
Messages
1,032
Trophies
1
XP
3,865
Country
United Kingdom
if take-two would have just released them and made some money for themself none of this would have been necessary

Don't you just hate sour grapes
 

FAST6191

Techromancer
Editorial Team
Joined
Nov 21, 2005
Messages
36,798
Trophies
3
XP
28,373
Country
United Kingdom
if take-two would have just released them and made some money for themself none of this would have been necessary

Don't you just hate sour grapes
No. There is still great appeal in a reverse engineered back to source game, ones that will continue to see these made in secret (or be like ROM sites/let's plays where lists of devs and pubs that are accepting/care and those that don't) if this does go wide and decompilation tools get more and more advanced; while they have been somewhat practical for a little while I would have still been wrong on the timeline here and was expecting another few years at least, especially for console based stuff, as most things in decompilation are still more theoretical stuff that is the subject of research phds and them looking more to advance things a bit rather than rock the boat.

The amount of mods you can do vs the baseline what the devs envisioned in the API, and made tools for, even a good one (and there are so very few of those) or hoping some assembly capable hacker* is massive.

*assembly is rarely taught in schools (if you are curious I suggest https://www.plantation-productions.com/Webster/ https://stuff.pypt.lt/ggt80x86a/asm1.htm and maybe as a more gentle into then this video series, and what little is will rarely be to be used in anger as much as demonstration of why you don't call a function within a function. Indeed many modern compilers might not even support it (gets in the way of various types of security). Even ignoring all that and magic summoning a decent assembly coder the amount of time such things take vs messing with source code (which can be done by almost anybody for some more basic things;if you find a variable saying draw distance and pump it up in most games it might grind a vintage supercomputer to a halt but given your phone today probably has more power...) is considerable.
I might even go so far as to say number of times games saw assembly hackers step in on PC games since the late 90s when I started following all this to do more than remove anti piracy, remove Windows version checks (they sometimes try to gently encourage people to upgrade for no technical reason), remove multiplayer server checks, occasionally be the ones to make widescreen work, and maybe occasionally search things for evidence of future updates (though most things you see erroneously attributed to "dataminers" on gaming news sites are more someone pressing find strings in a hex editor) is minimal, and indeed I reckon you are more likely to find people using assembly in anger in console game hacks where it is still considered hard but an essential step on the path to becoming good there.
That is also saying little about expanding it beyond its baseline abilities; want a make a world 500 times the size, or maybe streaming, multiplayer, all new graphics... all well within reason where the assembly type might be faced with a nightmare project.
General bug fixing; most mods tend to work within parameters of the game. Remove items, maybe block a way, maybe change some stats, maybe make ammo rare, changing a spawn point... this you are literally controlling the game's code and all that entails.
It also feeds back into more conventional level editing as you literally know how the game works/handles data now.

The ability for glitch searchers, speedrun types, cheat makers, in game animation/machinima types to do their bit with this sort of thing is also massively expanded by having source code to play with/look at/ponder.

Some graphics tweaks already mentioned but higher res, widescreen, ultrawidescreen, multi monitor, odd aspect ratio (maybe you have a 16:10), 3d glasses... go from hacky nasty method ( https://www.wsgf.org/ for many) to glorious and able to fix bugs. Nice new filters also get to be a thing.

Porting to other systems as no financially sane dev will port it to half the things it got ported to.
 

smf

Well-Known Member
Member
Joined
Feb 23, 2009
Messages
6,647
Trophies
2
XP
5,894
Country
United Kingdom
They mostly used the disassembled assembly and not directly decompiled code. So that's a fair point I guess.

I'm not saying they can't get sued for it, but the sm64 one was a clean room project. One group de-compiles the code, and writes a document describing the requirements to get the files to run, then another team builds the game from the ground up based on those listed requirements. Then the one that was built from the document gets distributed.

sm64 can't be clean room, no matter how many people were involved, as they said they went to great effort to make sure their source code compiled to the exact same binary as the original.

https://arstechnica.com/gaming/2020...e-effort-to-reverse-engineer-n64-source-code/

"Our goal is to match byte for byte the original assembly code of all functions in the game [after running through the compiler]," Kenix said.

"When there are optimization flags, you have a harder time matching a loop to a 'for' vs 'while' [statement] etc.," Kenix said. "You have to try all equivalent patterns of code until you find the one that matches."

Whether they used a decompilater or disassembler and manually decompiled is irrelevant.

Everything here is true except for the last sentence, which I am not sure about. It might be possible that it only works one way, because the reverse engineered source code is different from the original, and when it is compiled, the binaries are also different.

No, it's not just one way. The differences are irrelevant as copyright isn't limited to bit for bit copies.

Otherwise you could copy a book by changing the formatting, or a movie by mp4'ing it.

The question is whether any expressive code is left, and that is pretty likely if you decompile it all.
 
Last edited by smf,

Zajumino

Well-Known Member
Member
Joined
Aug 1, 2020
Messages
153
Trophies
0
Age
24
XP
933
Country
United States
No, it's not just one way. The differences are irrelevant as copyright isn't limited to bit for bit copies.

Otherwise you could copy a book by changing the formatting, or a movie by mp4'ing it.

The question is whether any expressive code is left, and that is pretty likely if you decompile it all.

You made me think it was not covered by precedent when you said "it's safe to assume." Therefore, it's your fault I was wrong.
Anyways, I found this: "The computer file generated by the disassembly program, the printouts of the disassembled code, and the computer files containing Accolade's modifications of the code that were generated during the reverse engineering process all satisfy that requirement."

With that being said, it can be very difficult to prove that a certain binary was derived from another. The way Apple did it only worked because they were comparing two binaries that were exactly the same, and so contained certain bit patterns that had no impact on the functioning of the code.
 

FAST6191

Techromancer
Editorial Team
Joined
Nov 21, 2005
Messages
36,798
Trophies
3
XP
28,373
Country
United Kingdom
Would I expect someone that otherwise does well in obfuscation contests (judging or making) to be able to lift some code and have me never know (possibly even with source code to both in front of me)? Certainly.
Average person copying code (which by design are generally lazy else they would have rolled their own) of some kind of substantial length? Different matter entirely. Even someone with some basic skills and seeking to obscure things will probably be caught barring them spending more time than would be necessary to make it from scratch.

Bug matching (bugs are inevitable here, http://gria.org/programming-errors-three-common-types/ https://textexpander.com/blog/the-7-most-common-types-of-errors-in-programming-and-how-to-avoid-them for those not familiar with the general idea of programming errors), unoptimised code ( https://media.ccc.de/v/27c3-4096-en-code_deobfuscation_by_optimization ), function names (if present), ordering of code... and that is saying nothing about any traps placed there to detect this (happens often enough for people wandering off with code samples to new jobs).
Granted in this case it is all academic from where I sit; you don't get 1:1 binaries for massively complicated code like this* in a fan project (or even a nation state project) in this kind of timeframe without dipping into the copyright bothering methods.

*I have not bothered to do some kind of line count here, not that I particularly like line counts as a general concept for programming effort, but I doubt anybody would make the argument this is some kind of basic programming effort that any random say phd computer science student might make in a C family language off their own back.
 

smf

Well-Known Member
Member
Joined
Feb 23, 2009
Messages
6,647
Trophies
2
XP
5,894
Country
United Kingdom
Average person copying code (which by design are generally lazy else they would have rolled their own) of some kind of substantial length? Different matter entirely. Even someone with some basic skills and seeking to obscure things will probably be caught barring them spending more time than would be necessary to make it from scratch.

If the average person didn't advertise that they had copied the code, then it's basically almost impossible that someone would ever audit their code. If they don't do something stupid like include text strings/debug symbols that are copied verbatim then even if someone does look at their code, then it would be very unlikely anyone would spot anything.

Bug matching (bugs are inevitable here,

If two people implement an engine independently then they will both have bugs, but they will likely have different bugs.
It's like if we both flip a coin then we should get roughly 50/50 heads/tails, but we won't have the same sequence.

Granted in this case it is all academic from where I sit; you don't get 1:1 binaries for massively complicated code like this* in a fan project (or even a nation state project) in this kind of timeframe without dipping into the copyright bothering methods.

I can't see how they could match 1:1 binaries without violating copyright. Even if someone wrote a description of the function and you implemented it, as soon as you start comparing the output and changing the source so that binaries match then you've failed.
 
Last edited by smf,

FAST6191

Techromancer
Editorial Team
Joined
Nov 21, 2005
Messages
36,798
Trophies
3
XP
28,373
Country
United Kingdom
If the average person didn't advertise that they had copied the code, then it's basically almost impossible that someone would ever audit their code. If they don't do something stupid like include text strings/debug symbols that are copied verbatim then even if someone does look at their code, then it would be very unlikely anyone would spot anything.



If two people implement an engine independently then they will both have bugs, but they will likely have different bugs.
It's like if we both flip a coin then we should get roughly 50/50 heads/tails, but we won't have the same sequence.



I can't see how they could match 1:1 binaries without violating copyright. Even if someone wrote a description of the function and you implemented it, as soon as you start comparing the output and changing the source so that binaries match then you've failed.
Given the paranoia of tech companies and what I have seen there (and what others can handily see with the no compete aspects of contracts, some might be thrown out in court but if they are there in the first place) I would not sign on for the first part of that, even if I would bet on it not being tracked down.

As far as 1:1 matching, and ignoring the hidden functionality/compiler left it in problem (compiler optimisation was not exactly as much of a thing as it is today, see also hot coffee if we need an example relevant in this discussion), then I can see a path with one way functions/hashing/trapdoor functions (combined with some kind of function name and branch/jump... I don't know if anonymiser is the right word but hopefully you see where I am going). You would doubtless have to explain it in court and it would offer no real advantage over basic clean room, indeed be actively more work for very little practical gain, but it is what I could see as a not so copyright troubling path to 1:1 vs anything in the straight disassembly, decompilation and bonus of someone leaving some symbols somewhere camps.
 

Site & Scene News

Popular threads in this forum

General chit-chat
Help Users
    Xdqwerty @ Xdqwerty: @OmDRetro, good point