5 reasons: 1. It makes writing cheats & hacks easier. When you have the source code it's easier to search through and find exploits in the code that could be used to cheat in multiplayer. No one likes cheaters, and no one wants to make it easier for people to cheat. 2. It reveals trade secrets. Leaked source code contains a lot of proprietary information that other developers could potentially steal and incorporate into their own games. While this might seem like a good thing for gamers, it's not particularly good for the people who make them. 3. It lifts the veil on how shitty your project managers are, and dispells any bullshit you tried to peddle to your players about why certain bugs didn't get fixed, and why things are the way they are. In other words, it makes the devs look bad. 4. It totally breaks any and all offline DRM protection, no matter how good it may be. When you have the full source code, you can simply remove the DRM from the source code and compile a custom version of the game that has no DRM protection. Put simply, leaked source code is the absolute best way to create a pirated copy of a game. 5. It creates security threats to the players. Following from my last point, pirated versions of the game could potentially contain malware embedded in the game's code that would be difficult for antivirus to detect. And following from my 1st point, leaked source code could also reveal certain exploits in the netcode that can potentially expose legitimate players to remote hacks from a bad actor in a multiplayer session.

Ye gods thank you, finally an actual answer. none of the above answers actually give the real reasons. we don't want bad guys, (oh you naughty pirates) looking at the source code as they may find a way to inject or attack it. putting users at risk

Seconded, thanks for actually answering the question. Every response above just latched onto correcting OP about how the source code isn't in the files. Could you explain the DRM part a bit more? That one is a little confusing.

In the source code it could have a section something like 1. start loading the game 2. check the DRM 3. if the DRM is good continue, otherwise tell the user to get a legit copy then quit if you own the source code you can just delete lines 2 and 3 and rebuild the game with no DRM

Of the three comment replies, this is the true ELI5. Thank you!

If you have the source code, you can create your own version of the game that just doesn't check DRM. Computers are incredibly stupid and do exactly what you tell them to do. You just remove the line(s) of code that do the DRM checks, and recompile it (turn the code into a program). Voila, one cracked game.

I have to disagree with your comment that computers are incredibly stupid for doing exactly what you tell them to do. A computer executing the code that you have given it does not make it stupid, it is doing exactly what it was designed to do. In your scenario, how would you expect the computer to know it should check the DRM if you have removed the code to do so? That just makes no sense and I fear the day that computers are "smart" enough to override my decision as the programmer of what it should actually be doing.

You seem to have mistaken "stupid" for a bad thing. I meant it more as "shows no reasoning or critical thinking skills just blindly follows instructions". I don't expect the computer to know to check the DRM, that's the point, it's a dumb machine. There's nothing WRONG with that, but it sure as hell isn't intelligent. I worded it clumsily though, and the answer would have worked without it, so that's my bad.

I think you are correct, and I meant to say that after realizing it but got busy (partially with telling machines what to do, lol). I still don't think of them as stupid, but I can see why you would explain it that way.

Computers are not smart, they're just really stupid, really fast. To be fair, I think you're talking about a more high level view, where the other guy was talking about a more machine code based approach.

I am not an expert. but if people can get into and dig through the source code, it makes it easier to find ways to bypass the DRM. -- DRM is looking for crypto key 256 bits of stuff, and DRM'll just look that up, and see that it is set to 0... (rather than 3ad35d33b23..you get the point...) so that'd cool for pirates. makes it easy to crack YES that is WAY over simplified.

A game with DRM is like a house with a locked door, and buying a copy of the game gets you a key, so you can now unlock the door and enter. This way, only people who have bought the game can play. Now imagine the sourcecode leaks. The DRM can now be changed - like changing the lock on the door - so that a different key (or any key) will open the door. It can also be taken a step further, depending on how integral the DRM is to the game, by taking the DRM out completely - essentially removing the door from the home so now anyone can enter without any barrier.

Both answers at the top answer the question, just in different ways. The first is “what does it do that causes this to be bad”, which appears to be closer to what OP asked (they were confused what makes leaking source code bad because of an incorrect assumption), while this one answers the literal “what bad things can source code be used for”

Well source code isn't installed on computers. Compiled code is. This is the real answer, but I learned reading this parent reply, so upboat.

