I don't know if "hackers" actually tried RE softwares locked behind paywalls; for Health research (Flowjo, Kaluza, GraphPad Prism, Pymol ..). This could really give scientists a huge push and help em advance quicker. Any informations regarding this matter ?

Hello,

I won't bore you with the details of my current mental breakdown. A lot of things suck, and today to make it worse, I found a discarded gift I bought my bratty baby sister and my downward spiral went full vortex. It's a Sphero BB8 robot toy. I thought she was gonna go nuts for it, but it's sat completely abandoned in a backroom unused. I went to download an app to bring the poor little thing to life only to realize it was discontinued..... the app that seems to be the alternative has a paywall. I think it might have some features that supposedly work without paying, but they aren't responding and my dumb gerbil brain doesn't know if its the app or the robot.
I will learn anything.
I will study anything.
I will go down rabbit holes.
I want to jail brake it.
Please suggest any resources...

LIVE RESOURCES IN COMMENTS BELOW>>>>

I've recently came across a two-year-old post of this decompiler called rev.ng and have been wondering if (and how) it has changed in the past two years. I heard that it has worse decompiler quality than ghidra, so has the decompiler quality improved? Have any of you tried it out or have been meaning to try it out? Just curious.

Can someone help me bypass Enigma's HWID protection? I read that it's possible using entry points, but since this is my first time doing it, I didn't understand how to go about it. I'd appreciate any help—I can send the file.

Started this morning with a Garmin nüvi 2455 collecting

dust in a drawer. No documentation existed for the .GCD

firmware format. Here's what I found.

**The OS:** GarminOS built on OS20 RTOS (STMicroelectronics)

on ARM. Confirmed via leaked source paths in the binary:

gpk\gps_st\garminos\os20\gps_st_os20_task.c

**The format:** 9-byte record header:

[01 00 01 00] [TYPE] [FieldA: 2B] [FieldB: 2B] [Payload]

**What's inside GUPDATE.GCD (48MB):**

- 19 records mapped

- 20 PNG bootloader assets extracted (SOFTWARE, SYSTEM,

LOADER, MISSING, LOADING... + UI icons)

- ARM Thumb code blobs confirmed via entropy analysis

- 6 compressed streams with unknown compression method

**Workflow:** Claude + Claude Code + Codex + Mistral Vibe

**Toolkit:** github.com/theodorebeaupre-prog/garmin-gcd-toolkit

I'm 15, Quebec City. Happy to answer questions.

Hello!
I am a recruiter at SpaceX and I am on the hunt for talented security engineers! 
Specifically, I am recruiting for our security team working on Starlink. We want your help securing the world's largest constellation of satellites. We have user terminals in countries all over the world communicating with 10k+ satellites in orbit. This is a massive distributed system and as you can imagine, a fascinating security challenge. People with a reverse engineering background have had success here in the past! I will put down a link to both the job posting (we are hiring Eng I/II and Sr.) as well as my LinkedIn!

Hey all,

I recently built a tool to help me with packet annotation and documentation and wondered if its something that may be useful to others. The software is currently tightly coupled with another application I'm building, but it shouldn't be too hard to separate if there's interest.

Packets are ingested into a "packet collection service" and then displayed in the UI, I've been analysing 200MB+ pcap files without any perceived lag. You can either ingest packets directly (if they're unencrypted) or publish to the packet collection service using a DLL once they've been unecrypted.

Current feature set:

- Annotate packets by producing documentation in markdown format + provide a category/colour for each opcode

- Visualise the rolling byte diff between opcodes that change (summary column where the changed bytes are highlighted in orange)

- See a visual timeline of all packets, allowing you to spot which actions cause which packets to appear

- Create Python scripts to unmarshal packet data and visualise the decoded values, OR manually probe and annotate the packet

- Provide filters to remove noisy packets and hone in on what's useful in your investigation

- Compare packets of the same opcode to your current selected packet (advance the right bytemap by using the prev/next arrows - or press play to see a realtime feed of that opcode as it arrives)

- Custom filter DSL to filter packets based on probes you've created

probe(field,value)

match(value,BYTE_OFFSET) - if no byte offset is applied, match all occurences of value.

I'm keen to expand the feature set, but this has been enough to help me make significant progress vs my old approach. Looking forward to hearing what you all think!

https://drive.google.com/file/d/1WbzxpphjJ4L9J4oeQm3hnRS87DPqDpP1/view?usp=drive_link

the above like contains a file called cirno.dll

this is part of a bypass for a video game floating around in the pirating communities so i decided to take a peak.

It unpacks something to memory sets the memory region as executable and jumps to it.

i managed to get the second stage payload. which is again heavily obfuscated by RC4 cipher. i think (thats what ai told me).

If someone is up for a challenge please take a look into this ? if this is an actual malware there could be a lot of infected users.

(for legal reasons i can assure u that this is not a copyrighted file)

I've been thinking about the gap between static and dynamic analysis tooling.

