Quixxi Security
How can we help you today?
FAQs
- PRODUCT OVERVIEW
- What is Quixxi Security?
- Why is Quixxi Security different?
- Which kind of apps are supported by Quixxi Security?
- Which is the reference model applied for evaluating the app security level?
- What is the performance overhead introduced by Quixxi Security?
- What is the expected increase in the size of apk/ipa after applying the different frameworks?
- What’s the difference between Quixxi Security and an antivirus?
- Where can I find Quixxi Service Agreement?
- Which Quixxi services are included in my plan?
- How to upgrade from a free account to a premium account?
- How to delete my credit/debit card details from Quixxi portal?
- How will I stop my auto-renewal for monthly plans?
- Will Quixxi debit my card at the beginning or at the end of the subscription period?
- How can I print/download the payment receipts?
- Can I integrate Quixxi Security with other security tools?
Quixxi Security is a suite of multi-platform frameworks developed to ease the SDLC of mobile apps in terms of security. The mission of this product is helping the developer to easily and quickly bring to market apps willing to integrate features like security flaws detection, automated protection, license check, diagnostics and custom statistics. In particular the App Shield offers the protection level needed both to prevent tampering and reverse-engineering and to pass penetration tests, so that end users can experience the app as you conceived it
Quixxi Security’s unique combination of integration, intelligence and affordability makes it stand out from the competitors
Point by point:
- integrated because the different modules can work both standalone or with the others and a simple console will allow you to detect threats, manage illegal users and identify issues
- intelligent because the Shield will be effortlessly applied - both on apk and ipa files - through a drag'n'drop and because other modules like Diagnostics and Analytics are already set to efficiently display, manage and filter data according to your needs
- affordable because our product and its pricing options have been studied to be accessible not just by enterprises but also from independent developers
Quixxi Security Scan and Shield support Android [Java or Kotlin] and iOS [Obj-C or Swift] apps but with different features depending on the platform of choice. We provide protection also for Android libraries distributed as aar or jar files. Moreover we are able to secure Cordova/PhoneGap apps. Our SDks are currently available in Java and Obj-C but we already started working to extend them also to Kotlin and Swift developers
Quixxi Security is currently referring to the OWASP Mobile Security Project, in particular to the OWASP Mobile Application Security Verification Standard [MASVS] and its sections. This is evident in particular from the Vulnerability Report structure. We take as well inputs from CVE, CWE, FFIEC and a few others too, depending on the industry domain
The absolute value depends from the particular case. First of all in terms of frameworks implemented [i.e. Analytics, Shield, Licensing, Malware Detection]. And secondarily because - even considering the same framework – there could be different working conditions. For example different security settings for the Shield or different number and different frequency of events to log for Analytics. Anyway we provided here a full case study on VoicePRO, featured on Google PlayStore as one of the top 20 paid apps in Music category. Moreover – in order to help our customers profiling their own Android apps in the same way - we created a dedicated how-to page here
A detailed analysis of this aspect is available for Android and iOS
A mobile antivirus constantly acts checking the whole phone. On the other side Quixxi Security was born to be app-centric, not device-centric. That said, some of our customers are dealing on a daily basis with sensitive data and for this reason they required a feature to ensure that their app was running on a malware-free phone. Then Quixxi Security recently developed a Malware Detection tool to analyze the phone and detect them as soon as the protected app starts
Our Service Agreement consists of Terms & Conditions and Privacy Policy. For any further details please do not hesitate to contact us via support(at)quixxi.com
Depending on your needs you may need to switch plan and each one of them has a different set of services included. You can see the current monthly and yearly plans with the details visiting Quixxi pricing page
In order to upgrade your plan please login on the portal -> click on your name in the top right corner -> "User Settings" -> select "Subscriptions" from the left side menu -> select between "Bill Monthly" or "Bill Yearly" -> select the new plan and click on "Switch Plan". In the case of Enterprise plan please click on the "Contact Us" button or email us at support(at)quixxi.com
IMPORTANT - all the monthly plans are auto renewal plans. In order to stop your renewal plan please contact us at support(at)quixxi.com or through the Quixxi portal live chat. The yearly plans instead must be automatically renewed
We don't let a user delete his default card from our portal because we need at least a valid card in case of automated billing. Any card other than the default one can be easily managed/deleted clicking on your name in the top right corner -> "User Settings" -> select "Account" from the left side menu -> scroll down to the bottom of the page and click on the "Add card" button
1) All Quixxi monthly plans are to be considered auto-renewal plans. In order to stop your auto-renewal you need to contact our support via email at support(at)quixxi.com or through the Quixxi Portal Live Chat (bottom right corner)
2) All Quixxi yearly plans are one-time plans. Auto-renewal will NOT be applied on these plans
The payment for any Quixxi plan is upfront. Once done, you can enjoy using all the features included in your subscription till the plan expires
1. Click on your Username (login and look to the top right corner)
2. Select Billing option from the dropdown menu
3. You will get the list of payment history
4. Click on View, to view the online receipt of interest
5. Click on Print. If you need a pdf copy just change the destination printer from this same browser window and select the option mentioning the pdf [e.g. “Save as PDF” on Chrome]
We currently don’t support any other security tool but it’s definitely a possibility for the future
- SCAN
- Which apps can be submitted for the Automated Vulnerability Report in the Scan section?
- What is the difference between the Automated Vulnerability Report from the Scan section and the Advanced Manual Assessment?
- How is the assessment score for an app calculated?
- Are the Vulnerability Reports for Android and iOS produced according to the same philosophy?
- So what's the difference between the Vulnerability Reports for Android and iOS apps?
- Is it possible to have false positives from the Automated Vulnerability Report?
- In which formats are the reports available?
The apps that can be uploaded for the Automated Vulnerability Report are written in Java or Kotlin for Android or Objective-C for iOS. The Android Java apps can include also include native code through the NDK. We can also assess Cordova/PhoneGap apps. Independently from the platform the apps MUST be uploaded as compiled by the IDE but unobfuscated, otherwise the static vulnerabilities themselves will be obfuscated
IMPORTANT - just to be crystal-clear: obfuscation is great plus to increase the security level but it prevents also the Quixxi Scan to properly assess. So please submit the app with the following modalities: unobfuscated app for the Scan phase and obfuscated app for the Shield phase
The Vulnerability Report from Scan includes only a static analysis made on the apk/ipa code. This means that in order to perform this kind of analysis you don’t need to launch the app, it is only an assessment on the package delivered as it is. The Advanced Manual Assessment is meant to add also black box tests on the app. In this case the original app will be run and the analysis will then search also for the pitfalls coming from its runtime behavior. For further details about the differences between the two please refer to this OWASP table where you will find the full view of what is covered by the two
The Vulnerability Report score is calculated both for Android and iOS apps as the ratio between the number of vulnerabilities passed and the total number of vulnerabilities analyzed, so plain arithmetic average normalized into a 0 to 5 stars range. For example if you have 12 unsolved issues out of 36 then your score will be given by the ratio between the vulnerabilities passed (36-12 = 24) and the total ones scanned (36), normalized on the 5 stars scale. In this example the final result is then: (24/36)x5 = 3.3
The technique used to produce the reports is based on the same theoretical principles and both the platforms are compared against the OWASP guidelines. Again, the vulnerability report will make sense only if the apks and ipas to be checked will be submitted without applying any obfuscation to the source code
The difference is due essentially to the combination between the different policies from the two companies and the programming languages used:
- for the former please keep in mind that iOS apps can be officially delivered only from the Apple Store whose policies will perform deep security checks starting from the time of the app submission. It is not possible to install an iOS app which has not been approved by Apple, unless your phone is jailbroken. Android has multiple legal stores with their own policies [PlayStore, Samsung store, Amazon store, etc]. Moreover after granting your authorization you can install even any unofficial apk file and without any need to root the mobile
- for the latter in the case of Android apps a Java decompiler on an unprotected apk will give us something which is very close to the original source code. In fact, Android apps are initially compiled to a machine-independent Java bytecode. This bytecode contains a lot of metadata - such as local variable types and classes structure - to allow it to be compiled later for different targets. All this info is now kept until the Android RunTime [ART] – or better, its Ahead-of-Time [AOT] compilation phase - compiles to native code once, at app installation time. But when it comes to iOS apps the source code is in Obj-C and they are compiled directly to machine code, with an aggressive optimization pass that tends to destroy a lot of the structure of the original code. So in this situation it will not be possible to directly retrieve high-level code [like in Java through the decompiler] but only the assembler of the app [through the disassembler]
The two effects combined together explain why statically analyzing an iOS app is harder than statically analyzing an Android app
Yes, it is possible but totally depends on the specific app. Let’s take an app which doesn’t deal with any sensitive data, e.g. an app that just lists names for newborn babies. Your Vulnerability Report can e.g. list that your app is not protected against the possibility to take screenshots and sharing screens. In this case - if the developer has nothing against this specific feature - this would be a false positive. But if the same thing happens to e.g. an app dealing with healthcare data then the same issue is definitely not a false positive but something to absolutely consider
The reports are currently provided as pdf files
- SHIELD
- Why should developers and companies secure the app with Quixxi Security App Shield?
- My application is a free one. So what is the purpose of securing it?
- Can I secure an app through the Quixxi Shield SDK instead of using the SaaS [Software as a Service] process?
- What are the options for applying the Quixxi Shield in the SaaS fashion?
- What are the security principles applied by the Quixxi Security App Shield?
- Which are the file extensions supported for direct app signing on Quixxi portal?
- Which is the encryption standard used by Quixxi Security App Shield?
- Which are the OWASP areas fixed by Quixxi Security App Shield?
- Why do I keep receiving an error when trying to apply the App Shield on my app? Is there any limitation in applying security?
- Can I secure only a part of my app?
- Can I apply Quixxi Shield on Android apps integrating native code through NDK?
- Can I apply Quixxi Shield on Cordova/PhoneGaps apps?
- How does the anti-malware feature work?
- Why don't you provide the anti-malware feature also for iOS?
- My user could perfectly use the app and now he is systematically bounced out of it. How is it possible?
Properly securing an app requires a large set of knowledges which is not immediately available to most of the developers. Quixxi Security App Shield fills exactly this gap, allowing the team to focus only on the app functionalities. In fact - once your app gets built with your usual process - security is added on top of your work via a simple drag’n’drop of the final apk or ipa on our portal, without any coding ability involved!
Having a free app doesn’t mean at all that securing it is unneeded. This is the most common misbelief!
The first real consequence you can experience is an Intellectual Property [IP] theft. In the case of unsecured apps your code can be easily decompiled and the extracted pieces of code can be used as core for a new free competitor and/or a new paid app. If this looks like an unreal and/or complicated scenario then please have a look to our video. Secondarily - for the same reason - your code can be tampered with malware injection and republished on the internet as the original app, discrediting your brand and its reputation
We started developing the product with the main target of being easy. For this reason the Quixxi Shield is currently applicable only through a totally codeless process
The codeless shielding process can be triggered through three channels: drag’n’drop on the portal, command line and REST API
Quixxi Security uses state-of-art technologies to provide the highest security level to its customers. In particular we can mention: whitebox cryptography, debugging prevention, root/jailbreak check, attached debug and emulator detection, randomization, spoofing techniques. Features available vary depending on the platform, being different between Android and iOS because different are both the programming languages and the policies from the two companies
Quixxi Security supports the direct Android app signing via jks keystore type only. On Apple side you can sign your ipa file on portal uploading your p12 file and mobile provision file
Quixxi Security makes use of the AES-128 encryption standard. This happens both for Android and iOS apps. In order to give you an idea of the efficacy of this protocol "the best attack [...] on AES with a 128 bit key requires storing […] about 38 trillion terabytes of data, which is more than all the data stored on all the computers on the planet in 2016 [...] At present, there is no known practical attack that would allow someone without knowledge of the key to read data encrypted by AES when correctly implemented" [source: Wikipedia]
Quixxi Security is strongly focused in preventing both the reverse engineering and the tampering of your app. A comprehensive list of what is covered for Android apps can be seen consulting our table under the “Android Shield” and “iOS Shield” columns. The vulnerabilities that can be fixed by Quixxi Security in your app are also evident by looking at our automated Vulnerability Report and searching for the “Fixable by Quixxi Security” label
Quixxi App Shield can't be applied on apps where security has already been placed by Quixxi Shield itself or a similar tool. A significant case in this connection comes from Apple. It is not possible to shield applications downloading them from their official AppStore because Apple automatically places an encryption layer on the ipa binaries. Anyway the Shield is designed to perfectly work with all those Android apps obfuscated using ProGuard and all the iOS apps obfuscated through PPiOS-Rename
In this case you have two options. The first one is submitting the final apk, excluding packages and classes through the related Quixxi Shield option. The other one is writing your Android code to be compiled into an Android ARchive [aar file] or Java ARchive [jar file] library and then secure it according to what explained in the Docs. Third-party developers can then use the library in their app following the instructions provided in the same document
Yes, Quixxi Security security supports the Java apps making use of native libraries
Yes, Quixxi Shield supports Cordova/PhoneGaps apps
The anti-malware framework is made up by a few modules that check all together for malicious software on the device every time that a user launches the app. The first module we rely on - Play Protect - is the official built-in solution developed by Google. With its 24/7 action and 2 billion users per day it is already a very high-quality filter. The second module we integrate checks the apps on the device against known malware signatures. Finally we offer a third module based on Machine Learning which - after a study of the distinguishing features of thousands malwares - provides predictions about unknown apks
Each iOS app is required by Apple's security policies to live in its own app sandbox, segregated from the other apps for security reasons. In such a scenario, the action of the antivirus - which is called by default to analyze and then interact with the other apps - is simply not possible
If this is the case there are a few possible scenarios:
- the first is that you configured the app in such a way that it has to immediately and strictly stop when executed on rooted/jailbroken devices. If your customer buys the app before rooting/jailbreaking the phone, at the beginning he will be able to execute the app. He won’t be anymore after the root/jailbreak – despite being a paying customer - because of the related Quixxi Security Shield setting. If your intention in this situation is letting him continue to use the app be sure to switch ON the very next setting that allows him to bypass the root protection when the app comes from recognized stores
- the second issue comes from a change in the "user profile". For example he recently enabled the USB debugging and you asked to terminate the app when this condition is detected. Both in Android and iOS the app will be immediately stopped by default when the app will not pass the integrity check. Moreover there is the possibility to configure other reasons for the immediate termination of the app. On Android side you can select among the following items: 1) app attached to debugger, 2) app running in a rooted device, 3) app running in a device with malware[s] onboard, 4) app running in a device allowing installation from unknown sources and 5) app running in a device with active USB debugging while on iOS side: 1) app attached to debugger, 2) published or TestFlight app later resigned and 3) app running in a jailbroken device
- SUPERVISE
- Where is the advantage of Quixxi Analytics and Quixxi Diagnostics on similar products?
- Can I integrate Quixxi Diagnostics with project tracking tools?
- Which other integration options are available?
- I’m afraid that some customers may complain about privacy. Can you give me some reason to add Quixxi Analytics?
- My users emails are constantly detected as “unknownuser@unknown.com”. What is happening?
- Why do I need to mandatorily include Analytics if I want only Licensing?
- Which stores are supported for Licensing purposes?
- My customers buy the app and they are still seen as illegal destroying my reputation on the official app stores. What is happening?
- Can I test Quixxi Licensing capabilities before applying it on a production app?
- My application is free and includes in-app purchases: do I need to enable the Licensing to stop piracy on these additional content?
Quixxi Analytics offers a multi-platform tool that can be used with the same modalities across them. It allows you to display and filter data according to metrics like email, platform, app version, brand, store, status and OS version. Quixxi Diagnostics allows you to have the full view of the system offering multiple debugging files like the stack trace, the logcat, the shared preferences, the events log, the system settings and the app info at the moment of the crash. In the same space we also provide a basic automated research from StackOverflow about possible solutions for those issues
Yes, we offer already the possibility to log an exception on JIRA. In order to establish the connection with this tool enter the app container -> click on the “Settings” icon in the top right corner and then “JIRA” in the left-side menu
We offer “Webhooks” functionality to send events and diagnostics data to any endpoint of your choice. You can find them entering the app container -> click on the “Settings” icon in the top right corner and then “Webhooks” in the left-side menu
Quixxi Analytics takes care of collecting the needed metrics and showing you how users are interacting with your app through customized events. In fact, after the app is published you basically lose track of it. But a feedback about its actual usage could be the starting point to improve your app in the next releases and increase user engagement
Say that users don’t open so much the user guide. Is your app so nice that they don’t need any guidance or is too hidden to be quickly found and used? Or, say your game has 4 characters and 10 stages: what’s the favorite character? how many users can complete each level? Quixxi Security Analytics can help you solve such kind of dilemmas. Last but not least, Quixxi Security Analytics is always free
This email is the default value associated to your users before calling the sendUserEmail() API
For Android in the past we used to automatically retrieve the email and update this value on the portal. But with the most recent Android versions the GET_ACCOUNTS permission required for this task has been classified by Google as dangerous. Thus, in order to have the real Android users emails displayed on our portal there are essentially two ways:
- ask the customer to provide the email or integrate Google Sign-In into your app as described here and then send the email to our portal via the QuixxiAnalytics.sendUserEmail() API
- ask the customer to grant you the GET_ACCOUNTS permission at runtime [especially if it is really functional for your app purposes], implement your own getGoogleEmail() method and then call the previous API to send the user email on our portal. A snippet for this second option is provided in our documentation
For iOS instead your only chance is directly asking the user the email and push it to Quixxi Portal calling the sendUserEmail:completion: API
In order to be successfully applied Quixxi Licensing needs to differentiate the users. This is the reason for the aforementioned dependency
The Android markets officially recognized by Quixxi for Licensing purposes are: Google Play Store, Samsung Galaxy Apps store and Amazon AppStore. In the case of Google Play Store Quixxi is also able to verify the user status directly from Google’s Play Server. For Apple of course the support is given only to the Apple App Store
IMPORTANT - the Android everyday experience shows that when a customer purchases a paid app the user status may require time to be updated on Google Play Server. That's exactly why we implemented a grace period policy in our solution. More in general we strongly dissuade from using a brute manual block policy for Licensing purposes. A paying customer who is forbidden to use your app because seen as illegal by Google server for a pure technical delay will most probably destroy the app rating shortly after its installation
This is because – due to the Google PlayStore processing time after an app purchase – a new user can still be seen as illegal for some more hours, the ones required to validate the purchase. If the user – after a regular purchase - will not be allowed to immediately use the app there is a serious risk that the app rating on the market is going to drop, as it really happened. So better safe than sorry: all our Android blocking policies - except the “Manual only” – supply this issue providing a grace period, i.e. a period in which an illegal user can use the app exactly like a legal user
Yes, you can. Try to install your app from any source other than Google PlayStore, Samsung Galaxy Apps store or Amazon App Store. You will be detected as illegal and you will be able to block/unblock and contact the user/tester as you would do with an illegal user
There are publicly available tools for Android like LuckyPatcher, Freedom and others which are specifically designed to short-circuit the in-app purchase logic. Licensing can theoretically be applied also on free apps but whoever downloads a free app would be a legal/licensed user. For this reason it is not the right framework to stop illegal users in this scenario. Quixxi Security App Shield is what you need to apply to prevent this situation to happen. With Quixxi Security App Shield - once the original app gets tampered to get rid of the in-app purchase logic – it will be terminated immediately and all the illegal attempts will be detected under the "Threat Log" tab in our Shield section. So the users will need to buy the features they want to add or they will not be able to use the app. In this way you can then recover money for the paid content you are offering. Moreover, applying our security layer will drastically minimize the possibilities that these automated tools might actually work on your app