Forem: 0x57Origin

I Built NimPacket, a Raw Packet Crafting Library in Nim, and It Turned Into One of My Best Cyber Projects

0x57Origin — Thu, 04 Dec 2025 06:17:12 +0000

For my cybersecurity masters work, I wanted to go deeper than running tools and reading packet captures. I wanted to understand what was happening inside the packets themselves. Instead of calling Scapy or hiding behind Python abstractions, I decided to build my own packet manipulation library from scratch in Nim. That became NimPacket, and it turned out to be one of the most useful and eye opening projects I have done.

NimPacket gives full control of IPv4, TCP, UDP, and ICMP headers. Everything is exposed at the byte level. You can set fields, flip flags, stack layers, serialize to raw bytes, and then parse real traffic back into readable structures. Working at this depth made me understand not just how protocols work but how they fail and how attackers take advantage of them.

I included real examples so the library is not just a research exercise. There is a working SYN port scanner, a raw packet sniffer, and an ICMP echo builder. These examples helped validate the code and also give anyone reading the repository a clear idea of how to apply the library in actual security work. It runs smoothly on Kali and makes it easy to build custom packet tools without relying on heavy frameworks.

The project taught me a lot about checksum algorithms, endian handling, field packing, and protocol specifications. It also showed me why low level networking is still important for people in cybersecurity. You cannot fully understand network attacks unless you know what each byte represents and why it is there.

If you want to see the code or try it out, the repository is here:
https://github.com/0x57Origin/NimPacket

I am always open to feedback from people who have more experience in systems programming or raw socket work, so feel free to check it out and let me know what you think.

Enter RE_VAULT and Try Your Hand at Black Cipher

0x57Origin — Tue, 02 Dec 2025 19:44:54 +0000

RE_VAULT: My growing archive of reverse engineering challenges

When I first got into reverse engineering, I kept running into the same problem.

Either the binaries were so trivial that you could finish them in five minutes, or they were full blown malware samples that assumed you already knew what you were doing. There was not much in the middle that felt like a structured way to get better.

So I started building my own targets.

This repository is where I am collecting them.

GitHub: https://github.com/0x57Origin/RE_VAULT/tree/main

Contact for solutions: 0x57Origin@proton.me

What is RE_VAULT

RE_VAULT is my public archive of reverse engineering projects and challenge binaries.

Right now the main thing inside it is a project called:

Flag Hunt 2 - Black Cipher Edition

It is a C program that behaves like a hostile forensic artifact. It has menus, decoy output, fake analysis modules, and a lot of traps. Underneath that, it hides multiple independent challenges that all live inside the same binary.

There are:

10 primary flags
1 hidden bonus flag that is never printed
multiple layers of obfuscation and misdirection

The goal is simple. Give people something that feels closer to a weird piece of malware or an incident artifact, but still designed for learning.

Who this is for

If any of this sounds like you, then Black Cipher is probably useful:

You are learning Ghidra or another RE tool and want more than simple crackmes
You want to understand the tricks used in real malware, without touching actual live malware
You enjoy C, low level behavior, and weird control flow
You want to practice thinking like both the attacker and the analyst

You can treat this project in three ways:

As a pure puzzle. Run the binary, poke at it, and try to get all flags with Ghidra and a notebook.
As a learning lab. Focus on one module at a time, for example only the VM or only the heap artifact.
As reference material. Read the C source to understand how certain evasive patterns are implemented.

How Black Cipher behaves

When you run the binary, you do not get a clean CTF style interface. You get something that looks more like a small analysis console:

A banner that pretends to be a forensic tool
A list of "analysis modules"
Each menu option triggers a different challenge path

Some modules will print noise. Some will fail. Some will show partial information. Only a few of them will give you a clean flag without effort.

That is by design.

Part of the challenge is figuring out which output is real, which is a decoy, and which is an encoded form of something you can decode yourself.

Spoiler warning

The rest of this article talks about the internal structure of the binary.

I will not give any exact flag strings or full solutions here, but I will describe what each module is roughly doing. If you want to go in completely blind, stop reading now, clone the repo, build the program, and only come back later.

GitHub again:

https://github.com/0x57Origin/RE_VAULT/tree/main

High level structure of the challenges (light spoilers)

Each menu entry in Black Cipher maps to a different style of challenge. The idea was to compress a whole "mini curriculum" of RE techniques into one executable.

Here is what you are really dealing with.

1. String decryption module

This module is about encrypted strings and simple obfuscation.

The binary keeps an encoded string table in memory
A decoder routine performs a mix of XOR and rotation
If you find that routine in Ghidra and follow it, you can recover real text

