Adfichter
adfichter@infosec.exchange
😡 So sieht die Agov Access App bei mir aus, die man in der Schweiz für digitale Behördengänge braucht. Und ja, es macht mich hässig...
Gestern an der interessanten Konferenz TRANSFORM zu Digital Public Infrastructure haben Bundeskanzlei, BAG-Vertreter:innen betont wie wichtig es sei, dass der Staat wie bei der Eisenbahn eine hoheitliche Infrastruktur schafft (auch wenn sie von Privaten gebaut wird).
Digital ist das natürlich etwas schwieriger zu übersetzen, wegen Datenhaltung, Hardware, Software und technologischen Abhängigkeiten. Dennoch: der Big Tech-Zwang bei der Avov Access App ist eine absolute Frechheit. Nur für iOs und Android.
Zwar gelobt die Bundeskanzlei Besserung und will diese verfügbar machen für alternative Betriebssysteme. Ob die eID am 1.12.2026 für Nicht-iOS/Nicht-Android-Usern zur Verfügung stehen wird, das steht noch in den Sternen.
Es kann nicht sein dass man von digitaler öffentlicher Infrastruktur redet, jedoch alle Einwohner:innen dieses Landes nötigt das Big Tech-Duopol (von den man sich ja ironischerweise allgemein emanzipieren will) zu installieren.
@GrapheneOS One more app to add for your "Wall of Shame".
Mein Text dazu folgt am Montag.
(morgen kommt was zu Überwachung und VÜPF 2.0, kleiner Teaser;))
7
2
0
@adfichter This app works on GrapheneOS with the exploit protection compatibility mode disabled and secure spawning disabled. The app does incorrect anti-tampering checks which are incompatible with our secure spawning feature due to it causing small differences in the address space and properties checked by their anti-tampering. The exploit protection compatibility mode has to force enable secure spawning to disable hardened_malloc and the 48-bit address space so it has to be disabled.
1
1
0
@adfichter Disabling secure spawning reverts to the standard Android Zygote-based spawning model where apps start as clones of the Zygote address space and memory. The Zygote spawning model reduces security by sharing the same state for probabilistic exploit protections including hardware memory tagging (MTE), ASLR, heap canaries, heap randomization and more. Android has a workaround to avoid weakening the security of stack canaries (SSP) but the rest can't really be worked around for it.
1
1
0
@adfichter Our secure spawning feature was never expected to cause any compatibility issues. We aren't aware of any legitimate compatibility issues as opposed to apps doing incorrect anti-tampering checks which make incorrect assumptions about non-stable OS implementation details. Due to these incorrect checks, these apps frequently break with new major Android OS releases. They often don't address it during Android's Developer Preview or Beta testing but rather weeks after the Stable release.
1
1
0
@adfichter Various banking apps used to ban GrapheneOS because the secure spawning feature had a different initial Java call stack. We addressed this by making the call stack match for secure spawning which fixed most of the compatibility issues. There are still minor differences which are possible for apps to detect if they're checking implementation details such as low-level system properties, the address space layout or how much is initially preloaded. We plan to work around all of that too.
1
1
0
@adfichter For now, you can disable secure spawning if you need to use this app on GrapheneOS. Turning it off disables it for every system process implemented with app_process including system_server and various privileged components such as the main Bluetooth process. We could provide a more granular way to disable it. We didn't anticipate anti-tampering checks causing compatibility issues and the toggle was only added as a way to test memory usage and app spawning time without it enabled.
1
1
0
@adfichter The anti-tampering checks done by these are inherently insecure and most are incorrect which leads to compatibility issues with future Android versions, GrapheneOS and even OEM Android forks. The reason we had to adjust the initial call stack for secure spawning to match the standard one is because some apps insecurely try to detect tampering via method hooking by checking the call stack. We can make a similar change for their low-level checks of the data in certain memory blocks too.
1
1
0
@adfichter @cxor The app will work if you turn off exploit protection compatibility mode and disable secure spawning. We don't recommend doing this because secure spawning is an important security feature and we mainly provided the toggle for testing memory usage and cold start app spawning time with vs. without it. We've considered moving the toggle to developer options and making it only last 1 reboot but we've kept it around due to these rare compatibility issues. See https://grapheneos.social/@GrapheneOS/116528377935838679.
0
0
0
V.a. ist es eine dreiste Lüge dass das Gerät gerooted sei.
3
0
0
phone-company
andree4live@mastodontech.de@jonasgraphie @adfichter @GrapheneOS
Ja, daher genau richtig...Aufklärung überall und wo es nur geht.
1
0
0
@andree4live It's caused by incorrect anti-tampering checks and can be worked around by disabling an important security feature added by GrapheneOS (secure app spawning), which we don't recommend. It's possible to use this app on GrapheneOS already but we plan to come up with a built-in workaround which avoids needing to turn off secure spawning. See https://grapheneos.social/@GrapheneOS/116528377935838679.
0
0
0
@jonasgraphie It's caused by incorrect anti-tampering checks and can be worked around by disabling an important security feature added by GrapheneOS (secure app spawning), which we don't recommend. It's possible to use this app on GrapheneOS already but we plan to come up with a built-in workaround which avoids needing to turn off secure spawning. See https://grapheneos.social/@GrapheneOS/116528377935838679.
0
0
0
Truls (Klarname)
truls46@mastodon.social@flozo @adfichter Die Einstellung kann man auch pro App ändern. Das muss man nicht systemweit machen. Aber ob es den gleichen Effekt hat, kann ich nicht sagen.
0
0
0
GrapheneOS
GrapheneOS@grapheneos.social@flozo @truls46 @adfichter The app has incorrect anti-tampering checks and can be used on GrapheneOS with secure spawning disabled, which we don't recommend. Secure spawning is an important security protection improving app and OS security. The per-app exploit protection toggle needs to be disabled rather than enabled since it depends on secure spawning. We've already worked around most of these anti-tampering checks and plan to work around the rest.
See https://grapheneos.social/@GrapheneOS/116528377935838679 for details.
0
0
0
@jonasgraphie @adfichter @GrapheneOS yup, nur weil der bootloader unlocked wurde, heisst das noch lange nicht, dass das gerät gerooted ist. Ausserdem ist es Sache der Benutzerin, ob sie der App auf einem gerooteten Gerät vertrauen will. Airlock 2FA macht es vor: die App ist vollständig benutzbar, es wird lediglich eine Warnung, danach ein nicht-intrusiver permanenter Banner angezeigt. Auch da ist es zwar falsch, dass das Gerät gerooted ist, aber immerhin gehen sie einem aus dem Weg. Leute, die sich die Mühe geben, ein selbst gewähltes OS auf einem Gerät zu installieren, werden die Warnung meines Erachtens korrekt interpretieren können.
2
0
0
@f @jonasgraphie @adfichter GrapheneOS uses a locked bootloader and has full support for verified boot. We expand verified boot to covering more than it does for standard Android. GrapheneOS adds many important privacy and security protections. It's far more secure than any OS permitted by the Play Integrity API or incorrect checks like this. The security feature this app is detects as tampering can be disabled to use it on GrapheneOS but we recommend leaving it on.
0
0
0
Und bei Graphene wird ja sogar der Bootloader wieder zu gemacht, wenn man es korrekt installiert....
1
0
0
Urs Naegeli 🇨🇭🇺🇦
unaegeli@swiss.socialBei e/OS/ übrigens auch, da funktioniert sogar die UBS-App. Nur bei iodéOS konnte ich diese nicht zum Laufen bringen.
2
0
0
@unaegeli @jonasgraphie @f @adfichter This app works fine on GrapheneOS with the important secure spawning feature it adds disabled. The app wrongly detects the security protection as tampering due to incorrectly written anti-tampering checks which make bad assumptions about internal implementation details they can detect by scanning properties and memory. See https://grapheneos.social/@GrapheneOS/116528377935838679 for details. We don't recommend turning off this important security protection added by GrapheneOS though.
1
0
0
@unaegeli @jonasgraphie @f @adfichter GrapheneOS is a privacy and security hardened OS greatly improving those compared to the Android Open Source Project. /e/ and iodéOS are not privacy or security hardened. Both reduce privacy and security compared to the Android Open Source Project. They both lag far behind on crucial standard privacy/security patches and don't fully ship them. They lack important standard protections. It's the opposite of GrapheneOS greatly improving patches and protections.
1
0
0
@unaegeli @jonasgraphie @f @adfichter We take great care to preserve compatibility with our privacy and security features. Unfortunately, many apps have memory corruption bugs detected by improved memory protections so we provide toggles to work around it. Hardware memory tagging is mostly opt-in for user installed apps due to how many bugs it finds in them, but we recommend users enable the global toggle for it. Our dynamic code loading restrictions are similarly opt-in for user installed apps.
1
0
0
@unaegeli @jonasgraphie @f @adfichter Banking and government apps have the unique issue of including misguided anti-tampering checks trying to detect a modified app or OS. It's an insecure approach and can be easily bypassed by attackers. These anti-tampering checks often wrongly detect added security protections as tampering. That's what's happening in this case. We have a way to work around it but it's not a per-app toggle since we didn't anticipate apps going out of the way to detect it.
1
0
0
@unaegeli @jonasgraphie @f @adfichter We already fixed most compatibility issues caused by anti-tampering checks for our secure spawning feature by making the call stack match the standard Android Zygote spawning approach. There are rare cases of apps still having a problem with it due to other differences they can detect and we plan to eliminate those compatibility issues too. We shouldn't have to do this and what these apps are doing is incorrect and incompatible with future Android releases.
0
0
0
Roland Lötscher
rolandlo@fosstodon.orgDas ist unschön, aber immerhin kannst du dich auf AGOV anstatt mit der App auch mit einem Sicherheitsschlüssel einloggen. Der Token2 PIN+ Mini-C FIDO2 Key hat mich keine 24 Franken gekostet (inklusive Versand) und hat mit fido2-manage gar ein FOSS Management Tool, das auf Linux läuft und bei mir ohne Weiteres funktionierte.
1
0
0
@rolandlo @adfichter @GrapheneOS Das war bei mir dieselbe Erfahrung, FIDO2-Stick lief entgegen der Erwartung einwandfrei und ohne Zusatzaufwand unter Linux und wird nächstes Jahr zur Steuererklärung wieder rausgekramt. Es kann aber trotzdem nicht sein, dass eine ältere AGOV-Version unter GrapheneOS funktioniert, aber neuere nicht mehr.
1
0
0
@datacyclist @rolandlo @adfichter It's caused by incorrect anti-tampering checks and can be worked around by disabling an important security feature added by GrapheneOS (secure app spawning), which we don't recommend. It's possible to use this app on GrapheneOS already but we plan to come up with a built-in workaround which avoids needing to turn off secure spawning. See https://grapheneos.social/@GrapheneOS/116528377935838679.
FIDO2 and passkeys work well on GrapheneOS so you should also be able to use that approach on it.
0
0
0
chris 🔓 Digital Sovereignty
chrispy@chaos.social@adfichter @GrapheneOS die AGOV Access App mit LineageOS gar nicht erst versucht 🤷♀️
Aber zumindest mit Linux und einem FIDO2-Schlüssel erfolgreich, mit viel Durchhaltewillen und Identifikation am Schalter (strikte Reihenfolge der Etappen zu beachten!)
https://help.agov.ch/index.php?c=register&l=de
-> diese Anleitung muss definitiv verständlicher und mit den Anleitungen der Kantone harmonisiert werden!
1
0
0
@chrispy It's caused by incorrect anti-tampering checks and can be worked around by disabling an important security feature added by GrapheneOS (secure app spawning), which we don't recommend. It's possible to use this app on GrapheneOS already but we plan to come up with a built-in workaround which avoids needing to turn off secure spawning. See https://grapheneos.social/@GrapheneOS/116528377935838679.
FIDO2 and passkeys work well on GrapheneOS so you should also be able to use that approach on it.
0
0
0
@adfichter @GrapheneOS Bei der 2FA App Futurae die gleiche Meldung. Auf einem GrapheneOS Handy ohne Google Dienste kommt die Meldung das die Google Dienste nicht vorhanden sind, die App scheint aber zu funktionieren. Auf einem GrapheneOS Handy mit Google Dienste aktiviert kommt die Meldung dass das Handy gerootet ist scheint aber auch zu funktionieren. TWINT(prepaid) z.B. meldet auch bei jedem Start das die GDienste fehlen, funktioniert aber problemlos.
1
0
0
@DasPom @adfichter GrapheneOS displays a notice if apps use the Play Integrity API and supports blocking using it to work around apps which ban a result showing it's not a stock Google Mobile Services OS but permit not successfully providing a result.
AGOV app has an incorrect anti-tampering check which detects our secure spawning. It's possible to disable that but we don't recommend it. We're going to fix it by eliminating the differences it detects. See https://grapheneos.social/@GrapheneOS/116528377935838679 for details.
0
0
0
Stefan Gloor
stgl@infosec.exchange@unaegeli @jonasgraphie @f @adfichter @GrapheneOS
Mich warnt die UBS-App, dass sie bald nicht mehr funktionieren wird auf meinem GrapheneOS mit gelocktem Bootloader.
1
0
0
@stgl AGOV is detecting our secure spawning feature and can be used on GrapheneOS with it disabled. It's an important security feature and doesn't currently have a per-app toggle so we don't recommend disabling it. We've already shipped an improvement hiding the main difference between secure spawning and standard Android Zygote spawning by making the Java call stack match due to misguided anti-tampering checks. We have changes planned to address other cases.
See https://grapheneos.social/@GrapheneOS/116528377935838679.
0
0
0
Toke Høiland-Jørgensen
toke
1
0
2
GrapheneOS
GrapheneOS@grapheneos.social@toke @adfichter Standard Android spawning uses fork from the Zygote with a bunch of stuff preloaded to share more memory. This breaks ASLR and other probabilistic protections since it's all shared between the Zygote process, system_server, user installed apps and many system components implemented with app_process. Android implements a large portion of userspace with app processes. It's most of the high level base OS. Some are in the regular app sandbox while others are more privileged.
1
0
0
@toke @adfichter There's a bunch of stuff that's normally preloaded which gets loaded on demand with secure spawning instead. There are also things which simply aren't present in memory because it's only set up in the Zygote. None of this impacts correctly written apps not looking at internal implementation details. Unfortunately, these anti-tampering checks do very strange and incorrect things as part of their misguided goal of detecting tampering. It's completely insecure and has no benefit.
1
0
0
Toke Høiland-Jørgensen
toke
1
0
2
GrapheneOS
GrapheneOS@grapheneos.social@toke @adfichter We could make a per-app toggle for secure spawning. However, the Zygote has all of our per-app hardening features enabled so ones requiring a fresh address space to disable can't be disabled without secure spawning. If an app has a memory corruption bug requiring disabling hardened_malloc or can't run with a 48-bit address space then it will require secure spawning unless we have a non-hardened Zygote which we don't want to. It would also mean leaking Zygote layout to the app.
1
0
0
@toke @adfichter Zygote doesn't have much attack surface but we don't really want to have a compatibility approach for this depending on leaking the layout to specific apps which would then also know each other's layout. It's different than exploit protections which only protect apps from attacks. We already resolved the issue of apps checking the call stack to try to detect hooking and we should be able to resolve any other compatibility issues from anti-tampering checks for secure spawning.
1
0
0
@toke @adfichter It would be possible to apps to go out of the way to detect secure spawning in a way we couldn't prevent but they're not actually trying to detect it, they're just doing all kinds of cargo cult security checks by checking that things are the way they were on devices they tested which happen to be different when using exec after fork. We have a good idea about what the main remaining compatibility issue is and we should be able to fix it fairly easily. We just have a lot to do...
1
1
0
@toke @adfichter Our most recent release (2026050400) hasn't gone to the Stable channel due to incorrect anti-tampering checks which crash with this change:
> bionic: clamp the minimum size of the random guard region we add between the stack and pthread_internal_t (thread-local storage and other sensitive data) for secondary stack randomization to the page size to guarantee we always add a guard page protecting pthread_internal_t from stack buffer overflows
We fixed it for today's release.
1
1
0
@toke @adfichter Banking apps often use third party SDKs which claim to detect tampering. They do all kinds of invasive checks depending on internal implementation details. It's highly insecure and serves no actual purpose. The latest example we ran into is that apps are scanning /proc/self/maps for the first anonymous mapping named stack_and_tls:main which is where Android puts the pthread_internal_t and other per-thread data for the main thread. Other threads have their stack there too.
1
1
0
@toke @adfichter In Android, it's a mapping with a guard page at both ends with the stack, pthread_internal_t, static thread-local storage and libgen buffers in between the guard pages. We put a randomized guard region at the top of the stack to have secondary stack randomization and it also protects pthread_internal_t, etc. from stack buffer overflows. We were already rounding up to page size but the random size could be 0 which resulted in no guard. 2026050400 clamps minimum size to 1 page.
1
0
0
@toke @adfichter We also randomize the top of the stack for secondary threads by up to 1 page below the gap to have the lower bits randomized. It doesn't break anything because it's normally space used by pthread_internal_t and we added reserved space for it and the random gap.
Clamping to 1 page minimum resulted in adding a redundant guard to the main thread stack's pthread_internal_t / TLS region since the stack there is 0 size which is also the case for self-allocated secondary stacks.
1
0
0
@toke @adfichter That resulted in having a PROT_NONE page called anon:stack_and_tls:main page in /proc/self/maps followed by the area with pthread_internal_t, thread-local storage and libgen buffers. The anti-tampering checks and obfuscation done by these apps is doing something with that data and it crashes trying to access the guard. It's a nice example of how horrific these checks are. We've had a lot of problems caused by them which have certain security improvements into a hassle.
2
0
0
@toke @adfichter Facebook's React Native has a buggy stack overflow check which breaks if the minimum stack guard size (the one below the stack to catch stack overflows) is raised from 4k to 64kiB as required by the AArch64 ABI for the default stack probe size of 64k. We enable stack clash protection ourselves and use the default 4k probes although it's really meant to be 64k on 64-bit ARM in the ABI, but too many things use 4k themselves so 4k is the safe value. We still want a 64k guard.
0
0
0
Toke Høiland-Jørgensen
toke
1
0
2
GrapheneOS
GrapheneOS@grapheneos.social@toke @adfichter We also could have fixed compatibility with the guard page change we made in our most recent release by changing the name of guard part of the mapping. We were actually giving it a separate name but Android started naming the whole stack in 1 place at the end instead of naming the components of it separately which was overwriting our name. We dropped our code setting separate names for today's release too. Nothing should be inspecting and accessing memory that way though...
1
0
0
@toke @adfichter Their code does all kinds of stuff like this depending on internal memory layout details of Bionic. It shows why us making important security improvements which are entirely correct and compatible with correct code can cause problems. There's no way an app should be messing with the internal libc pthread_internal_t struct and thread-local storage. It's ridiculous. It means adding or reordering fields would likely break it too. These apps often break with major Android releases.
1
0
0
@toke @adfichter It's very common for these banking and government apps to stop working with a new major Android release. They start getting a trickle of negative reviews about it with the Developer Preview and Beta releases which build up into a regular stream of negative reviews until they're flooded with them after it's a stable release. They sometimes only deal with it weeks after a stable major release of Android. We just have to work around this stuff ourselves as they won't care.
1
0
0
Toke Høiland-Jørgensen
toke
1
0
0
GrapheneOS
GrapheneOS@grapheneos.social@toke @adfichter We're doing our best to work around the horribly incorrect code in these apps but it's difficult to deal with all of it.
People often wrongly blame the Play Integrity API even though we show a user-facing notification for that to end users. We regularly have requests to add more apps to our Play Integrity API list at https://grapheneos.org/articles/attestation-compatibility-guide even though it's not the problem.
It's hard to get reliable reports to figure out which apps have these issues and then hard to deal with.
1
0
0
@toke @adfichter The apps are often region locked on the Play Store which can make it a pain to even obtain them for testing. We often can't trigger the checks because we lack a way to make an account and log into it. The apps are typically extremely obfuscated and doing all kinds of horrific things depending on internal OS implementation details including the layout of libc structs and much more. It's often difficult to determine what the apps are doing wrong and how we could work around it.
1
0
0
@toke @adfichter We've spent an enormous amount of time dealing with this stuff instead of working on improving privacy and security. Adding low-level hardening features for userspace is heavily held back by this since we need to retain near perfect compatibility with horribly written apps doing all kinds of incorrect things. It has substantially slowed down progress on GrapheneOS. Many features have had to be deferred and we have to put a lot of time into resolving rare compatibility issues.
2
0
0
@toke @adfichter We haven't flipped the switch on enabling memory tagging by default for user installed apps since it uncovers an enormous number of memory corruption bugs. That's why that's an opt-in toggle in Settings > Security > Exploit protection instead of the default with reliance on per-app opt-out to deal with it. Memory tagging at least makes nice reports clearly showing it was caught by memory tagging. We could potentially put this into the setup wizard to explain it there.
0
0
0
1
0
0
RideDon'tSlide
ridedontslide@social.tchncs.de@adfichter @GrapheneOS I reached out to the agency providing the solution and to my surprise I got a nice reply that they acknowledge the need to support GrapheneOS and that they added it to the backlog of the company developing the app! They couldn't commit to a timeline, however.
Feel free to DM me if you want more details.
1
0
0
@ridedontslide @adfichter We can likely work around the issue ourselves. We know it's caused by the app being incompatible with our secure spawning feature and we already know the main issue with these anti-tampering SDKs which is causing compatibility issues. We need to figure out how to work around it. There's a high chance working around the issue we know about will solve it. It's possible to disable secure spawning to use the app but we don't recommend that.
1
0
0
RideDon'tSlide
ridedontslide@social.tchncs.de@GrapheneOS @adfichter Just in case it helps anyone, I quickly tested it with secure app spawning disabled and compat mode on but the issue @adfichter describes persists. These are the official OS requirements for the app: https://help.agov.ch/?c=myphone&l=en
It says installation exclusively from Play Store. I installed it from aurora store, so could it be a Play integrity issue in my case?
1
0
0
@ridedontslide @adfichter You need to have the per-app exploit protection compatibility mode disabled, not enabled. If it's enabled, that force enables secure spawning because the Zygote process has all our per-app hardening features enabled and cloning it will result in them being enabled. A couple of them can't be disabled dynamically (hardened_malloc and extended address space) so the toggles for those including the main compatibility mode toggle force enables secure spawning for that app.
0
0
0
@adfichter @GrapheneOS die Fehlermeldung auf dem Screenshot ist schlicht unzutreffend - GrapheneOS ist nach seiner Installation nicht im Root-Modus. D.g., die Interpretation des Ergebnisses eines Aufrufs des Play Integrity API durch den APP Entwickler ist falsch. Richtig ist, dass die Firmware nicht von Google zertifiziert ist.
1
0
0
@opinonToo @adfichter This isn't a case of the Play Integrity API being used but rather an app with an incorrect anti-tampering check which thinks the more minimal initial state of app processes on GrapheneOS due to secure spawning (exec-based spawning) indicates tampering. We already mostly addressed this issue by changing the call stack for secure spawning to match Android Zygote spawning but it isn't fully solved since some apps look at certain internal properties/memory that's different.
0
0
0
@Rairii @GrapheneOS @adfichter @toke In general; doing shit like checking the memory layout of libc structs should be an instant ban criteria in the PlayStore. That's basically malware territory
0
0
2