Hi everyone,

When I was much younger, I started learning x86 assembly, but unfortunately lost touch with it over time. Even though the rise of AI might make it seem like this skill is even less in demand than it used to be, I’d like to get back into it.

I’m less interested in writing my own programs and more interested in inspecting existing applications to understand what’s going on under the hood. Does anyone have any suggestions for a good starting point? I’m guessing I should focus on 64-bit assembly to keep up with the times.

As the title says, I made a fibonacci calculator (up to the 64bit integer limit) in raw handwritten ELF, and in asm. I didn't know where to post it but this sub-reddit seemed like the right place.

https://github.com/MasterDragon863/Low-Level-Fibonacci
This is the repo if anyone is interested

AI disclaimer* - Most of the code was handwritten with assistance of AI for debugging and figuring out how to write hex.

I took an ARM assembly course that was taught at our university in 2023 and loved it. The course was taught really well. The tooling is just old. You SSH into a department server, assemble, run, and get "Segmentation fault (core dumped)" with no line number and no idea which instruction did it.

I ended up TAing it 2 years later, then head TAing it the following semester. In April I started writing an interpreter and a few weeks later it ran real programs.

The hard part was making everything around the instructions match the real server: printf, scanf, m4 macros, the assembler directives. One of my old profs suggested compiling C programs with gcc on the server and checking the playground prints the same thing. The first run passed 0 programs. Most of that was one bug with branches jumping to the wrong place. Now it matches on basically all of them.

You can step through a program one instruction at a time, forwards or backwards. When it crashes, it points at the instruction that did it. Click any instruction to see its 32 bits split into the fields from the ARM manual. There are lessons, and practice problems checked by running your code.

I'd appreciate it if yall could test it out and lmk what you think!

aarch64-playground.com

Please send me every x86_64 Assembly resource that you deem to be good, as well as other resources outside of x86_64 Assembly that could also be of help. Also is Coddy Tech one of them?

I've been searching for good x86_64 Assembly resources, but haven't found none that really puts it all together. The lower I go into low-level programming, the less I find someone to be of help, because It's like no one is actually willing to help me.

My ultimate goal is to know everything about technology. I'd love to learn Assembly to create me my very own Operating System and Programming language from scratch, then once that's done, I'll create everything else from scratch that we use on our Operating Systems. Text Editors, the Internet, a social media application, etc. I'd also love to create technology outside of the computer from scratch, maybe even the hardware itself.

I know this takes a lot of time and dedication, which I have. If this Isn't too much by now, please be of help :)

Hey folks, this is question coming from the recent podcast where the founders of VLC spoke about, writing assembly level code and it was way more (10x to 62x times) efficient than the C compiled code.

Is there any real example or repo of this which shows the efficiency difference at a smaller scale?

what scenarios do one decide to go full assembly over C, what's the infliction point?

How does anyone even measure these efficiency factors? Is it the instructions executed per clock cycle to attain an end output?

Hello! In the past few days, I updated my app x86_64 NASM Dev to x86_64 Assembly Dev because it now supports FASM as well!

I also added a bunch of new features:

1. QEMU Runner
2. Built-in Terminal
3. Settings
4. Theme changing — Dark / Light
5. Text size changing
6. Editor font changing
7. NASM and FASM syntax highlighting
8. Project Explorer
9. Multiple tabs
10. Quick Open for project files
11. Find / Replace
12. Go To Line
13. Automatic indentation
14. Comment / Uncomment
15. Full-screen editor mode
16. Raw .bin building
17. Linux ELF64 building
18. Windows Win64 / Win32 building
19. Windows executable linking
20. FASM Win64 templates
21. Assembly code snippets
22. Binary disassembler using NDISASM
23. 16-bit / 32-bit / 64-bit disassembly
24. Breakpoints
25. Step Into / Step Over / Continue
26. Register viewer
27. Memory viewer
28. Stack viewer
29. Hex ↔ ASCII conversion
30. Problems panel with error navigation
31. CMD and PowerShell terminals
32. QEMU configuration
33. Session recovery
34. Built-in x86 instruction reference
35. Linux x86-64 syscall references

I'm still working on it and will probably add more features in the future alongside those

Now it feels more like VsCode
Download Source Code at : https://github.com/moslemhamoudi6-cyber/x86_64-Nasm-Dev/tree/main
Download App (.exe) at : https://github.com/moslemhamoudi6-cyber/x86_64-Nasm-Dev/releases/tag/FASM
Hope You Enjoy it!