The raw output when you run it looks wrong on purpose. The point is to make you pull the decoder out, not just rely on printing.

2. Control flow tracer

This is a function pointer maze.

There is a table of function pointers
Some point to dead ends, some to decoys, one path leads to the real flag
The correct sequence is not obvious from the strings

Reversing this is good practice for reconstructing strange control flow and focusing on what is actually executed rather than what looks interesting.

3. Hash verification system

This module is built around a custom hash.

Input is run through a polynomial style hashing function
The code never stores the answer string in plain form
You are expected to reimplement the hash and find the right input

This is a common pattern in license checks and challenges. It rewards careful reading of the decompiled logic and a bit of scripting on the side.

4. Binary data extractor

Here you deal with data hidden in the binary sections.

The program walks over what looks like random bytes in a data segment
A simple transform turns those bytes into something meaningful
Again, the program does not present the final result nicely on screen

You will probably end up using Ghidra to inspect the .rodata layout and then write a small script to decode what you find.

5. Anti tamper detector

This one focuses on anti debugging tricks.

Uses ptrace to detect basic debugging
Contains timing based checks that complain if something feels off
Only reveals the flag when the checks pass

This encourages you to understand what the anti debug logic is doing and either patch it out or simulate the expected behavior.

6. Virtual machine analyzer

This is a small custom VM.

There is a bytecode array in the binary
An interpreter loop implements a set of opcodes
Running the VM with the right state eventually triggers a flag print

You can either reverse the VM and emulate it in a script, or step through it and watch what it is computing.

7. Mathematical solver

This is a logic trap.

The program shows you equations that are not actually the ones that matter
The real constraints are hidden behind different branches
Only a very specific input satisfies the true condition path

If you try to solve the visible math directly, you will get nowhere. You need to trace which conditions are actually used in the path that prints the flag.

8. Memory forensics tool

This challenge lives on the heap.

A struct is allocated and partially filled with encoded data
The program prints noisy bytes related to that memory
The clean flag never appears directly

To win here, you should identify the struct layout in Ghidra, understand the encoding used inside it, and reconstruct the original content.

9. Network protocol decoder

This module pretends to be packet analysis.

A fake PCAP style blob is embedded in the binary
Simple protocol checks determine how it is parsed
A small decoder recovers a hidden message from it

The idea is to get used to the pattern "embedded binary blob plus decode routine" which you will see a lot in malware and droppers.

10. Multi stage hash validator

The last visible flag rides on a chain of hashes.

The input is run through several custom hash like functions
Each one feeds into the next
Only a very specific string survives all checks

To solve this, you basically have to replicate the full chain in a script and let it guide you.

The hidden bonus flag

There is an eleventh flag that is never printed and never referenced in an obvious way.

The only hints I will give here:

It lives in a custom section of the binary
The bytes are encrypted and reversed
The logic that explains how to decrypt it is split across several unrelated functions

If you are comfortable with ELF internals, custom sections, and Ghidra scripting, you will eventually find it. It is not meant to be fast. It is meant to reward full understanding of the binary.

How to get the solutions

By design, the repository does not include the full solutions.

There is a separate solutions document that walks through:

how to find each challenge in Ghidra
what to look for in the decompiled code
how the encoding and hashing actually work
concrete steps from first load to final flag

If you are:

an instructor who wants to use this in a class
a student who got stuck and needs to check their work
someone reviewing my code and wants to see my full reasoning

You can email me and I can share the solutions privately.

Contact: 0x57Origin@proton.me

Please mention "Black Cipher" or "Flag Hunt 2" in the subject so I know what you are asking about.

Final notes

RE_VAULT is not meant to be a one off project. It is where I plan to keep building and collecting more reverse engineering challenges over time.

Right now the main focus is Black Cipher. In the future I want to add:

smaller warmup binaries
more VM based puzzles
challenges that mix file formats, crypto, and protocol analysis

If you try the project and have feedback, ideas, or want to collaborate on future challenges, feel free to reach out.

GitHub repo again:

https://github.com/0x57Origin/RE_VAULT/tree/main

Email for solutions or questions:

0x57Origin@proton.me

I built a beginner-friendly reverse engineering challenge using Ghidra

0x57Origin — Sun, 30 Nov 2025 05:40:45 +0000

Spoiler Warning: The breakdown below explains how each challenge works. If you want to attempt it blind, stop reading after the GitHub link.

I spent the weekend putting together a small reverse engineering project, and honestly, it turned out way better than I expected. When I first got into reversing, I kept running into the same problem: everything online was either too advanced or too boring. So I decided to build something simple enough for beginners, but still fun to dig through with Ghidra.

