All Activity

It need license how to get a trial or something @lengyue

@CodeExplorer framework : net6 : https://forum.tuts4you.com/topic/43240-netreactorslayer/page/6/#findComment-228560

Use Net Reactor Slayer (GitHub) and Megadumper

I’m posting this here because I’m not exactly sure where to open the topic. If necessary, the moderators can move it to the correct section. Thank you. There is a protection developed for Silkroad private servers called Maxiguard, and I want to bypass the HWID of this guard — in other words, I want to remove the PC limit for this game by bypassing the guard. Is this possible, and how can it be done? I’m leaving the DLL link here. (Since the file size is too large, I can’t upload it directly, so I’m leaving a link instead.) https://dosya.co/amurea6iyicu/MaxiGuard.dll.html

Hi @Nooboy Have you crackme version winlicense v.3.2.5 ?

How to bypass license checks?

Just wanted to post my solution here for anyone who might stumble upon this thread. GitHubGitHub - hekliet/tsrh-kgm: Keygen for TSRh TeaM Trial Key...Keygen for TSRh TeaM Trial KeygenMe #1. Contribute to hekliet/tsrh-kgm development by creating an account on GitHub.The 'keygen' provided in this repo is a simple command line program that takes a line of input (the username) from stdin and prints a regcode. It should compile anywhere. MSVC users might have to substitute getline with gets or something, I don't know. A keygen that looks pretty and plays music can be found here: https://hekliet.nekoweb.org/tsrh-kgm/tsrh-kgm1-keygen.zip It's a Win32 executable that also works in Windows x64 and was coded on Linux using MinGW. No video, sorry.

Unpacked. WL_unpacked.7z

Hi Codexplorer, First of all, I wanted to say a huge thank you for your work on the Unlicense project and for sharing your compiled version/updates. It’s an incredible resource for the community. I've been testing the tool on some specific WinLicense 3.x protected targets (specifically 32-bit/x86 binaries). While the tool works great on many samples, I encountered a few hurdles with recent Python/LIEF environments and x86 targets that might be worth looking into for a future improvement: LIEF Compatibility: Recent versions of LIEF (0.17+) seem to have changed some attributes (like MACHINE_TYPES moving to Header.MACHINE_TYPES) and now return section names as bytes instead of strings, causing TypeErrors in dump_utils.py. Frida RPC Stability on x86: I've noticed frequent TypeError: not a function errors during the setupOepTracing or enumerateModuleRanges calls when targeting x86 apps on Windows 10/11. This often leads to AccessViolation because the IAT resolution gets interrupted or fails to map correctly. Forced IAT/OEP: On some complex targets, adding a more robust "forced mode" for OEP and IAT (bypassing the Frida instrumentation if the user already knows the addresses) helped me get further, but a native implementation in your branch would be amazing. If you have any plans to optimize the x86 engine or update the dependencies handling for the newer LIEF versions, that would be a game-changer for those of us working on older automotive or industrial software. Thanks again for the hard work and for keeping this project alive! @CodeExplorer Hi Codexplorer, First of all, I wanted to say a huge thank you for your work on the Unlicense project and for sharing your compiled version/updates. It’s an incredible resource for the community. I've been testing the tool on some specific WinLicense 3.x protected targets (specifically 32-bit/x86 binaries). While the tool works great on many samples, I encountered a few hurdles with recent Python/LIEF environments and x86 targets that might be worth looking into for a future improvement: LIEF Compatibility: Recent versions of LIEF (0.17+) seem to have changed some attributes (like MACHINE_TYPES moving to Header.MACHINE_TYPES) and now return section names as bytes instead of strings, causing TypeErrors in dump_utils.py. Frida RPC Stability on x86: I've noticed frequent TypeError: not a function errors during the setupOepTracing or enumerateModuleRanges calls when targeting x86 apps on Windows 10/11. This often leads to AccessViolation because the IAT resolution gets interrupted or fails to map correctly. Forced IAT/OEP: On some complex targets, adding a more robust "forced mode" for OEP and IAT (bypassing the Frida instrumentation if the user already knows the addresses) helped me get further, but a native implementation in your branch would be amazing. If you have any plans to optimize the x86 engine or update the dependencies handling for the newer LIEF versions, that would be a game-changer for those of us working on older automotive or industrial software. Thanks again for the hard work and for keeping this project alive! @CodeExplorer

I was not able to download your firmware completely (Catbox seems to be having problems today) but I can give you some tips anyway. Step 1: It's unlikely that you've encountered a very unique hardware that has no existing tooling or documentation. Also a lot of hardware is made by the same OEM manufacturer in China and just sold under different brand names. So, use Google. Seriously. :) First few kilobytes of your firmware contain plenty of interesting and unique strings. Search for each one separately, or some combination of them. You're basically looking for the information about your hardware - CPU and system board manufacturer, addon boards, sensor information, and so on. You'll be amazed how much information a single search can provide. You could also search for the hardware make/model (which unfortunately you didn't tell us) or FCC ID. Step 2: Once you know the basic hardware information, use Google again. Look for tools and SDKs for the specific manufacturer/CPU. Use Google Translate to browse Chinese and Russian sites - they are a goldmine when it comes to hardware hacking and documentation. You should be able to find this github project. too. I didn't run the tool but a quick look at the source code tells me it should unpack your firmware with little to no modifications. Step 3: Load the unpacked firmware in Ghidra/IDA and start the actual reverse engineering process. :)

