I have been using different techniques for jailbreak detection and it was working fine till iOS 11.4. However when I upgraded my iOS to latest 11.4.1 it is showing me the device is jailbroken when the device is not. This issue we are facing only in iOS 11.4.1 and iOS 12 Beta.
Following were the techniques we are using:
1.Process forking
2."CydiaApp" Scheme Detection
3.Check for suspicious/root folders and files
4.Check for folders that was created during the jailbreak process
5.Check for write permission for non user folder
Is there any thing related to these files and folder access permission we are doing wrong to detect the jailbreak detection?
Any help will be appreciated.
But which one is actually gives you false positive?
If I were to guess, I would say that checking write permissions is not reliable. The way that iOS protects unauthorized access to system files is not with permissions but mainly with sandbox profiles. With that in place Apple can assign any permissions they want to system files, sandboxing will still protect the system. Even when you jailbreak your phone you still have sandboxing in place (don't remember any jailbreak that would disable sandboxing completely) and often limited by it when, for example, injecting your CydiaSubstrate dylibs into system daemons/applications that operate under sandbox profiles. That's the whole security of iOS - code signing, entitlements, sandboxing, IPC. No need for POSIX permissions which Apple actually doesn't use that much.
Checking for suspicions directories and files could also give you false positives and is not very reliable in general. Apple often changes it's root file system, you never know what might be in the new iOS version. Of course, if it's related to Cydia then it should be ok.
And that's, in part, why Apple doesn't like AppStore apps checking for jailbreak and often rejects them because of it. Not only you try to access something you shouldn't, which makes it hard to distinguish between jailbreak detection and actual usage of private API to circumvent iOS security. But given that jailbreak is all about very specific kernel patches and things that you wouldn't have access inside AppStore app due to sandboxing anyway (launching unsigned binaries, modifying root partition), there's no reliable way of detecting jailbreak in general. Forking, Cydia, support for CydiaSubstrate - all of that is optional and depends on specific jailbreak implementation. With recent jalbreaks that's even more relevant - all of them are very different and not completely finished lacking some features that were standard in the past. Even more importantly, if Apple decides to change something in iOS, in might trigger jailbreak detecting code by accident. False positive is much worse than false negative.
In the end, no matter what you do, every jailbreak detection code can be easily patched or hooked. When you're in control of the system, apps are no longer able to protect themselves. That's all offtopic but it's a good reason to just ignore jailbreak.
Related
Just made an installer (using QTIFW) for my Qt project but when I tried to install it on other machine the 360 Total Security interrupted the installation process.
It pops up and complains about d3dcompiler_47.dll, asking the user to allow/block the file. If user do nothing, or don't allow, it
seems to be preventing QTIFW of writing it as part of the application installation.
That led to following error
Can't create C:\Program Files\company\project\d3dcompiler_47.dll"
That's quite terrible. I'm wondering how to deal with this situation?
False Positives: False positives from maleware scanners can be quite hard to deal with. To check using more than one malware scanner you can upload the release files individually as well as the complete setup to https://www.virustotal.com. This service runs many malware scanners on the submitted files so you can see what malware scanners flag which binary. There are a few other such anti-malware online scanners such as Kaspersky, Avira, etc...
Update: And then there is Process Explorer. Check this tweet chain for how to check your running application for malware hits per process and loaded file.
When you see the scope of the problem (how many files are flagged), you should work backwards to see how you could go about solving the problem. This can involve getting the files whitelisted by the malware vendor(s), eliminating them from your setup, or fixing technicalities that flag the files, etc... There are some options listed and elaborated below.
Fixes: There are both technical and practical fixes you can try. Don't expect it to be easy. The issue of false positives is a very serious deployment problem. The proposed fixes and workarounds below are in random order:
Compiler Settings: Sometimes you can actually choose different compiler settings to avoid the problem, but often you are not so lucky. I have seen this with files compiled with special Spectre / Meltdown mitigation settings. They were flagged as unknown by malware scanners.
Dangerous API-calls: You should also check what API-calls are made in the problem file(s) that could be known to cause security warnings (unusual and / or dangerous API-methods) - and remove them if you can. I have heard of cases where malware vendors want to refuse to whitelist your binary because what the binary does makes no sense to them (try calling a firmware update for an embedded system as part of your setup installation or some low-level call triggered by a security tool you are installing).
Eliminate Files: Removing certain components from your application can also help sometimes - especially if they are third-party components added to your application for convenience only. In other words your application works fine without them. Removing a problem can be much simpler than fixing it.
Vanilla Installer: Sometimes you can split problem components into a separate setup so your main setup installs without issues. This can help enormously with support issues or overall application approval in corporate settings. You can also make 2 full setups where one has all probable false-positive triggers removed - your "vanilla setup" that should install without drama in all cases.
Digital Signatures: Signing the file with a digital signature can help since a proper certificate "buys trust outright" in reputation-based score systems such as Microsoft SmartScreen. Note that this needs to be an EV-level certificate. Please check for updated information here as technology evolves. Certificate / signing technologies always seem to cause something unexpected.
Malware Scanner Whitelisting: Submit file for white listing. Then there is the formal approach with the malware vendors as explained by Bogdan Mitrache of Advanced Installer here: Antivirus Whitelisting Pains. You submit files to them for white-listing. The article explains real-world experience with binaries flagged as malware when delivering software. Mandatory reading.
Microsoft SmartScreen: Microsoft has their own way to submit files for analysis and white-listing: https://www.microsoft.com/en-us/wdsi/filesubmission. They state: "Microsoft security researchers analyze suspicious files to determine if they are threats, unwanted applications, or normal files. Submit files you think are malware or files that you believe have been incorrectly classified as malware.".
Unique Executable Per Customer: Sometimes a unique executable is used for every customer by auto-generating an installer for each sale. I would advise against this since the installer executable - even when signed - will be a "new encounter" for malware scanners. You could run into trouble you do not need. There is also an added risk for each generated installer executable to actually be infected by real malware, and there is also the QA-issue that every installer should be tested before release.
Signed Malware: Whatever you do, make sure the file in question isn't actually real malware! Obviously your own files can get infected. Test well. If you sign malware and deliver to your client the digital signature is proof positive that you delivered the malware to them. Not good. And then.
More on Digital Signatures: Some information and links to get your setup and / or files signed:
https://www.advancedinstaller.com/user-guide/faq-digital-signature.html
https://knowledge.digicert.com/generalinformation/INFO1119.html
https://www.thawte.com/resources/getting-started/how-code-signing-works/
Installshield Custom Dialogue Installer
Chrome is on the verge of definitly break compatability with NPAPI, and IE breaking with ActiveX the future of Java Applets is dark. Currenty we actively use a secure applet for out client organizations that enables their users to upload a bunch of files from their file system to our servers with the click of a button. The applet has full access to any configured drive, including network drives.
With the imminent death of the applet this functionality is going to be lost if we don't find an alternative. I have already tried to explore different solutions, including the chrome FileSystem API but that is currently only available for Chrome (http://caniuse.com/#feat=filesystem) and has limited access.
Does anybody know about an alternative to keep supporting the much appreciated functionality? Unfortunately we are obligated to support all browser down to IE8.
I've written a post about this here.
Once Google Chrome was the first to announce that they won’t be supporting NPAPI anymore, they were also the first to provide a new architecture in order to rewrite your code to work on their browser. You can take a look on Native Messaging, which “can exchange messages with native applications using an API that is similar to the other message passing APIs”. The problem is that this approach only works on Chrome, is not something that you can adapt to other browsers.
A more useful approach is FireBreath, a browser plugin in a post NPAPI world. Check the words below from one buddy of the project:
“FireBreath 2 will allow you to write a plugin that works in NPAPI, ActiveX, or through Native Messaging; it’s getting close to ready to go into beta. It doesn’t have any kind of real drawing support, but would work for what you describe. The install process is a bit of a pain, but it works. The FireWyrm protocol that the native messaging component uses could be used with any connection that allows passing text data; it should be possible to make it work with js-ctypes on firefox or plausibly WEB-RTC or even CORS AJAX in some way. For now the only thing we needed to solve was Chrome, but we did it in a way that should be pretty portable to other technologies.”
In light of the answer provided by Uly Marins I have researched the options suggested. Unfortunately these options weren't viable for our application, because the mayority of our users do not have sufficient rights to install third party plugins. Additionally the API is still in Beta which won't do any good in a stable production environment.
The main problem we wanted to solve was the abbility to delete files from the accessed folders. It seemed like one of the mayor goals of the removal of the NPAPI support was exactly to prevent this kind of possibility. Therefore we needed to reduce our goals to a simple solution that was still acceptable for our users, with the additional training on how to clear the selected folder manually (because most of our users are almost computer illiterate and needed to access network folders).
Long answer short. The requested solution is just not possible anymore and had to be replaced by a simpler solution and additional training.
Somewhat related to this question I just asked, but I know it isn't good to have multiple questions in one, so making a separate question.
I know Licenses Comparison shows that it is available on all versions (even free) of Unity on all platforms in that list. However, I've found other mistakes/misleading info in that list, so I'd rather hear from someone with experience or someone from Unity.
Also, if I do end up using WWW, I'd need to use a long-polling design (where server waits several seconds, even minutes to reply). Any issues I'll run in to on different platforms?
Main platforms I know I need to target: Windows Store 8 (Surface RT), iOS, Android -- tablets and phones -- probably desktops later (Windows and Mac)
WWW reference
EDIT: I'll be using HTTP and HTTPS in case not obvious (not file: or ftp: protocols).
I have used the WWW-class on PC standalone and Android builds. It worked well with both text and textures. Only platform that requires additional tweaking, that I know of, is the web player where you have to add crossdomain-settings for fetching files.
I talking about Native Client thing for google chrome...
Developers claim it can run native code compiled from c / c++ in browser's sandbox.
They describe a lot of things, but never point at what I need... So, if I create window in my application with CreateWindow, would this window appear when my Native Client application loaded into browser?
In short, no. Two key things to know about apps that use Native Client in Chrome:
They are platform independent (platform-specific calls are
disallowed).
They are still web apps with the restrictions and possibilities that come with that.
If Native Client allowed operating system-specific calls like CreateWindow, it would no longer be platform independent (and it would also present a security risk).
Instead Native Client provides a set of platform-independent APIs called Pepper or PPAPI that work the same for all supported operating systems (currently that's Mac OS, Windows, Linux, and Chrome OS). As mentioned, apps that use Native Client are still web apps, so Pepper gives the same possibilities and restrictions that you'd expect from JavaScript. E.g., you can fetch URLs or ask the user for fullscreen permission, but you cannot access any random file from the local file system (app-specific isolated local storage is possible; as is having the user upload a file for the app to use).
Moving an existing C or C++ codebase to Native Client is very much like porting to a different operating system. Instead of using, say, Windows API calls, your app should use Pepper API calls.
For additional background it may be worth noting that Chrome Packaged Apps can request access to a much wider set of APIs in the chrome.* namespace. These APIs include USB, sockets, opening new windows, and more. A Chrome Packaged App will still not be allowed to make OS-specific calls, but they have access to quite a few more APIs, all of which are platform-independent.
In short, if your app can be made to work with the Pepper API plus the chrome.* APIs, you could write it in Native Client and JavaScript, and you'd have an app that worked the same way across the four operating systems mentioned above. If your app cannot be made to work with those APIs, Native Client in Chrome is not the right choice.
Seems not.
This is a bit related: http://ssj-gz.blogspot.com/2013/01/emscripten-qt-progress-faster-better.html. It's translated to javascript, though, and only for QT. And slow.
Does Apple have a way to find out that an application already is in the Cydia store when I try to submit it to the AppStore?
For Example, if I change the name and icon for an application that appears already in Cydia and try to submit it to AppStore? Can Apple find out?
Is it possible that Apple collects statistics about jailbroken phones and their applications and has this data in its db (by sending it in some background process)?
First of all, I'm assuming that the existing app on Cydia is your app. I certainly don't condone stealing some other developer's intellectual property, just because they released a Cydia store app.
To answer your questions:
Yes, of course. They can just use Cydia themselves and search for your app's name. They could certainly also just use a desktop browser and search for your app's name, to see if there is any obvious copyright infringement. While I don't think Apple feels obligated to do this, I have had apps rejected (before ever being released) because Apple believed my client was violating some other 3rd-party's intellectual property. This kind of search could also turn up a listing in a Cydia store repository. So, it is possible.
I very much doubt Apple would find out about this. Simply renaming the app seems likely to avoid any problems.
I'm not sure I understand the question. Are you asking if iOS checks to see if the device it's running on has been jailbroken, and if so, reports that status back to Apple? I don't know, but millions of users run jailbroken phones, and I haven't seen Apple try to disable their functionality.
I have had clients release apps on the Cydia store first, and then try to release them on the iTunes App store. Although none of those have been approved by Apple, they have been rejected for private API usage, or violation of Apple's Human Interface Guidelines, not because they already existed on Cydia.
I suppose that if an app was released on Cydia, because it used private APIs, and then iOS later added that capability in public APIs, then you could try to submit it to Apple.
I don't work for Apple, so these are only my guesses based on personal experience.
It depends on the repo you put it on. If you put it on a personal repo im sure you will get away with it. It depends on what your app does, it shouldn't really matter to apple as long if it doesn't mod, exploit, change, or use a private API or do any illegal acts/violate copyright it should go right past apple's appstore. They monitor and last time I heard check code manualy.