Technical Analysis – Improper Use of Private iOS APIs in Vietnamese Banking Apps
25 comments
·March 28, 2025bradyriddle
musjleman
> Are they able to load a .so/dylib file during runtime and just call a method on it as long as they know the name of the method?
Yes, usually that's the entire point of an .so/.dylib/.dll - to load it and call it's functions by name?
> How does iOS even allow that? How does an iOS even get to load those files? Seems like that would be locked down.
Because it's something that higher level apple interfaces might rely on. It's not a security issue in the first place - if you submit an app obviously using them the message you get is:
> The use of non-public APIs is not permitted on the App Store because it can lead to a poor user experience should these APIs change.
bradyriddle
Man, this is gonna reveal some ignorance. But here goes. Please correct me where I'm wrong
.so/.dylib/.dll's typically get linked at load time, right? Like we aren't all manually loading dylibs in our source code. I guess I'm surprised on a platform as locked down as ios that they even allow you to link anything at run time.
chatgpt gives me this snippet but I have no way of knowing if this is roughly how it would look.
Class SBApplication = objc_getClass("SBApplication");
SEL launchSel = sel_registerName("launch");
id app = [SBApplication getAppWithBundleID:@"com.example.app"];
objc_msgSend(app, launchSel);
freeone3000
You can put in an autoload section and the runtime linker will load it for you, but you absolutely can load a DLL and its symbol names at runtime. Usually this is done for boring reasons like compatibility with multiple versions of an external library.
null
saagarjha
There’s not really any way to stop it, considering Apple’s apps need to make these calls.
quyleanh
Original hightlight from @opa334, developer of TrollStore [0]. There are also some sharing about that on his page like sandbox escape published by @wh1te4ever [1]
0: https://infosec.exchange/@opa334/114224756352953362
1: https://gist.github.com/wh1te4ever/c7909dcb5b66c13a217b49ea3...
a012
The banking apps exploited non-public APIs to provide “protection” for users, it doesn’t sound right
alephnerd
It's due to regulatory mandates around device fingerprinting and biometrics.
VN is in the process of rolling out a China style biometrics validation system.
Zak
A quick web search of the list of apps it's checking for suggests it's jailbreak-related, not general fingerprinting. Only banks get to escape Apple's restrictions, not end-users.
alephnerd
Sadly, it goes well beyond BIDV and Agribank as well. There is a lot of similar hacky fingerprinting done by all the Vietnamese banking apps.
My understanding is it's because there was some regulatory change in the last 1-2 years requiring identity fingerprinting using banking apps, and partially related with the new biometrics rollout [0]
[0] - https://xaydungchinhsach.chinhphu.vn/huong-dan-cai-dat-sinh-...
NotPractical
So the law is now requiring that you find zero day exploits in iOS in order to make a banking app? Are there banking websites you can use instead? Are criminals incapable of using these websites for malicious purposes?
musjleman
Showing a 5000$ bounty example of "enumerating all apps" sounds a bit disingenuous when this is more of a "check if this exact app by bundle name was installed not through store.
I also don't think that this deserves to be called anything as scary as an "zero day exploit", "sandbox escape".
bri3d
There seems to be some weird beef in the background here with the TrollStore developers and Verichains, but Verichains come out looking much better here by naming the exploit what it actually is rather than misleading puffery around “sandbox escape 0days!!!111”
I think app enumeration info leaks generically might be eligible for that bounty, though, so mentioning it doesn’t seem too wild.
petesergeant
So, the post author makes software for checking if bad apps are running on the phone, and is complaining that the banks are using their own home-grown system that they say violates Apple’s rules for checking for malicious apps, rather than doing is safely like the software the author sells does.
lmz
I think some people pointed to them as the vendor behind the home grown system, and this is their denial.
Onavo
For these sort of large, well connected, or state owned companies in Asia (banks, big local unicorns etc.), Apple has a lot of carve-outs and exceptions (see do-everything apps that contain mini app stores). They have to play nice else they find themselves "under investigation" or worse lose access to the entire market. There's no rule of law for them to litigate over breach of contract.
jjani
> Apple has a lot of carve-outs and exceptions (see do-everything apps that contain mini app stores)
Which ones are you thinking of? Does Grab operate this way?
The China case is well-known, but that's really its own beast. KakaoTalk (Korea), while more of an 'everything' app than those in the West, is still a far cry from containing a mini app store. A user can't choose to add any new functionality by installing something - it's all included right from the get-go. My (limited) experience with Line (Japan, Taiwan, Thailand) is similar. So I'm curious if there's any non-Chinese apps you can name.
FWIW I'm not arguing against your fundamental premise, would just like to know which do-everything apps you mean.
alephnerd
Grab isn't a good example of an "everything app". Zalo is probably the closest to WeChat and Line.
null
agos
there might be no rule of law but it's important to point out these exceptions because it weakens Apple's position when they harass other developers with the excuse of maintaining whatever it is that the walled garden provides
I'm curious about this. I'm familiar with reversing http api calls using a mitm proxy. But this ain't that.
Are they able to load a .so/dylib file during runtime and just call a method on it as long as they know the name of the method? How does iOS even allow that? How does an iOS even get to load those files? Seems like that would be locked down.