Using any suffix with a Roman numeral (I, V, X...) is only a viable suffix when you're describing a major distribution version of the software.

According to table.find documentation, you provide the table first, then the value to look for second. You have that mixed up.

table.find({ "Hello", "World" }, "World") --> 2

Orbit take it or leave it.

I would highly consider reinstalling Windows or switching to Linux. While it may suck, it's better than having to remove all that stuff manually.

I ran this on my iPhone for no reason at all lol.

@Syraxes_ Nah you'll be fine just get a fancy prosthetic leg that integrates with your nerves. I would recommend you don't look at the bill, especially without medical insurance 😬

Fun fact: This is an actual thing for prosthetic hands so you can move your fingers but I think they're still in the early stages.

@Finity It depends on what you're cracking and what method you want to use. I would try hooking HTTP request functions to see what's being done, then seeing if you can spoof the returns, which is easier than setting up a lower level replay attack.

@Alternate That's a good question, and you are absolutely correct. That's the reason replay attacks can't be used in some cases. What an attacker could do to get circumvent protection through SSL is to issue a fake server certificate to use from their own rogue CA (which is free), then trusting that rogue CA on the target computer. I don't even know if you need a certificate authority; any certificate may work because I don't believe any validation is done on the custom HTTP request functions.

A much simpler task would be carrying out a replay attack through hooking any function that initiates an HTTP request in Lua and making it return a false response body, which would skip having to make a HTTP request, inevitably skipping the certificate validation step on low level code, as no server request would have to be made. This works because the validation code is completely done on Lua. This method may be easier to detect from Lua, but it's easier than setting up your own certificate authority and issuing false certificates.

Edit: It looks like (at least Script-Ware) validates HTTPS requests. I couldn't get it to work on a self-signed cert, so a CA would need to be created.

https://i.imgur.com/uO676g3.jpeg

The class generated by ChatGPT isn't that useful. It's essentially a wrapper class for an API (that doesn't exist?), which in this case, it just creates unnecessary boilerplate code. If you're going to share code, I'd recommend looking over it, as ChatGPT doesn't always provide the best output. This is the same reason StackOverflow banned the use of ChatGPT in their platform.

Most key systems aren't secure, as the client (for the most part) validates that the user has a valid license, either directly or indirectly. Some key systems use hardware ID for authentication, others may use a GUID, maybe a random string, the Roblox user ID, etc. These are just a few examples that a developer may use to authenticate their client, and there's many ways a key system can be implemented. You'll need to conduct your own research to figure that out. Due to the nature of Lua (where you're not able to hide your code easily), some of the developers have resorted to using obfuscation, which is not secure either. There's a large number of methods to crack a key system, all of which depend on the method that's used to verify the client's integrity, forcing the attacker to think out of the box and reverse engineer the system.

Although you may have to conduct your own research, there are common ways key systems are cracked. I wrote these methods for you to read below. If you need any source examples, make sure to reply to me so I can provide some.

1. Replay attacks - These consist of "faking" the endpoint(s) that the client utilizes to verify the user's key. This allows the attacker to have full control over what data is transmitted to/from one endpoint to another. Let's say I'm the computer and I want to verify my user's key. I send a request to "example.com/api/v1/validate" with the payload '{ "key: "123456abcdefg" }'. The server replies with '{ "success": 'true', "valid": 'true" }'. I now know that the key is valid because the server says that it is. What can happen is that the attacker can create a host entry with the domain "example.com" that points to a rogue server instance that's self-hosted. Now all of the traffic goes to the local server, so this rogue server can be programmed to relay all the data to "example.com," except when a key is being validated. When a request is being sent to "/api/v1/validate," the rogue server can reply saying that the key is valid without ever needing to contact the legitimate key server. The client can't tell the difference between them, so it proceeds to believe the key is valid when it's not. These types of attacks are actively used in the real world for not only cracking key systems, but for spoofing data sent between clients with a man in the middle. Replay attacks run at a much lower level than the other attacks.

2. Web request hooks - These are less sophisticated attacks. They simply hook web requests and replay the data. It works likewise with a replay attack, but there is no intercepting web server, rather the web request is checked by the hook's code and if there's a certain pattern in the request, it'll return a fake response. Web request hooking runs at the application level (Lua virtual machine), which is in a higher level than that of a replay attack. These attacks can be detected much easier, as it's done completely on the Lua virtual machine. One way this can be implemented is by hooking a function that makes a web request, such as game.HttpGet or syn.request, and returning fake responses when necessary. 

3. EQ inversing  - When messing with obfuscated code, equality (EQ) instruction inversing may work well. Lua runs a lower level form of itself as VM instructions. Think of this low level form of code as an intermediate language (IL), or bytecode, for short. This code is essentially machine code that the VM can understand. Most Lua obfuscators will emulate a virtual machine on top of the shared VM that you execute your scripts on. The goal is to find the equality instruction where it checks the server response, and flipping that. You're essentially turning your code from "response.valid == true" to "response.valid ~= true", which in turn makes the code proceed when the key is invalid. Many obfuscator VMs implement their custom forms of the Lua VM, so a bit of reverse engineering would need to be conducted to determine how the equality operator in that specific VM works, if it has one.

The fact that exploits aren't being made for the Microsoft Store version can imply that it can't be exploited, however that thought is completely false. The reason the UWP version of Roblox isn't targeted is due to the fact that there's substantially less demand. In other words, the Microsoft Store version of Roblox has a much smaller user base. Think about Roblox distributions as a capitalist economy. When there's more demand, there's more success. Exploit production developers target the native Roblox application because more people will use it, mainly because it supports the browser UI. You also have to take into consideration the fact that Roblox can be played on legacy versions of Windows (such as Windows 7). If the developers targeted a UWP app—where UWP support was implemented after Windows 7—any user on a legacy distribution of Windows would not be able to use it without upgrading their computer, where their computer may have hardware incompatibilities with Windows 8 and above.

I believe that introducing a subtly faster animation would make it more appealing to the eyes, but overall it's good.

@Gulg Have you attempted manually entering the process ID you see in the task manager? I can't remember if Roblox creates a new process if it's launched like that.

The process ID can be found here:
https://i.imgur.com/Eauc7By.png

If you don't see it, right click the top bar where it says "Name, CPU..." and check the PID entry.

Reviewing your situation, I can see two issues.

1. There is a good chance you're attempting to load your library inside Roblox's daemon process. This second process runs in the background and serves as a reporting tool for modules allocated to the game's memory space. Since the process runs in the background, the process doesn't have a window, therefore you can get the process ID of the game's true process instead of the daemon process by ensuring it has a window handle.

2. There also may be a conflict with architectures, as you said that it worked fine on the Notepad application, which runs on 64-bit mode by default on 64-bit editions of Windows, which I'm going to assume you're running. Make sure you're compiling your library on the x86—or Win32—platform, and not x64.

Here is some pseudocode for getting the non-daemon Roblox process:

var robloxPid = 0;
foreach (var proc in Process.GetProcessesByName("RobloxPlayerBeta")) { // Don't include ".exe" at the end, because it's stated that GetProcessesByName requires a "friendly name."
    if (proc.MainWindowHandle != IntPtr.Zero) {
        robloxPid = proc.Id;
        break;
    }
}

if (robloxPid == 0) {
    // Roblox not found.
}

Let me know if anything worked.