The project is called Flag Hunt, and it is up on GitHub here:

https://github.com/0x57Origin/Flag_Hunt

The whole idea is to give people a small binary they can load into Ghidra and actually learn something in the first 10 minutes instead of feeling lost. It is a short C program with five tiny challenges, each one teaching a concept you will see over and over again in real reverse engineering work.

Challenge 1: The warmup

The first challenge is about as simple as it gets. The program asks for a 4 digit PIN, and the PIN is literally hardcoded in the binary. This teaches one of the first things every beginner learns: check the strings. Ghidra practically hands you the answer. It is silly and easy, but it warms you up for the next steps.

Challenge 2: Understanding XOR

After that, things get more interesting. The program checks a password, and if you get it right, it calls a decoding function. This is where beginners usually freeze up, but you do not need to be a genius. You just look at how the function works. It loops through each byte and XORs it with one key. Once you spot that pattern, you can write a five line Python script and decode the flag yourself. That feeling when the readable text appears is addictive.

Challenge 3: A tiny math puzzle

The third challenge checks three integers against a couple of equations. At first it looks confusing, but it is not a math test. It teaches you to slow down and read the conditions. You do not need calculus. You can brute force the values or solve them by hand. This builds confidence with condition logic, which is something you use constantly in reverse engineering.

Challenge 4: Custom hashing

Now it gets fun. Instead of comparing your input directly, the program hashes it with a custom function. When I first learned reversing, custom hash functions always scared me. But once you decompile it and see the logic, copying it into Python and brute forcing the right word is not as hard as it looks. This challenge teaches patience and pattern recognition.

Challenge 5: Final phrase

The last challenge is simple once you beat the others. It checks a final phrase, then decodes the last encoded flag. By now, you already know how to decode it because the earlier challenges prepared you for it.

I built this whole project to help people get comfortable with Ghidra without feeling overwhelmed. The decompiler does most of the heavy lifting. You just need curiosity and patience. If you want to try it, grab the project from GitHub, load the binary into Ghidra, and see how far you can get before peeking at the walkthrough.

It is honestly one of the best ways to learn reverse engineering from scratch.

Inside DBIR 2025: Why Vulnerability Exploits & Credential Abuse Are Dominating Breaches

0x57Origin — Fri, 28 Nov 2025 07:18:29 +0000

The 2025 Breach Landscape: Biggest Dataset in DBIR History

The 2025 Verizon Data Breach Investigations Report (DBIR) analyzed the largest volume of breach data ever recorded** in the history of the report. Verizon said:

22,000+ security incidents
12,195 confirmed data breaches
Victims spanning 139 countries
Data contributed by nearly 100 cybersecurity organizations

This year’s dataset is important because it reflects a major shift in attacker behavior.
Over the last 2–3 years, software vendors have unintentionally expanded the global attack surface through weak edge-device security, misconfigured cloud services, and delayed patching cycles.

What used to be occasional vendor mistakes has now transformed into what the report calls:

“a widespread and insidious problem that can have a devastating effect on enterprises.”

For defenders, that means breaches are no longer isolated events; they’re happening at a scale and speed that’s fundamentally different from previous years.

The Three Major Initial Access Vectors (Credentials, Exploitation, Phishing)

The DBIR 2025 data indicates that most breaches continue to originate from the same three entry points. The percentages shift slightly year to year, but the pattern stays consistent:

Stolen credentials -> 22%
Exploitation of vulnerabilities -> 20%
Phishing/social engineering -> 16%

These three techniques comprise a significant portion of initial access events across nearly every industry.

1. Credential Abuse (22%)

Credential-based attacks continue to be the single most common way intruders enter a system. Victims usually don’t notice anything unusual because the activity looks like a normal login.

A few points the report highlights:

Many stolen credentials come from older breaches.
Some are reused across multiple accounts.
Secrets leaked on GitHub or other repos take a median of 94 days to be remediated.

In many cases, the origin of the stolen credential is never discovered.

The main takeaway:
Attackers don’t need an exploit when they can simply log in.

2. Exploitation of Vulnerabilities (20%)

This is the category with the biggest jump compared to last year, up 34%.

The most notable change is where the exploitation is happening:

Edge devices
VPN appliances
Public-facing services

The DBIR notes that exploitation against edge devices and VPNs went from 3% last year to 22% this year. That’s nearly an eight-fold increase.

Patching is a clear issue:

Only 54% of edge vulnerabilities were fully remediated.
Median time to patch: 32 days.
That one-month gap is the opportunity window that attackers take advantage of.

3. Phishing & Pretexting (16%)

Phishing is still one of the most reliable ways attackers steal credentials or trick employees into granting access. It didn’t disappear; it simply settled into a stable percentage while other attack methods grew.

