 |
Cheat Engine
The Official Site of Cheat Engine
|
| View previous topic :: View next topic |
| Author |
Message |
Csimbi
I post too much
 Reputation: 97
Joined: 14 Jul 2007
Posts: 3320
|
 Posted: Sun Aug 25, 2024 3:52 am Post subject: How to protect your hard work? |
 |
|
Hi folks,
I am working on something that takes a lot of time and effort to build.
In the world we live in, people steal your work, change a few things in it and sell your work as their own and give you zero credit.
I would like to understand how I could protect my work - so I could release it to the general public knowing anyone could use it 'as is' but nobody would be able to steal the code, modify it, claim it they made it, and put it on their paid site. Not even those with knowledge of the CE source code.
If, this is, at all, possible.
I would not want to be setting up a server for API keys, manage keys manually, etc. The intention is to allow anyone to use the CT for free, while preventing the actual theft and shadow releases.
Please keep discussions on the why out of this thread. I have zero interest debating why we live in this world, why I want to protect my work, what is theft, and so on.
I would like to discuss solutions only.
Ideas, examples, references to forum articles, anything you think that could help taking this forward are welcome.
Thank you!
|
|
| Back to top |
|
 |
panraven
Grandmaster Cheater
![]() Reputation: 62
Joined: 01 Oct 2008
Posts: 958
|
| Posted: Sun Aug 25, 2024 4:38 am Post subject: |
|
|
I wonder if the official CE itself can be the keeper.
If I'm not wrong, only a few creators with reputation get DarkByte's approval to has a signed-logo in their Cheat-table (*.CT or may be generated exe).
How can it be done? I don't know. But I assume there is some encryption/decryption process to prevent impostor.
updated: DB must be giving some thing to the creator in order to enable signed-logo, this thing can be the source of password for en/decrypt below.
Under this assumption, can CE also en/decrypt AA script memory record (mr)?
Something like this:
A. On creator side:
a1. approved creator can create CT/exe in enhanced protected mode;
a2. all script mr is encrypt into a single table-file (those in MENU/table/add-file);
a3. all saved script mr is cleared to only left '[ENABLE][DISABLE]' (empty AA);
B. On user side:
b1. in runtime, user cannot view/edit script mr and the main Lua (MENU/table/show-cheat-table-lua-script);
b2. when user activate/click a script mr, the respective script data store in the single table-file is decrypt/restore to the respective mr;
b3. After script mr executed, success or not, the mr script again clear to empty AA;
( ALTERNATIVE: run the script in memory? )
ADDED: it cannot be load from a running ce (may be compromised), it must be executed from os and call the offical CE.
For convenience of the creator, when creator open an enhanced protected ct/exe, do [b2/b3] when view/edit the script, and [a2/a3] when close the script.
That's it atm.
UPDATED:
only official CE can en/decrypt, so modified CE can not expect to by-pass the protection, may real-time hash the executable region to prevent official CE being modified in runtime. Should also include creator's used autorun files in the ct/exe, not load user's autorun files. Only approved creator can use enhanced protected mode, to prevent any others protect their stolen work 
self-note:
where is Lua? autorun / main Lua / AA script MR / custom-type-definition (lua), lua-engine (print box), anymore ?
_________________
- Retarded. |
|
| Back to top |
|
|
Dark Byte
Site Admin
 Reputation: 470
