Play integrity android Maui implementation?

[gabsamples6]

When it comes to security you are pretty much on your own unless you want to spend a fortune on those third parties. Looking to integrate play integrity and the equivalent for iOS but finding some samples is pretty hard. Apart from the official reference link has anyone done it before and willing to share info or gotchas or anything …

many thanks

[scottkdavis]

I'm not aware of any solution for iOS. Goole Play can be a nightmare to get working correctly. Documentation of general flow is good, but details can be vague, especially for Xamarin or MAUI. This code for getting integrity information in MAUI 8 works using nuget package, Xamarin.Google.Android.Play.Integrity 1.1.0.2. I attempted to upgrade, had issues with the new version and rolled back. I have not had time to figure out the "new way". I assume this is using "classic" play integrity check since it is a port from my Xamarin project from a couple years ago.

`
private async Task GetDeviceInfoAsync(string nonceString, long projectNumber)
{
try
{
int resultCode = GoogleApiAvailability.Instance.IsGooglePlayServicesAvailable(Platform.CurrentActivity);
if (resultCode == ConnectionResult.Success)
{
try
{
IIntegrityManager manager = IntegrityManagerFactory.Create(Platform.CurrentActivity);
IntegrityTokenRequest request = IntegrityTokenRequest.InvokeBuilder().SetCloudProjectNumber(projectNumber).SetNonce(nonceString).Build();
Java.Lang.Object integrityResult = await manager.RequestIntegrityToken(request);

                    return integrityResult?.ToString() ?? "Result was NULL";
                }
                catch (ApiException apiExc)
                {
                    //TODO: Google Specific Error - Log and rethrow
                }
                catch (System.Exception exc)
                {
                    //TODO: Log and rethrow
                }
            }
            else
            {
                //TODO: Google Services Not Available. Log Result Code - rethrow
            }
        }
        catch (Exception exc1)
        {
            //Log and rethrow
        }
    }

`
Of course you need to verify the integrity token on your own backend server, which is where you should also create the nonce and attach it to the user's account/device in your backend storage when the nonce is created, then retrieve it from the account later. Don't pass nonce back to your server.

On the server side, this code will decode the integrity information. It has been many years, and I don't remember how to get the P12 file or where to find all the identifiers you need for the API. You'll have to match up the documentation of the API calls. I did not include evaluation of the results because it is quite a bit of code, and the documentation isn't very good on what all the values do, and I could easily have bad logic. You will also need to remove some checks to use this in a debug/testing environment because apps won't be signed or you may be using an emulator.

Things to look for in the results include... Look for cloned apps. Users that have made a copy of the app, or decompiled/modified/recompiled the package. Do this by looking for invalid signatures or wrong package names. Generate the nonce for every request. Check the timestamp and nonce to make sure it isn't a replay attack, where the user sent you an old successful result, instead a recent one. You'll need to decide if you want to allow your app to run at all on "unsafe" devices or emulators.

This code uses nuget package Google.Apis.PlayIntegrity.v1 1.62.1.3199

`
public async Task<Google.Apis.PlayIntegrity.v1.Data.DecodeIntegrityTokenResponse> ValidateAndroidIntegrity(string p12FilePath, string deviceInfo)
{
try
{
ServiceAccountCredential credential = GetIntegrityCredential(p12FilePath);
PlayIntegrityService ps = new PlayIntegrityService(
new BaseClientService.Initializer()
{
HttpClientInitializer = credential,
ApplicationName = "YOUR APP NAME"
});

            string t = deviceInfo.Substring(deviceInfo.IndexOf("token=") + 6);
            t = t.Substring(0, t.Length - 1);

            Google.Apis.PlayIntegrity.v1.Data.DecodeIntegrityTokenRequest req  = new Google.Apis.PlayIntegrity.v1.Data.DecodeIntegrityTokenRequest { IntegrityToken = t };
            Google.Apis.PlayIntegrity.v1.V1Resource.DecodeIntegrityTokenRequest r = ps.V1.DecodeIntegrityToken(req, "com.your_company.your_app");
            Google.Apis.PlayIntegrity.v1.Data.DecodeIntegrityTokenResponse response = await r.ExecuteAsync();
            return response;
        }
        catch (Exception ex)
        {
            if (System.Diagnostics.Debugger.IsAttached) { System.Diagnostics.Debugger.Break(); }
        }
        return null;
    }
    private static ServiceAccountCredential GetIntegrityCredential(string p12FilePath)
    {
        //https://developers.google.com/api-client-library/dotnet/guide/aaa_oauth
        X509Certificate2 certificate = new X509Certificate2(p12FilePath, "notasecret", X509KeyStorageFlags.MachineKeySet);

        ServiceAccountCredential credential = new ServiceAccountCredential(
           new ServiceAccountCredential.Initializer("qonqrplayintegrity@api-project-XXXXXXXXXXXXXXiam.gserviceaccount.com")
           {
               Scopes = new[] { PlayIntegrityService.Scope.Playintegrity } 
           }.FromCertificate(certificate));
        return credential;
    }

`

