The question is related to this one: How to check obfuscation results of flutter app?
But the answer there is unclear.
Is it possible for hackers to see the dart code in flutter apps? Or is it compiled in a way that is difficult to understand and track?
After unzipping the apk that resulted from flutter build apk - the only file I found related to my own Dart code was "libflutter.so". Looking at the functions in it by nm -D libflutter.so didn't show anything resembling my code, so it seems pretty safe. But - I would like someone who actually knows to confirm, perhaps I missed something.
What is the best practice used to publish flutter apps?
UPDATE - December 2019 - the following post says that if the app is compiled in release mode, then the dart code is compiled to assembly, which is pretty hard to reverse engineer: https://medium.com/#rondalal54/reverse-engineering-flutter-apps-5d620bb105c0
In debug mode flutter apps are jitted from source. This requires the source be distributed with the app. However you shouldn't be distributing a debug build, so let's not worry about that possibility.
In release mode your source is AoT compiled, so there is no actual copy of your source, but if someone wanted to recreate it, they could potentially (easily?) reverse engineer it from assembly.
If you want to obfuscate your compiled code, your best bet is probably to follow the advice given here:
https://github.com/flutter/flutter/wiki/Obfuscating-Dart-Code
I don't claim to be an expert on this so please do your own research, but hopefully this points you in the right direction.
Further reading about the build process:
https://proandroiddev.com/flutters-compilation-patterns-24e139d14177
Related
I am facing the project which should be as many other "boost cleaners". I'd appreciate any advise on this theme. As far as my research goes, I see, that it is quite more difficult to do in iOS, rather then Android. I don't hope for any good lib out there, and should probably do platform channels.
In general I need right now somehow get all device info - memory, battery, installed apps, cache, etc.
AS I've said, I had done a bit of research, and see the problem as stated.
If you can use Libraries for it i don't think there is any library which can support all info so you will have to use multiple libraries.
Just make sure library should support all the platform you want to build you apps on.
https://pub.dev/packages/system_info_plus.
https://pub.dev/packages/battery_info.
https://pub.dev/packages/device_info_plus.
https://pub.dev/packages/installed_apps (Only Android)
I am having an issue with SqlCipher and Akavache on iOS. When I add the Akavache library to my project with an existing implementation of SqlCipher I get a number of duplicate sqlite errors during linking.
What is the current behavior?
When I build iOS with Link SDK assemblies I receive the following
Sqlite Linking Errors
If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem
Install/Implement SqlCipher
Install Akavache
Build Xamarin.iOS project
What is the expected behavior?
That Akavache Sqlite and SqlCipher Sqlite just work together.
Which versions of Akavache, and which platform / OS are affected by this issue? Did this work in previous versions of Akavache?
Akavache 5.0.0
iOS 10.3
I wouldn't know. SqlCipher was implemented months ago, and we are just now adding Akavache to the project.
Other information (e.g. stacktraces, related issues, suggestions how to fix)
Linking is set to SDK Asemblies only
This is a Xamarin Forms project and the Android Linking does not produce the same result.
I am actually able to execute the code on Android and have proven that the technologies play nice (from what I can tell)
I contacted SqlCipher and the recommended approach is to fork Akavache and swamp the following line of code with another
implementation.
https://github.com/akavache/Akavache/blob/develop/src/Akavache.Sqlite3/SQLite.cs#L224
Before I go down the road of maintaining a fork, I was wondering if there is better way?
What you're effectively doing here is adding Akavache, which contains a custom SQLite build, to an app which already contains a custom SQLite build. And because of the way iOS linking is done, that's a problem.
I doubt you actually need a "fork" of Akavache. What you really need, IMO, is an implementation of Batteries_V2.Init() which talks to the SQLCipher instance you already have in your app.
This is doable, as SQLitePCL.raw already contains multiple implementations of this "bundle" concept, and uses bait and switch to change from one to another.
Your question is equivalent to one I get from time to time: "How do I use a custom SQLite build with SQLitePCL.raw?" The only difference in your situation is that you already have such a custom build as part of your app. Anyway, it's similar, and unfortunately, SQLitePCL.raw doesn't make this as easy as it should.
Anyway, explaining how to bridge the gap between Akavache and your existing SQLCipher build is probably beyond the scope of this SO answer, but I might be able to help you head in the right direction. You can post an issue on https://github.com/ericsink/SQLitePCL.raw and I will see it.
I have minimal interest in adding Cipher support to Akavache. If you can find a non-terrible way to do it then release it on GitHub for others. Akavache already has an encryption API via http://kent-boogaart.com/blog/password-protected-encryption-provider-for-akavache
It's a little concerning that the authors of Sqlite Cipher are recommending removing that line as it means you'll also run into and experience problems with the greater Sqlite ecosystem, including azure mobile services.
I'm working on research that requires me to be able to load an iOS app from a custom piece of code running on the device. I more or less want to modify the current sandbox and then run an existing application in it. I would rather not modify the application, although I realize at some point I'll at least have to re-sign it.
Mocana can apparently do this with their "MAP" technique, but I've not seen any papers or presentations explaining the technical details of how this is accomplished.
I was attempting to dlopen an application's executable and then dlsym on it's main. That moderately works, but requires a debug version of the application. Trying to use an archived version is problematic since the symbol table is separate. Not sure if there is a way to merge the symbol table with the executable. Tried unsuccessfully with lipo, but no real luck (says the architectures are the same and won't merge).
Any direction or good publications would be appreciated.
I was trying to get the header files from the ToneKit framework on iOS7.1, but I found that I cannot use class-dump because there are no executable files inside the framework. From what I have found after some research, it seems as if the actual executable file is inside the dyld_shared_cache on the device. After reading this article, it seems as if there are some tools to decrypt the cache, but since iOS 3, Apple has implemented ASLR which has made the decryption tools not work. How can I extract the Frameworks from inside the dyld_shared_cache on iOS7.1?
I am very new to jailbroken ios development so please bear with me.
If you're interested in how they got those headers then the answer is very simple - iOS SDK. SDK contains ARM binaries of public and private frameworks because they are required to compile iOS applications. Class-dump them and you will get headers you need. ToneKit.framework binary is also in there.
Usually you don't need dyld_shared_cache, almost everything you need is either in iOS SDK or on a device itself like SpringBoard, other system applications etc.
Of course there are rare cases when dyld_shared_cache is the only place you can find certain binaries as they are missing from both iOS SDK and device. In that case I use IDA. It has free demo version that can open dyld_shared_cache files - you can even open individual binaries inside it rather than dump everything. You just need to copy dyld_shared_cache on your PC.
I think Elias Limneos's classdump-dyld can help you. If not, check out RuntimeBrowser. Failing that, even, weak-classdump has proven to be a very useful runtime tool for me.
I am using cordova-brunch in a project and I would really like to not have to re-run the cake build:ios:dev command each time I modify the JavaScript/CoffeScript source. Even more since I usually have to also make changes in the iOS Objective-C code for my hybrid app and I generally rebuild the App from XCode forgetting to rebuild the JS/CS part.
The behaviour is identical for Chapless Brunch and Cider Brunch, but I still don't get what prevents a cake watch:ios:dev functionality. The available cake watch:cordova:dev doesn't solve the problem.