Joined: 09 May 2003
Posts: 25769
Location: The netherlands
|
| Posted: Sun Aug 25, 2024 6:06 am Post subject: |
|
|
impossible, the scripts are going to get decoded before being passed on to the autoAssrmble function
best you can do is obfuscate your code and maybe also put in unique identifiers that make no sense to people so when they do take it over you can file a lawsuit against the site that hosts it
you can put in code that check if it's an official CE release
at best i can make it so tables can only be loaded on official releases of CE, but someone just has to extract the table afterwards and that's it
_________________
Do not ask me about online cheats. I don't know any and wont help finding them.
Like my help? Join me on Patreon so i can keep helping |
|
| Back to top |
|
|
panraven
Grandmaster Cheater
![]() Reputation: 62
Joined: 01 Oct 2008
Posts: 958
|
| Posted: Mon Aug 26, 2024 1:02 am Post subject: |
|
|
| Dark Byte wrote: | impossible, the scripts are going to get decoded before being passed on to the autoAssrmble function
...
|
So we need a new autoAssemble function, may be just a wrapper to current, that run in memory (possible in custom lua), then wipe the decoded data stay in ce memory.
| Quote: |
...
you can put in code that check if it's an official CE release
|
<***>
Doing from custom lua code, or even a custom ct loader is still static target to be analysis. On inverse, running ctx from shell only can trigger CE to check itself and validate the ctx in the tiny duration while loading.
| Quote: |
at best i can make it so tables can only be loaded on official releases of CE, but someone just has to extract the table afterwards and that's it |
[+++]
That's why we need official ce's encrypt/decrypt to generate and restore those aa scripts, by a special key for each approved creator. Base on the signed-logo data is just it is already existed for creator with reputation, it may be some unique key/cert file for each approved creator. We don't want the protection benefit to stealer. Even if an approved creator turned evil, encrypt by signed-logo data may reveal him.
====
Perfect protection is impossible, but it may be make (highly, hopefully) improbable for stealers rebrand others' works as their product.
The idea is minimize the chance(or duration?) for even the skillful stealer to look at the aa source.
Let's call the ct table file with enhanced protect as ctx.
0. while generate ctx, it moved all aa script to a single encrypt data storage <AA-ALL>, on itself , may be another layer of encrypt, ie. not in xml format;
1. without the data of the signed-logo <authid>, ctx cannot be made, so non-approved creator cannot protect their stolen work;
2. ctx can only run from shell, see <***>;
3. when load, decrypt <AA-ALL> using authid and also run included autorun lua files etc, <how about some dll in autorun?>;
4. then encrypt the source again using a time-stamp-hashed key (tid),
called as <AA-ALL2>;
5. decrypt individual mr aa script from <AA-ALL2> by tid when need to execute individual mr;
6. run the mr script in memory, but apply to the respective mr, ie. new autoAssemble function with memory record ID as one of the parameters ;
7. may need some special callback to wipe the aa source in ce memory after 3/ and 6/;
8. CE should block ALL USER Lua while loading ctx.
On 3/ 4/ 5/ steps de->en->de, it change the static authid key to random tid key, may make even most patient stealer give up?
It should be streamed (ie. char by char or piece by piece) from authid encypt data to tid encypt data, so no all aa script appeared in ce memory.
On this, if tid and encrypt data come next to next in ce memory, ie. in
a structure, it may be possible to identify the tid and how to work on
it, especially as ce is open source; may arrange tid in its own array or
mapping, and also the respective encrypt data?
2/ 7/ 8/ need CE official support.
It start from the signed-logo data, so also need ce official support, see [+++].
====
_________________
- Retarded. |
|
| Back to top |
|
|
atom0s
Moderator
 Reputation: 205