I hope this helps with the unpleasant need to work with Google API, or fight hackers in general. Another thing to look at is to obfuscate your code. Keep as much as you can in private methods or use a good obfuscator like https://www.babelfor.net/ so that you can obfuscate public methods. If you have made the unfortunate decision to use IoC for app development, most of the value of obfuscation is lost if you don't rename your public interfaces. IoC mandates your public attack surface is extremely large. IoC is good for server code, not so good for client code. Keep all your code in a single assembly, or merge them, so hackers can't pull out your lower projects and automate calls to your servers with the embedded security measures. All important calls between your client and server should have some type of hash in the header or post to verify they originated from your app and were not modified by a proxy server, including some type of timestamp to avoid replay attacks.

[gabsamples6]

@scottkdavis thank you very much for your time in replying to me. I will have another go at this play integrity.. and also thanks for the tips on obfuscation, we did try babel but we were not that successful as it did not obfuscate as much as I thought it would . We do use iOC for dependencies .. now your comments gave food for thoughts!.

[scottkdavis]

Obfuscation definitely isn't easy to get the best coverage. I'm guessing Babel is using a minimal set to ensure everything works out of the box. If you have issues, contact support. Alberto (owner) is amazing. There are extensive configuration files that allow you to fine tune where rules are applied and where they are skipped. Ideally, on Android, you want to rename anything that doesn't screw up binding, Android system callbacks (activities/intents) and all models that are part of API calls. Regardless of what obfuscator you use, reducing your external entry points (public methods) is best. For important button clicks you would never want a hacker to automate, you may need to avoid public command binding and use protected/internal click events in the code behind to hide the event execution. You may also need random button naming in release configuration (run a script) to further reduce users employing common testing tools to automate the app. Using a graphics library to combine text with an image to create an image button to make it harder for testing tools to find the button to automate a click, while still making localization an option. There are so many absurd tricks you can employ. I have no idea what your app does and certainly some apps don't need the protection others do. I have a mobile game, so I constantly have people attempting to tear apart my app, talk to my API directly, steal in app purchases, automate game play, and create dozens of griefing accounts with cloned apps. Living as a developer in the mobile world is much harder today than it was 10 years ago. It would be nice if Microsoft, Apple and Google put more emphasis on helping developers protect their products and customers. Unfortunately, most of this is a "figure it out yourself" situation and learning lessons the hard way. Best of luck.

[gabsamples6]

Again thanks for your time in replying , our app is constantly pentested and obfuscation is a big issue for us , but we did look into third parties and the one we were very happy with was extremely expensive, Babel unfortunately did not obfuscate as much as we would have liked and I only tried the trial version. Unfortunately we do not get obfuscation out of the box like other languages and Microsoft/Maui does not seem to be concerned about security in the mobile app- its a "figure out yourself" kind of thing. I am really interested in all those suggestions you made , are you using any public nuget to aid security and make it difficult for the hacker. I totally get its a "cat and mouse" game but any layer of protection is better than nothing. thanks again

[scottkdavis]

My experience is entirely based on Xamarin at this point. My Maui migration is still in progress and I have not implemented obfuscation for MAUI yet. I am moving all my security practices in the migration however.

I had a phone conversation with the Xamarin team years ago about the issues with app security. It was the second time the Xamarin team had changed the Android build pipeline and broke multi-assembly obfuscation. They did it for speed, which broke the ability to obfuscate the public interfaces of a child DLL, and import the renaming map into the parent DLL's obfuscation. I had to restructure my Xamarin solution so everything was in a single assembly using a shared project. Thankfully, MAUI supports a single project solution for all platforms as the default setup.

Part of that phone call was a discussion about obfuscators and security. It was discouraging back then, but more encouraging now since Android is supposed to compile down to native code, which should make it more difficult to decompile. I have not verified yet.

Speaking of verifying, are you tearing apart your aab file to verify what got bundled? Back in the Windows Phone 7/8 days, I discovered an issue with Dotfuscator where it silently skipped my child libraries that included all my security measures and packaged that DLL in the clear. It only obfuscated the top level projects. The behavior changed as part of a new release. No failures in the build process. It was the last time I would ever trust Dotfuscator and I switched to Babel. Since that time I always tear apart every package and verify all my code is obfuscated. Here is a blog post that describes how to undo the K4 compression so you can actually see what is inside.
I have not checked yet to see if this is the same way aab files are made in MAUI. It is on my todo list.
https://www.x41-dsec.de/security/news/working/research/2020/09/22/xamarin-dll-decompression/

