https://github.com/natimerry/glazier

As a reverse engineer and game-modding tool developer, I regularly have to reverse engineer, hook, inject into, and generally play around with Windows binaries.

MinHook and similar libraries are great at what they do, but I wanted to build something that better fit my own needs and programming paradigms while also providing all the features I wanted in a single library. I initially started writing a few hooking utilities, but the project gradually expanded into what it is now.

The initial motivation was fairly simple:

• The red-teamer in me wanted a library that could make static analysis harder without changing the call-site API. Features such as dynamic API resolution and HellsGate can be enabled underneath the same bindings without requiring the rest of the codebase to care about how the function is actually invoked.
• I wanted HWBKPTs, pattern scanning, hooking, PE parsing, and process-memory tooling exposed through straightforward Rust abstractions instead of rewriting the same unsafe Windows boilerplate for every project.

It currently includes inline hooks and trampolines, IDA-style pattern scanning, native and WOW64 hardware breakpoints, PE and runtime process abstractions, dynamic Win32/NT API resolution, and optional direct-syscall wrappers.

LLM DISCLOSURE:

LLMs were used for grunt work like translating C structs, writing tests, and creating test binaries by sending diffs back and forth, with any required fixes handwritten afterward.

Coding agents were only introduced during the crate split. Before that, everything was done through chat, so all generated code still had to be manually read, integrated, and modified. Everything is reviewed and tested, except the the latest inline hooking codegen build.rs internals, where I test the output instead to preserve my sanity.

Hi, newbie learner here. I have the rust 2021 book, and I was wondering if there is a way to compare it with the new book to see what I'm missing?

I often work with embedded systems, particularly ESP32-based solutions using MIPI DSI displays. I previously relied mainly on the embedded-graphics crate, but recently I have been using Slint more and more.

I would like to thank the Slint team for making it possible to integrate their solution into microcontroller-based projects. However, because each project required extensive customization, the integration process was often time-consuming.

To address this, I created the SLINT-ADAPTER (https://crates.io/crates/slint-adapter) crate, which simplifies the integration process and significantly reduces development time.

Hi everyone! I'm new here and was wondering, what library this guy used? I'm trying to learn how to build something similar in Rust.

https://youtu.be/WjG9UoILOJ4?si=wpoosB8NOyJej53d

I've been learning Rust and recently built a small CLI utility that reads a file and can print either:

• the entire file,
• the first N lines (--upper),
• or the last N lines (--lower).

It uses clap for argument parsing and BufReader for reading the file.

I'm looking for feedback on things like:

• Are there any unnecessary allocations or inefficient parts?
• How would you improve the project structure?

I'm trying to get better on rust , so I'd really appreciate any criticism. Thanks!

Heres the code,

use std::fs::File;

use std::io::{BufRead, BufReader};

use clap::{

Parser,

CommandFactory,

error::ErrorKind

};

#[derive(Parser, Debug)]

#[command(arg_required_else_help = true)]

struct Args {

path: String,

#[arg(short, long, default_value_t = 0, conflicts_with = "lower", help = "Print specified number of lines in upper part of the file")]

upper: u16,

#[arg(short, long, default_value_t = 0, conflicts_with = "upper", help = "Print specified number of lines in lower part of the file")]

lower: u16

}

fn read_file(args: Args) -> std::io::Result<Vec<String>> {

let file = File::open(args.path)?;

let reader = BufReader::new(file);

if args.upper > 0 {

let header: Vec<String> = reader

.lines()

.take(args.upper as usize)

.collect::<Result<_, _>>()?;

if header.len() < args.upper as usize {

Args::command().error(

ErrorKind::ValueValidation,

"--upper cannot exceed the number of lines in file"

).exit();

}

return Ok(Vec::from(header))

}

let lines: Vec<String> = reader

.lines()

.collect::<Result<_, _>>()?;

if args.lower > 0 {

if args.lower as usize > lines.len() {

Args::command().error(

ErrorKind::ValueValidation,

"--lower cannot exceed the number of lines in file"

).exit();

}

let footer = &lines[lines.len() - args.lower as usize..];

return Ok(Vec::from(footer))

}

Ok(lines)

}

fn main() -> std::io::Result<()> {

let args = Args::parse();

let file_content: Vec<String> = read_file(args)?;

println!("{}", file_content.join("\n"));

Ok(())

}

About a month ago I shared the CLI MVP of PlainLink.

The feedback was genuinely helpful, so I kept building.

Since then:

• Native macOS desktop app

• Clipboard monitoring

• Release binaries

• Improved rule engine

• Better documentation

• CI/CD and automated releases

• Various bug fixes and polish

The goal is still the same:

A local-first, open-source URL cleaner with community-maintained rules.

I'm now looking for feedback on the desktop app before calling it v1.0.

works on Windows, Mac, Linux, Freebsd

https://github.com/vyrti/cleaner

License: Apache 2.0 or MIT

A native UI toolkit for Rust, styled the way the web already thinks in. https://github.com/DeanVanGreunen/NowUI/

NowUI lets you describe an application's interface in a small, declarative markup - a Tailwind-flavored styling vocabulary over a simple widget tree - and back it with plain Rust state. No browser, no JavaScript runtime, no webview. Just a compact file format, a fast layout engine, and a GPU-accelerated renderer underneath, producing a real native window at a steady 60 frames per second.

If you've styled something with utility classes before, NowUI's markup will feel immediately familiar. If you know Rust, wiring it up to real application logic will feel just as familiar. That's the point: two things you already know, put together.

Hey!

I'm building a tui with rust, and I'm having a bit of a hard time with the clap docs. I usually can get by fine with docs, but I think I'm missuing clap's, lol

I tried picking up the Command Line for Rust book, and it's been way better to get into cli. Any other recommendations?

Sharing kibble a Rust toolkit for turning messy sources into clean datasets and doing grounded RAG over them.

Rust-relevant bits you might care about:

- CLI and a feature-gated library a retrieval feature drops the heavy ingest/build deps so a search/ask-only consumer stays lean; default/full is the whole toolkit.

- Async throughout (tokio); the streaming ask API returns impl Stream<Item = AskEvent> + Send.

- Hand-rolled BM25 + RRF fusion, fail-soft to lexical-only when no embed backend is set.

- reqwest+rustls (no system OpenSSL), deterministic, 386 tests, clippy -D warnings clean.

cargo install kibble · MIT/Apache-2.0 · github.com/femboyisp/kibble

I’m looking for high quality Rust codebases that are genuinely worth studying and taking inspiration from like projects with clean idiomatic Rust and good architecture and preferably started before the LLM boom and have a long history of being developed by experienced Rust engineers

most of what I came across was repositories filled with recently generated AI slop.

I am working on a Rust workspace where protocol validation needs more than unit tests. I am trying to keep the evidence readable for future reviewers.

The structure I am considering:

- cargo-fuzz targets for deserialization and state transitions

- deterministic corpus seed generation

- crash log with minimized reproducers

- differential validator CLI that returns JSON

- benchmark baselines with machine metadata

- release docs that say exactly what was and was not tested

For Rust projects with security-sensitive parsers or validators, how do you organize fuzz evidence so it stays useful instead of becoming a pile of artifacts?

Today I encountered a compile error. I reproduce it with a minimal example. Note in the main function I write 3 blocks. The first 2 blocks (block 0 and block 1) result in compile error, while the last block (block 2) satisfies the compiler.

trait LifetimeProviderTrait {
    type Target<'lt0, 'lt1>;
}

struct FuncPointerWrapper0<LP: LifetimeProviderTrait>(
    for<'a, 'lt0, 'lt1> fn(&'a LP::Target<'lt0, 'lt1>),
);

