Disclaimer: this article discusses understanding whatever DRM is leftover in an already cracked Jailbreak tweak. This is for educational purposes only. I will not provide the pirated tweak.
Back in the days of iOS 6, we had App folders, but they were far more limited than in modern iOS. Namely, you were limited to 12 apps in a folder. This means you had to create many app folders in order to organize your apps, instead of nowadays where you can have multiple pages of 9 apps within each folder.
However, there was a nice tweak that solved this problem called FolderEnhancer. This paid tweak allows you to have multiple pages of 12 apps within a single folder. There is one huge problem though in 2026: the Cydia Store has been offline for years. This means that not only are we unable to purchase the tweak, we are also unable to authorize new devices if we did purchase the tweak in the past. (As of this writing, both Google and Facebook login are broken, but Facebook has been broken for far longer).
Thus, on any devices purchased since the last authorization window (Facebook, in my case), I am SOL, and the only way I am able to obtain this tweak is unfortunately via piracy.
All is fine and dandy, until…
So I grab my archive of an old piracy repo, install FolderEnhancer from it, and I was off on my merry way. Or so I thought. One day, I open my old iPhone 4S running iOS 6, and open a folder, only to find the following message:
Piracy Detected.
You appear to be using an illegal copy of FolderEnhancer.
If you wish to continue using FolderEnhancer, you must purchase it via the Cydia Store.
Your device will now restart to Safe Mode so that you may either purchase or uninstall this software."
(Todo: include a screenshot of the actual dialog)
Once you dismiss the dialog, the device resprings into Cydia Substrate Safe Mode as described, rendering the device partially unusable until you uninstall the tweak. I have encountered this multiple times over the years, but somehow the tweak actually did work for a while each time before throwing this error. Since I really did not want to give up on the folder arrangement that I had set up, I fired up my copy of Ghidra and got to work figuring out how the DRM worked. Or at least, what was left of it.
Reverse engineering with Ghidra
The first order of business was to get the dylib files. I grabbed the deb from my archive and extracted it to reveal the dylib files, of which there are three:
- FolderEnhancer.dylib
- libFolderEnhancer.dylib
- libFolderEnhancer.lt42.dylib
I loaded all three dylibs and hit Analyze. The first thing I did after that was to do a Memory search of the piracy notice string, which brought me to the actual message in libFolderEnhancer.lt42.dylib.
From there, I could use Find References to find the code that referenced that string, namely the method that initializes the dialog displaying the message.
I also noticed that the method seemed to be responsible for drawing the first run dialog, but it wasn’t immediately clear how it decided which message box to show.
I did see that it was trying to pull some config from /var/mobile/Library/jp.ashikase.folderenhancer.plist in order to determine whether this was the first run of this tweak.
Once I had identified that function, I could trace the call tree and find which functions were calling it.
There were two such references: FUN_00014b08 and FUN_00014b34.
I could see that in turn, both were called by FUN_0000b1d8.
FUN_0000b1d8
This particular function was interesting: it seemed to do a bunch of stuff and then call the two methods earlier depending on some conditions, before hooking the methods in SpringBoard via Cydia Substrate.
After converting some C-string initializations that got decompiled to char array assignments, the key "SBPWCTime" came out.
Since I had already checked the jp.ashikase.folderenhancer.plist and saw that the only keys were currentVersion and firstLoad, I knew that it had to be elsewhere.
The decompiled code wasn’t perfectly straightforward, but I assumed it could have been in com.apple.SpringBoard.plist, and lo and behold, there it was.
The value seemed to be some large integer that could have been in range for a UNIX timestamp.
Putting the timestamp into a converter, out it spit a date in February of this year, which is approximately when I originally set up the device.
Digging deeper into the function, I realized that it was pulling the value out of the config, ensuring that it was the correct type, and then loading the current timestamp using gettimeofday.
Subtracting the tv_sec member of the struct from the timestamp from the file, the code then compared the value to a magic number 0x127500, which works out to the number of seconds in 14 days.
The value of this comparison is then written to some global variable which is then read in some code that calls the dialog drawing routine above…
Bingo! This was the source of the grace period that seemed to be in effect for the cracked tweak.
The fix
I could patch the code to skip the checks (which I briefly attempted, without success)… or I could just set SBPWCTime to a number far in the future… like January 19, 2038…
This is what I ultimately did. I set the value to 2147483647 and resprung the device.
It worked! I expect this fix to work until time_t rolls over in the year 2038 (not too far in the future), but I assume I’ll have bigger problems by then…
Follow-ups
I actually want to compare the pirated version with the original version to see what the original cracker changed. Surely there was more DRM before, but this one was overlooked since it had a delayed effect (14 days). I’ll need to pull a copy from one of my old devices that was actually authorized to use this tweak… assuming I didn’t uninstall the tweek due to an auth server being taken offline or something…