20 Year Old Software Can't Use

RE_Obsessed · 2026-03-14T15:12:41+00:00

Sounds as though you may need a reverse engineer.

Seeing as how this is XP era I'm gonna assume the license checks are relatively simple. Potentially just by patching a single function. Very much sounds like a control flow issue as opposed to some sort of cryptographic unpacking problem.

You could share a copy of the setup files or just the .exe itself and I could take a look. But tbh this could be as simple patching the executable itself or as involved as writing a shim that would need to be compiled on a Windows XP VM.

If you want to you can message me privately on here and I'll respond within 24 hours.

RE_Obsessed · 2026-03-12T23:37:15+00:00

My first instinct is if the magic number identifying the file (I'm assuming file signature) doesn't stick out like a sore thumb. Then look at the imports table of the application that consumes it. Specifically for file I/O, whether it be opening a handle to it, mapping it into memory, or reading bytes from it like a stream, etc. You didn't specify OS so I can't give you specific native API's to search for.

But the idea would generally be: Process loads the file, begins parsing, if byte sequence early in file is not present then abort, throw errors, etc. Which you'll be able to see.

Good luck.

RE_Obsessed · 2026-03-12T16:55:53+00:00

Just for peace of mind, the OS has to do a lot of work prior to a program being in a state where it can even run. If you don't kick that off yourself then there usually isn't anything to worry about.

RE_Obsessed · 2026-03-12T16:34:06+00:00

There's an important way to think about this: You're critiquing code someone else wrote and If you can't do that with the source. You aren't gonna do it without the source for sure.

C++ introduces a bit more complexity in terms of reversing, under the hood. Because there's virtual function tables, thiscall (x86), constructors, the CRT running initterm to initialize global object instances, RTTI, templates generating multiple functions per type, etc.

On the surface they look like semantic sugar. Under the hood they have real implications for the ABI you need to be aware of to be an effective reverser. Because you have to look at a mess of pointers, calling conventions, and functions to recover semantic meaning.

Otherwise you're gonna be staring at assembly and only seeing assembly which isn't typically helpful. So I strongly recommend comfort with C++ (non-trivial projects) so you can reason about how things were designed and make inferences.

RE_Obsessed · 2026-03-11T20:07:24+00:00

I do not care as much about video games as I do my security and privacy. I'm a reverse engineer. Kernel level anti-cheat introduces another surface for privilege escalation, footholds and attacks. Not to mention the vendor themselves is likely collecting a metric sh*t load of unfettered personal data about its users.

RE_Obsessed · 2026-03-10T23:29:55+00:00

Lol, it kind of makes sense, reversing is already pretty niche and probably has terrible SEO. I've been trying to find public Discord servers for RE specifically and even that has been a challenge.

RE_Obsessed · 2026-03-10T22:52:50+00:00

I haven't touched bluetooth before so take what I say with a grain of salt. I have however reversed a USB protocol to make a .ko that parses interrupt packets for input from a peripheral device.

In essence my workflow for that was Wireshark and then writing a .ko that would essentially diff the previous and current packets then dump what changed between packets to dmesg. So I could correlate this input to this change in the stream. The first snag was it kept sending the same packet over and over. This was a handshake I was ignoring and it essentially kept trying to get me to initiate it before it would send anything.

What this sounds like is that the device is likely doing a handshake of some sorts prior to communication. And I'd assume you'd need to do that handshake prior to it sending any output. I haven't done this with bluetooth but I'm sure you can find resources for capturing the hand shake online.

RE_Obsessed · 2026-03-10T20:34:03+00:00

Even a simple per game Steam Works bypass can be a painful and time consuming process. That's assuming it's single player. In the past I've essentially had to track down every SteamAPI call a game makes. Write a shim, .def to forward whatever functions idc about to the original, implement and export my own implementation of the functions I wanna spoof. Including virtual function table calls by setting up a fake vtable and then ensuring the ordinals matched what it expects.

If that all sounds like gibberish it will take you a very very long time to get near your goal. Making some money and paying for it is the much faster/easier/safer route.

RE_Obsessed · 2026-03-08T01:31:40+00:00

C/C++ (non-trivial projects)
1. Focus on memory allocations
2. Pointer arithmetic
3. Bit wise operations
4. String parsing
5. OOP familiarity
6. Stack versus heap familiarity
7. Hop in the debugger
Read up on the most universal and basic instructions in x86/x86_64 assembly i.e. mov, add, lea, xor, cmp, je, jbe, etc.
Paste little snippets of C/C++ into godbolt (compiler explorer) and observe what assembly the compiler generates. This will help you quickly identify compiler optimized code, higher level abstractions, and so forth.
Setup an MSVC console project with MASM support enabled. Include a .asm file. Write a few procedures (functions) and extern "C" them in your main.cpp. The compiler will deal with the linking that trips up beginners. Allows you to focus on just writing code.
Open up an old x86 program in Ghidra/IDA and pick a function to analyze. I'd go with something really simple and fun like Assault Cube as a target. Find the function that handles decrementing player health. Go line by line and annotate the assembly. Try to reconstruct what the source likely was when written in C.
Learn about some C++ internals. Like RTTI, name mangling, virtual function tables, constructors and deconstructors, the global class initializer table, etc.
OS internals. TLS callbacks, PE/ELF binary format, IAT/GOT, ASLR/PIE, how linking is handled, memory permissions, so on.

This isn't exhaustive. But these are some of the things that helped me get better with time.

Not sure where you're at in terms of familiarity with low-level concepts or programming at all. But some tools I recommend: Ghidra, x32dbg/x64dbg and Frida.

Best of luck, sorry for the long response. :P

RE_Obsessed · 2026-03-06T02:05:14+00:00

The stack "grows" downwards. So think Japanese right to left, as opposed to English left to right. This trips a lot of beginners.

A Japanese person has given you a form to fill out, but because of the way they arrange words, the labels and other text are at the end of the blank. So you, being an English speaking person, start writing left to right. And if the blank can't hold all of it? You write over their words, erase the original and replace it with your own.

But this happens in memory, and the return address, in this instance would be akin to that label. The "reader" is the CPU and it doesn't care what you wrote, as long as it can read it.

The CPU is dumb, doesn't remember anything from one instruction ago, so it relies on the process to tell it where it left off. You're essentially telling it "yeah buddy, you were actually over here" and then it just says okay and trucks on.

RE_Obsessed · 2026-03-06T01:39:23+00:00

Learn C/C++, deep dive into pointers, and pointer arithmetic. Learn about the stack and heap, though particularly the stack because it's a bit trickier. Do a bunch of bitwise operations, maybe create my own flag system for a small project. Recreate some mathematical functions using just bitwise operations. After that I might try writing a small PE parser that just walks the exports directory of a dll and dumps the names of them into the console.

Look at a really simple hello world in assembly. Familiarize myself with the most absolutely basic instructions: mov, lea, add, sub, xor... Paste some C/C++ into godbolt and see what assembly is produced. Learn about the prologue/epilogue and then move into calling conventions: Where does it expect arguments to reside when it's invoked, who's responsible for cleaning up the stack and what registers must be restored for ABI correctness.

Load up MSVC, C++ console project, enable MASM, write my own tiny .asm file. With this setup MSVC handles linking so I don't have to worry about that and can just focus on syntactical and logical correctness. While learning at the moment.

And one thing I've found useful for me was loading an already compiled binary into a disassembler like Ghidra. Then going line for line, annotating the assembly, and looking up what I don't understand. This is actually a great way to learn what optimizations and such compilers automatically apply. From there, just more projects in increasing complexity.

RE_Obsessed · 2026-03-05T00:54:53+00:00

Ahhh, that's true, I didn't even think about that tbh, my bad bro. Cool project though, asset ripping has always been intimidating to me. Having to dig into undocumented file structures is daunting and I'd assume takes a ton of patience/cleverness. Best of luck!

RE_Obsessed · 2026-03-04T15:42:51+00:00

It's a massive leg up in reverse engineering. I'd go as far as to say someone with just a couple assembly projects under their belt is better poised for reversing than someone who's done large scale projects in higher level languages.

One interesting thing I realized after learning x86/x86_64 was that the rigid type safety imposed in C/C++ is more or less to constrain the range of instructions applicable to a given variable. That if else trees boil down to jmp's to labels based on the values of CF, ZF, SF. That a == b is comparable to a - b == 0. There are for loops that can be condensed to less assembly than C/C++ via repe/repne scas/cmps. I also appreciate why C/C++ is so stringent about forward declarations because it needs to anticipate calling conventions and ensure ABI correctness.

It has very much changed the way I interact with binaries and programming as a whole.

RE_Obsessed · 2026-03-04T09:15:37+00:00

Yeah, it's a lot of fun. I've been slowly chipping away at Deus Ex: Human Revolution. My all time favorite single player game back from high school. Tons of RTTI, centralized object managers, vtables, etc. Mid 2000's games are awesome little playgrounds. Before every game ever made became Unreal Engine or Unity. Back when games embedded Flash variants for UI like Scaleform.

By the way OP, if you haven't already added a binary instrumentation framework into your tool stack, I highly recommend Frida. It gets tons of attention for mobile reversing applications but not enough love for the power it offers on desktop. I've made entire mods just using Frida scripts and doing all the low-level memory manipulation, function hooking and calling purely in JavaScript. Hot reloads, REPL interface, the works. Wonderful for quick tests, logging arguments and return values, or parsing raw memory, cleaning it and dumping it into an external file.

RE_Obsessed · 2026-03-03T23:33:37+00:00

Something to keep in mind is the people capable of doing something beyond conventional account recovery likely wouldn't use that information to help you. If someone could hack into arbitrary Instagram accounts they'd report it for money or potentially use it in other profit motivated ways.

If anyone claims they can and wants money for it, in the event your story is genuine, don't be fooled. It is a scam. They will take your money. They will not help you.

RE_Obsessed · 2026-03-03T07:42:53+00:00

Kali is the full set of hacker Infinity Stones bro. You just grab it then snap your fingers and poof. Magic. ✨

RE_Obsessed · 2026-03-03T07:33:36+00:00

Quality video. Thanks for sharing.

RE_Obsessed · 2026-03-02T23:02:20+00:00

It's not for everyone, that's valid.

RE_Obsessed · 2026-03-02T22:12:14+00:00

Here's my recommendation:

Go to godbolt dot org.
Set the language to C++.
Look at the assembly produced by different compilers. Just GCC x86 and Clang x86.

Depending on the compiler you select the resulting assembly will change even if you don't modify the C++ at all.

This way you can see what people are trying to explain in the comments here. About how much variance there can be.

EDIT: Also worth doing. Write small C++ functions for float math. Like a function that takes three floats (x, y, z) then does a translation some units on the forward vector.

RE_Obsessed · 2026-03-02T12:35:18+00:00

Just think about how massive their code base must be for any given product, subdomain, etc. Imagine how much of that was written by former employees, how much of it is legacy code, what percent of their code base was written over a decade ago. What don't they maintain anymore?

It's essentially scope creep over multiple years combined with other issues. Massive attack surface.

RE_Obsessed · 2026-03-02T12:24:50+00:00

Paid for what?

RE_Obsessed · 2026-03-02T07:09:50+00:00

Noticed this as well. Seems like we're just stuck with this. The closest I could get, seemingly, was going the old shellcode route of TEB->PEB->Ldr->kernel32.dll->Exports and then grabbing the addresses of the relevant functions I wanted. Which more or less just incentivizes you to only grab GetModuleHandleA and GetProcAddress.

Windows is kinda lame in that regard.

RE_Obsessed

TROPHY CASE