![]() ![]() without a human intervening to help identify the distinct layers because. Done well, that could make it rather difficult to mechanically de-obfuscate their code changing over time, i.e. If the FreeSlots devs are clever, then they likely have a scheme to randomly generate the code they want (producing their desired result in terms of odds), where the random part is w.r.t. ![]() There are likely several tricky rounds of that technique (and others) used at layers within the obfuscated code. Re: the program, shows that most of the obfuscation is related to decoding characters per some algorithm of their devising and eventually eval'ing the string as a JS program. Meaning, effectively, it can be de-obfuscated into code with control flow that's readily understood by a human, even if it would take some patience and practice (and the right tools) to perform the de-obfuscation. That's why they wrote "Anyone dedicated enough can de-compile that javascript." There's then more to determine whether your state is a winner (based on the game mode), but I didn't feel like looking into that specifically. So, we're generating a random integer from 0 to 890,000 (inclusive, with negligible chance of generating 890001) with each spin, and using that to update the state (seeded with current time the top 1e6 of the value is determined via mixing of Date.now() and Math.random() and is fixed for a given session). credits is `Lma` if you want to cheat, you can edit that variable directlyĬredits < 500 & (Ika = Ika - Ika % 1E6 + rand_int(890001) + 1E5) Using those two together to decode the RNG function, and searching around for some more local pointers (with some judicious renaming of functions for legibility, and some comments): It'd be interesting to see what some real JS devs could get to, both from a "how hard is it" perspective but also just to see what different obfuscations are used in the real world.Įven easier: open up Chrome DevTools, add a breakpoint at the eval, step into function. ![]() Anyways if I were evil I'd make sure at some point in this chain there is a subtle change in what's happening that breaks this approach so I wouldn't be surprised if someone told me that was the case :). There is probably something that could be done with debugger breakpoints here but I don't know enough about how that plays out inside eval. I'm not sure how many levels it was applied but my general strategy on it was the first obfuscation method seemed to be an IIFE that triggers eval on a big string that has had some transformations applied which then calls eval on the next level and so on so I would take the IIFE, turn it into a function definition stuck in a variable like "decodeFunction1" so I could just recursively call directly and change the ending to return the string instead of eval it directly. ![]() In the end those two tricks (both I'm sure being a pain on purpose not by accident) netted me not getting very far as expected, I was only a couple iterations into the first method of obfuscation. Once I got that out of the way with some policy the next issue was the console not really being used to non-printable characters catching me up. My main enemy for the first few minutes was the browser trying to tell me I can't do things like eval/etc. ![]()
0 Comments
Leave a Reply. |