The Benefits of Open Source Development

In that case, they would be loaded from different phases (no overwriting) and restricted by extension (i.e. sound and textures only), so that cheaters don't replace models to perform glitches such as go out the map.
grrr... you just HAD to beat me to writing my post.
 
If texture packs would be made. Only textures/sounds would be loaded. Models would be used from the standard downloaded resources, to prevent issues that may come in-game from end users changing up the models. (I.e, changing a huge building into a dog. The issues that can follow are self explanatory).
Lol..
 
Hi GangStarr, nice to meet you! For some time, I've been hearing that you'll reverse engineer Nirai. That's no big deal. However, some inaccurate things have been said. Please allow me describe Nirai's security model.

First of all, Nirai is now open source! No more security through obscurity. In fact, it's never been. Panda3D and Python are almost 98% of its code and they are publicly available. Because of that, looking for TLOPO-specific code is unfeasible. You gotta be quite lucky or determined to find the relevant 2%. The rest is just Panda3D/Python/third-party code you aren't interested into. Ain't it cool?

https://github.com/nirai-compiler

2. For most projects, AES is used. Remember Kerckhoff's principle (since you mentioned kernel I'm assuming you know what you are talking about, therefore you should know it): even if you use a dissembler, you won't know the key, as long as it's done properly. And for TLOPO I will do it correctly. Ain't it cool?

3. Nirai supports Python bytecode obfuscation. Even if you happen do dump PyImport_FrozenModules array, a lot of garbage would be dumped. The bytecode is deobfuscated just in time. Ain't it cool?

4. Nirai generates a static executable. That means no exposed python DLL. That means no Python code injection. Ain't it cool?

5. The connection between TLOPO client and server uses properly validated TLS. We use certificate pinning, so even if you happen to intercept it, the client would not accept your certificate. Ain't it cool?

6. All our phases are digitally signed and properly verified. Phase files which are tampered with are not loaded at all. Ain't it cool?

7. TLOPO AI method properly validate all requests. For example, if you request an invalid weapon in your inventory, it refuses to add it and logs such event. Ain't it cool?

Now, I'm gonna make you an invitation. Since Nirai is open source, go ahead and have fun! Clone and build it (docs are yet to made but if you claim you can decompile it you must be able to compile it, which is extremely easier and doable), compile the sample project and try to reverse engineer it. But... the sample project is easy to "hack". There's no security enforcement: AES key is hardcoded into the exe and the obfuscation process is ridiculous (let's see if you can even figure that out).

After you have successfully hacked the sample project (I would consider only arbitrary Python code injection or module dumping, with proof-of-concept, successful), move on to a real-world application which is already using (an older version) of Nirai: Toontown Next. I doubt you can harm them in anyway. Ain't it cool?

However, if you do find any serious exploit in Nirai, feel free to report it at

https://github.com/nirai-compiler/src/issues

So long,
Loblao

I don't need to decompile your whole client to hook some simple engine functions...


Besides, in a hypothetical world, i'd be writing to memory. Maybe a simple ESP or something, and then, i'll find some server sided exploits. And don't worry, loblao, it will certainly be "Cool" :)
 
Last edited:
I don't need to decompile your whole client to hook some simple engine functions...


Besides, in a hypothetical world, i'd be writing to memory. Maybe a simple ESP or something, and then, i'll find some server sided exploits. And don't worry, loblao, it will certainly be "Cool" :)
I don't even think you know who you're talking to. ;)
 
I don't even think you know who you're
talking to. ;)
yIjCM8u.png



And wileee, i don't think you know who you're talking too as well
 
This thread (https://piratesforums.co/threads/the-benefits-of-open-source-development.10437/) is not the place for anyone to puff up their chest and to argue back-n-forth into discussion which has nothing to do with this thread's topic of discussion.

A simple inquiry was made (earlier) which sought out to understand those concerns of "critics" of a POTCO open-source project and as such, everyone needs to take argumentative posts and other discussion into a pm which doesn't purposefully bog down this particular thread.

*IF posts written continually go off-topic (due to heated debate), such posts will be moderated and in-turn possibly deleted altogether deeming such expression ineffective.
 
This thread (https://piratesforums.co/threads/the-benefits-of-open-source-development.10437/) is not the place for anyone to puff up their chest and to argue back-n-forth into discussion which has nothing to do with this thread's topic of discussion.

A simple inquiry was made (earlier) which sought out to understand those concerns of "critics" of a POTCO open-source project and as such, everyone needs to take argumentative posts and other discussion into a pm which doesn't purposefully bog down this particular thread.

*IF posts written continually go off-topic (due to heated debate), such posts will be moderated and in-turn possibly deleted altogether deeming such expression ineffective.

Sorry
 
It's understandable that everyone would like to contribute key points openly on this thread here but problems often arise where posts are conveyed in such a way to where people are indirectly/directly put on the defensive. Therefore, it is encouraged that such points be expressed but...not drawn out to the point to where the initial topic of discussion/point being made is therefore lost.

Also, such undertone to specific points being conveyed (i.e., 'Ain't it cool' @loblao) doesn't necessary imply that the writer is directing his or her point to the community at large but rather a specific person...again, placing someone on the defensive and instigating them to respond back in a certain way when the goal should be to persuade them positively.
 
So...back to the question proposed earlier.

Besides hacking/modding/account stealing and general chaos (which will 'always' been issues to be dealt with, taking into consideration the deliberate choices made within the past), what would then be the "next" highest concern critics do have against a open-source POTCO project?

Mind you, most of us can just review earlier pages on this thread to discover a better idea. However, it's important to understand those concerns (on a hierarchy level) amongst those whom remain openly opposed to the open-source idea.
 
One aspect no one has brought up yet is the issue of access to the repository where code, resources, documentation, etc. are maintained. For the uninitiated, a repository (aka repo) is basically a database where all versions of all files are maintained, as well as a history of what changes have been made to those files over time. The general term for this is "configuration management".

Generally there are 3 levels of access to a repo: 1) admin, can perform any operation which CAN be done on a repo, 2) update, can read/write files in the repo, and 3) view, can only read files in the repo. Your typical repo will have a small number of admins (possibly only one), a group of developers with update access, and zero or more people who can only view files (sometimes used for testers or other non-developers).

These access levels are set in place for individuals based on their anticipated contributions to the repo; based on the person's role, experience level, and their "need to know" what's in there. Besides the potential for malicious actions like deleting key / all files in the repo (need to look no further than POTCO MC for a recent example), it's impractical to allow update access to anyone who is not qualified to change the repo contents. The POTCO code base consists of thousands of files with some very large number of lines of code (not sure of the approximate SLOC count), the vast majority of which we have zero design documentation for. Not to mention the very specific skillset required to correctly make changes that achieve desired functionality and don't break a few other things.

The end result is only a select few would be able to control and/or update the repo contents, while the rest would be limited to read-only access. And based on past / recent history, that restricted access could in too many cases (greater than zero) be used for all the nasty things previously pointed out in this thread.
 
...The end result is only a select few would be able to control and/or update the repo contents, while the rest would be limited to read-only access. And based on past / recent history, that restricted access could in too many cases (greater than zero) be used for all the nasty things previously pointed out in this thread.
So this statement is basically implying that with open-source, because of the "restricted" access levels, those whom wouldn't be within the loop would be more inclined to have malicious intent than say...if they were actually granted such access? (Or do you mean than those whom actually have acquired said access would do much of the same)?
 
Back
Top