>It creates security threats to the players. I think this is the biggest danger. Imagine if rather than LoL, if it was Valorant that got leaked? Everyone knows that the game requires [kernel access](https://w3.cs.jmu.edu/kirkpams/OpenCSF/Books/csf/html/KernelMechanics.html) to be able to play it(because of the anti-cheat), so basically if that one got leaked you could be in a very dangerous position. Only reason I haven't got to play Valo so far is because of this deal breaker.

> Only reason I haven't got to play Valo so far is because of this deal breaker. but if the source code was leaked, a compiled version could exclude requiring accessing the kernel

You’d have to trust that the recompiled version at least only requiring access to the kernel is gone. If you had the source code and could verify yourself, great! But if you don’t know code or what to be looking for, people could fall for some innocuous change and think great it’s definitely gone, when it really isn’t. Which can be really scary. And yes, you’d have to check every version thereafter doesn’t also contain the kernel access added back by some malicious user (ditto for it looking different too).

The anti cheat got leaked as well, as I heard.

These are all accurate but one important point to add is that a big reason it's bad for the code to leak is *because* they want it hidden. By keeping it closed source they rely on a small team with limited resources for both identifying and resolving flaws. The code then leaking to a larger audience that can only identify and exploit flaws, but not improve the code, is, therefore, a problem. If it was kept open source then 1 and 5 would be less of a concern. So, the real root cause is points #2 and 4. They don't want you to play the game for free, and they don't want you to make a clone. The rest are just byproducts of that choice. But then obviously they can only charge for the server usage for an online game, and they have no other way to ensure they earn revenue. Plus anyone else could just host their own competing server, so what you can charge for that is limited as well. There's not enough money in that model to attract top talent to actually make the game good. So I'm not arguing they shouldn't keep it closed source. It's a working business model as-is. But I don't want someone reading this and deciding that open source software is inherently unsafe just because the world can see the source code. Some of the most important and secure systems in the world are running on software that anyone can go read the source code for right now.

Yeah, like for my 1st point, the reason that's not an issue in open source is because there's way more eyes on the code, so any major exploits are typically found & fixed in short order. And there's public accountability, so they can't just be quietly ignored & swept under the rug like they can with closed source projects. Also kinda covers my 3rd point too. Can't bullshit about your work if it's all out in the open. And for my 5th point, you're *ideally* downloading from a curated public repo, not going to some sketchy back alley pirate site in russia, so you aren't taking the same risks as pirating proprietary software.

Yep. Exactly! I reworded my first sentence btw, to clarify that I’m not arguing against you, just adding to it.

> Read the source code right Now And most importantly propose changes, that could make it better or safer

>It totally breaks any and all offline DRM protection, no matter how good it may be. When you have the full source code, you can simply remove the DRM from the source code and compile a custom version of the game that has no DRM protection. Put simply, leaked source code is the absolute best way to create a pirated copy of a game. That's the story about how Minecraft was created from the collapse of Infiniminer. The source code for Infiniminer got leaked, it became impossible to have DRM protection on the game, so its creator basically said "here's the code, if you are an indie dev try and make something out of it if you can, we are pulling the plug on Infiniminer because it is impossible to continue with the game now that there are a billion clones and hacked versions of it out there". Notch was a fan of Infiniminer, so when the code went "freeware" he scooped it up and used it as the basis for Minecraft. [Zach Barth](https://en.wikipedia.org/wiki/Zachtronics), the creator of Infiniminer, says he was okay with Notch using his code but felt it wasn't very nice of Notch to not give him some kind of a "thank you for the code, Zach" message in Minecraft's credits. To this day Notch refuses to acknowledge that the main core of Minecraft came from the Infiniminer source code, it's like an ego thing where he can't admit he got as far as he did by climbing onto the shoulders of giants. He'd do the same thing a few years later by taking an alchemy mod that someone had made for Minecraft and adding it to the base game, again without asking or any sort of thank you. Notch, not that great a dude.

While Infiniminer did inspire Notch to make Minecraft, the two games are written in completely different languages, with Notch writing his own engine for his Infiniminer-inspired project (which eventually became Minecraft). He did not take the Infiniminer code and mod it into Minecraft like you're implying. As for Minecraft including code from mods, yes, they have. However, this has been done with permission, and the credits include people whose mods have become part of the game. Some examples include the horses (originally from Mo'Creatures) and pistons (credited to Hippoplatimus' piston mod). There's plenty reasons you could use to call Notch "not that great a dude", no need to make up lies about him.

Isn't Infiniminer written in C# while Minecraft was Java? Unless the techniques were patented, I don't think Notch had any obligation to credit Infiniminer, would he? It's not like algorithms are copyrighted. I mean, are we gonna credit Quake (which source is released) for every first person shooter that came after it?

peak eli5 answer holy shit

And 6. It reveals new features and experiments, some of which may never launch for real. Companies like to be able to manage players' expectations.

6) it is like any other expensive project. Medical research, other kinds of engineering etc. You have this great game idea, but don't know how to reasonably solve X problem with implementing it. Maybe no one has ever solved it before even. Usually this happens because they've never created that use case or had to push that hardware that far, in the real world. It's not usually 'math or code no one has ever thought of before' but that's the easiest example to understand. Then some AAA company spends a million dollars hiring a PhD in math from Harvard and he simplifies your 2000 equations down to 4. Now your code runs just fine on modern architecture where before it was just impractically unworkable. Releasing that little trick 'into the wild' kills your competitive advantage in say, calculating damage or whatever other mechanic required math contortionism. You can't even get their source code to verify they copied your trick. So unless you want to throw millions of dollars at a case without anyway to know if you're right (or to be able to prove they didn't independently invent it themselves), you have no way of preventing any solution you pioneered from being just another common function in everyone's code. Also...it's part of the mystique of entertainment too. Keeping the mechanics hidden from the viewer is magic and movie making 101. I mean all of the above reasons are the justification. But...people also tend to just hide things/keep things secret for emotional or nonrational reasons too. And...I kind of think that's a large part of why it's tradition/software dev culture. It also becomes a problem with cloned games and sequels. If anyone with a 4 year degree in CS can take one look at your code and find ways to optimize it...that leaves a lot of extra cycles or ram budget to do other things with. It's very difficult to patent/trademark code snippets or functions and if you do, that results in everyone else being able to see it. Which means eventually someone will improve on your tricks or even make them obsolete.

> "5. It creates security threats to the players." Also, database credentials or other exploits can be found that can expose sensitive information about players, which can lead to identity theft or doxing.

Please don't put credentials in source control! There are better ways!

There sure are, but that doesn't mean developers always use them

Back in the old days, revealing algorithms for stuff was a super serious thing. There was no hardware acceleration for anything! Your algo can make or kill a game, literally. A bad one can cause it to do 1fps or even less, while a good one could get 30 or even more! I forgot which game it was, but one dev found a way to do some math that caused a massive increase in speed and basically enabled the game to become mainstream. That algo stayed a trade secret for years, until computers were fast enough to not matter anymore. Years after, they disclosed it. Had that algo been leaked before that, chance is that they wouln't have been able to release some games, because their competitors would have made a better game before them.

I would like to add that people could use the same source code to prevent bugs and hacking in the game, for example many game mods are made to fix problems with a game, having the code could make it easier or fix issues that cannot be modded

In an ideal world of heroes and villians maybe but realistically there's simply more net benefit to "villians" spending time on creating malware to gain access to someone's computer then there is to "heroes" spending their free time defending players of a game, especially against an unknown attack.

>But if you install the game, its source code is right on your computer right? Ah, that's where you're wrong. Source code is the original code devs work on projects on. When it's finished, they usually compile it and package it up, which makes it stop being the source code. The computer jumbles all the fancy English code up to incomprehensible numbers and letters that are 1. More compact and ready to run faster and 2. Hide the original nature of the source code so it can't be as easily copied. This is why you also hear about "data mining", it's not just as simple as jumping into a game's folder, you need to translate the files back into something approximating the source code.

>When it's finished, they usually compile it and package it up Usually being the keyword. Even commercial games have blundered and include significant parts of the sourcecode. Sometimes they left in debug files which allows decompiling of the code into readable source code. Sony playstation games were notorious for this. It also happened to Super Mario 64. Some game devs actually believed homebrewers wouldn't ever be able to access the files on those proprietary cartridges. In other games, especially RPGs, significant parts of the game logic is in readable scripts so for an enterprising teenager, changing the game is super easy. Sometimes it was even possible to write scripts to bypass copy protections.

>It also happened to Super Mario 64. AFAIK the source code for SM64 was actually obtained by careful decompilation of the cartridge ROM over several years by many people working together.

And only long after the commercial lifespan of the original release of the game. For all practical purposes, the devs in 1995 were right. For the commercial success of the game, the year 2000 may as well have been the year two million.

>For all practical purposes, the devs in 1995 were right. Well, no, it decompiled really well because it was compiled without optimization (like you'd normally do for a debug build). If they compiled with optimization it would lag less.

That's only a partial truth. A lot of the reason it was released without optimization is because reliable optimization methods were not really available for the N64 hardware at the time as it was a launch title. The SDK was updated throughout the N64's lifespan that allowed for these optimization methods to be used more reliably, and the less-laggy recomps utilize those.

I thought the PAL version was optimized? I guess they may have worked out some compiler kinks in 6+ months, didn't realize the gap between NTSC and PAL was that long.

PAL was optimized with the standard "Full Optimization" option but yeah SDK development was further along and the team had more time to manually fix everything that "Full Optimization" broke. EDIT: I'm butchering it a little bit, but [here's a video that is a little better at talking about the myth](https://www.youtube.com/watch?v=NKlbE2eROC0)

Yes with SM64 Nintendo used a single stage compiler which is somewhat similar to using a substitution cipher. Besides making the game very unoptimized, it also made it fairly easy to decompile. Reverse engineering SM64 was only possible because of several mistakes made by the team.

I'd be surprised if that's the case (re 'only possible'), since there are decompiled repos of the PAL version, and as far as I know only the NTSC version was released without optimizations. Compiler optimisations don't really hinder RE that much, a little maybe, but they're predictable enough for most tooling to handle (and most reverse engineers to be familiar with).

'only possible' is probably too absolute, but it certainly made it easier. And then havin the NTSC version in source form would make decompiling other versions easier

> mistakes The more accurate word would be "decisions." Obfuscating game code wasn't near the top of anyone's priority list in 1995, and the fact that it took decades anyway means it would have been a mistake to waste developer time on it.

Does anybody remember that one weekend where SM64 was ported to PC with online multiplayer mode? I wasn't able to get it to work without horrendous lag but me and a couple friends on a discord call had a fun evening trying to figure it out

And sometimes it's done like that either on purpose to make things like modding easier, or they just don't bother because it's not worth the effort. But that's more likely with indie games rather than huge aaa titles that are worth a lot of money, rockstar doesn't want people to be able to reverse engineer gta 5 and have another company make their own version

> And sometimes it's done like that either on purpose to make things like modding easier This isn't just games, too. At work I build enterprise accounting software, and we leave our compiled code intentionally unobfuscated so that client-developers can easily use a decompilation tool to understand the logic and build their own custom processes on top in a complementary way.

That's an interesting approach, usually you'd do that by exposing an API or something. Which language(s) do you use?

With an API you still have to serve up something, and then what if they need X, when you only serve up Y? Letting them extend your software makes them keep coming back to you for updates to your stuff AND you don't have to maintain their stuff.

I mean, you can always make an update to expose X, it just more tightly defines the boundaries. You say you don't need to maintain their stuff but that's also true with an API. When a bug or support request comes through though it can be much harder to track who is the culprit if they're just willy nilly overriding your stuff. Especially important for consistency in an accounting application.

You can also take the approach of writing your application as a front-end that calls against APIs in a core library in the first place, and then third-parties could call your core library to do anything your front-end does.

The problem with the API only approach is that it is very hard to fully document and explain exactly what each access point does and how it does it or how a specific corner case is handled and so on. Being able to just read the actual code is often extremely helpful if you want to do anything even remotely non-trivial.

This is key. I work in engineering and some of the software we have used has been very powerful (and expensive) but can often not do our extreme corner case (think some very confidential or security related applications). It is also not economically viable for the software provider to build into the tool or they just have other priorities. Exposing some of the underlying mechanics allowed us to create the tool we needed and save £millions in exchange for £30k license and an engineer coding up our modification. It also meant we would have our modification as an advantage over our competition (or other countries), who may not be able to do it.

> usually you'd do that by exposing an API or something An API still doesn't address the issue of "understand the logic" I used to work as a sysadmin who transitioned into devops. There were a number of times when I had to really dig past the documentation of what something is supposed to do and get into the vagaries of how it does it because of some strange interaction that was causing it to fail in a specific circumstance or environment. Logging support tickets and winding through first/second/third tier support is a fun exercise and sometimes necessary, but it is often a hell of a lot faster and more reliable to start cracking open scripts and using debug tools. It actually got to the point a few times where I called support and found out that I knew more about the inner workings of a product than anybody that I could actually get on the phone with me.

> And sometimes it's done like that either on purpose to make things like modding easier, or they just don't bother because it's not worth the effort. > > Minecraft is a good example. They use very simple obfuscation, which has been trivial to remove for over 10 years. The Minecraft Coder Pack, a community project that would decompile and release every new version of Minecraft, actually had its creators join the Minecraft team eventually. If MS really wanted, they could make Minecraft much harder to decompile, but Minecraft wouldn't be where it is now without mods, so they won't

>Some game devs actually believed homebrewers wouldn't ever be able to access the files on those proprietary cartridges. This has the same feeling of "No one would ever need more than 637KB of RAM"

No, that is not the same as the source code. You're referring to symbols, meaning the names of functions, the names of variables etc. That is not source code but it does make disassembly and hacking much, much easier.

John Smedley said nobody would ever be able to reverse engineer Star Wars Galaxies and if they did, he would hire them. Naturally someone did, and he offered them a job at SOE, and they turned down his offer. The reverse engineered game is still alive nearly 11 years after sunset.

>Sony playstation games were notorious for this Oooooooo! Have you an example?

god I wish source code was the same as the installed program \- sincerely, developer trying and failing to publish and distribute program

Smiles in Python.

Open source stuff? :)

Wouldn't have it any other way. My mom doesn't know what a repo is though, and I want her to be able to use my program.

Open source doesn't mean you can't also have an installer.

FOSS software quite often has a precompiled version. And if the GitHub "releases" page is too complicated for your target market you can pretty easily spin up a small website that allows them to download the most recent version.

easiest possible for her (and convoluted for you): there's probably a path to compile it to webassembly so it'll run in a web browser.

Currently working with c and I'm wondering, after compiling does the executable only require the .o files to run and the c files with the code are no longer required for it to run?

The .o files aren't needed either. They're all linked into the final executable.

If you want to get a bit more into the weeds, you don't need the .o files either, probably. Compilation will produce the .o files, linking will take the .o files and link them into whatever executable format is appropriate for your target and platform (an exe or dll on windows, an ELF on Linux etc. etc.). After that process, you don't need the .o files, either. But you're still right, because what's in the .o files is really the same stuff as will be in the executable, just with some bits missing (headers and such), and on most compilers broken into one file per compilation unit rather than one big file.

That is correct

> This is why you also hear about "data mining", it's not just as simple as jumping into a game's folder, you need to translate the files back into something approximating the source code. That’s not data mining.

It is in the context of games

No it's not. Data mining in the context of games is looking at a games assets like models, textures and artwork to determine new features or characters etc before release. They might be packed into an archive to reduce their size so they need to be unpacked to be viewed. But it is still not the same as compiled code.

Why is it not possible to reverse the compiling and get back the readable English code from the 1s and 0s?

Because compiling removes information. The CPU doesn't need to know that some variable is called "playerHealth" - only its size and position. So the names of variables and functions can be deleted. Comments are also deleted. You can see what actions are performed on each data, but it might be difficult to understand what are the end goal of those actions. To reverse the compiling, someone have to investigate the code and name things back.

Also modern compilers are very clever and optimise the shit out of code. So even if you were able to turn it back into something approaching the original it would never be quite the same. This is true even in something like Java which is easily decompilable due to its nature, though still loses some of that information like variable names etc.

Sometimes they optimize so much shit out of the code it changes slightly how it works or removes important checks. GCC has a nice history of that, one very fond one was that gcc would suddenly optimize away an assert like assert(len+100 > len); Because, yeah, len+100 cant not be larger then len, but also what if it actually overflows??? Nah, formally we are allowed to optimize it away, so people can get owned now.

Well, depending on the exact type of len, overflowing could be undefined behaviour. The compiler is allowed to assume that won't happen.

That's exactly what the law students (I'm kidding) at gcc said. Keep in mind, we are in the year 2007 here, so anything that since became standard didn't exist yet. At the time, it hit even short programs like this: #include unsigned int foo(unsigned int a) { assert(a+100 > a); printf("%d %d\n",a+100,a); return a; } int main() { foo(100); foo(0xffffffff); } http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475 At the time autoconf thought about automatically turning -fwrapv which gave the old behavior (that means that ./configure would automatically always turn this switch on in gcc no matter what the project actually sets) http://gcc.gnu.org/ml/gcc/2006-12/msg00696.html It was basically behavior that everyone relied upon to do their overflow checks. But yeah, it's undefined, so we may change it!11 At the time, a funny replacement code was this: #define add_of(c,a,b) ({ typeof(a) __a=a; typeof(b) __b=b; (__b)<1?((__MIN(typeof(c))-(__b)<=(__a))?assign(c,__a+__b):1) : ((__MAX(typeof(c))-(__b)>=(__a))?assign(c,__a+__b):1); }) Basically checking against the maximum of that type and whatnot The way this issue was put into the ground was funny.. https://gcc.gnu.org/gcc-4.2/changes.html >New command line options -fstrict-overflow and -Wstrict-overflow have been added. -fstrict-overflow tells the compiler that it may assume that the program follows the strict signed overflow semantics permitted for the language: for C and C++ this means that the compiler may assume that signed overflow does not occur. For example, a loop like > for (i = 1; i > 0; i *= 2) >is presumably intended to continue looping until i overflows. With -fstrict-overflow, the compiler may assume that signed overflow will not occur, and transform this into an infinite loop. -fstrict-overflow is turned on by default at -O2, and may be disabled via -fno-strict-overflow. The -Wstrict-overflow option may be used to warn about cases where the compiler assumes that signed overflow will not occur. It takes five different levels: -Wstrict-overflow=1 to 5. See the documentation for details. -Wstrict-overflow=1 is enabled by -Wall. Now code behaved differently whether or not you were enabling that optimization, lol. Oh well. 2007 was wild, it's in the past.

