by nharada on 4/23/24, 2:58 PM with 87 comments
by msla on 4/23/24, 6:01 PM
by stong1 on 4/23/24, 8:13 PM
I also do reverse engineering streams on YouTube: https://www.youtube.com/basteg0d69
by redbell on 4/24/24, 9:11 AM
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.
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 :)
by alin23 on 4/23/24, 8:58 PM
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/) and Clop (https://lowtechguys.com/clop) and it seems to be good enough as they have no recent cracks.
by WirelessGigabit on 4/23/24, 6:35 PM
by pests on 4/24/24, 3:00 AM
by hermitcrab on 4/23/24, 7:36 PM
by smolsky on 4/24/24, 12:52 AM
P.S. who remembers the legendary Phrozen Crew cracks? They were minimal byte patches that often toggled a conditional jump in an MS-DOS app/game...
by lossolo on 4/24/24, 4:08 PM
in 2024"
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.
by cedws on 4/23/24, 11:02 PM
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...?)
by lionkor on 4/24/24, 5:45 AM
Thanks for sharing, it was interesting, but wow that's a bad format and bad writing.
by hruzgar on 4/23/24, 5:36 PM
by ptsneves on 4/23/24, 8:51 PM
by skilled on 4/23/24, 5:02 PM
by can16358p on 4/23/24, 7:19 PM
Is that the case or is it a bug?
by doix on 4/23/24, 5:13 PM
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.
Someone please correct me if I'm wrong.
by brcmthrowaway on 4/24/24, 1:19 AM