Static analysis tells you what code could do. Dynamic analysis tells you what it actually does. Most of our tools treat these as separate worlds — you run Ghidra for static, then switch to a debugger or Frida for dynamic, and mentally correlate the results.

What if we could bridge them more directly? Some ideas I've been considering:

Runtime data feeding back into static analysis:

• Function called with "config.json", "settings.ini" → auto-suggest name like load_config_file()
• Observed memory layouts → auto-generate struct definitions
• Execution traces → highlight actually-executed code paths, gray out dead code
• Crash traces mapped back to decompiled functions

Potential integrations:

• Frida hooks feeding runtime values back to Ghidra annotations
• GDB/LLDB breakpoint data correlated with decompiled code
• Coverage data (from fuzzing, etc.) visualized in the disassembler

Questions for the community:

1. Is anyone already working on bridges like this?
2. What dynamic data would be most valuable to import into your static analysis workflow?
3. What's the biggest pain point in correlating static vs dynamic findings today?

Curious what tools/approaches people are already using or would want to see.

hi, i dont know if this is the right place to post but im looking for a dev that can reverse an app, gather network reqs and make an api reg bot for me, paying for the job of course.

please get in touch if you have some experience, i can help out here and there too with some resources.

https://forum.tuts4you.com/files/file/2536-prometheus-12-layers-of-insanity/

Sharing Zyrox, an obfuscator implemented as an LLVM compiler plugin.

It applies multiple IR-level obfuscation passes, including control-flow flattening and encrypted jump tables, with the goal of making native binaries more resistant to static analysis.

Repository

Dev Blogs

This project reflects techniques and lessons I learned from over three years of reverse engineering.

Happy to hear thoughts or discussion from anyone interested 🙂

Hey everyone! 👋

Just wrapped up my first serious reverse engineering project and I'm posting here to get feedback from folks who actually know what they're doing.

The Project: I spent about 28 hours analyzing a World of Warcraft 3.3.5a game client to understand how its cryptography works (SRP6 authentication + RC4 encryption).

What I did: - Reverse engineered a 6.6 MB DLL with 5,200+ functions using Ghidra/Radare2 - Built custom packet capture tools with MinHook (DLL injection) - Analyzed 11,645 network packets with Wireshark - Found that their crypto implementation is actually solid (no vulnerabilities) - Did responsible disclosure anyway (they were polite but not interested)

Full write-up and code: https://github.com/Kyworn/wow-335a-security-research

Why I'm posting: This is literally my first RE project beyond tutorials. I'm transitioning into security work and want honest feedback:

• What did I do wrong/inefficiently?
• What approaches would experienced folks have taken?
• Red flags in my methodology?

• Suggestions for next learning projects?

  I tried to document everything professionally (1,400+ lines of docs), but I'm sure there are rookie mistakes everywhere.

  Be brutally honest - that's how I'll learn! 🙏

  Tools I used: Ghidra, Radare2, x32dbg, Wireshark, MinGW, Python, C

  Thanks for reading!

Help

Hello guys, I'm not sure if this is the right place... I have a friend that has a keyboard and he needs to change some settings. We have got the firmware and have tried different tools like IDA Pro, Ghidra, Binary Ninja, Binwalk etc

It does not have a file extension associated to it as well.

Problem is simple, add manual HEX Colors to ring.

Thanks in advance.

I recently created an application to teach basic RE for Android apps. I am, of course, not an expert and also still learning more! But I thought that this would be helpful for those trying to learn Android RE.

I've spent the past 8-9 months building a crackme solution archive and recently hit 100 write-ups, making it the largest archive of its kind. The collection includes write-ups, keygens, and some hand-written decompilations (which I don’t post elsewhere), covering a wide range of challenges from crackmes.one and crackmy.app.

Everything is tagged and organized for easy browsing, and the write-ups link back to the challenges on crackmy.app to make practicing easier.
https://github.com/johnnnathan/Crack (Text Files Only)
https://johnnnathan.github.io/BurstMirror/ (HTML Render)

Hope it’s useful! Feedback is appreciated.

I remember reading a news about some one reconstructing a binary by decompiling it and using the same compiler to rebuild the code, then get an identical binary. After searching on the internet, I found at least two such projects:

ZZT Stories: The Reconstruction

lethal-guitar/Duke2Reconstructed (Also the Twitter post in archive https://web.archive.org/web/20220928183538/https://twitter.com/lethal_guitar/status/1575123187360227335 and reddit post https://www.reddit.com/r/ReverseEngineering/comments/xqi5e6/reconstructed_source_code_of_the_game_duke_nukem/ )

I also found this: https://github.com/pret/pokeemerald but I don't know what kind of this project is.

However, these projects are both after 2020. I thought there was some this kind of project that happened before that when Ghidra was not released. Does anyone know any reconstruct project earlier?

I've been using r2 for many years and I was there when Rizin was born as a fork (I was using cutter at the time).

I just remembered Rizin was a thing a few days ago and I am trying to find what are the key benefits of Rizin vs Radare nowadays (feture wise).

Any experience with both?