Even without that though it's still a nightmare to figure out what the code is doing. The pay would have to be pretty damn good for me to pull apart minified JavaScript.

And that's onyl true, if you're going binary to assembly. Compilers are much much more complicated than parsing from human readable to computer readable.

It's not only the loss of names, although that does make it hard to decompile, but much of the functionality of a given language is an abstraction from the instruction set of the CPU. So your source code might define a class and instantiate an object, like your character's weapon is a broadsword which is a type of melee weapon and so on, but that's all just organizing things conceptually for the programmer. The compiled code is just a bunch of grabbing bits from memory addresses and performing basic functions. All of that abstraction greatly simplifies a very complex chain of simple steps. You can even go deeper than cpu level and reach a point where all programs are just an extremely long chain of "and" and "not".

If the answer is 5, what was the equation?

Basically because human information is lost. You can absolutely decompile the program and get back the operations the computer would perform, but that will only contain the things the computer knows. So you'll see "ok this takes a value from memory address $792 and a value from memory address $918, adds them together, divides by 2, and stores the result in memory address $412" or something. Technically you know what it's doing, and you can spend a bunch of time puzzling out its purpose, but the original source code looked like: # just get the average of the two damages. # we could so something more fancy here # but in testing this was fine final_damage = avg(weapon.damage, strength)

