I believe being successful in reverse engineering, cracking, bypassing security layers (e.g., unlocking cars without keys), and other hacks comes down to understanding the basics of how these systems are designed to work in the first place. Add to this, the possession of the right toolbox to do the job.
Back in 2010, I took on the challenge of cracking paid/licensed POS software. I am, in no way, a cracker or hacker, but once I understood how this app works, I followed a simple logic based on these rules:
a. The app had a trial version with a number of *runs* set, and with each launch of the app, the number will decrease by one. It was set to around 100, I believe.
b. The app runs on a LAN, on multiple computers, with one being the server. To my surprise, there were no IP configurations, and it turned out that it worked on LAN by setting the app directory as a *shared folder* in Windows!!
c. On each app launch, even from other computers (having access to the shared folder), the count will decrease.
So, I started my investigation:
1. Since you have a shared folder, based on (c) above, I assumed the location where the count number is stored *must be inside* this shared folder, not in the Windows registry or other places.
2. I launched the app, wrote down the current count, and closed it.
3. I searched inside this shared folder for *.* (all files), then sorted them by last edited.
4. I picked the first one from the search result as it was the only one with the same time as *now*; it was in a binary format.
5. I opened it using a hex editor, converted (using calc.exe) to HEX the count I wrote down on (2), searched for it, and found it. I identified its position.
6. I closed the hex editor, repeated (2),(3) and (4), and got the same results.
7. Now, I typed 999 in calc.exe and converted it to HEX, and in the open HEX editor, I edited the count at its current position with the new value, saved, and closed the binary file.
8. Restarted the POS app, went to about, and.. booooom , it now thinks that you have 999 days remaining :)
Although I never used this Point of Sale software, it was an exciting achievement for me. I felt like a real hacker.
You were a real hacker. That's exactly how a real hacker would have done it, starting from the simplest method of reverse-engineering, and moving to more difficult methods or complicated tools only as necessary. Luckily for you, this POS app wasn't very well-designed from a security standpoint, but that's not unusual, especially for software that has a very limited market and is written by a very small team.
Similar story from me, I was digging around in the code of this game that I had been playing since I wanted to make mods for it. At one point I found the internal IDs for different outfits you can put on your characters which was relevant to what I was making, so I grepped for those IDs since they were one of the few strings that weren't jumbled by code obfuscation. Stumbled upon the code that checks if you own the DLC outfits and found out you could basically just swap the check for a return(true). You could even use them online... Hardly any protection at all but it hadn't been cracked simply because nobody else looked that closely.
It’s done in a similar way on macOS: a dylib is added to the bundle and an LC_LOAD command is added to the app binary. The dylib is the first thing that runs because of using the constructor attribute, like this: https://notes.alinpanaitiu.com/Injecting%20a%20DYLIB%20into%...
The nice thing is that a signed app will refuse to load a dylib that does not have the same signature. So crackers will be forced to change the whole app signature which can be easily detected in app code.
This is different though, because it's modifying the executable to load the new lib, right?
If you're modifying the executable anyway, why not just patch it directly instead of going through these hoops?
The equivalent on Linux would be setting LD_PRELOAD and putting your .so file there. A quick Google search seems to imply that the OSX equivalent is DYLD_INSERT_LIBRARIES but I have no idea how similar they are.
While code signing and verification is the way, you should also include a step on your own and not rely on the OS to do that for you. Apple’s code signing has been bypassed a few times. Granted they patch it, however one can include a script that enables developer mode in a terminal process that can then disable code signing (enable in-secure apps via developer-mode AppleScript).
It’s impossible to get past inspection on the Apple Store due to that extra script in the app bundle but a downloaded dmg off the web…
Yes, I was referring to the fact that I do a manual code sign check in my own code. Otherwise, Gatekeeper will be happy to run any cracker-signed app, they even found ways to staple forged notarization tickets.
Manual code sign checks can only be cracked by patching the binary, which requires a lot more effort than swizzling some methods in a dylib. Or by process injection with Frida, but that requires disabling SIP which most people won’t do just for a cracked app.
The macOS cracking scene is also much much weaker. It's
1. Mildly harder on a OS level
2. Less popular in countries that produce the most cracks
3. Less popular in general
4. Has an audience that is demonstrably more likely to pay for software
5. Has less strong reverse engineering software. Hopper was awful.
Also, I just wanted to say I love your work. I've learned a lot from your blog, your free trial strategies are interesting, and quite effective: https://shottr.cc/s/1vQa/SCR-20240423-re6.png
> 4. Has an audience that is demonstrably more likely to pay for software
The flip side of this is that I've noticed software written solely for macOS/iOS is often more polished than many of the most popular FOSS projects written for Linux.
Obviously I don't have any expectation of software provided for free, but as someone who makes a living developing software I do find it funny how much reticence there is among other developers to pay for high quality software.
I have an aversion for paying for artificially scarce things. I am happy to "pay for software" if that software doesn't exist yet, and what I'm actually paying for is the labor to make it.
My mechanic doesn't speculatively contact me about work I should do on my car. If I want new software that I can't write myself, I should reach out to developers, not the other way around.
I would extend it to the words in a book, but not the book itself. That is a physical object and therefore has real scarcity. Similarly for movies and games.
Though I'm actually not against paying for access to stream media. I am however against telling people what they can do with the media once they stream it (ie saving it to their own drive for future playback).
So if you're not against paying for access to media, why are you against paying for access to software? If you're against DRM, that's an argument I can support more
I guess I'm not against paying for access to software, it's just that the consequence of being against restricting what people can do with it once they have it (such as redistribute it) makes paying for access seem unrealistic.
Paying for access to a media repository makes slightly more sense than paying for access a to software repository also, just given the sheer amount of data that media tends to take up vs how much data software tends to use. GNU software repositories are fairly easily hosted by hobbyists; multi-billion dollar companies often burn money trying to monetize media storage and distribution (particularly video). In that sense, there is some scarcity in media distribution. Software distribution trends to be next to nothing though.
I am also certainly against DRM, as I am any malware :P
I am a developer who likes to be paid for my work. I was also a diehard FOSS fan. I've also switched to macOS, and after I did so I spent probably $200 on software. What was interesting to me is that even in my Linux phase, some proprietary software was acceptable — notably steam. Why was this the case?
I think, as a developer, I value the ability to fix things I don't like. I've done it quite a lot in open source software. Just plant my fix and move on. Steam always felt complete. macOS software often feels closer to completion, though sometimes I do wish I could modify it still. Also, another class is software I trust that I could not do a better job on, like Affinity.
Anyway, I think that's the root of the developer aversion to paying for software.... Well, for me anyway. I wish we had better culture around donating to free software as well.
What is interesting here is that a signed piece of software can pick up an unsigned dll, execute it, and that execution causes a compromise of the system.
Probably in this case the installation of the crack requires admin privileges to modify files in "Program Files" folder. Boom, you've broken the rules ;)
This also raises a vulnerability. The author seems convinced this pirated copy is safe because the main binary is signed by Ableton, but there’s no guarantee if there’s a signature check on any of its dependent files (or that the check is not vulnerable or the parsing isn't vulnerable in some way which would allow hijacking the execution flow).
Same, I'm far from a prude, but time and place. And reading about reverse engineering is neither.
It reminds me of a really smart kid who doesn't want to be seen as a nerd, so writes nonchalantly and injects vulgarities into an otherwise brilliant project. Good Will Hunting vibes.
The first software I cracked was in 2004 (some video converter software), the motivation was simply that I can’t afford it, but the “feeling” you get after is like a drug, then it’s more of a challenge knowing that it’s doable no matter what, just like lock picking, then that spark just dies and you stop cracking them.
Because Dalvik/ART (and regular JVM for that matter) bytecode is much less lossy than machine code. Most of the type information stays intact even after obfuscation, so you still get sensible output from a decompiler. This is in contrast with C/C++ where all struct and class usage gets converted into direct memory accesses.
That doesn't have anything to do with being old fashioned. It's about how racing works in scene FTPs. When you release something race begins starting from so called affil "sites" (group release to all their affil sites at the same time) from there it propagates to whole scene by couriers. Because of how FTP works you need to split the file into multiple files so it can be uploaded by multiple people from multiple sources making distribution fast. And rar is used for that, there are scene rules for it and it's not using compression option.
From the 2021 scene release rules for games (ISO rips) [0]:
> 1.7 The ISO file has to be packed into a RAR archive using the RAR4 or the RAR5 format and the old style volume naming scheme. e.g. grp-gamename.rar, grp-gamename.r00, grp-gamename.r01, ...
Very interesting. I really should get back into RE.
Selfish question for a project of my own: is there any way to magically gain early code execution in a process on Windows other than a shim DLL? I'm too lazy to write one to pass through the all exports (reflective shim DLL possible...?)
CreateProcess the victim with CREATE_SUSPENDED, do whatever code patching, then ResumeThread it. Pretty sure you can even CreateRemoteThread into the victim for DLL injection, since it just suspends the primary thread, and then patch "yourself" in DllMain instead of having to do remote memory calls.
Alternatively, give frida a go. It handles all the hard parts for you magically and then you get to instrument the binary with Javascript :) mixing dynamic and static techniques is really powerful
A nice topic and insight if not for the way it is written. I could not finish it. It feels the author is unable to articulate his thoughts without interjecting curses and write incoherently.
Is this how people communicate technically in the newer generations?
> Is this how people communicate technically in the newer generations?
I suspect this question is in bad faith but I'll answer anyway: this live tweeted thread is more like someone's thought stream, it is not a technical report.
Many humans are capable of both technical writing, free of cursing, and also of dumping a swear-filled thought stream right into their favourite medium - especially when excitedly reverse engineering, or doing anything they're passionate about.
This has been happening for a long time and is not about "the newer generation". You could've found me writing in a similar way on IRC in the late 90s, also talking about reversing.
FWIW your comment feels valid enough up until your final sentence, you just didn't need to attack "the newer generations".
>FWIW your comment feels valid enough up until your final sentence, you just didn't need to attack "the newer generations".
Why not? He's exactly right, in my experience. It's definitely been my experience that the newer generations (of Americans) are much more likely to casually use swear words, usually the f-word, in regular conversation, even at work. I hear it all the time with my American colleagues. When I was their age, no one talked like that at work, or really in general except maybe in private with their closest friends.
Another big difference is mass media: when I was their age, American TV did not allow swear words. But in the last 10-20 years, it's completely changed, and it's pretty common to hear the f-word on regular TV. So of course the "newer generations" are going to reflect this in their casual speaking.
When I say young generations I don’t mean they are incapable, but that the tools they use and influences they are subject to, are new. This seems to lead to a normalisation of personal communication rituals that are often at odds with previous norms and conciseness.
Courtesy used to be a fallback protocol in society that allowed people of different sensibilities to communicate more efficiently and without personal contexts getting in the way of subject matter. It was also non threatening and the effort put into it was a sign someone was taking the counter part seriously.
Having worked with stong before I can assure you they're perfectly capable of articulating their thoughts when they want to. This is quite a bit more off-the-cuff.
It works fine but does lag sometimes. It’s the only public Nitter instance that is reliably up since nitter.net was shut down or whatever else happened to it.
Your error has happened to me also but it does eventually work.
"as designed", due to the gradual decrease in Twitter's functionality due to unknown reasons (probably trying to manipulate people into signing up to boost user count and ad revenue)
AI models for... spam bots? There are way better sources for human writing. Is this a reasoning Melon Husk gave for closing off the so-called "town square"? Pretty poor reason, if so.
This was a pretty long read and I didn't really get much from it. The format of a million tweets is awful.
tl;dr it patches the executable by having a shim dll that does the patch when it gets loaded. Pretty common in the game modding community. It finds where it needs to patch by scanning for a byte pattern.
What does the actual patch do? No idea, that's what I was waiting for and I never got it. I was expecting a disassembly comparison of the before and after.
Because the whole article can be written in 2 tweets but you need that social media “interaction”, so the author goes on talking about non essential things.
The crack itself is simple and smart to bypass the check by changing the public key, the only issue from what I have seen is there’s a lot of hardcoded stuff like the key and the functions numbers, so most likely it won’t work in future updates.
As far as I can tell - and I could be wrong having spent about five minutes reading the thread - the shim DLL basically swaps out a public key used by the applications key verification system for a different one so the keygen can create a valid licence key.
Without affecting any integrity checks in the target binary.
Ah, that makes sense, thanks! I was pretty confused about the string copy and what that was doing. Normally I'd expect it to be writing a byte array. Now it all makes more sense.
Is this akin to using LD_PRELOAD on Linux to hook something like __libc_start_main and modifying specific data in one of the data sections of the ELF binary or something?
That’s about 75% of reverse engineering work in IDA or Ghidra, to be fair: labelling/annotating shit, adding types to shit, and making sense of structs and other data types.
There’s extensions to both which automatically try detect such things from common libraries/known calls/etc which massively cuts down on the timesink.
https://threadreaderapp.com/thread/1782656618015904103.html?...
Archives:
https://archive.ph/rpFft
https://web.archive.org/web/20240423175847/https://threadrea...