Learn Script 2

In this chapter of a scripter's guide to ROBLOX exploiting, we will be taking a peek at the ROBLOX player to see what kind of Lua internals it has in store for us. This is where your exploiter eyes will start to open! By the end of this part, you will hopefully begin to understand the direction we are going. But even if you aren't, don't worry, because in the next part, we'll be taking it to the next level.

I hope you did your homework, because this guide assumes you did. You should have spent at least a good day or two making yourself familiar with the Lua C API using a comfortable non-ROBLOX environment. If you can't tell a stack from a stick, it's time for you to go back and learn some more. Only continue when you feel 100% comfortable with the prerequisites. Rushing will very badly harm your learning experience.


[Image: KQUJY8x.gif]


~ Part 2: Reverse Engineering ~

The steps you need to take to write a brand new exploit from scratch depends on how you are going to write that exploit. There are many different approaches. In fact, there are so many different approaches that I can't even list them all. If you're curious about these approaches, I encourage you to read more about them after this guide, and perhaps even stop and decide to follow your favorite one. But we are going to do it the most common way, and you are going to learn that all approaches have 1 thing in common: Reverse engineering.

These are the steps you will follow in this entire guide, in order, from start to finish:

Apply reverse engineering to locate the ROBLOX player's Lua C API functions
Write a DLL file that finds and calls some of those functions using their memory addresses
Use DLL injection to force the ROBLOX player to run your DLL

There are quite a few hurdles along the way, and there are some concepts you need to be introduced to if you're going to be able to do this by yourself. But I know you can do it. This guide is laying out a path for you. I will teach you my tricks and show you clear as day what things you need to practice. Just keep in mind if you want to get better, you are going to need to help yourself in your own time as well. Just putting that out there.


[Image: KQUJY8x.gif]


~ Disassembling ROBLOX ~

IDA Pro is a wonderful tool. If you've never heard of it, you probably haven't been browsing V3rmillion very long. It's something called a disassembler, and this particular disassembler has sort of become the standard tool that everybody on V3rmillion uses. Unfortunately, it's very expensive. You are free to use any disassembler you'd like - and there are quite a lot of them - but for the sake of clarity and familiarity, we will be using a cracked version of IDA Pro in this tutorial. That is what most V3rmillion exploiters, including myself, learned to use. The Internet is your friend.

So let's talk about what IDA Pro really is. It's a disassembler as I mentioned before, but what is a disassembler? Feel free to skip this little section if you already know the answer to that question, but if you're simply a ROBLOX Lua scripter, you might have never heard of it. Essentially, a disassembler takes apart a program and shows you each and every one of its individual instructions. A program like ROBLOX is made up of an extremely massive amount of instructions. The format of a program's instructions depends on your processor, because that's what reads them. For the most part though, it's the same.

ROBLOX uses the Intel x86 instruction set. Normally, instructions would be in the format of binary (that is, a bunch of 1s and 0s, just like the Hollywood hacker movies), but lucky for us, there is a notation version of these instructions. The notation version is called assembly language. You've probably heard of it before. An assembly instruction is a short keyword (such as "push" or "mov") which acts as a shortcut to an instruction made up of binary numbers that would otherwise be extremely difficult to memorize. The first programmers invented assembly to make programming their ancient computers much easier.

Don't worry, you won't be learning assembly. That is an extremely difficult task that takes years of devotion. It's the lowest level of programming. When you code a program in C++ and compile it to an .exe, the compiler is automatically taking your code and turning it into assembly, and then those assembly instructions are further turned into machine code. That machine code is 1:1 with assembly, but it's designed for your processor to understand. If you've ever opened an .exe file in notepad then you'll know what I mean.

But with all that explained, do you see why programs like IDA Pro are called disassemblers? It's because a program is assembled with many different instructions, and the disassembler breaks it down to show you everything in assembly format. IDA Pro will take any compiled binary - such as RobloxPlayerBeta.exe - and analyze it from start to finish so you can see its inner workings. This is the ultimate reverse engineering tool. By simply understanding a few basic assembly instructions (and by using IDA Pro's magical pseudocode decompiler to see what the instructions might look like in C++ syntax), you will be given the next best thing to actually reading the ROBLOX client's source code.

When you open IDA Pro, you will probably see a window like this:

[Image: RphC2uT.png]

That lady is judging you. Ignore her, she does that every time you use the program. What you want to do is click "New," and then browse for the latest RobloxPlayerBeta.exe. It will always be in %localappdata%\roblox\Versions\versionid, where versionid is the ID for the latest version. At the time of writing this guide, the folder is called version-c2285b6f3d724119, but ROBLOX updates every week and you will always have to disassemble the new player. There is one folder for the ROBLOX player and another for Studio.

Once IDA loads the ROBLOX player, it needs to perform its autoanalysis. This can take a while. The status bar along the bottom will show when the autoanalysis is active, and you will be able to see in the output when the autoanalysis is complete. Here is a screenshot of what IDA will look like when it's open in this state:

[Image: CXxU5uX.png]