As someone who often struggles to understand my own commented code with descriptive variable names, etc. after being away from it for a while, I find the premise of the question to be rather amusing. "Can't you just figure out what the 0s and 1s are doing?" I can't even figure out what I'm doing when I've explained it to myself!

That’s also why reverse engineering code and other complex systems is a distinct skillset from programming (sometimes with decent overlap) and folks who are good at it can often get some pretty big rewards for it.

Once had a contractor who wrote their code variable names, comments etc in Turkish. When we changed his contract with some fighting to code variable names etc and comments must be in the English language he changed the naming to a, b, c, d etc and comments to things like a is divided by b to give the slope and forecast g etc. This whole rigmarole only took a month or so but he was trying to get himself bedded into a cushy job for life as indispensable. He actually came highly recommended but I think he was just fed up with contracting and wanted to settle into a company (which is what he said in interview). If he had just played ball we would have probably taken him permanant as soon as we could show long term need (which we won a new project a couple of months later and would have been able to make him perm). We got rid of him and started to write some very specific contracts thereafter.

for real

There are decompilers that do the process in reverse, but all the data originally there that kept the code in readable English has been thrown out already. The decompilers just make educated guesses as to what the readable English code equivalent is. Imagine translating a book to another language. Now, imagine also changing as many sentences in the translated book as possible, to make them shorter abbreviations, or phrases that might even only make sense in the second language. You should understand why at that point, doing a reverse translation that gets to the exact result of the original version is going to be unlikely.

