I might actually start doing some releases now 
1 Like
This is a great release. Thanks 
2 Likes
So if there are ui files in my script I need to put them in escrow_ignore (atm) ?
4 Likes
on the surface, it looks simple. it’s not. everything you’ve thought of has been thought of by the team creating this system. if you find a bug, don’t abuse it but rather send a message to the CFX.re team through https://support.cfx.re
1 Like
Thank you for this release - This may have already been covered, but how does it fair up against Server Dumping specifically?
1 Like
Thank you cfx.re dev team, we waited a long time for this!
5 Likes
What happened to “FiveM is a sharing-based community?”
This is an incredibly disappointing change in my humble opinion. I have only been part of the FiveM ecosystem for around three years, but this transition to monetization over the last year has been disappointing to see. When I joined the FiveM ecosystem, most involved (and especially Cfx leadership) seemed to be of the opinion that FiveM should be free and open. I still remember the note in the FiveM docs that said “hey, anybody can do a fetch() from the NUI console to grab your client-side files and that’s how it’s intended to be.”
To be honest, I was fine with the initial rollout of Tebex. I understood that some developers were selling their assets anyways, regardless of FiveM’s rules, and felt (like I presume the Cfx team did) that if it was going to be happening, it might as well happen under the purview of Cfx where some reasonable controls (such as disallowing harmful obfuscation) could be put in place.
I present two arguments as to why asset encryption is harmful.
Encryption prevents customization and leads to a homogenous ecosystem
Introducing encryption of this type can only lead to more “copy and paste” servers that look, work, and are broken in exactly the same ways. While many FiveM server operators have limited development skills, there are many of us who are capable and want to extend and build upon resources we obtain (whether those be freely downloaded, or purchased.)
Let’s say a resource needs to show notifications to the player. Many of these frequently have dependencies on mythic_notify or bake in something similar. If I want to change that to use Thefeed... natives, I very well may not be able to depending on how “configurable” the developer has made their resource.
This is a very simple example, but I frequently extend resources far beyond what is released, and completely overhaul them from how they look, to how data is persisted to database or key-value stores far beyond what the developer anticipated and made “customizable” out of the box.
Encryption doesn’t just discourage this type of customization and ability to make each server stand out on it’s own, but it downright prevents it.
DRM only punishes the rule-abiding user
It has been proven time and time and time again that DRM does absolutely nothing to stop piracy, and only punishes the customer. Adding DRM to FiveM is highly ironic given the amount of work that has gone into working around Rockstar’s DRM to make FiveM.
While I mean absolutely no offense to the Cfx team - I doubt this new DRM is any more sophisticated than that rolled out by billion dollar companies like Rockstar, Adobe, Netflix, or others. Which means it will be trumped in time, and the leakers and resellers will continue selling assets illegally, and ones that are likely better than what you get by playing by the rules and paying since they’ll likely be unencrypted.
And thus begins the cat and mouse game. I fear the long term result of this change is that instead of being able to focus on improving FiveM, the core maintainers will instead be forced to play a perpetual game of cat and mouse each time the next iteration of this DRM is broken.
I could share many other concerns, especially about subscriptions for resources, but I think I’ve probably written enough of a wall of text. It doesn’t seem there’s any putting this genie back in the bottle, so all I can do is implore developers to consider the downsides escrow and encryption carry, and if the upsides are worth the harm it can cause to your customers or users.
60 Likes
Nothing changed about how the community is. The consensus across the community has been to do shady things like this (e.g. using weird paid Lua obfuscation services originating from the Roblox community that lead to a lot of behavioral issues and more), and this being done out-of-band off the forums by nearly everyone led to issues with us being unable to actually fix bugs at all as e.g. people were dismissing requests for a repro like such:
This so-called ‘nat215 framework’ was being sold out-of-band, likely with a lot of ‘IP locking’ etc., and the user was refusing to provide any such asset to replicate their issue: now, with an official solution for resource sellers to be able to do ‘locking’ of whatever sorts while keeping the original resource on our backend services so we can actually reproduce this kind of issue, even if the resource author is not explicitly playing along.
The ‘asset escrow’ system was meant to be initially ‘done’ before we’d allow paid releases on the forum at all, but this took a lot more time than expected, mainly as we had to find a new set of developers skilled in working on web/backend services for this: none of the core game folks are working on this whatsoever, e.g. I’m explicitly keeping my hands off of this mess.
As to the core ‘root of trust’ for the access control here: the basis is that these wrapped assets are not able to be loaded by simply unwrapping (e.g. server-signed Lua bytecode, similar to MTASA: without actually decompiling fully and cleanly which currently no Lua decompiler can) and since a server owner usually won’t be able to get all people playing on their server to run a custom game version, any ‘stolen’ assets are unusable to them on normal builds of FiveM.
Other things done by this ‘under-the-table’ off-site selling of assets being normalized has been stuff like backdoors in re-re-re-sold resources being remarkably common, without us being able to revoke, check or otherwise deal with these resources. This is also why ‘obfuscated code’ from random weird ‘Lua obfuscation services’ is generally prevented from loading by the actual client/server patch sets: it’s just too risky to keep like that.
Finally, the assumptions made in the last four paragraphs in your message are again entirely irrelevant since the point here is that clients are generally trusted in their form of being a ‘consensus’, and the threat actor is a potential malicious server owner or their supply chain. While a single client may definitely be able to load an unauthorized copy of a resource, all of them being able to do so is highly unlikely.
Summarizing: I’m personally also very much against what’s going on here and the general tendency to see FiveM as a ‘get rich quick scheme’ for everyone involved, this however is needed to allow the community to do what they already have been doing since the project has existed but without it being something we can’t monitor, influence or even be aware of at all other than trying to ‘fight it’, which is a fight one certainly will lose.
15 Likes
I completely agree with this. Most of the time i find that resources don’t work the way I want them to and often change lots of things about them. This stops almost all customization of resources that you paid for.
5 Likes
The ‘paid encrypted resource’ ecosystem is not meant for people who are actually able to customize code. It’s one propagated in general by people writing code of such low quality that you don’t even want to base anything off of it.
If a resource author were sane enough, they’d not be selling obfuscated, encrypted, or whatever code in the first place, as they understand e.g. people who are pirating a resource aren’t people you’d (like to) have as a customer.
As in my post above, this is done solely to deal with the people who are doing this kind of nonsense selling-of-obfuscated-stuff already and not have it harm actual platform development by repros being blocked on ‘hey, buy it yourself you dunce’ or seeing a crash dump fail in some 5000000000000 character string of interpreted Lua from a Lua-in-Lua-in-Lua VM.
Join any of the top-played RP servers in certain regions and use fetch to download some resource files. You’ll see that even without them having any FXAP-style resources, most code in these regions where abuse is normalized is extremely unreadable from who-knows-whatever-obfuscation-tools people sell now, and still filled with weirdness.
4 Likes
Untill it is a choice of resource authors if they want to encrypt or not encrypt they work - I like this update. Especially I like that there is an ability to choose which files will not be encrypted. Amazing news, great job!
3 Likes
This is true. Is there any warning anywhere that the resource you’re paying for is encrypted?
2 Likes
I think it depends on the developer of the resource, in any case you pay for the finished product
4 Likes
Maybe there should be a way to leave reviews on tebex, this way customers can read about what they’re buying.
7 Likes
follow up on the post above, if they don’t disclose it but yet you receive an encrypted resource. Just call them out for it. It does enough to their image as a seller but yet again some people really don’t care what their image looks like. Edit: the post underneath you, doesn’t add up after approval 
3 Likes
Been waiting for this for a long time, I hope JS support will come soon.
2 Likes
Is there an api we can use to automate the process?
Also is there a performance impact on obfuscated lua code?
1 Like
Amazing work guys
1 Like
From my tests there is close to no loss in performance of the code, and if there is it’s most likely very minimal
Good Morning,
Definitely been long awaited but if I am a developer for a server, this is locked to a key. I cannot test this resource in my test environment before using the live server. Is that correct??
2 Likes