Saturday, November 3, 2018

I saw Scott Davis explain just how hard it is to secure a mobile game at the Twin Cities .NET User Group Thursday night.

This was a heavily negative talk, perhaps the most gloom-filled I've seen since this talk at Black Hat by Jennifer Granick, and we, the audience, were all warned upfront. Mr. Davis makes the mainstay of his living off of his mobile game QONQR which allows players to battle each other in local locale-specific environments (fight for control of Minneapolis if you live in Minneapolis not unlike being the mayor of the Olive Garden on Foursquare I guess) and has in-app purchases that players may make. Scott mentioned towards the end that he would not have tried to make his fortune in the mobile game space if he had once known what he knows now. As far as the geolocation stuff goes you cannot trust GPS. Comically, even though Android devices record a time from the applicable satellite, they end up replacing it with the device time before reporting it onward. A user may just fake GPS with a rooted Android device which is an Android device with a modified kernel. Beyond that one pain point however there are many more. Hackers are a demographic. There is an entire class of people who want to steal from you and the major players in the platform space are really more interested in providing security to consumers than to anyone developing for their platform. Apple doesn't want to even admit that it has security problems. Windows Phone 7 used to encrypt the packages that you publish as a downloadable from their store and with Windows Phone 8 Microsoft just took the encryption back away. Google has never encrypted the .apk packages that come down from something published to the American market store (or any of the multitude of stores in China's market) and anyone smart enough to rename an .apk to a .zip can have at your code. Therefore you will need to obfuscate your code which explains why Scott is pointing at a package named a in the photo here. (This was .NET talk. Unity did not have a map control of its own and the third-party map controls were Mickey Mouse when Scott started QONQR. This meant that Scott settled for Xamarin.) The obfuscation can only help you so much. If someone is stubborn enough they can reverse-engineer your code of course. The goal to settle for is to try to make things tough enough for thirteen-year-old kids in China following a YouTube movie to give up on hacking you and move on to an easier victim. Chinese hackers will try to download your application and reskin them as your own. They probably won't compete with you in the American marketplace because the Chinese marketplace is bigger and more lucrative. Naturally, one way to curtail this is roundtripping to the server-side of things for anything important be it the incrementing of in-game currency or your character's health-level I suppose. This makes it such that if anyone tries to pass off your work as their own they are still using your backend which they won't be able to just guess at and rewrite quickly on the fly. Beyond that you don't want things like in-game currency to be incrementable at the client anyways because someone could just hack the memory space holding the number on an Android device and make themselves rich. Someone could reskin your app, use your backend, and then use what is known as method hooking to find the applicable method for a trip to the server to make a payment (just search the code for something that has a name like "Transfer Balance") and splice in their own code there to give their account five dollars whenever a user uses the reskinned application to pass money on to you. Arxan.com is a not-too-affordable tool for preventing method hooking. There is no device-specific id on an iPhone. The device advertises an id that anyone may just reset by resetting the device so you cannot really block bad users based upon who they appear to be devicewise. SSL prevents man-in-the-middle attacks but at the end of a call a sinister individual can set up a proxy server with a fake certificate that doctors up requests and reencrypts them. I guess this environment could then pass through to your own environment in the case of a reskinned application that hits web services at the proxy server and then carries on to the legitimate backend. You may use something called SSL pinning to know if the SSL certificate is from an authoritative source. If you use open source software in your front end (John Sheehan's RestSharp which is an API tool was given as an example) unfortunately any hacker can just go pull the open source code, splice in their own logging, and then recompile a .dll that they use to replace the one that came down from the store and gain insights into what your code is up to. Your own home-rolled .dlls may be decompiled with Redgate .NET Reflector or Telerik JustDecompile so they may be hacked in kind. babelfor.NET was suggested to be a pretty good obfuscation tool. Amongst the things which normally make for good practices that get in the way of obfuscation are the S in the SOLID principles as if you keep things small and tight they can only be so misdirected and IoC. babelfor.NET will try to obfuscate public-facing interfaces in the IoC circumstance by giving the methods goofy names and giving you a map that does not get published to help you make sense of the gibberish and translate the obtuse to the sane while you are working on the code to ultimately be published in a different shape. The Android SafetyNet Attestation API can help you tell if a user is rooted. It is wise to have an incrementing number come back with each API call to your server. This helps tell if a user is really using the app and not just bouncing stuff off your API. Use BSON (binary JSON) in lieu of mere JSON. Use something like Captcha to prevent physical robots from using your application. Every if statement should have an else even if it seems like the else case can never be tripped. Put this in the else case:

if (System.Diagnostics.Debugger.IsAttached)
{
   System.Diagnostics.Debugger.Break();
}

 
 

Other things named-dropped include that an Azure worker role is a command line app that runs in Azure and that a NRUN is a non-repeating unique number. I hope I have that acronym right. Scott has put a lot of trial and error into figuring out how to prevent users fighting with other users. Basically there are four things you may do if someone makes you cranky in an exchange:

  1. report it
  2. ignore it
  3. block the user
  4. fire back

 
 

The problem with reporting users is that people go crazy with it. Scott introduced a way to appeal being reported and if you appeal and the reporting party is found to not have any real ammunition for getting you in trouble, they get in trouble twice as hard. This prevents an abuse of reporting.

No comments:

Post a Comment