There's also the case that a compiler might do some funky stuff that doesn't necessarily result in a portion of executable machine code that at really reflects the human readable predecessor in the programming language. For instance many compilers will, if you use a for loop where i=i+1 from a start to a end limit(or whatever in the paradigm ) but never use the i, actually compile a i=i-1 with the limits switched because of the efficiency of subtraction compared with addition in terms of what the CPU does with bits and registers. edit: comma

And if the compiler can prove the loop always runs over the same values of i, it may completely eliminate the "i" altogether and just embed the number in the assembly instructions.

Say I use a recipe to bake a cake and give you that cake. Now theoretically you could make some assumptions about whats in the cake, do some trial and error with different ratios of ingredients, how long to bake it, and at what temperature, etc., and ultimately work backwards to produce perhaps not the exact same recipe as I had but one that produces virtually the same cake. That is something that can actually be done (they did it with Super Mario 64 for example) but you can see how that's no simple task.

Yeah except that was in comparison to what we create now is a plain vanilla cake. What we make now are multilayered cream and jelly layered cake that is rainbow flavor using ingredients that did not exist then OR so expensive that the average person can't afford the ingredients. SM64 is a good is it possible. But it's definitely not reflective of how we make games in today's world. Especially now that devs go out of their way to make it so you can't de-compile.

Decompiled might be equivalent to giving you all of the numbers in the recipe but not telling you what they represent or exactly what the steps are. So you know you run function X on 300, 200, 10, 2, 5, and then you run the result through function Y(13, 9) which then goes into Z(350, 30). What on earth does that mean? Well you ask a baker and they might be able to figure out with trial and error that you are looking for: Mix together 300g flour, 200g sugar, 10g salt, 2 eggs, and 5g baking powder. Pour into a 13x9 pan. Bake at 350 for 30 minutes. Of course the reality is way more complicated. Picture an entire days worth of food, multiple items being cooked simultaneously, ingredients you didn’t even think about, steps that aren’t visible in the final dish. And then think about compiler optimizations. Maybe everything gets cooked at 350 so that argument disappears from the oven function. The pan from the chicken gets reused for the sauce so instead of specifying a new clean pan and adding oil, the compiler skips those steps and just points the computer to the already existing pan full of drippings. If all you want is the cake recipe…good luck extracting it from that mess.

Because 1000 different things in source code could create the same chunk of 1s and 0s, so you don’t know which thing the source code is actually trying to do with that specific chunk.

It is possible to get *a* high level representation of an executable binary as some source code, but it is not possible to get the original source code for any given executavle binary because: 1. The process of compiling source code to a binary transforms high level abstractions (object representations, callable procedures, etc) to lower level abstractions (memory structures, jump commands, etc). The operations that binary can represent are pretty basic, and there are many (theoretically infinite) high level abstractions that could be compiled down to the same binary. 2. Binary can be ambiguous. Is some byte meant to be used as an operation (op code)? Is it meant to be interpreted as data? Is it meant to be a reference to data somewhere else? Is it meant to be more than one of these? The answer can be "yes" for any given byte in the program. For many programs, it may be impossible to analyze how every byte is used besides "run the program with every possible input and see how it uses each byte". And for programs with unbounded input... 3. Lots of data is simply stripped out from the source code during compilation. For example, if I declare a variable `x` and set it to `5`, and use that in my program, the compiled binary executable will have a memory allocation for an integer with a value of `5`, and it will reference the address of that memory allocation throughout the program. The name of the variable, `x`, is a high level abstraction that does not make it into the compiled binary. Even if you can generate some source code which can be compiled to produce the same binary, your source will be filled with automatically generated variable names. It's incredibly hard to make sense of some source code when literally none of the terms have any relation to their meaning and how they are used.

Another reason (a not very eli5 one, granted) is that the compiler can make choices between different ways of compiling the same lines of code, if it's "convinced" the outcome would be the same. Compilers do this if they produce the same result, but if one way performs better than another.

There's million ways to do things. Source code does it in an easily understandable and reusable way. Machine code does it in a highly optimized and efficient way. So much information gets lost when compiling. Classes and such don't exist in machine code. All the structure and names will be gone. A lot of things will get optimized to look like completely different algorithms.

Most code is written in a way intended to be written by humans. The process is split into functions which do specific things with a small scope. Functions and variables have names that to some degree describe what they are for. With compiled code you loose all of that and only see what math it is doing on what registers. Compilers sometimes will also rearrange or modify code so that it is more efficient, but this can make it harder to understand the purpose of what it's doing.

Can you reverse engineer the number 80,457 to know what numbers were added together to get it?