This year’s changes include:

More MFA prompt bombing
More Adversary-in-the-Middle (AiTM) login capture
More malicious software downloads through poisoned search results
Increased state-sponsored social engineering activity

Notably:

52% of social engineering breaches had an espionage motivation.
55% had a financial motivation.
Some nation-state groups were involved in both types of operations.

Overall, social engineering remains a dependable way for attackers to bypass defenses when technical controls fail.

Why These Three Methods Dominate

The DBIR doesn’t frame it dramatically. The explanation is straightforward:

Credentials are easy to steal or purchase.
Exploits scale well with automation.
Phishing works because humans make mistakes.

Together, these three methods explain most of the initial access cases seen in 2024–2025 data.

Ransomware Growth, Human Error, and the Shift Toward Third-Party Breaches

The DBIR 2025 numbers show three major trends that shaped most breaches this year:

Ransomware is increasing again, human involvement is staying high, and third-party breaches are doubling.

Each of these has different causes, but together they paint a clear picture of how attackers operate today.

1. Ransomware in 44% of Breaches (Up 37% From Last Year)

Ransomware continues to be one of the most common outcomes after attackers gain access. The report shows:

44% of all breaches involved ransomware (with or without encryption)
Up from 32% last year
A 37% increase

Even with the rise, ransom payments have started to drop:

Median payment: $115,000 (down from $150,000)
64% of organizations refused to pay -> (this was only 50% two years ago)

One interesting detail is the difference between large companies and small ones:

Large orgs: ransomware in 39% of breaches
Small orgs: ransomware in 88% of breaches

Small businesses continue to get hit hardest because they lack patching speed and detection.

2. Human Involvement in Breaches Remains High (60%)

Despite more MFA, more training, and better tools, the human element remains a major factor:

60% of breaches involved some type of human action
Last year: 61%
Essentially unchanged

The report breaks down human-driven errors into categories:

Phishing / Social engineering → stolen credentials
Misconfiguration or mistakes
Downloading or installing malware
Interacting with malicious MFA prompts

The overlap between social engineering and credential abuse is significant. A phishing email may steal the credentials, but the breach is then logged as credential misuse.

The DBIR emphasizes that many orgs now have two chances to stop the attacker:

During the social engineering attempt
During the credential misuse attempt

But most still miss both.

3. Third-Party Breaches Doubled (15% → 30%)

This is one of the more concerning shifts in the dataset.

DBIR reports that breaches involving third-party access or systems doubled in the last year:

15% last year
30% this year

Major reasons:

Credential reuse across environments
Contractors with overly broad access
Supply chain exposures
Secrets leaked in external repositories

A standout datapoint:

Median time for an organization to fix leaked secrets on GitHub: 94 days.

That’s nearly three months of exposure.

4. Espionage-Motivated Breaches Rising (17%)

Another shift this year is the increase in espionage-focused attacks:

17% of breaches now involve espionage
Many tied to state-sponsored actors
Heavy use of zero-days and edge-device vulnerabilities

The report mentions that around 28% of incidents involving state actors included a financial motive, meaning certain groups are now mixing intelligence gathering and revenue generation.

5. MFA Bypass Techniques: Prompt Bombing, Token Theft, AiTM

This year had enough data to analyze MFA bypass methods clearly:

Top techniques seen:

Prompt bombing (MFA fatigue)
Token theft
Adversary-in-the-Middle (AiTM)
SIM swapping and account hijacking

Microsoft 365 telemetry showed:

40% of attacks had suspicious logins
31% came from token theft
MFA interrupt (push fatigue) is also significant
AiTM present but less common

The point is: MFA helps, but attackers now adjust to whichever part of MFA is weakest.

Conclusion: What the 2025 DBIR Really Tells Us

The numbers in the 2025 DBIR point to something straightforward:
attackers aren’t getting “more creative,” they’re getting more efficient.

Stolen credentials are still an easy way in.
Unpatched edge devices are now one of the fastest-growing targets.
Phishing continues to work because human behavior doesn’t change as fast as technology.
Ransomware keeps showing up because it still makes attackers money.
Third-party weak spots are becoming the new normal.
State-sponsored groups are mixing intelligence work with financial crime.

Nothing in the report suggests attackers are slowing down.
What is changing is the speed of exploitation, the automation behind attacks, and the shrinking gap between vulnerability disclosure and real-world exploitation.

The takeaway is simple:

Organizations that don’t patch their edge devices, don’t rotate secrets, and don’t train employees will end up in next year’s statistics.
The attackers are adapting, so defenders have to move just as fast.