hello everyone! first post here :D im somewhat new to reverse engineering xiot firmware binaries, so please forgive my ignorance as i learn. ive been working on this one embedded linux binary, but ive been having trouble. using binwalk, it cant seem to fully decompile it, only return a .lzo file. based on entropy analysis of given lzo file, it appears encrypted with partial plaintext for bootloader (high entropy/low variance, please correct me if im wrong). im not sure how exactly to go about decryption or further analysis. i thought maybe xor encryption algorithm, so i tested the binary against all possible xor encryption keys, with no results. https://files.catbox.moe/cnre9d.bin if anyone has the time to help out, pls do so!! ive linked a copy of the binary, if you make progress, pls let me know what you did so i can learn from it too. thank you! ^^

Rar Pass 1 Rar Pass 1

Here my unpacked. CFF Explorer_unprotected.7z

Thank you very much, appreciate the PDF copy and extras! Ted.

Hello @boot, bad news, your tool & driver can't kill the python process too like all those other tools. ☹️ Really sad. It can kill other running processes but not that specific one. I really would like to know why it is impossible to exit this process. Ever heard something about that a process really can't get terminated and the only way to get a rid of it is to reboot the system? Do you have another ideas? Remember, in this thread you could see my video I did post where it happens when using ComfyUI Portable (even outside of Sandbox) which used a embedded Python file which also makes that trouble I can't terminate at the end when this problem occurs by random etc. https://forum.tuts4you.com/topic/45702-how-to-terminate-a-process-which-is-denied-to-terminate/#findComment-226957 greetz

Bypassed the license check but unpack is too complicated. The imports are very heavy wrapped. Can do it but few hours manual work will need.

The crackmes.one CTF is officially live, built by the RE community, for the RE community. https://crackmesone.ctfd.io/ Start at: Sat 14 February 2026 00:00:00 UTC Enter the matrix and prove your skills. See you there!

Hello. I have organised it in two different formats. I also added the modified solver.c file as an extra. Thank you. Link: drive

Thank you very much for detailing the solution and method/s taken to solve. Would it be possible to get a PDF copy please? Ted.

Yes, please post crackme's in the correct area, read the description at the top of the category in the link below, thank you... https://forum.tuts4you.com/forum/146-challenge-of-reverse-engineering/ Ted.

https://dr4gan0x.github.io/dr4gan-portfolio/?post=prometheus-12-layers I hope this write up catches your interest

I would appreciate a full writeup! Also, please consider publishing your solve to crackmes.one, where the author cross-posted this challenge.

Threw this into Binary Ninja, turned out to be Rust-compiled ELF64 PIE not C as DiE claims, debug strings like src/main.rs src/vm/dispatcher.rs src/crypto/sbox.rs give it away, main at 0x41bea0 is just the lang_start trampoline real logic sits in sub_41a0c0 which drops into the verification orchestrator sub_418a10 running all 12 layers with bitwise AND accumulation no early exits, layers 1-3 are RDTSC delta and clock_gettime CLOCK_MONOTONIC anti-debug gates, 4-5-6 enforce the 28-char [A-Z0-9_] format with underscores pinned at positions 10/15/23 last 4 digits only and ASCII sum exactly 1901, identified the core hash at sub_433b80 as SipHash-2-4 from the init vectors 0x736f6d6570736575 0x646f72616e646f6d 0x6c7967656e657261 0x7465646279746573 aka "somepseudorandomlygeneratedbytes" with rotation constants 13/32/16/21/17/32 two rounds per block four at finalization, the actual crack comes from Layer 10 which splits the key into four 7-byte segments each hashed with independent k0/k1 pairs reducing the search space from 36^24 down to 4x36^6 roughly 2^33 which is the single architectural weakness in the design, brute-forced the last 4 digits first against Layer 6s YEARHASH/KEY01020 keys in 10K iterations got 2026 then segment 4 in 1.3K then segments 2 and 3 each in ~2.2B iterations then segment 1 with sum-constraint pruning total 55 seconds single core, validated against all remaining layers including the full-key SipHash triplet layers 7/8/9 with three different key pairs and the polynomial evaluation through MurmurHash3 fmix64 at five prime evaluation points all passed clean, key is PR0M3TH3U5_F1R3_ST34L3R_2026, I have a full writeup sitting around too lazy to format it properly but if anyone wants I can publish it

It seems that although the executable looks protected, no real encryption or obfuscation has actually been applied. There is also a possibility that I accidentally tested the original executable file. I will review my program and fix any shortcomings in the protection pipeline. Thank you for your feedback. Would you like me to open a new thread after I make the corrections?