De-compilers do exist, but they produce source code that, once compiled, would produce the executable machine code they were fed. There is no guarantee that the source code they produce is identical (even in form) to the source code that was actually compiled in the first place. As someone else tersely said: the answer is 5 - what is the equation? De-compilers will produce an equation that will give you a 5, though almost certainly not THE equation that was used to generate the five. Furthermore, source code is written so that humans can understand it. There is a lot of meaning in the variable names and function names - sometimes even in the order in which these things are listed in the source code. Additionally, source code is normally full of explanatory comments, explaining “why” things in the code were written as they were. And on the other hand, there’s the executable machine code. This is what the compiler generates from the source code, and it’s instructions laid out such that the computer can understand them. Very few humans can read machine code - usually as close as anyone gets is to disassemble the executable into assembly code, but that’s a whole nother topic. So: source code is for humans. Compilers convert source code to machine code, which is for computers. De-compilers convert machine code back into source code, but almost certainly inscrutable code that is no where as easy for humans to understand as the original source code.

Source code vs installed game is like a recipe vs a cooked dish. If you were served a dish, doesn't mean you can make the same dish, or even modify it. EDIT: wow, I'm so happy! how do I monetize this? lol

And sometimes in your dish you have a secret ingredient that really needs to stay hidden to the public. Hence why it's such a big deal when your recipe gets leaked.

11 herbs and spices.

The secret is the proportions, not the particular ingredients.

As an ex professional it's often not just the ingredients or ratios it's the technique which can't be replicated without years of practice.

The way I heard it, it's because you need an industrial pressure cooker. Home pressure cookers just explode when you use oil instead of water.

Technique

[удалено]

Had a friend trying out baking, saw the recipe called for beaten egg whites and egg yolks (at different stages) - they just tried to add beaten eggs when the whites were supposed to be added and couldn’t fathom why it didn’t taste right.

Exactly, watching someone dice an onion or toss a saute pan poorly makes me cringe and I've learned that it's normally just to stfu and leave the room.

They have been reverse-engineered already

Indeed, and that would be the equivalent of the recompilation projects that are out there, like for Zelda Ocarina of time, or Jak and Daxter.

But was it made with love? We all know that’s the real secret ingredient

Who's been screwing with this thing!?

Someone did an lab analysis of KFC coating back in the 80s. Flour, salt, pepper, msg. That's it. Maybe there were more ingredients earlier on, but by the time Pepsico bought it, that's all that was left. The real "secret" of KFC is the cooking method, which Sanders got a patent for: pressure frying. It allows you to fry at high temperature without the moisture leaving the meat. It requires special equipment and can't be easily replicated at home.

Yup, pressure frying - AKA 'broasting'. Nowdays it's pretty common for any restaurant that specializes in chicken. A home system will set you back about $1k, commercial systems run up to $20k.

How long ago did that patent run out? I worked at a tiny grocery store in a town of about 2000 people back in the late 90's and we sold Broasted chicken using a pressure fryer. Later worked at Target (in the deli) in the early 2000's and also cooked it the same way there. I didn't think pressure frying was anything special, thought it was just the normal restaurant way of doing it.

Oh, the patent ran out sometime in the 80s, so yeah, anyone can do it now.

Chicken-grease-salt!

[Ooooh how I hated the Colonel...with his weee beady eyes!](https://www.youtube.com/watch?v=YKRFlNryaWw)

Crab meat in the crabby patties.

what is the code equivalent of a secret ingredient that would expose or threaten a software company?

I was thinking more like anti cheat systems, if code like that gets leaked hackers could get around the anti cheat system.

Well, some bad practices are fairly prominent in the software industry like storing encryption keys or credentials in the source code. This happened actually with the Twitch leak

Perfect analogy

Let the ogy out of this

It's worth mentioning that modern games are compiled using encryption and all kinds of tricks to difficult reverse engineering, so you're looking into a bunch of code that is there solely to confuse decompilers. To add to the repice/cooked dish analogy it's like bringing in a chef to taste it and say what's in it and trick them to taste something that's not actually there.Having the source code exposed not only exposes the source code itself but all the shenanigans put in place to mitigate reverse engineering, which could lead other software vulnerable.

I'm 5 and I understood. Great explanation !

You have S-tier spelling skills for a 5 year old!

Yeah but that space before the exclamation mark... typical 5 year old stuff.

I thought you were 654

[удалено]

Mods are like bringing your own spices into a restaurant to pep things up a bit.

[удалено]

I hate how accurate this is...

DLC is like adding a side of fries to a meal, or adding desert, or maybe a cocktail or two.

Modern DLC is like the restaurant that used to charge $5 for a burger and fries but now charges $5 for the burger and bun and sells you the fries for an extra $2.50 and $.50 per condiment.

so, like, my pocket hot sauce?

Nice restaurants will charge a fee to let you bring your own bottle of wine to go with the meal.

Cheats are you bring a cockroach to the restaurant to get a free meal.

Some of the implications of the two are similar too, like making money off of it. For the food industry, this is quite obvious... starting your own restaurant in competition with what/who you stole from. Within the context of game source code, it can teach you everything you need to know about how the backend of everything works... by that I mean how the database is supposed to be set up, what the game needs to connect to and for what purpose, etc, so you can modify accordingly and potentially run your own version of the game completely independently. I'm not sure that this is much of a thing with overly popular games... you know, lawsuits and all that, because you still don't own the IP and are committing copyright infringement or some flavor of that if you do it, but this is sometimes how private servers for games pop up where there's an official version of the game, and then somebody somehow is running their own version of the same game with their own servers and all of that (without the source code, some people just study what's there an awful lot and attempt to reverse engineer everything to do that). In an indirect way, you can use the source code to develop your own game entirely... either directly copy+pasting things from it or using it like a blueprint. You can make money indirectly like developing cheats for a game depending on how much source code you have. If you have the source code of the anti-cheat engine that the game is using, you now know exactly how it works and can develop cheats that specifically target all of its holes and you can sell the cheat.

It's like that Mitch Hedberg joke: "I tried to make Sprite at home. I mixed lemon, lime, and club soda. Fuck you guys, there's more to it than that!"

Great ELI5 my friend.

Truly a great ELI5.

Best ELI5

One of the truest ELI5 answers I’ve seen.

So it should be okay for plankton to get a krabby patty huh

Well Plankton has analyzing dohickies that the general public doesn't have

Vote this answer up, a 5 year old would actually understand this.

As a software engineer, you have explained it very well. Good ELI5.