Joined: 25 Jan 2006
Posts: 8585
Location: 127.0.0.1
|
| Posted: Mon Aug 26, 2024 3:16 pm Post subject: |
|
|
| Csimbi wrote: | so I could release it to the general public knowing anyone could use it 'as is' but nobody would be able to steal the code, modify it, claim it they made it, and put it on their paid site. Not even those with knowledge of the CE source code.
If, this is, at all, possible. |
The simple truth is, it's not possible to fully protect anything that runs on a users local machine. No matter what you do, if it runs locally then it can be reversed and recovered eventually. You are fighting a losing battle that is not possible to win. The most you can do is layer different means of deterrents to make it more difficult or annoying to deal with trying to recover the work you're trying to protect, but you will never completely block people from being able to eventually recover/steal it.
When it comes to game hacking as well, your trainer is not even going to always be the focus of an attacker to try and steal your trainers code.
| panraven wrote: | | If I'm not wrong, only a few creators with reputation get DarkByte's approval to has a signed-logo in their Cheat-table (*.CT or may be generated exe). |
The cheat table signing is nothing special and does not add any protection to the table at all. It is simply there as a 'credits' style addition to the table. Anyone can open a table that is signed and simply remove the block that is added to the table and it will still work as-is, with the signature removed. It does not add anything in the form of protection or encryption to the actual table contents.
It also does not matter if Dark Byte changes how the cheat signing works either. Even if the entire tables contents are actually encrypted against the private key, Cheat Engine still has to load and decrypt the contents to be able to load/read it. You can simply modify the source code of CE to dump a signed table after its been decrypted and loaded in memory to get the entire unencrypted contents back.
It is not a means of protection.
| panraven wrote: | | So we need a new autoAssemble function, may be just a wrapper to current, that run in memory (possible in custom lua), then wipe the decoded data stay in ce memory. |
This does not matter and does not prevent someone from recovering the information that your trainer is reading or writing to another process. Someone who wants to steal information from a trainer does not need to even bother touching the trainer at all to obtain that information.
Regardless of how your trainer is created, if it's reading/writing to the memory of another process, those reads/writes can be monitored and dumped. It does not matter what level of obfuscation, encryption, or other forms of protection you want to layer onto your trainer or CE's code, it can be recovered without ever touching the trainer itself other than using it normally.
This, itself, is another cat and mouse chase because it's not something you can block/prevent in full. If your trainer operates in usermode, then the attacker can simply just hook lower level APIs. If your trainer tries to detect those hooks, the attacker can just operate at kernel level. If your trainer requires the use of a driver, then the attacker can simply load theirs before yours and have more control. If your trainer tries to prevent that kind of load chain attack, the attacker can simply move to using special hardware or similar to still win.
| panraven wrote: | | Doing from custom lua code, or even a custom ct loader is still static target to be analysis. On inverse, running ctx from shell only can trigger CE to check itself and validate the ctx in the tiny duration while loading. |
That tiny window is all that is needed to be exploited. This will not prevent things from being recovered.
| panraven wrote: | | That's why we need official ce's encrypt/decrypt to generate and restore those aa scripts, by a special key for each approved creator. Base on the signed-logo data is just it is already existed for creator with reputation, it may be some unique key/cert file for each approved creator. We don't want the protection benefit to stealer. Even if an approved creator turned evil, encrypt by signed-logo data may reveal him. |
As I explained above, this does not matter and does not fix or prevent anything.
| panraven wrote: |
Let's call the ct table file with enhanced protect as ctx.
0. while generate ctx, it moved all aa script to a single encrypt data storage <AA-ALL>, on itself , may be another layer of encrypt, ie. not in xml format;
1. without the data of the signed-logo <authid>, ctx cannot be made, so non-approved creator cannot protect their stolen work;
2. ctx can only run from shell, see <***>;
3. when load, decrypt <AA-ALL> using authid and also run included autorun lua files etc, <how about some dll in autorun?>;
4. then encrypt the source again using a time-stamp-hashed key (tid),
called as <AA-ALL2>;
5. decrypt individual mr aa script from <AA-ALL2> by tid when need to execute individual mr;
6. run the mr script in memory, but apply to the respective mr, ie. new autoAssemble function with memory record ID as one of the parameters ;
7. may need some special callback to wipe the aa source in ce memory after 3/ and 6/;
8. CE should block ALL USER Lua while loading ctx.
|
This does not do anything new or special that is already being done by many different protection mechanisms on the market. It does not fix/solve anything either but instead just adds a level of deterrent and moves the 'goal post' of what needs to be attacked or targeted by the attacker in order to recover the data they need or want.
0 - This does not matter how the data is stored. CE has to eventually read it back into a usable format that the trainer will need/use to function. The attacker will not care about the data format used or when its in this state because it does not matter then. They will instead focus on recovering the needed information after its decrypted and being used by the trainer.
1 - This does not matter. If the attacker already stole the work, they don't care about reprotecting it, let alone specifically using CE to redistribute it.
2 - Adding buzzwords onto things does not mean its more secure.
3 - Again, doesn't matter. It does not matter what data you make a requirement to decrypt the data, the attacker does not care about that unless they are specifically looking to make a static dumper of sorts. If their end goal is simply to steal the information your trainer is reading/writing (ie. addresses, code patches, injected code caves, etc.) then they don't care about this at all and simply will just target dumping that information after its decrypted.
4 - This just adds another weak-point to the setup that can be attacked to obtain the unencrypted data.
5 - This only adds a level of delay to the entire trainers data being dumped/recovered. It just means someone looking to dump your trainers information will have to individually execute each part instead of an all-in-one decrypt pass.
6 - It living in memory does not matter.
7 - Again, just adds another weak-point that can be hooked onto and abused.
8 - This can just be patched out / removed by the attacker to bypass any kind of blocks like this.
| panraven wrote: | On 3/ 4/ 5/ steps de->en->de, it change the static authid key to random tid key, may make even most patient stealer give up?
It should be streamed (ie. char by char or piece by piece) from authid encypt data to tid encypt data, so no all aa script appeared in ce memory.
On this, if tid and encrypt data come next to next in ce memory, ie. in
a structure, it may be possible to identify the tid and how to work on
it, especially as ce is open source; may arrange tid in its own array or
mapping, and also the respective encrypt data? |
Everything you are describing here is nothing new or unique. This is how a lot of FPS cheat sellers run their operations and function. They build a loader that streams per-user encrypted data to the users machine to be injected into the game. It does not matter how much protections, encryption schemes, or other nonsense you layer onto of each other, the dll code that is streamed is eventually on the users machine and injected into the process and can be dumped back out.
The same goes for any kind of memory edits, memory patches, code caves, hooks, etc. All of it can be recovered by an attacker.
---
Here are some examples of how an attacker may try and catch what you are doing to another process. In these examples, the attacker does not need to ever attempt to decrypt, reverse engineer or do anything with your trainer itself. Instead, they will simply focus on the target game process as the attack vector.
1. Basic Memory Edits (ie. changing health address from 10 to 100)
This would be the most basic kind of feature of a trainer to simply read/write to a single address value that controls some part of data you would want to modify. Lets assume your trainer has a feature to 'Set health to 100' for your character that simply writes the value '100' to your current players health address. This does not do any kind of game function patching, code cave, or other more advanced methods of editing the game process. It is simply changing the variable value for health.
This example is to show how even the most basic means of memory editing is vulnerable to basic attacks.
In this case, an attacker would simply hook the APIs used for interacting with a remote process to monitor what your trainer is doing.
This would include API calls such as:
- OpenProcess - To see which process your trainer is opening.
- ReadProcessMemory - To see what memory address(s) your trainer is reading data from.
- WriteProcessMemory - To see what memory address(s) your trainer is writing data to.
By doing this, every little additional 'protection' you tried to add to your trainer has now been rendered entirely useless. It did not matter how much time you spent trying to protect the data stored in your trainer because the attacker did not need to even care about it or try to dump it from the trainer itself. They simply get the bits of information they needed from the OS itself because your trainer needs to use system API calls to function properly.
Now lets say you try to 'protect' your trainer to avoid this kind of attack. Such as by adding some means of detecting API hooks. The attacker can just then hook onto lower level APIs instead such as the 'Nt' equivalents of the 3 API I listed above. (NtOpenProcess, NtReadVirtualMemory, NtWriteVirtualMemory)
Now lets say you try to 'protect' your trainer again to avoid these lower level hooks, the attacker can then move onto either more sophisticated means of API hooking from usermode such as inline hooks to those API calls to avoid basic detections like prologue/epilogue hook checks, or hooking further into those API calls that avoids being seen at the surface level if you decide to ensure the full surface level of the API call is not tampered with.
This becomes a cat-and-mouse chase where the attacker will always have the upper hand. They will find a new way to hook onto the information they want that your trainer does not have the means to prevent or detect. They could then move to writing a kernel mode driver just for the sole purpose of dumping trainers if they wanted.
Keep all of this in mind as it will be relevant for all of the following examples as well.
2. Advanced Memory Edits (1) (ie. simple patch of a game function, such as nops or changing inc to dec or jnz to jmp etc.)
The next example would be for how an attacker can go about detecting your trainers memory patches. This would be for things such as nopping out parts of game functions, patching code to change things from say 'inc' to 'dec' or modifying jumps to alter how a function behaves. First, this is no different than example '1' I gave above. These are simply memory edits to an address (or addresses) in the games memory that would be easily dumped in the same manner I explained above.
However, these kinds of edits are also vulnerable to an even more basic attack. In this example, an attacker can simply do the following steps to steal your trainers code:
- Load the game that is for the desired trainer.
- Load the desired trainer.
- Enable the trainer as needed. (ie. if it has an 'enable this first' option or anything and ensure its attached to the game.)
- Enable the cheat option(s) the attacker wishes to steal from your trainer.
- Dump the memory region(s) of the game process that contain code. (ie. the main '.text' section and/or additional sections that contain code.)
Next the attacker simply closes the game and trainer, then reopens the game without any modifications applied. They then dump the same memory regions that contain code. At this point they simply compare the two memory dumps and find the patches your trainer made. In most cases, games are not using any kind of polymorphism that would cause large amounts of code changes, which means your trainers patches will be the only things they find when comparing.
This has completely rendered all of that extra time and effort protecting the trainer pointless. The attacker never once needed to try and reverse engineer your actual trainer meaning you did nothing to actually protect your work/effort.
3. Advanced Memory Edits (2) (ie. code caves)
This is the same as example 2, but now includes code caves. This is a little more work because the manner in which code caves are injected now adays do not follow the same trends back in the early days of game hacking. (Originally, trainer makers would not allocate their own memory for caves and instead looked for static blocks of unused space in the existing code section(s) to put their cave code. In the event that your trainer does make use of existing space, then it would easily show up in the steps I outlined in step 2 already.)
For most modern day trainers/cheats, caves are allocated now instead. This can either by simply allocating a new block of memory and writing your cave to it, or by injecting your own DLL and having the call/jump go to a function within your injected DLL. Either way, these are in allocated blocks of memory that would not be part of the base code section dumps.
Instead, the attacker would first do the same two dumps of the modified and unmodified game memory. (While leaving the modified game opened for further dumping.) They would first do the code section compares to find where your patches are being performed and locate the call/jump changes you made. They would then use those call and jump addresses to determine what else needs to be dumped to obtain the allocated memory of your caves. This would also help lead the attacker to any kind of DLL injected into the memory space and allow them to dump the entire DLL too. (There are much better ways to detect if a trainer has injected a full dll and dumping it though.)
---
The point is, regardless of how much work you put into protecting your trainer, your trainer is often the last point of interest to an attacker who is trying to steal the information that's inside of it. They will instead focus on the game process itself first to try and get as much information about what your trainer is doing as possible.
_________________
- Retired. |
|
| Back to top |
|
|
Csimbi
I post too much
Reputation: 97
Joined: 14 Jul 2007
Posts: 3320
|
| Posted: Mon Aug 26, 2024 3:18 pm Post subject: |
|
|
panraven,
I like where your head's at and where you are going - thank you for that.
I do agree that official CE support might indeed be the only way go to go.
We're going to have to get endorsement from Dark Byte - well, far more than endorsement.
It would surely help avoiding a lot of disputes in the future.
|
|
| Back to top |
|
|
panraven
Grandmaster Cheater
![]() Reputation: 62
Joined: 01 Oct 2008
Posts: 958
|
| Posted: Mon Aug 26, 2024 5:19 pm Post subject: |
|
|
Thank you for the detailed and knowledge response.
Yes, in the cat and mouse game, the most skillful and patient one will win more. And that's why-not.
I make cheat too, and understand Csimbi's concern. Probably our target are those low-tech lazy theft. We need solution to prevent our works being rebrand easily. Currently they probably only need to save the CT as exe with their custom trainer skin code, with some adjustment. A new ct format is partial for this.
Anyway, as Csimbi opening post said, why or why-not is not that important, we all know the protection will be breaking one day by someone, but hopefully not by the lazy one.
_________________
- Retarded. |
|
| Back to top |
|
|
Dark Byte
Site Admin
Reputation: 470
Joined: 09 May 2003
Posts: 25769
Location: The netherlands
|
| Posted: Tue Aug 27, 2024 1:33 am Post subject: |
|
|
"Why don't you save the table as a .cetrainer with protection enabled ?"
The answer to this question explains the issue.
I can of course change the protection, but i'm quite certain some people (like atom0s) will bring out a decryptor within a week
_________________
Do not ask me about online cheats. I don't know any and wont help finding them.
Like my help? Join me on Patreon so i can keep helping |
|
| Back to top |
|
|
atom0s
Moderator
Reputation: 205
Joined: 25 Jan 2006
Posts: 8585
Location: 127.0.0.1
|
| Posted: Tue Aug 27, 2024 2:53 am Post subject: |
|
|
| panraven wrote: | | Anyway, as Csimbi opening post said, why or why-not is not that important, we all know the protection will be breaking one day by someone, but hopefully not by the lazy one. |
That was the reason for the first paragraph of my response; to reply to the topic in his expected manner. The rest of my post is to simply backup my point and why I feel trying to strengthen Cheat Engine is a waste of time.
| panraven wrote: | | Yes, in the cat and mouse game, the most skillful and patient one will win more. And that's why-not. |
I personally disagree with this based on my interaction with hundreds of thousands of people over the last 25 years in the game cheating/hacking/modding spaces. Skill does not matter, at all, in this context. If someone really wants to take something that is not theirs, they will find a way, no matter what. Even if that means hiring someone else to do it for them.
The single player cheat space has been extremely toxic and full of thievery for many of years at this point. There was a large shift in the cheating space years ago where things went from being free, open and shared to being private and for-profit. Certain 'teams' and sites at that time then focused on doing anything needed to get ahead and make their site the focal point for anyone searching for cheats related to a given game. This same business model is the primary one on many single player cheat sites, even if they want to pretend to be 'blind' to it happening or basically 'look the other way' when the people they pay to create trainers are doing it under their brand. (I'm not going to name names as I have no interest in the drama. I'm not part of the single player cheat space at all and haven't been for years.)
There is also the ability to completely negate any trainer protection functionality and being able to completely dump scripts back to full plain text, or decompiled text, without ever touching a single thing in CE. Simply replacing 1 file in CE's installation can do this, and it can be done with tooling that is not even made for CE specifically. Cheat Engine makes use of Lua which is a highly well known library that has years of tooling for itself and the thousands of games that make use of it. There are countless proxies, hooks, injectors, etc. specifically made for hooking onto, hacking and dumping information from Lua. Some of those proxies can be used as drop-in replacements for Cheat Engine's Lua dlls and can dump everything from the Lua state automatically.
| panraven wrote: | | I make cheat too, and understand Csimbi's concern. |
I am not saying their concern is pointless. Rather, that it is pointless to waste time 'strengthening' Cheat Engine as a means of protecting your work.
Cheat Engine should not be the means of which you are releasing cheats/trainers if you are concerned with the ease of it being stolen. Instead, you should be making your own framework(s) that are not public and open source which reveal all of the underlying work and usages of how to simply bypass any kind of additional layers added to it.
No matter how many layers are added to Cheat Engine, there are already 'weak points' in it that will leave it open to having trainer information dumped with ease. The simple fact that it is open source also rules out any actual protection layer being effective. Look at the current things in it that are aimed at protecting things and you will see why it's not any real means of protection but rather just a simple deterrent of obfuscation to prevent things from being seen in plain text immediately.
| panraven wrote: | | Probably our target are those low-tech lazy theft. We need solution to prevent our works being rebrand easily. |
Like I said above, the skill level or laziness of someone does not matter. If they want it, they will get it done by any means necessary such as paying someone else to do it. The amount people will do something for is so cheap anymore as well that it will not deter anyone from doing it just because there is some incentive to pay. It also only takes someone 1-2 times of doing something like that to see there is a potential 'business' behind it and turn it into a Discord server where they sell a 'service' of doing it. They can toss together a few quick scripts/tools to automate it entirely as well and just make money hex editing files.
| Dark Byte wrote: | "Why don't you save the table as a .cetrainer with protection enabled ?"
The answer to this question explains the issue.
I can of course change the protection, but i'm quite certain some people (like atom0s) will bring out a decryptor within a week |
None of my trainer dumping/decrypting tools were ever released to the public. They were always kept private and only used for the assistance of recovering lost trainer templates and for moderation here before we banned the posting of cheat files and trainers. I have never released or given my tools to anyone else, have never used them to assist anyone in stealing others work and have personally never used it for that either. I have no absolutely no interest in single player cheating and haven't for years. It's one of the reasons I'm not that active here anymore.
My tool(s) are also no longer updated and haven't been since like 2015. After the trainer ban here, I had no reason to continue updating it since I do not need to moderate them anymore. I don't participate in any of the third-party sites made after the ban either given who runs them, I have no interest in dealing with childish behavior.
_________________
- Retired. |
|
| Back to top |
|
|
Csimbi
I post too much
Reputation: 97
Joined: 14 Jul 2007
Posts: 3320
|
| Posted: Tue Aug 27, 2024 5:42 am Post subject: |
|
|
There is indeed a lot of truth and wisdom in what you said.
I did not want to open the can of what was, what is and what might be, so I will you leave it at that.
I was worried it might come to this because this means one cannot actually use CE anymore and this means we push people even further away:
| atom0s wrote: |
...
you should be making your own framework(s) that are not public and open source which reveal all of the underlying work and usages of how to simply bypass any kind of additional layers added to it.
...
|
Thank you all for your thoughts and inputs - it sounds like it will have to be proprietary.
|
|
| Back to top |
|
|
paul44
Expert Cheater
![]() Reputation: 2
Joined: 20 Jul 2017
Posts: 198
|
| Posted: Sun Apr 13, 2025 10:21 am Post subject: any intention ? |
|
|
To pick up on this subject: now that the code is no longer released, is there any intention to include some sort of CT contect protection ?
Just talking for myself here: what i would like to see is a possibility to 'obfuscate' any files "attached", such as Forms and Lua extensions.
These are now already zlib-ed - based on some topics i found here - but perhaps there is a way to use a 'variant' to scramble that content ?!
I also thought about "removing" [Edit form] or [Save lua to disk] options, but since tools already exist to 'export/unzip' this stuff: that is not really a solution...
I really would like to see the dev_team considering this. In the last 1-2 years or so, some big tablemakers left @FRF simply because people steal their stuff and use it as "their own find". Or worse: they charge money for it; and usually casting a bad name on the original author...
fyi: i have no intention to "lock up" my tables in any way (the day I'll have to do that is probably the day I'll stop doing this stuf anyways).
Just asking here because #Csimbi and I have been working on a UE tool - spanning 6+ months - and pretty much the "main authorities' @FRF almost immediately suggested NOT to publish that tool...!
We both DO want to make this tool public, if we can be assured somehow that all our hard work is not "abused" the day it gets published...
ps: i'm definitely not expecting some vm-kind of solution. If some individual wants to research the asm, that is all fine by me. As long as they can't get hold of the - in this case - original Lua code, I'll be a happy man.
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
