as we write passwords in key.properties file for signing flutter APK. its not dangerous? how we can make it secure after debugging and reverse engenearing?
storePassword=
keyPassword=
keyAlias=
storeFile=
This is already a secure mechanism that is followed by Android.
Full Article : Article to refer
In Brief:
Creating a keystore file is quite similar as storing configs in environment variables, By default if you generate or sign app using android studio it stores the credentials directly in the gradle file so instead of this when we are working in teams we store these in a different file which is not included when we build and also can be excluded when from source control using .gitignore
So we use this keystore variables while signing the app instead of hard coded strings.
Another reason is the .jks file which is indeed really important exists on your pc only and without which you cannot compile the app.
There are practices that you can follow to ensure security like using Proguard and code obfuscation, flutter still is in growing stage so they would likely ensure the use of NDK with which one can write the files natively into .so files, which are much less likely to be decompiled than APKs.
To keep the file private, add it to the .gitignore file:
**/android/key.properties
Related
I am building a flluter application.
I don't want to compromise my secret_key by putting it in the code, so I tried making a .env file and created an apk. Then I unzipped the apk and found my config file there. So now I am not doing that.
The next thing I tried is using --dart-define variable declarations to put my secret_key while building the app and I am accessing it using
const secret = String.fromEnvironment("secret_key");
Coming to the question, where do these variables go inside the dart code and is there a way to get them by reverse engineering.
Basically is it safe to put my secret key this way?
From what I found, you can find the --dart-define variables in the binary file generated for each ABI, so yes, you can reverse-engineer it.
How to try:
Call the variable from your code with String.fromEnvironment("ANIMAL").
Run flutter build apk --dart-define=ANIMAL=Dog to build for Android
Open the generated .APK file with a file archiver (7-Zip, for example) and navigate to /lib/(ABI)/
Open /lib/(ABI)/libapp.so file with a text editor or hex viewer and search for the value Dog and you will find it
Observations:
If you don't use the variable in your code, it won't be added to the binary
Using --obfuscate with flutter build won't help, because it doesn't obfuscate environment variables
In sign tool I'm getting the error: bad executable.
I'm sure this has something to do with the application already being signed.
How do I remove the signature from the application.
I made it by unreal and I've heard unreal automatically signs the app on export.
I also heard if you change the extension to .zip, and then back to .exe or .appx, it will remove the certificate. But I tried that and had no luck.
By the way I don't use visual studio is there an straight forward way of doing this?
Thank you.
This will help. It is a utility called delcert with soure code on xdadevelopers. It removes digital signatures (Authenticode) from executable files.
Also check that you are running the correct version of the signing tool (32/64 bit) for the executable you need to sign.
I'm interested in Qooxdoo as a possible web development framework. I have downloaded the SDK and installed it in a central location on my PC as I expect to use it on multiple projects. I used the create-application.py script to make a new test application and added all the generated files to my version control system.
I would like to be able to collaborate on this with other developers on other PCs. They are likely to have the SDK installed in a different location. The auto-generated files in Qooxdoo seem to include the SDK path in both config.json and generator.py: if the SDK path moves, the generator.py script stops working. generator.py doesn't seem to be too much of a problem as it looks in config.json for an updated path, but I'm not sure how best to handle config.json.
The only options I've thought of so far are:
Exclude it from the VCS, but there doesn't seem to be a script to regenerate it automatically, so this could be dangerous.
Add it to the VCS but have each developer modify the path line and accept that it might need to be adjusted whenever changes are merged.
Change config.json to be a path and a single 'include' line that points to a second file that contains all the non-SDK-path related information.
Use a relative path to the SDK and keep a separate, closely located copy of the SDK for every project that uses it.
Approach 1 would be ideal if the generation script existed; approach 2 is really nasty; I couldn't get approach 3 to work and approach 4 is a bit messy as it means multiple copies of the SDK littered about the place.
The Android SDK seems to deal with this very well (using approach 1), with the SDK path in its own file with a script that automatically generates that file. As far as I can tell, Qooxdoo puts lots of other important information in config.json and the only way to automatically generate that file is to create a new project.
Is there a better/recommended way to deal with this?
As an alternative to using symlinks, you can override the QOOXDOO_PATH macro on the command line:
./generate.py source -m QOOXDOO_PATH:<local_path_to_qooxdoo>
(Depending on the shell you are using you might have to apply some proper quoting of the -m argument). This way, every programmer can use his locally installed qooxdoo SDK. You can even drop the QOOXDOO_PATH entry from config.json to enforce this.
We work with a symbolic link pointing to the sdk ... config.json contains just the path of the link.
I'm trying to get my ad hoc build distributed but have started experiencing problems. It used to work up until around a week ago, but now ITunes gives an 0x8008017 error when I try to Sync.
I've narrowed it down by using the iPhone Configuration Utility and then discovering the error seems to be coming from a failed code sign. I've ran codesign -vvvv myApp.app and the outup lists a load of missing resources from my Help documents (from my Apps Resource folder). each missing resource begins ._ so for my index page:
01 - Index.html
the codesign is also expecting: ._01 - Index.html
It also has the existing file listed (as it should) but fails because all ._files are not included in the app.
I've looked through my projects directory and can't find any files beginning with ._ so am not sure where the codesigner is getting these filenames from, but they are included every build, after a clean or an Xcode restart.
All the resources that are causing problems are all recently updated files that I copied over the old resources at the beginning of the week; might this be something to do with it?
Any help appreciated
Make sure you do one of these:
copy those files with an Xcode Copy Files phase, which should Do The Right Thing by default, or
exclude resource forks and ._* files if you copy through a script, or
make sure you build on HFS volumes (where ._* files are not generated for resource forks).
Sounds like your partition type is generating resource-fork files which are also being signed as separate files in the bundle, rather than as part of the original files (which is bad); and then, they're also not getting copied (if you use Finder zipping, they'll be removed and set aside in a different portion of the Zip file, IIRC), again bad. Avoid having them in the bundle, so they don't get signed and you don't have to wade through this mess :)
I'm collaborating on an iPhone application, with the project files (.xcodeproj directory) checked into source control. One important setting is the "Code Signing Identity", which specifies the certificates to use to sign the application in order that it can run on the iPhone.
Each developer on the project has his own Code Signing Identity, so whenever anyone makes a change to the project, his Code Signing Identity gets saved into the project settings, and then everyone else inherits that change. They then have to change that to their CSI before they can continue.
Is there a way to have the Code Signing Identity saved in some local per-user project file that doesn't get checked into source control?
You could base the Xcode project on an .xcconfig file, then make each developer use their own .xcconfig file and keep the identity setting in there.
Either that or have your source control system ignore the file that contains the signature, in git you can create a file called .gitignore, theres probably a similar thing for what you are using. It means even though you've changed it the change won't get mirrored.
I worked around this by making different builds. The one named "Dev - Rob" had my settings in it, and the one named "Dev - [Other Guy's Name]" had Other Guy's settings.
We also used this to make builds like "Release - Beta" and "Release - AppStore" etc., for all situations where we'd have different signing configurations.