Feel free to be overwhelmed. You probably don't understand what each of these tabs, words, and numbers mean, and you don't really have to yet. The only concept you really need to understand right now is that this is a disassembly of the ROBLOX player. Once the autoanalysis is finished, you can demonstrate this to yourself; click View -> Open subviews -> Strings (or press Shift+F12) and wait for IDA to generate a list of every string it can find in the program. The strings up at the top are all garbled and uncomprehensable, but use the scroll bar to scan over the whole thing. You will recognize a lot of things.

If you want to see IDA's coolness in action, take a look at this demonstration. The official Lua website has all the info you'll ever need when it comes to the language's internals. Here is a link to a function called luaI_openlib from lauxlib.c, a part of the Lua 5.1 source code: https://www.lua.org/source/5.1/lauxlib.c...aI_openlib

This function is totally insignificant for anything we want to do, but it calls a lot of very useful Lua C functions inside of it. Can you spot the line that calls luaL_error? There is a string in that line; it's the message argument for the error function. It says "name conflict for module " followed by what looks like some formatting stuff.

Now remember, ROBLOX includes the entire Lua 5.1 library. That's how it implements Lua into the game in the first place. So what happens if we go to IDA's string list and search for that error string with Ctrl+F?

[Image: i5j1oYd.png]

Gasp! Do you see where we're going with this? Double-click the line to be taken to the place where the string is defined. IDA has automatically given it the name "aNameConflictFo," which is very descriptive and artistic.

[Image: ZmajieX.png]

On the right-ish side of the IDA view, in light blue text, you will see lines under all the value declarations with the prefix "DATA XREF." An xref in IDA (short for "cross reference") is another place in the disassembly where a certain value is used. aNameConflictFo only has 1 xref. Can you guess where it must be used? luaI_openlib of course! This kind of logic and reasoning is what you need to get used to as a reverse engineer. It's all guesswork, common sense, and educated guesses. And normally you're right. You just need confidence, which you build by trying things out.

So for me, it says the xref was found in sub_546B80+87. In IDA, automatically-generated function names are "sub_" followed by the function's area in the program's memory. That memory address will change every update, so don't panic if the number is different for you. The +87 at the end means that our aNameConflictFo string is 0x87 bytes down from the beginning of the luaI_openlib function. I will teach you about bytes and hexadecimal numbers later, so for now just don't worry about that.

Double-click the function name in the xref line and IDA will take you to the part of the function where the string is used.

[Image: uXbSESE.png]

Notice how the instruction being used in that line is "push?" Just like in the Lua C API, assembly language uses a stack. Look at the lines above and below the one we jumped to. The string argument is being pushed onto the stack along with a couple other arguments, and then afterwards, there is a "call" instruction. It's calling the function sub_5473A0 with the arguments that were just pushed. Can you guess what that function must be? If you were paying attention, you'll guess correctly. It's luaL_error!

We could click on luaL_error and go examine it, but instead, we are going to keep examining luaI_openlib. For the sake of convenience, you can actually rename sub_5473A0 to luaL_error, since we know that's what it really is. Do that by highlighting the function and pressing the N key, then entering the new name into the box that comes up.

[Image: Cq39SPK.gif]

Let's scroll up to the top of the function. Functions are also called "subroutines," and that's what IDA uses (which is evident in the sub_ prefix), so when you see a gigantic border that says "SUBROUTINE," you know you are at the place where the function begins. The address to the left of that border (and the chunk of argument-related code after it) is the address of the function itself, which is luaI_openlib in our case.

I have good news: You don't have to sift through the assembly instructions and try to understand what's happening. IDA has a magical tool called the Hex-Rays decompiler. When you position the cursor inside of a subroutine and press F5, IDA will read over the whole thing, and it will create an estimate of what that function would look like in C++ syntax. It's an imperfect guess, and it's designed for reading. That means you couldn't copy/paste the pseudocode into C++ and compile it without making adjustments. But it's perfect for understanding a function or just reading bits of it without being a genius!

Let's hit F5 to view the function's pseudocode, then scroll down a bit to where that error string is used:

[Image: bvUTOUL.png]

Jackpot! Look at all these functions that are being called. Those are Lua C functions. Let's compare it to the original function:

[Image: bqpmkSY.png]

Look closely. Do you see the similarity? It matches perfectly. We now know what each of those functions are, thanks to the magic of reverse engineering. We can copy the address of each and every one of them for use in our exploit later, and rename them to useful names that we can recognize in the disassembly.

Creativity and discovery are at the heart of exploiting. I thought outside the box to find these values, and you should too. Get familiar with IDA Pro (there are more than a few guides and tutorials you can find) and learn to use it well as you progress. If you've made it this far, your eyes should be starting to open. Can you feel the exploiter inside you calling out to you?


[Image: KQUJY8x.gif]


~ In the Next Guide ~

In part 3 of a Lua scripter's guide to ROBLOX exploiting, I will talk about DLL injection, memory-related math, and how to begin your first ROBLOX exploit. We may go over some more reverse engineering techniques and C++ tricks you probably haven't learned yet. In your finished exploit, you will be calling the Lua C API functions that we found by disassembling ROBLOX, so your learning will pay off. I will give more details on that when the time comes, but for now, keep practicing your Lua C API smarts, and try to get used to using IDA Pro