| MATH keygen |
[Click to reveal]Hi Mazzotti, thanks a lot for the reply — and for confirming there's no shortcut. I pushed the analysis to the end, here's the short version.
**Fully reversed + bit-exact oracle.** The check is a per-character chaotic hash (signed-byte products, `sin`/`cos` truncated ×1000, glibc `random()` reseeded every char) accumulated into a 128-bit sum that must exactly equal `0x1d:24347a11c16a54a6`. Reproduced bit-for-bit in C/Rust/CUDA (`"a"*32 → …0583e12e`).
**No keygen — confirmed by measurement, not just intuition.** Inversion (sin/cos non-injective), linear algebra (killed by the ARX mix), meet-in-the-middle (the `acc` carrier is a full 64-bit mixer), and SMT all fail — z3/Bitwuzla return *unknown* even on a planted-SAT instance with the transcendentals frozen. So brute force is genuinely the only road.
**The interesting part — why the target `hi = 0x1d = 29` is a fingerprint.** The 128-bit sum is `Σ r12ᵢ` with each `r12ᵢ < 2⁶⁴`, so the high word isn't a free 64-bit value — it's just the **carry count** of the additions. I measured its distribution on the real oracle: mean carry ≈ N/2−1.5, so `hi=29` forces a **long** password (≈50–55 chars); short ones are nearly impossible (N=31 would need 29 carries from 29 additions). Effective work factor comes out to **≈ 2⁶⁸** (measured `p(carry=29)=0.071` at N=55, low 64 bits verified uniform), i.e. ~4 million years on my GTX 1070 at 2.1 MH/s.
**The paradox:** there are on the order of **2²⁹⁴** valid passwords in the ≤55 printable-ASCII space (2³⁶¹ inputs into a ~2⁷⁰ reachable output space), yet the crackme is unsolvable — the solutions are uniformly scattered at density ~2⁻⁶⁸, with no gradient or algebra to steer toward them. Many needles, no compass.
I also wrote a working hashcat 7.x plugin for it (`-m 99420`, FP64, 2.1 MH/s on Pascal — ~7000× slower than MD5, exactly as your design intends).
Bottom line: the password 100% exists, the hash is fully understood, but it's unbreakable by construction — a beautiful piece of work. Big respect. :3
|
2026-08-30 14:50 |
| MATH keygen |
[Click to reveal]Hi Mazzotti — "MATH keygen" was a fantastic rabbit hole, thank you :3
Quick summary of where I got: fully reversed check(). Per character it computes bytesum (signed), three trunc(sin/cos(u2d(x))·1000) stages, and glibc srandom()/random() reseeded every character; the carrier is ×(2·k1+1) then XOR a bounded mask, pushing one 64-bit word per character, and success needs the 128-bit sum to equal EXACTLY 0x1d24347a11c16a54a6. I re-implemented it bit-for-bit and validated against your binary via gdb (read the internal sum at the compare), and wrote a CUDA/hashcat cracker too — so I'm confident I have the real algorithm (a solver of your "Next generation" even described the same glibc-PRNG method).
Where I'm stuck: the exact 128-bit target. Inversion runs into the fixpoint where every mask depends on the value being solved (via sin/cos + the reseeded PRNG), and I empirically ruled out linear/ARX, Gröbner, MITM, SMT (times out by 3 cycles) and differential paths — all converge on a ~2^64 needle for the low 64 bits, with acc being a full-entropy chained mixer and bytesum coupling globally.
Could you confirm whether there's an intended shortcut I'm missing, or — if it's genuinely meant to be found by knowing the key — would you be willing to share the intended password (or its length/character set)? I'd love to close the loop and verify it against my oracle. Either way, huge respect for the design. :3
|
2026-08-07 18:02 |