93 karma · joined August 30, 2021
https://twitter.com/RunasSudo
[ my public key: https://keybase.io/runassudo; my proof: https://keybase.io/runassudo/sigs/3OwmGioEm40YoGdBrtenCLxAcCbTuIo8vgAmqSsrkOo ]
> Totally, putting some small patches into the binary would definitely work in the case of just wanting to get rid of the licence validation. The goal of my project, though, was to get to a state where the software could be used in its original unmodified state, with a "real" licence. Just felt more authentic! So the process over the 3 parts of the blog series is guided by that final destination.
Sounds like try-catch handling is not implemented in general yet, but is on the cards.
In the first case, the decompiled code reports a function call, but in the disassembly it is preceded by pushing some suspicious-looking magic numbers onto the stack which are not reported in the decompiled code – clearly, something was going on there.
In the second case, the "ret" instruction at the supposed end of the function was immediately preceded by pushing an address to the stack – so again fairly simple to determine that the return must necessarily jump to that address, rather than return from the function.
What if you release a new version where, if the key is valid under the old check but not under the new check (indicating a keygen-ed licence), you start subtly screwing with the user. Like EarthBound or Spyro...
Quite off topic but very interesting!
Re: anti-CV – Thanks! Imposter syndrome is a big problem in medicine, as it is in IT and probably every field, and I wanted to do my little bit to combat it. (Not my idea, got it from my seniors, who got it from some uni professors.)
The key validation algorithm in this software is extraordinarily simple, so I'm leaning away from there being anything fancy. I was unable to correlate keys used in later versions of the software with this algorithm, though, so you might be on to something. (I don't have a copy of a later version, but would love to check if I ever get my hands on one.)
I actually don't know all that much about binary RE – my usual work is generally high-level Python stuff – so I try to write how I would like things explained to me, which I think helps.
It sounds like what you might be after is some content on crackmes/specific RE challenges. I'm not involved in that space, so someone else probably would have better links, but one challenge that was my start in RE was the Synacor Challenge: https://challenge.synacor.com/
It starts off just as a programming challenge, no real RE knowledge required, but if you see it through to the end you'll definitely wind up with a bunch of foundational RE skills. And there are a whole bunch of public writeups online if you want to follow along with someone else's approach.
(Just to note, though, that it's based on a custom CPU architecture – implementing that is the programming part of the challenge – so very much from the ‘learn it the hard way so when you do regular stuff it feels easy’ school of thought.)
The Youtube channel LiveOverflow also has some videos going step-by-step through some RE puzzles, and his content is very digestible.
The broader point to make is that this is a general policy of mine – I deidentify all software that I discuss in any of my RE writeups. Having a blanket policy avoids needing to make ultimately arbitrary decisions about what to name and what not to name – and in any case, not naming the software doesn't prevent anyone from reading the writeup and taking inspiration from it if they choose.
> Copyright law is pretty scary around anti-circumvention rules – putting the name of the software right in an article about how to break its DRM/licensing just sounds like asking for trouble, so I never do. (Not legal advice – just my personal musings!)
> At least if the software is unnamed, the article is clearly more for educational purposes – you won't find the article if you've got the software and you're trying to break it, and you won't have access to the software if you're just reading the article.
Ghidra's decompiler worked fine for this project. It made 2 relevant mistakes which I talk about in the blog posts, but they were fairly easy to identify when comparing with the disassembly.
As I discussed in the post, Ghidra did have some difficulty (which IDA did not have) locating all the functions, so I did end up using both Ghidra and IDA in the initial stages.
The progress that Ghidra is making though (e.g. the recent implementation of debugger support) is promising for the future.
This project is a spiritual successor to an earlier project reverse engineering a gaming DRM system, so if you enjoy this post you might enjoy that older one too: https://yingtongli.me/blog/2018/11/16/drm1-1.html