Prevents TrollStore detection by modifying bundle IDs#923
Conversation
|
This looks like an interesting approach. My fear however is that there may be exploits that can list all installed app ids instead of just being able to probe against pre-set identifiers. I'm not fully sure how CVE-2025-31207 worked in this regard... |
|
From what I see in the writeups (1, 2) I am able to find, it seems these apps are all exploiting |
|
So why not directly use an existing bundle instead? For example, com.apple.tips. This would also allow us to replace TrollHelper in the process to refresh the icon cache (after other TrollStore-installed apps have their type changed to user). Yeah, I'm already doing that — just by directly modifying the bundle ID. |
|
@invalidunit This removes TrollStore's trace, but not common TrollStore-installed apps such as Filza. As you can see in publicly reversed CVE-2025-31207 exploits, they always try to smell a list of bundle IDs, such as com.opa334.TrollStore, org.coolstar.SileoStore, com.tigisoftware.Filza, etc. |
|
Sorry, my bad. I didn't read it carefully. |
Hey @opa334, I’ve been working on a TrollStore stealth mode idea and wanted your take on it.
Lately more apps seem to detect TrollStore installs by abusing CVE-2025-31207, so this patch tries to invalidate that without having to bother Apple.
Basically this updates TrollStore’s bundle ID from
com.opa334.TrollStoretocom.opa334.TrollStore.TS_<random>. It also gives users a Stealth Install option for their IPAs: bundle ID gets the same random suffix treatment, and URL schemes are stripped. Normal install is still kept because some IPAs may break when Info.plist is patched.For updating, users currently need to open the new TrollStore.tar once in TrollStore, let it update, then do it again; on the second update, TrollStore reinstalls itself with the stealth suffix.