Most active commenters
  • alephnerd(3)
  • (3)

87 points quyleanh | 26 comments | | HN request time: 1.805s | source | bottom
1. quyleanh ◴[] No.43502427[source]
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...

2. petesergeant ◴[] No.43534248[source]
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.
replies(2): >>43534580 #>>43534814 #
3. lmz ◴[] No.43534580[source]
I think some people pointed to them as the vendor behind the home grown system, and this is their denial.
4. Onavo ◴[] No.43534814[source]
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.
replies(2): >>43535705 #>>43535979 #
5. jjani ◴[] No.43535705{3}[source]
> 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.

replies(2): >>43535821 #>>43536278 #
6. alephnerd ◴[] No.43535762[source]
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-...

replies(1): >>43536648 #
7. ◴[] No.43535821{4}[source]
8. agos ◴[] No.43535979{3}[source]
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
9. alephnerd ◴[] No.43536278{4}[source]
Grab isn't a good example of an "everything app". Zalo is probably the closest to WeChat and Line.
replies(1): >>43542960 #
10. a012 ◴[] No.43536286[source]
The banking apps exploited non-public APIs to provide “protection” for users, it doesn’t sound right
replies(1): >>43536302 #
11. alephnerd ◴[] No.43536302[source]
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.

replies(1): >>43537874 #
12. NotPractical ◴[] No.43536648[source]
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?
13. bradyriddle ◴[] No.43536835[source]
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.

replies(3): >>43537050 #>>43537125 #>>43537564 #
14. ◴[] No.43537050[source]
15. saagarjha ◴[] No.43537125[source]
There’s not really any way to stop it, considering Apple’s apps need to make these calls.
replies(1): >>43539764 #
16. musjleman ◴[] No.43537447[source]
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".

replies(1): >>43537719 #
17. musjleman ◴[] No.43537564[source]
> 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.

replies(1): >>43539576 #
18. bri3d ◴[] No.43537719[source]
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.

19. Zak ◴[] No.43537874{3}[source]
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.
20. bradyriddle ◴[] No.43539576{3}[source]
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);

replies(1): >>43539860 #
21. Rohansi ◴[] No.43539764{3}[source]
Surely Apple could just make those libraries inaccessible to third party apps. Why would they be required to make them accessible to all apps?
replies(1): >>43540200 #
22. freeone3000 ◴[] No.43539860{4}[source]
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.
23. saagarjha ◴[] No.43540200{4}[source]
Because their public frameworks depend on it.
replies(1): >>43541698 #
24. ◴[] No.43541698{5}[source]
25. jjani ◴[] No.43542960{5}[source]
Thanks. I think Zalo's only big in Vietnam, so we're at one example outside of China, where the rules have never been the same anyway. GGP's premise doesn't seem to hold up, though I can see the idea of banks getting exceptions being potentially more accurate.

Though if it's similar to Line I wouldn't even count Zalo either, as said, from what I've seen with Line it doesn't have an app-store-in-app, all functionalities are predetermined and preinstalled. It just does a lot of things, but that in itself doesn't go against any App Store rules.