ProcInSh is a web-based process inspector for Linux.

Inspired by Ghost in the Shell, it lets you wander through process space with your ghost.

ProcInSh lets you explore what's happening inside your Linux system through interactive 3D graphics.

It visualizes running processes, inter-process communication, file I/O, external network connections, and process tree structures. Processes glow when they run on a CPU.

The backend is written in Rust and collects information from several Linux interfaces:

• procfs
• eBPF
• ptrace
• perf_event_open

The frontend is written in TypeScript and Three.js.

• GitHub: https://github.com/akawashiro/procinsh
• Blog: https://akawashiro.com/articles/procinsh-en

I have currently reached the stage where this can be considered to be near to finish. And I want help around now for how I can improve and use in real applications

https://github.com/crydafan/AndroidLibraryInjector

I decided to make this because I'm reverse engineering a banking application in order to audit their API and make an MCP out of it.

The application itself can detect when the Frida server is running and when the application was modified with Apktool (even the code is obfuscated) and nothing worked so this is my attempt at trying to hack it: inject a shared library into the application process to hook SSL libraries functions and inspect the HTTP requests in plain text before they are encrypted.

For this, the first moving part is the library injector. I was thinking of using Dobby to hook the functions. Anyways, I'm open for any feedback.

Thank you!

Hi r/embedded,

xuan (玄) is a lightweight JavaScript runtime for IoT and embedded devices, built on QuickJS and forked from tjs/txiki.js (MIT).

It targets the place where Node.js is too heavy: ~6–7 MB binary, low memory, ~5 ms cold start, and it cross-compiles to x86/ARM/MIPS/RISC-V. Built-in MQTT, serial port and FFI (call C libs directly); GPIO/I2C/SPI are in progress. You can also compile a script into a single self-contained binary with xuan compile.

Repo: https://github.com/topelinux/xuan

It's early but usable — feedback welcome. I'm the maintainer.

Hi everyone,

When debugging processes and inspecting system behavior on Windows, tools like Process Monitor (Procmon) are great, but they are heavy graphical utilities that rely on kernel-mode drivers. On the other hand, having a lightweight, terminal-native way to inspect system calls and Win32 APIs in real time was something I felt was missing for daily workflow.

I wanted to build an independent, lightweight alternative designed from scratch for the Windows console, with two strict requirements:

1. Pure terminal workflow (interactive TUI and scriptable stream).
2. Zero kernel drivers (pure userland Win32 and native OS ETW) to ensure safety and stability.

This is why I created wstrace, written entirely from scratch in Rust.

Core Features:

* Zero Kernel Drivers: Runs strictly in userland without third-party .sys drivers or ring-0 dependencies.

* Interactive TUI: Built with Ratatui, offering real-time process monitoring, event filtering, search, and activity timelines.

* Headless Stream Mode: Direct output to stdout (formatted text or JSON) for scripting, log analysis, and automation.

* Single Lightweight Binary: Fast startup, zero runtime dependencies, and minimal memory usage.

* 100% Local and Air-Gapped: Zero telemetry, zero analytics, and zero network calls.

Installation:

Prebuilt standalone binaries are available on GitHub Releases, and it can also be installed using Scoop, Winget, PowerShell, or Cargo:

cargo install --git https://github.com/gilnett/wstrace

Or via Scoop:

scoop install https://raw.githubusercontent.com/gilnett/wstrace/main/packaging/scoop/wstrace.json

Feedback & Feature Requests Welcome:

This is the initial v0.1.0 release. I would really appreciate any feedback, suggestions, or edge cases you encounter while testing it.

If there are specific Win32 APIs, events, or CLI flags you would like to see added, please let me know. I am actively maintaining the project and very open to community requests and contributions.

GitHub Repository: https://github.com/gilnett/wstrace

Thanks for checking it out!

Hey guys,

Wanted to share a tool I've been using in my own reversing workflow:

GitHub: https://github.com/oscarsantanaarias/IDA-Ghidra-bridge

I needed a straightforward way to pull decompilation, cross-references, and struct layouts out of IDA Pro and Ghidra from external Python scripts and CLI utilities without setting up heavy web servers or dealing with bloated RPC frameworks.

It’s just two standalone scripts (`ID_Server.py` for IDAPython and `Ghidra_Server.py` for Ghidra). Once running, you send plain text commands over local TCP and get back JSON:

