5 ms·

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 be

by alin23 2y ago

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%20a%20macOS%20app 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. I have that kind of protection in Lunar (https://lunar.fyi/ https://lunar.fyi/) and Clop (https://lowtechguys.com/clop https://lowtechguys.com/clop) and it seems to be good enough as they have no recent cracks.

xyst 2y ago
> ... it seems to be good enough as they have no recent cracks. challenge accepted
- eps 2y ago
  Yeah, the GP should've not said that.
bobmcnamara 2y ago
Sometimes fixing integrity checks can be as simple as replacing the failure case with nops :)
doix 2y ago
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.
reactordev 2y ago
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…
- alin23 2y ago
  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.
int3 2y ago
seems like crackers could just patch the app code that detects this, no?
- alin23 2y ago
  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.
  - internetter 2y ago
    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 https://shottr.cc/s/1vQa/SCR-20240423-re6.png
    - ghostpepper 2y ago
      > 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.
      - internetter 2y ago
        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.

by alin23 2y ago

xyst 2y ago

> ... it seems to be good enough as they have no recent cracks. challenge accepted

eps 2y ago
Yeah, the GP should've not said that.

bobmcnamara 2y ago

Sometimes fixing integrity checks can be as simple as replacing the failure case with nops :)

doix 2y ago

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.

reactordev 2y ago

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…

alin23 2y ago
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.

int3 2y ago

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

alin23 2y ago
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.
- internetter 2y ago
  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 https://shottr.cc/s/1vQa/SCR-20240423-re6.png
  - ghostpepper 2y ago
    > 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.
    - internetter 2y ago
      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.