Re: Our official stance on Copyright as it Pertains to game assets
@Ethin, from time to time, you demonstrate that your knowledge is not as extensive as you think it is. There is nothing wrong with that, unless you give factual advice, in which case it is rather harmful for those who do not have as much experience as you, and choose to follow suit. For the sake of the community, please, please make sure that what you say is correct. As far as I am concerned, I am done discussing this, as it is getting off-topic. The reason why I pointed out and I am still pointing out what is incorrect is because this is not what people who are starting out should see. You are, of course, entitled to your opinion, unless you provide them as facts that others should follow.
This is not true whatsoever. There is a difference between what BGT does when it stores code and what Lua and Python do. With Lua and Python, you have tools such as luac that compile your code to native code.
Incorrect. What you mean by "native code" is actually bytecode, and not machine code, also referred to as "native code". Bytecode is interpreted by a virtual machine, and it is an intermediate form.
Most interpreted languages have this. BGT is a major exception, primarily because all the offsets for everything is fixed. Once you know the offset for string_decrypt, you always know the offset for string_decrypt. C, on the other hand, is not so easy: C compiles directly to machine code. I cannot just take a C program and pull the decryption keys out of it (because I don't know what is what).
For the record, BGT is using Angel Script, which does compile "BGT code" to bytecode, so no difference so far.
Name mangling does not make a difference her. It takes two minutes or less to get a function address via any capable debugger. It is not designed to protect functions, but rather to avoid collision. Rather than pretending to know what I don't know, you should actually listen, for once.
Furthermore, C, Python, Lua, etc., have a unique quality that BGT does not: you only know the function names for the standard libraries they bundle in. You don't know where the decryption logic is.
Please enlighten us about where the encryption logic is exactly in BGT. Just because you know the offset, which you are right, never changes, you do not know where the encryption logic is. This is the equivalentof knowing a function address via a debugger in any other language you personally encourage using. Surely, BGT encryption is not just one function, right? All you do is access a wrapper function, along with a few registers. Yet again, this does not mean that the entire encryption logic is in the function you know the offset of.
However, as someone who isn't a wiz at math, I can tell you that I use cryptographic libraries (OpenSSL, Monocypher, Mongoose, AWS KMS, etc.) safely without knowing any of the underlying extreme theory.
As I have pointed out earlier, knowing how to use a library does not necessarily make you effective. Effectiveness is not something you can judge alone. You will see this once you start working for a company where they rely on your code that uses encryption. There is a huge difference between: "It works, I can use it," and "It works, I can use it, and it is not vulnerable."
... aAlso, you cannot break Cython hooks and cannot determine (beforehand) its memory areas. A cythonized Python program with a single line is over 5000 lines in C. Add over 600 lines of game logic and Cython code is about 12 times that. I significantly doubt anyone could break Cython code without extreme effort, and no blind person is going to spend that much effort in breaking an audio game just to get the sounds.
Please look into Capstone, since you are a firm believer of using premade tools. A huge amount of automatically generated C code, or any code for that matter, be it in source or compiled form, is not an excuse on grounds for code protection. You do not expect anyone to go through those lines manually, right? If yes, you will be really happy about Cython's built-in debugger.
I'm not really sure where you got this information, but if someone is using cryptographic primitives in their program, I would expect them to know how to use them safely. So yes, I would expect someone, even at the age of 12-13, to know these things if they are using a cryptographic library in their applications.
So do I. In reality, we both know that this is not the case. Google, Microsoft, Apple, and thousands of other companies did not always make it right. Clearly, there must be some magic going on in your case.
Someone who is just starting out should be asking questions on how to use cryptographic systems, instead of blindly going with what works and what doesn't.
Were you? Can you honestly say that when you were starting out, you had these questions about encryption? I think you were rather busy with grasping the required concepts, hopefully practicing your programming skills, and were actually happy that you could create something. This is what we have from novice game developers at the moment. Even in an educational environment, encryption is definitely not the first, nor the second question anyone would ask about, or teach. But I guess all the universities that produce the world's best developers today must be doing it wrong.
Finally, your first reason about languages is just funny. That was my first clue that you've never looked into how C/C++ work, nor how the Python module system works, for that matter, or Lua either.
You are absolutely right. You should probably inform my employers as well, when they employ me for critical application development with more than 25 years of C and C++ (and other languages) experience. Well done! :-)
Rob
-- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