```python

import socket, json

s = socket.socket()

s.connect(("127.0.0.1", 5073))

s.sendall(b"FUNC 00401000\n")

data = json.loads(s.recv(65536))

print(data["code"])

MIT Lectures of 6.1903 Introduction to Low-level Programming in C and Assembly...

Side project I just wrapped up: an 8-bit CPU built entirely from NAND gates in Digital Logic Sim. 16-bit address space (64K of RAM), 800 kHz clock, and a small OS that runs Snake, Breakout, Flappy Bird and Tetris with live keyboard input.

The software side ended up being half the fun: instead of hand-assembling everything into binary, I wrote a small language and a compiler that generates the program memory contents directly.

Video (1:30): https://youtu.be/O8znJoZkAmw

Would anyone be interested in a step-by-step tutorial series on building your own CPU like this, starting from the NAND gate?

wrote a c99 tool (thornk) that turns kbuild into flat ninja files for samurai and it boots linux 6.12 x86_64 in qemu with zero gnu make

https://github.com/abit-foggy/thornk

(AI disclosure in README )

A while ago I shared my work on `rfs` (random-filesplitter), a tool designed to split files into N information-theoretic One-Time-Pad shares ($P = C_1 \oplus \dots \oplus C_N$) with plausible deniability.

I've just released v3.0.0—a ground-up architectural rewrite to eliminate memory-bus bottlenecks and harden the system against forensic extraction. Here are the low-level design decisions:

### 1. Memory Pinning (`--mlock`) for Swap Resilience

In anti-forensic workflows, writing plaintext or OTP keystreams into OS swap space or hibernation files invalidates volatile RAM zeroization.

- Implemented physical RAM locking via `libc::mlock` on the fixed buffer pools (`free_in_tx` and `free_out_tx`).

- Added graceful fallback: If `RLIMIT_MEMLOCK` (`ulimit -l`) restricts memory allocation, the system emits a warning and continues without crashing.

- RAM buffers are zeroized using `slice.zeroize()` immediately upon recycling.

### 2. Parallel Disk Fanout & Fanin (Multi-Mountpoint I/O)

Previously, the Stage-3 writer looped sequentially over all N shares. When writing shares across multiple physical USB flash drives or separate NVMe mount points, slow flash media created severe pipeline backpressure.

- Rewrote the I/O engine with decoupled worker thread pools for each share.

- Data chunks are fanned out concurrently over bounded crossbeam channels. Each thread writes independently at maximum bus speed, with pre-allocated pool buffers recycled back without a single heap allocation in the hot loop.

- Linux cache pressure is minimized using POSIX `fadvise` (`POSIX_FADV_SEQUENTIAL` and `POSIX_FADV_DONTNEED`) via `--direct`.

### 3. Hardware Jitter & Entropy Harvester

For seeding the CSPRNG alongside OS entropy (`getrandom`):

- Uses a 2 MB permutation pool (32,768 nodes × 64 bytes cache-line aligned) traversing a Sattolo cycle to bust L1/L2 caches and capture CPU memory latency and branch prediction jitter.

- Integrated NIST SP 800-22 diagnostics directly into the CLI (Runs tests, Block Frequency tests via Wilson-Hilferty Chi² approximation, and analytical `erfc`).

### 4. Throughput Benchmarks

Measured on a modern x86_64 CPU:

- **ChaCha20 Keystream:** ~1.85 GB/s

- **SIMD-XOR (RAM-to-RAM):** ~4.0 GB/s (64-byte unrolled vector loop)

- **BLKS-384 Hash:** ~1.2 GB/s (3.3x faster than SHA-256)

Code is open source (LGPL v3), 0 Clippy warnings, fully documented in English (with bilingual README), and verified across Linux/macOS/Windows CI:

https://github.com/Meik1982/random-filesplitter

Quick test:

```bash

cargo install --git https://github.com/Meik1982/random-filesplitter.git

rfs --benchmark

rfs --entropy-test

Five months ago, I announced Wolfram, a capability-based microkernel written in Rust. Then I stopped working on it.

Yesterday, I picked it back up. Roughly eight hours later, Phase 1 was complete.

Wolfram now has two architecture ports: RISC-V 64 and x86-64. Both have repeatable QEMU boot checks, and the x86-64 path has now booted from a USB stick on my actual desktop.

Here's what the sprint involved.

RISC-V 64

• OpenSBI handoff and early serial output.
• Device-tree parsing for RAM and reserved memory.
• A bitmap physical frame allocator.
• Trap handling and secondary-hart parking.
• Repeatable QEMU smoke tests with multiple harts.

x86-64

• A new UEFI bootloader written in Rust.
• ELF loading and page-table setup.
• Firmware memory-map handoff to the kernel.
• Framebuffer diagnostics and exception reporting.
• Debug and release boot checks under QEMU/OVMF.

Both ports share a boot-information contract and converge on the common kernel entry point, where they exercise the same core boot logic.

The final milestone was physical hardware. I put the UEFI boot files and kernel on a FAT32 USB stick, disabled Secure Boot, and booted it on an MSI B650M-A PRO WIFI.

The bootloader loaded the kernel. The kernel initialized its physical allocator, produced diagnostics, and reached the expected spawn init panic.

That panic is intentional. There is no init process yet.

A quick reality check: Wolfram is not a usable operating system at this point. The capability system, VMOs, process model, and IPC are still ahead of me. Phase 1 was about making the boot path reliable and observable before building the actual kernel facilities on top.

The project is built around a capability-based security model: programs should only be able to access resources explicitly granted to them. No ambient authority, no root, no sudo. That's the design goal; the mechanisms that enforce it are the focus of the next phase.

I'm sharing this here because I'd appreciate feedback from people familiar with UEFI, bare-metal Rust, memory management, or operating-system development.

In particular, I'd be interested in having someone experienced review the UEFI-to-kernel handoff and memory-map handling. Those are foundational interfaces, and I'd rather catch design mistakes early than build more code on top of them.

Repository: https://github.com/notvcto/wolfram-os

Release: Uranium-238-v0.1.0

I'd appreciate any feedback. Genuinely, need feedback. Please.

Hey every one this Kaif

I graduated this year and i am honestly bored using AI and developing. I want to try and check out kernel engineering, can any one mentor me .

Thank you for everyone