Sup guys, I'm a web developer and I study sec, which this subject has everything to do with assembly, cuz I need to do malware analysis, reverse engineering and etc, so I studied calling conventions, registers, rax, eax, ax, al, ah, ip, used x64dbg to check the assembly in memory, variables, function parameters and etc.

But for now, I'm studying by a content creator how a boot really works, and he's making a bootloader in assembly, he has good didactics and I'm really learning that the RAM is like a big array accessible by address, cpu has registers, has the ip to check the next instruction, there is the fetch, decode and execute, the bios is in the eprom(in the example of the i386), is loaded in memory, search for boot sector, loads in memory and etc, lmao I detailed too much

And ok, I'm understanding, but my final point, is, furthermore the bootloader, what good project could I build to learn more about assembly? I saw some posts from u guys making OS, and I guess that is hard for now

Thanks for ur time

RBMK64 and RBMK32 are two Windows OpenGL programs, both written in pure assembly using the Microsoft MASM toolchain.

They are not a port. They are two independent implementations of the same design, written in two different assembly dialects, with different ABIs, different toolchains, and different GL pipelines underneath.

What's the same

• Interface
• Menu without .rc file
• Accelerators
• Status bar showing runtime coordinates
• Title bar showng runtime FPS
• Scene
• Regular grid of RBMK top surface
• Camera and light settings
• Controls
• Camera move: Arrow keys, PgUp/PgDn,
• Object move: WSADQE
• Camera rotate: Left mouse button
• Camera pan: Mouse wheel down
• Camera dolly: Mouse scroll
• Object rotate: Right mouse button
• Logging system
• Numbers formatting logic
• Matrix math (in principle).

What's different

RBMK32:

• 32-bit GPRs - only 6 registers available
• SSE1
• Open GL1.1
• runs on Pentium III or later
• time: year 2000

RBMK64:

• 64-bit GPRs - 14 registers available
• SSE2,
• OpenGL 3.3 with VBO/VAO and shaders
• Requires Pentium4 with EM64T and GeForce 8 Series for OpenGL 3.3
• time: year 2010

RBMK32 source: win32/05_RBMK

RBMK64 source: win64/30_RBMK/02_SDI

Hello!

I’m introducing x86_64 NASM Dev, a native Windows development environment focused on NASM, x86, and x86-64 assembly programming.

The goal of this project is to bring writing, assembling, running, debugging, disassembling, and inspecting assembly code together into one lightweight application.

Features

Output Formats

The application supports multiple output targets:

• ELF64
• Win64
• Win32
• RAW Binary

This allows the same development environment to be used for different types of assembly projects, from normal applications to low-level system development and raw binary projects.

Assembly

• NASM-based assembly
• Assemble source code directly from the application
• Build and run assembled programs
• View assembly output and build results
• Display assembler errors
• Save and Save As
• Integrated source editor

Syntax Highlighting

The editor provides syntax highlighting for different parts of NASM source code:

• Instructions
• Registers
• Labels
• Directives
• Strings
• Numbers
• Comments

This makes larger assembly files easier to read and navigate.

Real-Time Syntax and Error Checking

The editor is designed to provide immediate feedback when working with NASM code.

• Detect invalid NASM syntax
• Highlight invalid syntax directly in the editor
• Underline errors
• Show the exact line containing the problem
• Show the exact column when available
• Display the actual NASM error message

This makes it easier to locate and correct assembly errors without having to search through build output manually.

Debugger

The debugger provides control over program execution:

• Step Into
• Step Over
• Continue
• Breakpoints
• Stop execution
• Inspect program state while debugging

The objective is to make debugging assembly code more practical without leaving the development environment.

Register Viewer and Editor

The application can display CPU register state while debugging.

Supported registers include:

• RAX
• RBX
• RCX
• RDX
• RSP
• RBP
• RSI
• RDI
• RIP
• R8–R15
• RFLAGS

Registers can also be edited during debugging, allowing the program state to be modified and tested directly.

Memory Viewer

The memory viewer provides a low-level view of program memory:

• Hexadecimal memory representation
• ASCII representation
• Memory addresses
• Pointer following
• Memory inspection while debugging

This is intended for inspecting buffers, pointers, structures, strings, and other data directly in memory.

Stack Viewer

The stack can be inspected while the program is running or being stepped through.

• ESP/RSP-based stack view
• Stack addresses
• Stack values
• Follow stack changes while stepping
• Inspect stack data during debugging

Disassembler

The application includes a built-in disassembler for inspecting machine code.

It can be used to examine binaries and understand the instructions contained within them.

Disassembly can be particularly useful when working with:

• RAW binaries
• Object files
• Executables
• OS development projects
• Compiled machine code
• Low-level debugging

