DEV Community: Zofia

AssaultCube | Writing your first external cheat in RustLang

Zofia — Sun, 16 Jun 2024 20:52:15 +0000

Writing a-salt-cube

Prerequisites

A decent knowledge of RustLang

Outline

Writing cheat requirements

Finding game modules
Finding pointers and offsets (we'll use Cheat Engine)

Coding

Create command line interface to modify cheat properties during execution
Open handles to the target process and module
Creating threads to handle cheat logic in parallel
Dereference pointer chains and write cheat values

Finding our pointers

Open AssaultCube, and enter the singleplayer mode.

First, I'm going to open up Cheat Engine and attach it to the Assault Cube process.

From here, we can enter our initial health value (100) into the value field and start our first scan.

From my first scan, I got 996 results. This is not ideal, as we need to find a small, consistent pool of addresses that
hold our health value.

So, let's run another scan after taking some damage from a bot friend.

One result! Wow, that was quick. For larger games, you will encounter more addresses finding pointers this way, and it
may be of use then to look into tools designed for reversing game data.

Let's click on our address and head down to the red arrow to save it in our address list.
After we have found our address(es), we need to run a pointer scan to see what points to our health address.

Right-click on the address from the address table and press Pointer scan for this address, then simply press ok in the
scan options prompt.

After our scan has completed we should get fairly large amount of entries. Not to worry though, this doesn't really
matter as we're going to automatically sort the offsets.

Click on each offset category to sort to the pointer with the least amount and smallest of offsets.
We're going to want to look for a module we can read from, followed by a small series of offsets. For AssaultCube, I
found the health pointer to be at "ac_client.exe"+0017E0A8 [0xEC]

I guess I never explained what a pointer, an address, or an offset really is.

A pointer is made of up of a base address, and offsets. This stores the address to a location in memory, and the offsets
are a series of other pointers, relative to our base pointer.

For example, if I have pointer "game.exe"+0x100 [0x0], we would first read from the module "game.exe" to find its
address. Then, we read at address 0x100 to get a pointer to, let's say our local player. We read the pointer 0x0 (0)
bytes away to get our final address, pointing to I don't know, the player id, which we can then use to later modify the
value of the player id.

Addresses are our way of accessing values held in memory. When we invoke our system API to read or write process memory,
we need to give it an address, a location of where the data is stored at.

# 0 - 60
0x0..0x40 => Example Executable Info, 

# 100
0x64 => Player
  # 100
  | 0x64 => Player Id

  # 104 - 114
  | 0x68..0x72 => Player Name

Offsets are just distance from one address to another, take the following example:

// "game.exe" + 0x10
#[repr(C)]
struct Player {
    id: u32, // offset: 0x0
    name: [u8; 10], // offset: 0x4 (an u32 is four bytes in size, so our next field would be four bytes away)
}

Creating our project

Run cargo init <NAME> to create your Cargo project.

We will be using one of my Windows-only libraries to assist us in developing the cheat. I know, right? If you're like
me, I hate when tutorials do that too. Feel free to look at the library's source to see how we interact with processes
and memory, and write your own instead. It's a fun task, really, so don't get discouraged.

Let's add the memwar library to the Cargo.toml, along with anyhow to help with error
handling, and my crate cnsl for reading user prompts from our command line:

[dependencies]
memwar = { git = "https://github.com/imajindevon/memwar" }
anyhow = "1.0.86"
cnsl = "0.1.3"

Writing the main function

We outlined our program logic previously, but now we need to outline the
processes:

main cli thread - accepts user input to change values
health cheat thread - modifies ingame health value

In our main function, I'm going to write some code to find our process and open a handle to it, returning an error if it
fails.

Although, we need to account for the fact that most of memwar's functions are unsafe. So let's run all of our code in a
separate, unsafe function.

// main.rs

use memwar::process;
use anyhow::{anyhow, Result};

unsafe fn run() -> Result<()> {
    let pid = process::get_process_by_name("ac_client.exe")
        .map_err(|e| anyhow!("Failed to get window! OS error: {e}"))?
        .ok_or_else(|| anyhow!("Failed to find ac_client.exe!"))?;

    let h_process = process::open_process_handle(pid)
        .map_err(|e| anyhow!("Failed to open a handle to AssaultCube.exe! OS error: {e}"))?;

    Ok(())
}

fn main() -> Result<()> {
    unsafe {
        run()
    }
}

Now run your program with cargo run, and see if you can catch an error.
If so, don't worry. Just remember Google is your best friend as a developer, so make sure to use it to your full
advantage.

We all make simple mistakes! I got the following error when I first ran the program:

Error: Failed to find AssaultCube.exe!

After looking through the task manager, I was able to see the problem. The AssaultCube process is named ac_client.exe.
After fixing our code, we can see the program returns without an error.

Writing our `tasks.rs` module

NOTE: As of memwar v0.1.1, a Task structure is available for you to develop your cheat thread around.

Create a module named tasks.rs.
Our tasks module will contain a Tasks struct that will hold all of our tasks.

NOTE: AssaultCube is a 32-bit process. Our following logic will contain code that will NOT work if you build to a
64-bit target. To fix this, append this option to your Cargo build command to compile to a 32-bit target:
--target i686-pc-windows-msvc

Instead of writing the health value once, we will continuously update the value with our modified value in a loop. This
is also a decent exercise to get you familiar with threads.

// tasks.rs

unsafe fn new_health_task(alloc: SendAlloc) -> Task<i32, u32> {
    todo!()
}

pub struct Tasks {
    health_task: Task<i32, u32>,
}

impl Tasks {
    pub fn health_task(&self) -> &Task<i32, u32> {
        &self.health_task
    }

    pub unsafe fn from_alloc(alloc: SendAlloc) -> Self {
        Self {
            health_task: new_health_task(alloc),
        }
    }
}

Defining constants in the `pointers.rs` module

Now that we have our half-finished implementation of our tasks module, we need to store a few constants. These constants
will store the game module's address of our base pointer, and the offsets of the chain of later pointers.

Remember this? "ac_client.exe"+0017E0A8 [0xEC] In this format, 0017E0A8 is the address of our base pointer,
(only in ac_client.exe), and after adding it to the base address of module "ac_client.exe", we need to dereference one
more pointer. We need to add offset 0xEC to get the address of our final health pointer. It is safe to assume that
address 0017E0A8 gave us our local player address, which we can take advantage of later on.

// pointers.rs

pub const LOCAL_PLAYER: usize = 0x0017E0A8;

/// Value type: i32
pub const OFFS_LOCAL_PLAYER_HEALTH: [usize; 1] = [0xEC];

Finishing `new_health_task`

For this approach I used a Sender<u32> and Receiver<u32> to send and receive the health value across threads.
I also used a Sender<u32> and Receiver<u32> to send and receive errors that occurred in the thread. This will be
useful for debugging broken pointers and operations.

unsafe fn new_health_task(alloc: SendAlloc) -> Task<i32, u32> {
    let (health_sender, health_receiver) = mpsc::channel();
    let (error_sender, error_receiver) = mpsc::channel();
    todo!()
}

We use an AtomicBool to modify and read if the cheat is enabled.

unsafe fn new_health_task(alloc: SendAlloc) -> Task<i32, u32> {
    // ...
    let is_enabled = Arc::<AtomicBool>::default();
    let is_enabled_sent = is_enabled.clone();
    todo!()
}

We need to check if our cheat is loaded, or if a new modified health value has been sent from the CLI.

unsafe fn new_health_task(alloc: SendAlloc) -> Task<i32, u32> {
    // ...
    thread::spawn(move || {
        let mut health = None;

        loop {
            // Try and read an updated modified health value from the CLI thread.
            match health_receiver.recv_timeout(Duration::from_millis(100)) {
                // The CLI thread has sent an updated health value.
                Ok(v) => health = Some(v),
                // The CLI thread has not sent an updated health value, so we will continue to
                // use the value previously stored.
                Err(RecvTimeoutError::Timeout) => (),

                // The CLI thread has disconnected, so we exit the thread.
                Err(RecvTimeoutError::Disconnected) => return,
            };

            // If the cheat is not enabled, continue the loop.
            if !is_enabled_sent.load(Ordering::Relaxed) {
                continue;
            }

            // TODO
        }
    });
    todo!()
}

Finally, if the cheat is enabled, we can write our modified health value.

unsafe fn new_health_task(alloc: SendAlloc) -> Task<i32, u32> {
    // ...
    thread::spawn(move || {
        let mut health = None;

        loop {
            // ...

            if let Some(health) = health {
                let alloc = Allocation::from(alloc);

                let p_health = match alloc
                    .deref_chain_with_base(pointers::LOCAL_PLAYER as _, pointers::OFFS_LOCAL_PLAYER_HEALTH)
                {
                    Ok(v) => v,
                    Err(e) => {
                        let _ = error_sender.send(e);
                        continue;
                    }
                };

                if let Err(err) = alloc.write_i32(p_health, health) {
                    let _ = error_sender.send(err);
                }
            }
        }
    });
    Task::new(health_sender, is_enabled, error_receiver)
}

Finishing our main function

Now that we have the main cheat logic out of the way, we will revisit our main function and set up a command line
interface for our cheat user, along with getting the base address of ac_client.exe.

// main.rs

use anyhow::bail;

unsafe fn run() -> Result<()> {
    // ...
    let p_base = module::get_mod_base(pid, "ac_client.exe")
        .map_err(|e| anyhow!("Failed to create snapshot of process! OS error: {e}"))?;

    if p_base.is_null() {
        bail!("Failed to find ac_client.exe module!")
    }

    let alloc = SendAlloc::new(CVoidPtr(h_process), CVoidPtr(p_base));
    let tasks = Tasks::from_alloc(alloc);

    cli(tasks) // We will write this function next
}

Our CLI function should look something like this, but adjust it to your taste:

// main.rs

unsafe fn cli(tasks: Tasks) -> Result<()> {
    println!("Type help to get a list of commands");

    loop {
        let input = readln!("$ ");
        let trim = input.trim();

        if trim == "help" {
            println!("help\ntoggle_health");
            println!("health");
            println!(" \\ value: i32")
        }

        if trim == "toggle_health" {
            tasks.health_task().toggle_enabled();
        }

        if trim == "health" {
            println!("New health value:");

            let health = loop {
                let health_value = readln!("$ ");

                match health_value.parse() {
                    Ok(v) => break v,
                    Err(e) => eprintln!("{e}"),
                }
            };

            tasks.health_task().send_data(health)?;

            match tasks.health_task().read_error() {
                Ok(err) => {
                    eprintln!("Thread raised error {err}")
                }
                Err(TryRecvError::Empty) => (),
                Err(TryRecvError::Disconnected) => bail!("Thread disconnected! Aborting.")
            }
        }
    }
}

Wow. You did it! You wrote your first external cheat. Or, we hope. Let's test it and see if we get any errors or
unexpected results.

Loading up our program gives us no errors:

Type help to get a list of commands
$

If we enter health and our desired health value:

$ health
New health value:
$ 1000

And let us not forget to toggle our cheat (🤦🏿‍♂️)..

$ toggle_health

We can see our updated health value ingame!

How to make your GitHub repository look and feel professional ✈🌍

Zofia — Sat, 12 Nov 2022 17:00:00 +0000

A good looking and nicely organized repository leaves a huge first impression on potential stargazers. 🌟

🕺 What makes a professional repository?

Nearly all professional repositories meet the following criteria:

Is nicely organized
Contains numerous files in the root directory
A detailed README
A security policy
LICENSE file
Workflows
A good description and About section

⚡ Creating workflows

What is GitHub Actions?

According to the official documentation:

GitHub Actions is a continuous integration and continuous delivery (CI/CD) platform that allows you to automate your build, test, and deployment pipeline. You can create workflows that build and test every pull request to your repository, or deploy merged pull requests to production.

I use GitHub Actions for all of the features listed above, but also for the workflow badges! (we'll cover those later)

In your repository homepage, press the Actions tab.
Browse workflows and configure those which meet your needs.
I use the Rust and clippy-check actions on all of my important Rust repositories.

If you're using Rust, your rust.yml workflow file may look like this:



name: Rust

on:
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]

env:
  CARGO_TERM_COLOR: always

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v3
    - name: Build
      run: cargo build --verbose
    - name: Run tests
      run: cargo test --verbose

📚 `README.md`, `LICENSE`, and `SECURITY.md`

These files are a must have in any repository. But what are they?

`README.md`

This file provides a landing-page like experience for those who visit your repository. It the first thing you are greeted with when viewing a repository.

Delivering a detailed README.md is crucial to keep a visitor's attention and introduce potential users to your software.

Earlier we set up workflows, which also provide status badges! You can find your badge here:



https://github.com/<OWNER>/<REPOSITORY>/actions/workflows/<WORKFLOW_FILE>/badge.svg

Try adding this to the top of your README.md and see the difference it makes:



<div align="center">
    <h1>MYPROJECT</h1>
    <img src="https://github.com/<OWNER>/<REPOSITORY>/actions/workflows/<WORKFLOW_FILE>/badge.svg" alt="Workflow status badge">
</div>

`LICENSE`

The LICENSE file defines the license of your software.

If you are having trouble picking a license, https://choosealicense.com/ may help you out.

Possibly the most common open-source software license is the MIT license.



Copyright <YEAR> <COPYRIGHT HOLDER>

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

`SECURITY.md`

The SECURITY.md file informs users on how to report security concerns and/or vulnerabilities.

You can view an example security policy here.

📝 Open source community standards

There are even more policies and guidelines you can setup for your repository. Your repository should check all of the recommended community standards.

To see what your repository is missing, visit the Insights/Community Standards page.

🎇 About section

Topics

Be sure to list the most relevant topics your repository falls under.

Picking good topics will make it easier for your repository to be discovered in GitHub's Explore tab.

Description

A good repository description informs users of what the repository is about.

Bad example, (bear with me), but if you were exploring on GitHub and stumbled across a repository named Oven, you'd expect it to have a description maybe along the lines of:



Oven is a lightweight Javascript library (~20kb) exposing hidden Javascript functions.
View the Wiki section for more information.

You would not want to see:



Oven is a library made in Javascript. It is my first repository. Please star it.

⛔ Disabling unused features

Don't bloat your repository! Removing bloat starts with removing unused features.

For example, if you aren't using the Wiki tab, remove it!

In Eddie Jaoude's video about getting more GitHub stars, he makes a really good point. If you are going to have documentation, you may not want to use the Wiki tab. You most definitely want to farm all of those pull requests that come with holding documentation within the repository itself. Consider using a docs/ folder.

You can disable select features by entering your repository's Settings page and scrolling down. There, you can check/uncheck the features of your choice.

👋 Conclusion

I hope this article helped you in some way. If it did, make sure to react with this post and share it! I make these articles for free to try and improve the open source community, and give beginners the resources I didn't have when starting out.
This article took 5 hours to write. 🕔

Follow me for more awesome articles! 🎉

Why do we need configuration? Creating and handling configuration files in Rust 📝

Zofia — Tue, 08 Nov 2022 05:29:25 +0000

Configuration is nearly always a necessity when it comes to both public and private software.

Just imagine, you install a program that plays a sound every 30 seconds. Then suddenly your needs shift, and now you need it to play every 15 seconds. Oh no! This program doesn't allow you to change the rate of which the sound plays. You are now left with two choices:

Edit the program yourself, which could take a lot of time
Find another program which allows you to configure the interval of the sound

From a developer standpoint, if configuration were present in this situation, fewer users would be turned away from the lack of flexibility in our software.

NOTE

Level: Beginner-Intermediate

In this project we'll use the toml crate. When it comes to handling configurations, this is not your only option. Take a look at these popular crates:

Getting started

Creating the Cargo project

In your terminal, run the following command:

cargo init <PROJECT_NAME>

Adding dependencies

For our project we will need two dependencies:

serde
toml

Add the following to your Cargo.toml:

serde = { version = "1.0.147", features = ["derive"] }
toml = "0.5.9"

Defining our config structure

What will our program do?

For this example, our program will print a given word N amount of times.

Our target config will look like this:

word = "Banana!"
repeat = 3

And the output:

Banana!
Banana!
Banana!

Definition

First, import the Serialize and Deserialize traits from the serde crate.

NOTE: This will only work if you have the derive feature enabled for serde. We added this feature earlier.

Create your struct and name it something along the lines of AppConfig. This struct will store the values for your config.

Above the struct definition, derive the Serialize and Deserialize traits we just imported.

use serde::{Serialize, Deserialize};

#[derive(Serialize, Deserialize)]
struct AppConfig {
    word: String,
    repeat: usize,
}

But there's a problem with our code, we don't provide the user with default values. We can fix that easily by implementing Default for our struct.

impl Default for AppConfig {
    fn default() -> Self {
        Self {
            word: "Banana".to_string(),
            repeat: 5
        }
    }
}

Great! We've finished defining the structure of our configuration. It's that easy.

Loading and initializing the configuration file

Creating the `ConfigError` enum

When trying to load the configuration, two errors can occur:

An IO error
The configuration is invalid

We will create an enum which covers both of these error scenarios.

This is necessary, because you want to inform the user of what's going wrong, instead of leaving them scratching their head.

use std::io;

enum ConfigError {
    IoError(io::Error),
    InvalidConfig(toml::de::Error)
}

// These implementations allow us to use the `?` operator on functions that
// don't necessarily return ConfigError.
impl From<io::Error> for ConfigError {
    fn from(value: io::Error) -> Self {
        Self::IoError(value)
    }
}

impl From<toml::de::Error> for ConfigError {
    fn from(value: toml::de::Error) -> Self {
        Self::InvalidConfig(value)
    }
}

Definition

With the error enum defined, we're able to create a function to either load or initialize the configuration file.

The function will go as follows:

If the config file exists, read the content of the file, parse the TOML, then return the AppConfig.

If the file does not exist, save the default configuration to the file.

The toml crate provides two methods which provide us the functionality we need:

toml::from_str(&S)
toml::to_string(&T)

use std::path::Path;
use std::{fs, io};

fn load_or_initialize() -> Result<AppConfig, ConfigError> {
    let config_path = Path::new("Config.toml");

    if config_path.exists() {
        // The `?` operator tells Rust, if the value is an error, return that error.
        // You can also use the `?` operator on the Option enum.

        let content = fs::read_to_string(config_path)?;
        let config = toml::from_str(&content)?;

        return Ok(config);
    }

    // The config file does not exist, so we must initialize it with the default values.

    let config = AppConfig::default();
    let toml = toml::to_string(&config).unwrap();

    fs::write(config_path, toml)?;
    Ok(config)
}

Implementing the program functionality

Implementing the program's actual functionality is pretty simple.

First, load the configuration (or handle the errors), then continue with the program logic.

fn main() {
    let config = match load_or_initialize() {
        Ok(v) => v,
        Err(err) => {
            match err {
                ConfigError::IoError(err) => {
                    eprintln!("An error occurred while loading the config: {err}");
                }
                ConfigError::InvalidConfig(err) => {
                    eprintln!("An error occurred while parsing the config:");
                    eprintln!("{err}");
                }
            }
            return;
        }
    };

    for _ in 0..config.repeat {
        println!("{}", config.word);
    }
}

Output

Hello readers!
Hello readers!
Hello readers!
Hello readers!
Hello readers!

`Config.toml`

word = "Hello readers!"
repeat = 5

That's it! We've successfully implemented configuration for our program.

Note that this solution is extremely scalable. With the power of serde, we can make extremely complex configuration files.

Conclusion

That's it for this article! Make sure to follow me for more well-written articles like this.

Creating a minimal RESTful song request API using Rocket 🚀

Zofia — Wed, 19 Oct 2022 20:07:20 +0000

What is a song request system?

If you watch streamers on platforms such as YouTube and Twitch, you may have encountered a song request system. A song request system allows the viewer to add a song to a song queue. When the song reaches the front of the queue, the song is played over the live stream.

With the help of the rocket crate, creating an API for this system in Rust is quite easy.

Getting started

For this project, I'll be creating a RESTful API using the rocket crate.

Initializing the project

To initialize a new Cargo project, run the following command:

cargo init <YOUR_PROJECT_NAME>

Adding dependencies

Add rocket as a dependency in your Cargo.toml:

[dependencies]

# NOTE: This is a pre-release version.
# Thus, It is suggested NOT to use this in production.
rocket = "0.5.0-rc.2"

Main function

With our Cargo project ready, we can remove the default main function entirely. This will make room for our new rocket method, which is attributed with Rocket's launch procedural macro.

This function will essentially replace our main function, and will be called on startup.

//main.rs

#[macro_use]
extern crate rocket;

use rocket::{Build, Rocket};

#[launch]
fn rocket() -> Rocket<Build> {
    Rocket::build()
        // Set the `/` route path as the base for our routes.
        // When we create our routes, we'll include them in the arguments for the `routes!` macro.
        .mount("/", routes![])
}

If we were to run this, we would see the following:

Configured for debug.
   >> address: 127.0.0.1
   >> port: 8000
   >> workers: 6
   >> ident: Rocket
   >> limits: bytes = 8KiB, data-form = 2MiB, file = 1MiB, form = 32KiB, json = 1MiB, msgpack = 1MiB, string = 8KiB
   >> temp dir: C:\Users\dev\AppData\Local\Temp\
   >> http/2: true
   >> keep-alive: 5s
   >> tls: disabled
   >> shutdown: ctrlc = true, force = true, grace = 2s, mercy = 3s
   >> log level: normal
   >> cli colors: true
Fairings:
   >> Shield (liftoff, response, singleton)
Shield:
   >> X-Content-Type-Options: nosniff
   >> Permissions-Policy: interest-cohort=()
   >> X-Frame-Options: SAMEORIGIN
Rocket has launched from http://127.0.0.1:8000

Now that we have our rocket function, we can start developing the functionality for our API.

Storing the song queue

For storing the song queue, we will use a static LinkedList.

We use a LinkedList because it's included in the standard library, and basically acts as a queue with extra features.

Though, to allow the list to be modified statically, we must wrap the list in a Mutex.

use std::collections::LinkedList;
use std::sync::Mutex;

static SONG_QUEUE: Mutex<LinkedList<String>> = Mutex::new(LinkedList::new());

To learn more about Mutex, click here.

Utility function

We will be repeating the following code a lot:

let lock = SONG_QUEUE
    .lock()
    .expect("Unable to acquire lock on song queue because the Mutex was poisoned");

It's better if we create a function that does this for us.

use std::sync::{Mutex, MutexGuard};

fn acquire_queue<'a>() -> MutexGuard<'a, LinkedList<String>> {
    SONG_QUEUE
        .lock()
        .expect("Unable to acquire lock on song queue because the Mutex was poisoned")
}

Creating the `add` route

With our SONG_QUEUE variable defined, we can start creating routes.

The add route will receive a POST request containing a song name, which will then be added to the song queue.

Optionally, we can return the position the song has been placed into.

#[post("/add/<song_name>")]
fn add_song(song_name: String) -> String {
    let mut lock = acquire_queue();

    lock.push_back(song_name);

    format!("Song added. This song is in position {}.", lock.len())
}

Don't forget to register this new route in the routes! macro.

- .mount("/", routes![])
+ .mount("/", routes![add_song])

To test this new route, run the program, then try curling our route with some parameters.

Result

C:\Users\dev>curl -X POST http://localhost:8000/add/Hello
Song added. This song is in position 1.

C:\Users\dev>curl -X POST http://localhost:8000/add/Hello%20number%202
Song added. This song is in position 2.

Creating the `view` route

Users can now add songs, but are unable to view which songs are currently in the queue.

Don't worry, we'll just create a new GET route.

Only one line of code!

#[get("/view")]
fn view() -> String {
    format!("{:?}", acquire_queue())
}

Don't forget to register this new route in the routes! macro.

- .mount("/", routes![add_song])
+ .mount("/", routes![add_song, view])

Result

C:\Users\dev>curl -X POST http://localhost:8000/add/Hello%20World
Song added. This song is in position 1.

C:\Users\dev>curl http://localhost:8000/view
["Hello World"]

Removing songs

For the sake of the simplicity of the article, we won't actually play songs once they reach the front of the queue. Instead, we'll just remove songs after a certain amount of time has passed.

In this case, we'll remove songs 60 seconds after they've reached the front of the queue.

use std::thread;
use std::time::Duration;

fn remove_song_timer() {
    while !acquire_queue().is_empty() {
        thread::sleep(Duration::from_secs(60));
        acquire_queue().pop_front();
    }
}

We need to modify our add_song route to make sure a remove_song_timer thread is spawned if a song is added to an empty queue.

#[post("/add/<song_name>")]
fn add_song(song_name: String) -> String {
    let mut lock = acquire_queue();

    if lock.is_empty() {
        thread::spawn(remove_song_timer);
    }
    lock.push_back(song_name);

    format!("Song added. This song is in position {}.", lock.len())
}

Result

C:\Users\dev>curl -X POST http://localhost:8000/add/Hello%20World
Song added. This song is in position 1.
C:\Users\dev>curl http://localhost:8000/view
["Hello World"]

60 seconds later...

C:\Users\dev>curl http://localhost:8000/view
[]

That's about it! Writing RESTful APIs in Rust are ridiculously easy with the rocket crate. Make sure to follow me on dev.to to be notified whenever I post a new article.

Thanks for reading!

DEV Community: Zofia

AssaultCube | Writing your first external cheat in RustLang

Writing a-salt-cube

Prerequisites

Outline

Writing cheat requirements

Coding

Finding our pointers

Creating our project

Writing the main function

Writing our tasks.rs module

Defining constants in the pointers.rs module

Finishing new_health_task

Finishing our main function

How to make your GitHub repository look and feel professional ✈🌍

🕺 What makes a professional repository?

⚡ Creating workflows

What is GitHub Actions?

📚 README.md, LICENSE, and SECURITY.md

README.md

LICENSE

SECURITY.md

📝 Open source community standards

🎇 About section

Topics

Description

⛔ Disabling unused features

👋 Conclusion

Why do we need configuration? Creating and handling configuration files in Rust 📝

NOTE

Getting started

Creating the Cargo project

Adding dependencies

Defining our config structure

What will our program do?

Definition

Loading and initializing the configuration file

Creating the ConfigError enum

Definition

Implementing the program functionality

Output

Config.toml

Conclusion

Creating a minimal RESTful song request API using Rocket 🚀

What is a song request system?

Getting started

Initializing the project

Adding dependencies

Main function

Storing the song queue

Utility function

Creating the add route

Result

Creating the view route

Result

Removing songs

Result

Writing our `tasks.rs` module

Defining constants in the `pointers.rs` module

Finishing `new_health_task`

📚 `README.md`, `LICENSE`, and `SECURITY.md`

`README.md`

`LICENSE`

`SECURITY.md`

Creating the `ConfigError` enum

`Config.toml`

Creating the `add` route

Creating the `view` route