ReverseEngineering

https://halove23.blogspot.com/2021/02/windows-installer-file-read-0day_12.html?m=1 @reverseengine

https://streypaws.github.io/posts/Race-Against-Time-in-the-Kernel-Clockwork/ @reverseengine

This is a Project Working on Reverse Engineering the Apple G13 GPU Architecture https://github.com/dougallj/applegpu @reverseengine

CVE-2025-50168-pwm2owm-berlin-2025 https://github.com/D4m0n/CVE-2025-50168-pwn2own-berlin-2025/tree/main/P2O @reverseengine

OpenSourceMalware https://opensourcemalware.com @reverseengine

First known AI-powered Ransomware https://x.com/ESETresearch/status/1960365364300087724 @reverseengine

What I Learned from Reverse Engineering Windows Containers https://unit42.paloaltonetworks.com/what-i-learned-from-reverse-engineering-windows-containers @reverseengine

Automation in Reverse Engineering: String Decryption https://synthesis.to/2021/06/30/automating_string_decryption.html @reverseengine

Reverse Engineering Go Binaries with Ghidra https://cujo.com/reverse-engineering-go-binaries-with-ghidra @reverseengine

https://youtu.be/bEsQ8UYioU4 @reverseengine

Analysing a 1-day Vulnerability in the Linux Kernel's TLS Subsyste https://faith2dxy.xyz/2025-10-02/kCTF-TLS-nday-analysis/ @reverseengine

Acunetix Premium Plus OnPremise with API Discovery v 25.8.250820089 https://cloud.proxy-bar.org/s/5KhtUcpx3Cxln0Y

https://youtu.be/I37--xkTsiQ?si=oQ8cuCp3v34zh_T9 @reverseengine

Theldus Bread https://github.com/Theldus/bread @reverseengine

Dissecting GobRAT https://jstnk9.github.io/jstnk9/research/GobRAT-Malware/ @reverseengine

DWARF as a Shared Reverse Engineering Format https://lief.re/blog/2025-05-27-dwarf-editor/ @reverseengine

Reverse engineering the Obfuscated TikTok VM https://github.com/LukasOgunfeitimi/TikTok-ReverseEngineering @reverseengine

Pwn20wn Ireland 2025 https://marcbarbezat.medium.com/pwn2own-ireland-2025-73-failles-zero-day-r%C3%A9v%C3%A9l%C3%A9es-pour-1-million-de-primes-25a2592dde57?source=rss------bug_bounty-5 @reverseengine

اگه مطالب رو دوست داشتید استار هم بزنید لطفا (: If you liked the content, please star it (:

Part 6 Buffer Overflow

Understanding the Crash and the Structure of the Function Frame on the Stack In this part, we are going to see what exactly happens behind the scenes when a buffer overflow causes a crash. After this part, we should understand why overwriting data on the stack changes the return address. What are the components of a function frame? And how can these components be viewed and analyzed with gdb. When a function is called in C, the system creates a space on the stack for that function. We call this space the function frame. Each frame contains these parts. Local variables of the function Parameter values Saved RBP or base pointer for return Saved return address which the function returns to after the function completes If more data is written to the local buffer than the limit, these important values ​​are overwritten in the frame And as a result, the program crashes on return or jumps to the wrong address This code helps us see the function frame and crash and analyze it in gdb

#include <stdio.h> #include <string.h> void crash(char *input) { char buffer[16]; printf("address of buffer: %p\n", buffer); strcpy(buffer, input); printf("done copying\n"); } int main(int argc, char **argv) { if (argc < 2) { printf("usage: %s input\n", argv[0]); return 1; } crash(argv[1]); printf("returned safely\n"); return 0; }

Execution and analysis commands

gcc -g file4.c -o file4

gdb --args ./file4 $(python3 -c "print('A'*40)")

After running the program in gdb, perform these steps

break crash run info frame x/32x $rbp x/32x $rsp

Here you can see that the buffer is below the saved RBP Every byte you write out of the buffer will eventually reach the saved RBP and then the return address To view the crash

continue

The program crashes with a segmentation fault error See the return path with the following command

backtrace

And check the last return address with this command

info registers rip

Full explanation When executing the crash function, the system first saves the current RBP Then it moves the RSP down to provide the necessary space for local variables In this new buffer space, Yes When we write data larger than the buffer size, first the data is written to local variables, then to RBP, and then to the return address At the moment the function wants to return, the wrong value is read from the stack and RIP jumps to the wrong address, which causes a segmentation fault Interesting part You can see the difference before and after the overflow in gdb with this command

Before strcpy x/32x $rbp-32

After strcpy x/32x $rbp-32

You can see that the A bytes have filled all the space between the buffer and the return address This is the reason for the program crash