According to Statista, over three billion people access the internet globally, giving cyber-thieves a very big pond to fish in. Last year alone, it was discovered that nearly one billion Android handsets could be hacked by just one SMS. Also, so-called rogue app stores are becoming a serious concern for banks. Subtly altered versions of popular apps, often available for free, are appearing more often on smartphones. In some cases, these apps allow the theft of mobile banking passwords or redirect text messages containing passcodes.
Traditionally, code protection meant storing as much code on the server as possible. This kept your code safe from prying eyes and it also allowed the server to do the heavy lifting, performance-wise. Even today, storing your code on the server certainly offers the best protection, although with some disadvantages.
One challenge involves forcing an internet connection; if you're developing an application you want to work offline then it's not feasible. Another consideration is performance. Server calls take time. Not an issue for simple apps but for high-performance apps like games, excessive latency can ruin the user experience.
Let us bear in mind that to date, organisations have relied heavily on endpoint security solutions to protect the client-side — yet solutions such as antivirus software have a low success rate of around 40 percent. If we consider that an application encompasses both server and client side and that the client side solution doesn't necessarily have to be endpoint security, then we understand that every client app has its own cloaking system and defence.
To date, companies have been focused on the threats via servers and have paid little attention to the hidden dangers of hacks through the client-side. Often, when we get in front of IT teams they are unaware of the risks they face if the client-side isn't protected sufficiently. Our technology is designed to detect tampering with the application on the client. This means that the development and security teams are made aware and can execute a plan to ensure the attack isn't successful. We make the assumption that execution takes place in an unsafe environment so we take every measure possible to allow the app to execute safely.
An additional layer of security allows an application to become self-defensive ensuring that it is able to detect any kind of tampering and make the code derail the execution of the program. Also, if you require real time notifications then you can use settings to warn you if your application is being tampered or used in a different environment or date other than the one you have defined.
Contributed by Pedro Fortuna, CTO and co-founder, Jscrambler
Originally published at SC Magazine UK on January 20, 2017.