Oh hey, I'm the author of the post! Happy to chat about any aspects of it.
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
Given that the application was written in Delphi, I'd bet it's using some form of Partial Key Verification [0], which I wrote a fun blog post about a couple months back [1]. :)
Wow, that's super interesting reading! Thanks for the links! I will certainly be keeping this all in mind if I ever jump ship to proprietary software land ;)
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.)
Oh boy there are some interesting possibilities here with the partial key verification stuff.
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...
Wine dev, here :) Using Ghidra & winedbg is something I do quite often for Wine development, it's super cool to see someone using those tools for other purposes, too.
Happy to oblige :P You know, now that you've mentioned that, it only just occurred to me that winedbg is probably mostly used for Wine-related debugging, not debugging things that happen to run in Wine!
Sorta. Winedbg mostly exists because most native debuggers won't have support for the situation Wine creates (Windows PE files with a non-native memory layout co-existing with native libraries). Just turns out that debugging Windows software in Wine is not a very common usecase outside of Wine dev :)
Interesting post! I recall a lot of older copy protection instructions around eax:edx register/space. Is there a reason you don’t just JMP around the license validation entirely?
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.
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.)
I think its pretty cool your in the medical field and doing this stuff lol. I've already noticed that "hacking" tends to attract a lot of random people from different disciplines lol
It's a good question – I'll copy what I wrote for the Redditors who had the same thought:
> 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.
To be honest, it wasn't too hard to figure out what the target software was from all the subtle clues; after all, crackers are the sort of people who will enjoy such a challenge too! I won't reveal it here either for your sake, but don't think that the "anonymisation" was even close to being complete...
Then again, I also exercised my skills from the Fravia/Searchlores era ;-)
- Industrial/control oriented (talking to bespoke hardware)
- An "internal" B2B line of business thing
- An off-the-shelf/productized/marketed piece of software
I suspect the latter.
I'm naturally also curious what it was for, but I suspect that even generally scoping that would make identification significantly easier for a large majority of people, so I'll leave it there :)
On a technical point, even if the company has ceased to exist, its assets might have been sold, or it might have assigned its copyrights at some point, or perhaps a third party has a copyright interest, and there would be no way for me to know about that.
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.
Many companies don't just cease to exist, but rather the rights to their IP are purchased. Some of that IP is viewed as not valuable and ignored... but they still hold the rights to it.
In some cases IP like this can be even more dangerous because there is some disgruntled CEO potentially sitting around with ownership of all the IP and he/she sees you're infringement as a quick cash grab.
Some other company or individual could have bought their IP portfolio and now own the rights. They have no obligation to publicize this, as far as I know.
It was fairly straightforward to see in this case honestly. I made a habit of looking at both the disassembly and decompiled code – my previous project was in IDA Free which had no decompilation, so I was used to referring to the disassembly. The address to use for breakpoints also come from the disassembly, so one naturally spends a lot of time looking at it.
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.
As someone who is significantly smarter than me, how does Ghidra compare to IDA? I'd love to get into decompilation, but I've heard that the free tools leave a bit to be desired.
Ghidra is as good as IDA with caveats, in my opinion. If you're reversing a less-common architecture (not ARM/x86) which Ghidra supports well, it's much more effective than IDA simply by virtue of having a psuedocode decompiler (IDA's Hex-Rays is architecture-specialized).
The IDA GUI and scripting functionalities are much more common in tutorials and the ecosystem, so the Ghidra learning curve can be greater, but it's not really inferior.
IDA has fewer decompilation/disassembly bugs but in both IDA and Ghidra, bugs are usually fairly easy to spot and not a huge detriment to achieving a goal.
IDA deals with C++ better than Ghidra (imo).
Anyway, for free Ghidra eats IDA's lunch, and the IDA home edition offering is weak - so for a hobbyist, Ghidra is a clear home run.
I haven't ever been able to test IDA's decompiler or debugger, as IDA Free only does x64, and all the RE I've done is on 32-bit binaries.
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