I believe there was also a time when Microsoft changed their Android packaging and started budling assemblies from a different location. Once again my package was made with DLLs in the clear, because my obfuscator was still running on assemblies in the old location and the packaging libraries were now somewhere else. It has been so long, but I'm pretty sure this happened. I think I'm remembering that correctly. Either way, always tear apart your aab file and verify what is inside before it goes to the stores. Not just once, but always. Historically, the packaging process seems to change every few years and you probably won't know about it.

I don't have a Nugut I can point you to. Everything is home grown.

You are correct that Microsoft doesn't care about app security. If they did, plugging in obfuscation (or better yet, having it built in) would be a dedicated and obvious part of the packaging pipeline and verifying obfuscation wouldn't require you to write more code to rip apart the package to verify what is inside. I'm optimistic compiling to native on Android will make a big improvement, but I have yet to verify. I think currently for Xamarin, obfuscation is plugged into a build target that starts with an underscore. Someone on the Xamarin team directed me to uses that event to obfuscate at the right time. I have read you should never uses private build targets (with an underscore) for custom MSBuild actions because those actions are subject to change in the future. A good indication obfuscation was not a consideration.

This isn't a just Microsoft issue though, it is an industry issue. So much of what goes into all coding platforms these days are intended to make development and testing easier, but most of those things (like IoC in apps that run on a customer's hardware) hurt security. We should stop pushing "best practices" that are bad for security. Too many of our design practices today are centered around testability and we figure out how to make them perform well and secure. It should be the opposite. We should be designing for performance and security, then figure out how to test. Its not hard, I've done it, but it requires you approach the problem from a different perspective.

Apple and Google and the governments like the EU are more to blame when it comes to making it hard for developers make a safe app. It is impossible for me to stop a predator from praying on my users. I can ban a users account if I see them doing illegal or abusive things towards other people in my community. But they can uninstall, reinstall and be right back into my app in 5 minutes with a new account. I've had an issue with a child porn poster in Brazil, and there is nothing I can do to keep them out but play wack-a-mole with his accounts. I identify users every day to attempt to use a manipulated application or modified network traffic. But I can't ban their device or Apple/Google account. All I can do is watch them create a new account over and over to attempt to hack or steal from me. Apple will let users claim they did not receive an in-app purchase refund their money and never disclose it to me. They can steal all day long, and Apple will happily assist in the theft. There is no way to verify GPS coordinates on Apple device and it isn't much better on Android. I agree that users should be able to block their GPS from apps, but if the coordinates are fake, the developer should be able to tell. Google has apps in the Google Play marketplace that will tear apart an APK, manipulate it, and install it on the device as a cloned app. Everything happens right on the phone. These apps are is in Google Play Store. They are assisting the theft of developer IP. Apple and Google need to give developers the ability to block app remoting/virtualization, screen tappers, automated testing software from interacting with apps, if they want to restrict that option. Developers should be able to know if the tap on the screen is real or not. The device certainly must know, that information should be available to the developers.

There are so many issues with mobile development today. The platforms and the governments has removed the ability for me to keep my community of users safe, and ensure legitimate, fair, and legal use of the app, while at the same time they are making more rules and laws to force me to be responsible for the bad users they won't let me stop.

[gabsamples6]

Hi,
Apologies for late reply - few days off :) thank you for sharing your knowledge and experience in dealing with these security nightmares.. It's a pity that MS totally washes their hands on this one, I get it they do not want the aggros that comes with it, but we are left totally unprotected here. Ok do not provide any nugets etc but some dos and donts would be nice .

The all security thing is quite a task and impossible to keep up at times.. we all know that a determined person can still decompile etc.. but we are after an extra layer of protections to deter as many as possible..

Our app Xamarin/Maui will always fail pentesters on the obfuscation front unless we pay $1000... for a third party again Babel did not work for us.

Api Keys - we all know we should not store them on the device but its a chicken and egg situation here. We have certain https calls that we should be able to make without being authenticated , so we must store some keys on the device - how do people tackle this one.

In the past we used to store the Appcenter keys in the device , pentester failed us, it was pointless to explain that it was just for logging..
Testing jailbroken devices - its tricky too

Not sure what the answer is unless the company is ready to spend a lot of money on third parties..

Interesting to know how people tackle these issues.