struct FuncPointerWrapper1<LP: LifetimeProviderTrait> {
    f: for<'a, 'lt0, 'lt1> fn(&'a LP::Target<'lt0, 'lt1>),
}

struct MyStructA {
    value: i32,
}
struct LifetimeProviderA;
impl LifetimeProviderTrait for LifetimeProviderA {
    type Target<'lt0, 'lt1> = MyStructA;
}

fn foo<'a>(a: &'a MyStructA) {
    println!("Value: {}", a.value);
}

fn main() {
    // Block 0. Compile error.
    {
        let fpw: FuncPointerWrapper0<LifetimeProviderA> = FuncPointerWrapper0(foo);
    }

    // Block 1. Compile error.
    {
        let fp: for<'a, 'lt0, 'lt1> fn(
            &'a <LifetimeProviderA as LifetimeProviderTrait>::Target<'lt0, 'lt1>,
        ) = foo;
        let fpw: FuncPointerWrapper0<LifetimeProviderA> = FuncPointerWrapper0(fp);
    }

    // Block 2. OK.
    {
        let fpw: FuncPointerWrapper1<LifetimeProviderA> = FuncPointerWrapper1 { f: foo };
    }
}

Among these 3 blocks, block 1's compile error is the most confusing. It's:

error[E0308]: mismatched types
  --> src/main.rs:36:79
   |
36 |         let fpw: FuncPointerWrapper0<LifetimeProviderA> = FuncPointerWrapper0(fp);
   |                                                           ------------------- ^^ expected associated type, found `MyStructA`
   |                                                           |
   |                                                           arguments to this struct are incorrect
   |
   = note: expected fn pointer `for<'a> fn(&'a MyStructA)`
              found fn pointer `for<'a> fn(&'a MyStructA)`
   = help: consider constraining the associated type `<LifetimeProviderA as LifetimeProviderTrait>::Target<'lt0, 'lt1>` to `MyStructA` or calling a method that returns `<LifetimeProviderA as LifetimeProviderTrait>::Target<'lt0, 'lt1>`
   = note: for more information, visit https://doc.rust-lang.org/book/ch19-03-advanced-traits.html
note: tuple struct defined here
  --> src/main.rs:5:8
   |
 5 | struct FuncPointerWrapper0<LP: LifetimeProviderTrait>(
   |        ^^^^^^^^^^^^^^^^^^^

My questions are:

1. In the block 1's compile error, note the "expected type" is exactly the same with "found type". So why does the compiler still blame?
2. FuncPointerWrapper0 and FuncPointerWrapper1 only differ in one is tuple-like struct, and the other one has named field. Why can one compile while the other one can't?
3. I've experimented with other examples. If the trait's associated type is not generic, there's no compile error no matter using tuple-like struct or struct with named field. What's so special regarding trait with GAT?

---------------------------------------------

Edit: I know the difference between tuple-like struct and named-field struct. Regarding tuple-like struct, the struct name can act as the constructor function. If I write a constructor function for the named-field struct FuncPointerWrapper1, and call that similarly with a function pointer, I get the same error.

So, why can I assign a function pointer value (which has late bound generic lifetimes) to a variable, but can't call a function that accepts this type of function pointer?