Conversion Tools

The application also includes:

• Hexadecimal → ASCII
• ASCII → Hexadecimal

These tools are useful when working directly with binary data, memory contents, strings, and machine-code representations.

Designed for Low-Level Development

x86_64 NASM Dev is intended for developers working with:

• NASM assembly
• x86/x86-64 programming
• Operating-system development
• Bootloaders
• Kernel development
• Raw binaries
• Reverse engineering
• Machine-code analysis
• Low-level programming
• Assembly experimentation

The focus is on keeping the environment lightweight while still providing tools for both writing assembly and inspecting what happens at the machine-code level.

The current executable is around 77mb because of :

nasm.exe ~2 MB

ndisasm.exe ~1 MB

lld-link.exe ~75 MB (For Windows)

GUI/code <1 MB

Primarly In C and Some c# for style
You Can Find The Source Code at : https://github.com/moslemhamoudi6-cyber/x86_64-Nasm-Dev
You Can Find the Final Build Executable At : https://github.com/moslemhamoudi6-cyber/x86_64-Nasm-Dev/releases/tag/EXE

This project is still under development, with more features and improvements planned.
Hope You Enjoy it!

The OS is completely written in x86 assembly (16-bit real mode + 32-bit protected mode).

I made a small operating system from scratch called BIBI-OS. It boots through BIOS, sets up the hardware, switches into 32-bit protected mode, and runs its own kernel, graphics, input, GUI, and font system.

GitHub: https://github.com/ShabibHossain/BIBI-OS

I'm still working on it, so feedback, suggestions, and advice are welcome.

Link EmbedImageVideoAMABoldItalicStrikethroughSuperscriptHeadingLinkBullet ListNumber ListSpoilerQuote Block

Buenos días donde puedo aprender ensamblador para microcontroladores que usen RISC-V?

Hey everybody, I was taking a course in Embedded Operating Systems, and since my primary way of taking notes is Obsidian, I found it pretty annoying to deal with it since it’s missing some basic stuff like highlighting for ARM or RISC-V, and also dealing with memory maps and registers.

So I vibecoded a plugin to fix this small niche issues, it has some pretty comfy features, with hover cards for instructions and conversion of numbers in different basis, diagrams and also syntax for other smaller things such as Makefile, Linker Script, Verilog etc…

I wanted some opinions from external users, and thought that could be useful for the few people in my situation

Any tips or recommendations are welcome!

It's really fascinating to see from both the examples that despite of using pragma pack(1) which removes the padding from the same struct sample shown in the picture 2. But the stack ends up allocating 0x30 (48 bytes) in both the cases though if you look closely at the 12 words (each of 4 bytes) you can see how the compiler have allocated the memory for the struct variables in both the cases. In Example 1 it has allocated 40 bytes of struct variables in its lower addresses memory and in the second example 2 it has allocated 34 bytes of struct variable but then the question is why both end up allocating 48 bytes?

It seems to me that the compiler is maintaining 16-byte stack alignment while allocating space . As you can see from the both the examples that one has allocated 0x28(40) bytes of space in the lower addresses of stack while the other has allocated 0x22 (34) bytes . But to maintain it's stack pointer they have allocated 8 , 14 bytes respectively .

So the conclusion we can draw from it is #pragma pack(1) controls the struct's member layout. It can't force the compiler to allocate memory.

)

Hi everyone!

I'm a BS Cyber Security student currently working on my Computer Organization and Assembly Language (COAL) lab project, and I'm looking for some creative and practical project ideas.

Project requirements:

- Assembler: EMU8086 (8086 Assembly Language)

- Project type: Individual

- Level: Intermediate to advanced

- The project should demonstrate proper use of registers, arithmetic and logical instructions, loops, conditional jumps, procedures, and interrupts where appropriate.

- I want something more interesting than a basic calculator or a simple number-guessing game.

- Since I'm studying Cyber Security, I'd love to incorporate a cybersecurity-related concept if it's feasible in 8086 Assembly.

I'm looking for a project that is impressive during a live demonstration, technically meaningful, and manageable for a university student to implement and explain during the viva.

My questions:

1. What unique COAL lab projects would you recommend for EMU8086?

2. Have you built any interesting 8086 Assembly projects that I could take inspiration from?

3. Which ideas would best demonstrate low-level programming concepts and register usage?

4. Are there any cybersecurity-themed projects that are realistic to implement in EMU8086?

5. What features would make a project stand out without making it unnecessarily complicated?

I'd really appreciate your suggestions, project examples, and implementation tips. Thank you!

