Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reverse engineering a software crack

twitter.com

Post reply on HN
Print view View original

41–50 of 95 posts

Re: Reverse engineering a software crack

#41

Post by alin23 »

reactordev wrote: post #38
alin23 wrote: post #33

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…

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 inspectio…

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.

Re: Reverse engineering a software crack

#42

Post by int3 »

alin23 wrote: post #33

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…

seems like crackers could just patch the app code that detects this, no?

Re: Reverse engineering a software crack

#43

Post by axoltl »

ptsneves wrote: post #30

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?

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.

Re: Reverse engineering a software crack

#44

Post by alin23 »

int3 wrote: post #42
alin23 wrote: post #33

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…

seems like crackers could just patch the app code that detects this, no?

For sure, it’s just a bit more effort to reverse the app binary and find that part of the code. Enough effort to deter most crackers apparently.

Re: Reverse engineering a software crack

#45

Post by Nextgrid »

WirelessGigabit wrote: post #12

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.

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).

Re: Reverse engineering a software crack

#47

Post by 3abiton »

tamimio wrote: post #22
hermitcrab wrote: post #20

If anyone is interested in crackers and their motivation, you might find this interview interesting: https://successfulsoftware.net/2011/04/07/interview-with-a-c...

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.

In the android space, most app cracking is rather easy. Surprisingly.

Re: Reverse engineering a software crack

#48

Post by grishka »

3abiton wrote: post #47
tamimio wrote: post #22

Earlier quoted context omitted.

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.

In the android space, most app cracking is rather easy. Surprisingly.

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.

Re: Reverse engineering a software crack

#49

Post by cedws »

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...?)

Re: Reverse engineering a software crack

#50

Post by internetter »

alin23 wrote: post #44
int3 wrote: post #42

Earlier quoted context omitted.

seems like crackers could just patch the app code that detects this, no?

For sure, it’s just a bit more effort to reverse the app binary and find that part of the code. Enough effort to deter most crackers apparently.

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

Post reply on HN