Jump to content
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble

MSFN is made available via donations, subscriptions and advertising revenue. The use of ad-blocking software hurts the site. Please disable ad-blocking software or set an exception for MSFN. Alternatively, register and become a site sponsor/subscriber and ads will be disabled automatically. 


UCyborg

Banking apps and their root checking bul*****

Recommended Posts

Posted (edited)

The bank that I use decided they will implement mandatory 2FA authentication to access their web services - the second factor second being none other than a smartphone app. For now it's still possible to access it using certificate installed on the computer and the password, but smartphone app is going to replace the certificate soon.

So now you have to own a smartphone - to enter PIN code in the app every time to be able to login to the website on the computer, something that was possible without a fuss until recently.

Now what really p***ed me off, their app must have tripped on the busybox (apparently one of many checks for signs of rooted phone) that was pre-installed with my current custom ROM and also sometimes came in handy in the past. Having only encountered one such app until now (for authorizing online payments - and it wasn't mandatory, you could've opted for dedicated code generator device), that was happy as long as it didn't find su binary / SuperSU.apk, this one caught me by surprise.

OK, so busybox can be removed entirely. Or installed systemlessly (so it doesn't reside on /system partition) with help of Magisk, which facilitates providing root access, hiding it from apps that don't want to see it and providing means to be able to do other modifications without modifying files on /system partition.

This banking app seems to have flagged my phone on their servers during activation process, so now can't be activated at all. It must have taken its serial number, which can't be spoofed in practice I think. There's Xposed module that does it, but there's no way around Google's SafetyNet with activated Xposed Framework.

What a load of crap! So one's supposed to just buy new phone for one stupid app...which could function on the old one...if it wanted to.

Planned obsolescence in general is really strong there...let's buy a new smartphone every year or two. New one would just be bigger, clunkier and preloaded with tons of crap I don't want or need, that can't be removed without root access and since Google's fixing SafetyNet...

End of rant!

Edited by UCyborg

Share this post


Link to post
Share on other sites

I'd take the route of calling the bank to complain about it. I would hate it if my bank went that route. I do not have anything on my phone connected to financials in any way and prefer to keep it that way.

  • Upvote 1

Share this post


Link to post
Share on other sites

Welp, their support is useless and didn't even properly read what I wrote. Whatever, I'm not going to bother with them anymore. Their app happens to have the worst rating on Google Play, compared to the apps of other banks.

They can choose to block me and I can choose to go somewhere else. Even better with an option to avoid having to rely on smartphone app for such things.

Share this post


Link to post
Share on other sites

So I was checking out this other bank and their procedure to log onto their online services is even more convoluted. And looking at other banks' offerings...the more, I look, the less I'm sure where to go from here.

I forgot to mention, there is some extra glitch with Magisk on my device; Magisk normally checks the ro.build.tags prop and sets it to release-keys if it was set dev-keys or test-keys, custom ROMs have it set to one of the latter two. It's written in /system/build.prop file that is generated during build process, which may be modified with rw access to /system.

The glitch is when Magisk modifies it during runtime, getprop utility returns the updated value, but a programmatic check through Java still returns the old value unless you modify build.prop file directly.

I don't know whether that app checked build tags first or the presence of busybox binary, which, BTW, is actually present on certain official ROMs! :realmad: I just identified the relevant blocks of code by taking its APK file apart with APKTool. It looks like root checks span across both Java code and one of the bundled native libraries.

So the things that I identified are successfully hidden on my phone, at least undetectable by Native Root Checker and RootBeer Sample apps. I also tried registering with the previous version of the banking app, which, in logcat, specifically mentions "negative root check", but no luck, log indicates their server returned some error code.

Of course, they could be blocking older versions. Back to the current version, I also tried changing my device's fingerprint, didn't help neither.

The thing about blocking my phone's serial number is pure speculation on my part, but this could be it as part of its code does read it. I figured the serial number is passed to the Linux kernel via androidboot.serialno=xxx paramater by device's bootloader.

There's also possibility that some hole still exists through which root may be detected. One such hole is known, but can be avoided by using Magisk fork with modules functionality stripped, which I ended up installing, though I haven't found that it's actually used by the app.

I guess they could also block the numeric ID they give to their customers to activate the app, but then even using different phone wouldn't make a difference...

I also messed around with various versions of Android-x86 on my laptop. It has its own quirks. Good to know ART cache (Dalvik cache in older versions, but still residing in /data/dalvik-cache in newer versions) wasting a lot of space is the problem of Android 7.x in general. I haven't been able to pass SafetyNet test on it, not even the basic one, so there goes the idea of using PC port of Android for that stupid app.

Not much positive is written about passing SafetyNet on Android-x86 AFAIK, just some guy hinting using his Magisk module safetypatcher supposedly helps, which just changes phone's fingerprint in a different way during runtime. But since changing the fingerprint directly in build.prop isn't evidently a problem, since I could do it on my phone and still pass the check and the author of MagiskHide Props module, which also changes the fingerprint, says it won't help if one is unable to pass even the basic check, that's just another dead end.

Finally, removing Magisk on my phone = SafetyNet check not passing due to custom ROM
Downgrading to latest official ROM (Android 4.4.4) = inability to run the banking app at all since Android 5+ is required

  • Like 2

Share this post


Link to post
Share on other sites

They didn't ban my phone after all.

I did some modifications:

  • Flashed default LineageOS 14.1 boot image, previously used Magisk patched image, so no more root access in the OS. Full root access is still available in recovery mode.
  • Matched prop ro.bootimage.build.fingerprint with ro.build.fingerprint in /system/build.prop file. Newer Android versions complain about the device having internal error after boot if they don't match. I already took care of other sensitive props before that. ro.build.fingerprint must also match one of the certified devices' fingerprints, though the person that ported LineageOS to Xperia E3 already took care of that.
  • Added a boot script that does "setenforce enforcing". This puts SELinux in enforcing mode. The default on this port is permissive mode. SafetyNet fails if it detects permissive mode.

After doing this, SafetyNet check actually passed! And the troublesome app...activated without a hitch.

But now the camera doesn't work. Any app that tries to use it hangs. It's a known issue with this LineageOS port not working 100% correctly with SELinux in enforcing mode. Hopefully future build comes that addresses it. Camera was an issue with custom ROMs for this phone from the very beginning, it started with the lack of driver support from Sony for newer Android versions.

So what the heck helped? My bet is that the main issue was permissive SELinux. And how to safely test without locking oneself out? If it always talks to the server first before panicking, then the only safe offline test is not possible. If the server is tripped, restoring backup copy of app data wouldn't help. There is the small chance that more checks are in place only during activation process.

  • Like 1

Share this post


Link to post
Share on other sites
Posted (edited)

There's more broken stuff with SELinux enabled, can't browse the web (nothing shows where the content is supposed to be), the phone doesn't ring... SELinux must be properly configured by ROM author so enforcing mode doesn't block normal functions. Looks like those settings are baked somewhere in the boot image during compilation time.

I flashed Magisk patched boot image back and put SELinux back in permissive mode. I can still login to bank website! :D

Edited by UCyborg

Share this post


Link to post
Share on other sites

Its as if you need to get a dedicated phone just for the bank website. Like one that isn't even on a plan and you connect only using wifi or something.

Share this post


Link to post
Share on other sites
On 8/31/2020 at 4:56 PM, UCyborg said:

The bank that I use decided they will implement mandatory 2FA authentication to access their web services - the second factor second being none other than a smartphone app. For now it's still possible to access it using certificate installed on the computer and the password, but smartphone app is going to replace the certificate soon.

So now you have to own a smartphone - to enter PIN code in the app every time to be able to login to the website on the computer, something that was possible without a fuss until recently.

Now what really p***ed me off, their app must have tripped on the busybox (apparently one of many checks for signs of rooted phone) that was pre-installed with my current custom ROM and also sometimes came in handy in the past. Having only encountered one such app until now (for authorizing online payments - and it wasn't mandatory, you could've opted for dedicated code generator device), that was happy as long as it didn't find su binary / SuperSU.apk, this one caught me by surprise.

OK, so busybox can be removed entirely. Or installed systemlessly (so it doesn't reside on /system partition) with help of Magisk, which facilitates providing root access, hiding it from apps that don't want to see it and providing means to be able to do other modifications without modifying files on /system partition.

This banking app seems to have flagged my phone on their servers during activation process, so now can't be activated at all. It must have taken its serial number, which can't be spoofed in practice I think. There's Xposed module that does it, but there's no way around Google's SafetyNet with activated Xposed Framework.

What a load of crap! So one's supposed to just buy new phone for one stupid app...which could function on the old one...if it wanted to.

Planned obsolescence in general is really strong there...let's buy a new smartphone every year or two. New one would just be bigger, clunkier and preloaded with tons of crap I don't want or need, that can't be removed without root access and since Google's fixing SafetyNet...

End of rant!

Damn, that is complete BS!

I don't have a so-called "smart" phone (or dumb phone?) and never will. Or any cell phone at all. Landlines are superior at everything that matters on a phone, just like desktops are superior to tablets for everything that matters computing-wise.

If I had a bank that scummy, I would call them up and demand another way. Otherwise, I'd simply close my account and take my business elsewhere. Those unethical gits don't deserve two pennies from me.

 

I realize there are technical solutions like bluestacks or whatever, but as a matter of principle, I would refuse to participate in this scheme. It's part of a disturbing trend more and more banks are hopping on. Say you only have a landline and stand your ground.

Share this post


Link to post
Share on other sites

Hm, 2FA auth only applies when logging in on the website, but if you decide to use the app exclusively, you're still back at one factor.

I wanted to make use of the ability to scan the QR code on the bill for quick payment. While it went through, the app hung when returning to its main screen and couldn't do anything but force-close it.

Now here's the fun part, its data got corrupted in the process. When trying to login, it gave useless "No services found on this device" message. Restoring all of its data got it back into a working state (at least until it bugs again if you try to do the above). But here's another catch, it uses Android Keystore, so restoring its data folder is not enough, there are also files in /data/misc/keystore.

The relevant file names for each app that uses it start with "uid" or ".uid", where uid is the numeric user ID of each app. MiXplorer makes it easy to look them up when you open the dialog to change any file's owner or group.

I had the entire data partition backed up, so restoring everything wasn't a problem.

When I initiated the login procedure on the website now, the push notification didn't arrive on the phone, I had to login on the phone and only then the screen for confirming login on the website shows. I tested with another app if push notifications still worked in general. Firebase Cloud Messaging is used to send such notifications.

So something was sent out, but since it crapped out, it wasn't in sync anymore, so I guess the notification never reached my device. I wanted to see if I could re-activate the app, so did the same dance as the last time, it went through and notifications from the app started working again. Guess I'll use the app just to access the bank's website.

I noticed at later point that MagiskHide wasn't actually working after I got the banking app activated and put Magisk back. The app might not care about SafetyNet status anymore once activated. There's this common problem with MagiskHide that you have to re-enable it after the device boots before it actually starts working and while there's the boot script that could help (in this guide), it's still not reliable. I had that script from before and thought I found the right timing as it worked a while back, but apparently not. So the only reliable way is to do it manually after boot. One usually doesn't reboot the phone often, so it's not that much of a hassle.

Think I've had enough of such adventures for a while, so I'll leave things as they are.

BTW, BlueStacks doesn't pass SafetyNet checks, so it's not suitable for such apps.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...