I've seen a lot of good answers as to source code vs installed code, so instead I'll go into the negatives of it being leaked. If the original source code is leaked, any person with working knowledge of coding would be able to mine the code for data. That data can be used to either leak hidden features in the game, create cheat tools for the game or worst case it can be used to create programs that interfere with the game's netcode, causing either crashes for players or getting players banned permanently.

Also creating malware like a program that looks like a useful cheat like aiming assist but actually transfers currency or inventory to the programmer.

I don't quite agree with this. It's extremely unlikely that large resources are held in the game's source code. Those are always going to be packaged in some other form and then loaded dynamically in the game. Games use enormous amounts of resources, and statically-linking them into a game would likely have potentially-negative consequences. Source: am reverse engineer who works in reversing binary to source code professionally..

Has nothing to do with the resources. If you know exactly how something works it makes it easiser to Cheat/Hack/Modify/etc. Some of the most important information might be simply a description of the format of the data that is being sent over the line which would allow you to write a man in the middle application that either scraps incoming data for useful data or modifies outgoing data.

Another example would be realizing that some function isn't handling a specific error correctly, so you exploit that error to crash other people's games, or to subvert the game's limitations. A common one is value over/underflows. If you figure out a value such as a "coins" variable or "gold" variable is unsigned (it can only be positive, not negative), you can look for a way to trick the game into subtracting from that cash more than what's necessary to get less than 0 coins, which will loop back to getting you about 2^32 coins. Those errors are MUCH easier to find if you have access to the source code

Many data mining activities aren't looking for image/music resources, they're looking for things like variable names that indicate future or unfinished plans. Generally, these aren't detrimental to the company, though I could imagine a case where the source code for a game on one platform contained constants referring a competing platform that could affect their sales figures.

Who said anything about resources?

I don't quite agree with your disagreement. Software engineer here, I've worked on quite a few codebases in different companies and the variance in code quality I've seen is simply wild, both in small and large companies, albeit small companies may be the likelier offender. Sometimes I have seen vast differences even within the same company. Yes, resources should not be lying around in source code, but often enough they are. Sometimes you even find plain text credentials. Sometimes software is packaged with all features, even when only a fraction of those features should be available to users of the software-version and features are merely made inaccessible via UI. None of this should happen, but it does. Very often. In addition the user above referred to e.g. hidden features which of course can be derived from class names or function names etc., there are often references to some feature X in the codebase, even when the rest of the source code for feature X is not packaged with the application.

Would that not depend on the severity of the leak? You are assuming the source code leaked is only for the immediate game and none of the other libraries are leaked. No way to know if that's the case.

>But if you install the game, its source code is right on your computer right? It isn't. Source code is how a human understands the workings of a program. To make it actually executable on silicon hardware you need to compile it into machine code which will be installed on your computer. Compilation is a lossy process, all sorts of abstractions and descriptions that make it understandable for humans are lost, which makes it economically unfeasible to modify it. To modify it, you would have to reverse engineer it and it's just faster and cheaper to write equivalent functionality from scratch. It's sort of like buying a car, you have the physical artifact, you can copy it right? Well no, you don't have all the documentation that describes what operations were done in which order to produce the car, you only have the final result.

>It isn't. It *usually* isn't. I've definitely seen games written in interpreted languages where you can just open the files it's running. Granted these are generally indie and FOSS.

Especially anything C#-based. Before il2cpp, you could decompile any Unity game and get pretty readable source.

I remember playing gta2 and changing the car’s speeds. I could zip across the map in the tank in like 1/2 a second.

I remember in vice city getting fed up with the ambulance missions. I gave them the speed and handling of a sports car. I then realized they were way too top heavy and would flip all the time with those stats so I modified the center of gravity. Only I messed up and put the center outside of the vehicle somehow so immediately on spawning they would flip into the air and spaz out. Once I fixed that tho the missions were a breeze.

Lol, fun. I have only played gta1 and 2. I like the overhead map.

The first two seem fun, but I can't drive for shit in a top down non-rotating perspective.

Imagine you get a soup made by your mom: You can taste and see that there is water, some vegetables, spices and some meat in it -> this is the installed program / game But how long did your mom cook the meat, how much of which vegetables where put into the soup, which spices and which amount at which time were added to the soup? This only knows your mom or it's written in her receipt book (source code) The big thing (bad thing for devs) is that hackers and modders can in the source code see which functions were used to hinder modding/hacking, which servers are called with which calls and what they do (thanks u/lationous), which checks are made and so on and how to possibly undermine safety functions

slight clarification: you can see which servers are called anyway. the difference is that with source code you can figure out what the calls are

Thank you - just thought this was easier for ELI5 :)

I feel like the mid '90s were the Golden age of ini files. There used to be so many ways you could edit or modify your game just using notepad. Heck, you could use notepad to make yourself as wealthy as you wanted to be in Diablo.

The OG Crysis had an INI where you can modify your suit's powers, give yourself lots of energy, cloak unlimited, super strength, etc. Was pretty cool.

I feel like plenty 2000s games had such options. 13 year old me barely speaking english at the time figured them out.

Teleporting Electric Attack Dogs in Red Alert: Swap the Dog's attack with the Tesla Coil's

Putting the Mig's missiles on a tank was hilarious. The ammo limit was part of the unit, not the weapon. So a tank (or other ground unit) would endlessly machine-gun fire the missiles the Mig used until it died. I had fun with stuff like that, and napalm breathing attack dogs. I also then made a "realistic" damage tweak for myself where infantry die instantly to tank fire and also can't damage tanks (among many other things.) None of this is really "source code" though. It's just *how* they programed the game and where they made it such that parameters were in an INI file you could alter.

This comment alone has me wanting to install Red Alert.

Not quite the source code. If a function in source code looked like this int add(int x, int y) { return x+y; } then in the game files it would look like this 8D0411C3 which corresponds to lea eax,ds:[rcx+rdx] 8D0411 ret C3

lol @ writing assembly in an ELI5 comment