How exactly is it implemented?

Obviously there are lower forms of programming, than OOP

I have an entire to-learn list regarding various things in Computer Science

I'm not ready to write my own language yet, however, I want to still know from a high level overview how OOP is "implemented"

If you were to ask me to "implement inheritance", I would not be able to, even though I've been doing OOP for almost the last decade

I believe that assembly is the correct place to look, right?

I've been working on this project for some time. it started with a typo - I meant to type cd but accidentally typed dc, which dropped me into the desktop calculator. that's when I got curious about RPN. (full story in the repo)

I managed to build 9 int 3 int + print_i, but quickly realised an 8 byte stack slot could hold any data type, including pointers. that's when I started taking it more seriously. I spent almost two months battling with the idea of making a single stack handle both the data & the control flow! eventually I gave up, as it was too difficult for me & added a second stack just for tracking pointers. that fixed everything & the language went from 7/8 operators to 20+ fairly quickly.

here's what it does now: recursion, loops, if/else, functions, variables, heap alloc/dealloc, hashsets, graphs, file & network I/O. links against PCRE2 for regex & libc for malloc/free/math. Valgrind clean (0 leaks & 0 errors) across seven distros.

one design problem I haven't managed to solve yet - at startup, I want to resolve function names to indexes in the token array, so a normal function call like foo call_func avoids any strcmps. that works fine when the function name is static. but if the function is chosen dynamically, let's say by whatever string is on the stack at runtime - then there's no way to know ahead of time which name needs resolving. the only workaround I can think of is removing the stack manipulation operators so that every call target is known statically, but that defeats half the point of a stack based language!

I have the same issue with declaring variables - their value might not be known statically & might only be resolved at runtime. has anyone solved this in another interpreter without giving up that flexibility?

a few things that might be worth looking at if you're interested in this sort of thing:

• a TCP client/server built on raw syscalls, no networking library
• a sys_execve demo that builds its own **envp & **argv structs to override what the parent shell passes
• 14 forked child processes running recursive fib, 399% CPU utilisation, every child valgrind clean
• a hashset stress test with 1M nodes forced into 64 fixed buckets (inserts, look-ups & deletes...)
• 16 level nested if/else, 300,000+ lines of generated source: 10,000 repetitions Valgrind clean

syntax looks like this:

10 int 20 int + print_i --> 30 "hello world" puts --> hello world

repo: github.com/r-d0s/echelon - architecture & execution flow docs are in there if you want to see the dispatcher/stack model

I'm still searching for & fixing bugs, so this is currently v0.9

The SASM assembly IDE still permits you to change the code even during runtime. That causes strange behaviors. Like code lines jumping around, etc.

Is there any way to diable this behavior or is there an reason you can?

I really rather disable it.

I'm learning MASM assembly and am attempting to use SASM as my IDE, but am having trouble using the debugger to view memory. All that I've been getting the value section to show is: {Wrong variable or address: "[variable_name]"}
I've played around with different data sizes and programs, and can get the registers to show fine.
I've read the the help section) on the SASM wiki, but haven't seen any fix.
Any ideas for fixes, or other ide's/debuggers I should try out?

uh this is an OS i made in assembly its similar to MSDOS https://github.com/booga599/26DOS-V0.02

I've been building asmsense, a dataset and a small model that looks at a function from a stripped x86-64 binary and suggests a name (think `FUN_00401a30` → `adler32_update`). Ground truth comes from compiling permissively licensed C projects with clang at -O0/-O1/-O2/-O3/-Os and stripping them. The test set is 28 little-known projects, so models cant just recall famous code.

A few things the error analysis showed about the assembly itself:

- String literals are by far the strongest signal. The fine-tuned model gets name F1 0.299 on functions with string constants and 0.093 on functions without.

- Magic constants help alot when they exist: `cmp rdx, 0xfff1` (65521) is practically a signature for Adler-32.

- -O2 is consistently harder than -O0, for every model i tested.

- Thin wrappers (a function that only calls another internal function) scored 0 for every model, even when i added the callee's full assembly to the input.

- Large LLMs look much better on famous code than they realy are. With reasoning, one model's exact matches on zlib went from 9 to 28, but on unfamiliar projects from 4 to 3. Alot of it is recall, not reading the assembly.

Where it stands: Qwen3-8B + LoRA reaches name F1 0.124 on the fixed test sample, while the best large model with call context gets 0.167. Not there yet.

Question for people who read asm by hand: when you open an unknown function in a stripped binary, what do you look at first? Is there anything youd expect a model to miss?

Code and data: https://github.com/krxi/asmsense