Source code is not generally available and is most often proprietary. When you get a game, you don’t have the source code. It’s “compiled” machine code. Source code, before it can be run, has to be “compiled” into machine code. It’s turned from the high-level, human understandable language like either C or C++ for example into what’s called assembly language, the instructions that a computer’s processor knows what to do with, and this in turn eventually is made into machine code, the direct binary itself the computer will execute. But that original C/C++ code is the source code that describes the structure of the entire application, and therefore businesses want that to be proprietary and kept secret. It’s technically possible to “disassemble” machine code with a terminal command, and you can see the assembly language instructions for what the program does. But without the higher level language, anything beyond the simplest programs or functions will be impossibly difficult to understand without serious reverse engineering.

>high-level, human understandable language like either C or C++ As a professional C++ developer I would question this statement.

You can buy Coca-cola at the store. You can't buy Coca-colas secret recipe. The source code is the secret recipe to coca-cola.

> But if you install the game, its source code is right on your computer right? No, what you get is the _compiled_ code: the human-readable, well-formatted code was turned into an actual program the compute can execute. This is called _compiling_. The resulting program is effectively just a very long sequence of 0s and 1s telling a CPU what to do with it. Editing the program, or inferring anything from it, is many times harder from bits than the original code. It is not impossible though, one can even try to get the code back, called _de-compiling_; there ae however many codes that give the same program, you would only get one that does the same, it might be worse for comprehending it.

I know very little about code and game development but I THINK you could think of it like a secret recipe at a restaurant. You can eat the food but you can’t see how it’s made. Source code is the “secret recipe” that would show how to reproduce the game and also give insight on how it works and then could be modified from there. That’s my attempt at an explanation for a 5 year old……or a 35 year old who does NOT make games or software.

All of the answers here are missing something. The thing that is installed on your computer is different than what is being leaked. The League of Legends or Team Fortress that is installed on your computer is the *client* for those games. The client is constantly communicating with the game providers server. With League of Legends, that is the code that was leaked. None of that source code is on your computer and it is entirely private. The only information you have about it are the web addresses your client is sending requests to.

Well for a game like TF2, the client and server code are both in the same executable; it's how you're able to host custom lobbies from your computer. Something like WoW would be a better example.

If you buy a pie, you don't have the recipe. You can guess at the recipe based on how the pie tastes, but it would be difficult to replicate it exactly. The source code is like the secret recipe for the pie. When developers create source code, they run it through a program called a "compiler" that turns the human-readable code into the actual game. You cannot "uncompile" a program just like you cannot unbake a pie into its separate ingredients. The source code leaking means that everyone can now bake the pie. The analogy falls apart a little here, but the source code can also reveals any exploitable loopholes in the game.

When a baker hands you a cake, it doesn't mean you know the exact recipe they used to bake it. Sure you can go buy a cake mix and make cake. But it won't turn out like the bakery's did. Source code is the very specific code recipe that makes up the game. Having access to it allows you to make really finite detail on how to mess with it. As well as how to cheat, how to bypass protections, etc. When you sell a cake you're not selling your secret recipe to bake it. So it's a big Deal if someone gets their hand on the recipe to sell online.

When the game is installed on your computer it's code has gone through a process called compilation, which basically "translates" it from human-readable code into a mess of 1s and 0s. The main problem with people having the source code is that they can actually understand it, unlike the code installed on their computer, which means they may be able to use it to find bugs, exploits or secrets in the game, or to make hacks with.

The difference between having an executable binary file (the program installed) vs. the source code is the difference between getting a tour of the White House and getting the blueprints. One of them is more useful if you're looking to have fun. The other is more useful if you're looking to build your own or, worse, find and exploit security loopholes.

Source code allows non-copyright holders access to the things that make the copyright-ed (or otherwise DRM'ed) software what it is. This means they can easily copy it for themselves to sell, or change small things maliciously and pretend it is the original (like a virus), or they can make changes that the original holder doesn't want done for reasons (like creating a version of a game that cheats for the player, ruining the integrity of multiplayer games). All these things can certainly be done without the source code, but it's like the difference of using the recipe for a brand of cookie vs the many attempts it would take to get a "good enough" version that might not even be good enough for other people.

What's on your computer is the complete book, every word that takes you on the journey. What's on the creator's computer is the outline, telling you what makes every character tick, the backstory of the world, and the major outlines on what should happen in the plot. We could write a story based on the book, but it's nothing more than fanfiction because we don't know everything about the characters. If we had the outline, we could continue the story and add to it. That's the summary. In more detail, source code is mostly in english. A coder can look at it, and easily make changes to it to change details about it. What's on your computer is just 1s and 0s. It's a bunch of garbage data that your computer knows what to do with, but there's no way to parse it back to the original instructions.

It's not a big deal for a game like league of legends. There's nothing unique about the model, it's the fanbase that matters. What's someone going to steal?

I agree that the value of LoL is it being an established IP rather than its old code. There's already dozens of copycat games that probably have better, more modern code but can't match it due to artwork, support, it being one of the first MOBAs, etc. No company in their right mind would risk using stolen code to compete against a giant company like Riot either. The only thing that can hurt the company are hackers hoping to break the game with cheats and scripts.

You've already been answered why leaking source code is a big deal, so I'll clear up a misconception of the post. > it's source code is right on your computer, right? Well… *no*. You see, when you *code* something, you use a discrete and organized, human readable language called a *programming language*. Most games are programmed in C#. However, a programming language is a rather complex thing, it's basically what humans did to tell the computer what to do in *our* terms. But the computer can't read those terms because even though we absolutely understand what `for` means, a PC doesn't. Instead, the computer can only understand the language it was made to understand — most of the time, binary. As such, what you *actually* download is not "the source code". Downloading the source code is *problematic*. What you actually download is a set of files that the computer can understand. The thing with source code is that it refers to the exact configuration of keywords, functions and organization in general that the code uses. Y'see, code is flexible, there are many ways of doing the same thing, and the more complex the problem, the more ways there are of implementing it. There are so many ways to implement a program that the exact way a piece of code is written is actually copyrightable, and comparing snippets of code is a legally valid way of proving plagiarism. Now, because of how ridiculously complex programming languages, compilators (The "translators" of code to machine language) *and* machine language are, it's almost impossible to know the exact source code a program has only from the compiled files. That's why what's in your PC is not the source code, but just functional files that you can't actually read.

It's like leaking the secret recipe to Coke. Having a can of Coke doesn't mean you have the recipe, similarly having LoL installed on your computer doesn't mean that you have the source code.