I want to setup this app called Http Toolkit and for some reason I have the warning "System Trust Disabled". My android device is not rooted.
This is due to limitations in recent versions of Android. On unrooted devices, it is impossible to install system certificates.
You can still intercept HTTPS traffic using just user certificates, but you will only be able to intercept apps that opt into this by explicitly trusting user certificates. Most apps don't do this, so this is useful for debugging your own apps, but not for reverse engineering other people's.
You have a few options:
You can root your device.
You can use an emulator - any emulator except the official 'Google Play' edition emulators will give you root access.
You can use user certificates only, and modify the app to trust your user certificates either by editing the network security config if it's your own app (instructions here: https://httptoolkit.tech/docs/guides/android/#intercepting-traffic-from-your-own-android-app) or using tools like apk-mitm if not to modify the APK (this can work easily, but not always, so in many cases you'll need to do some manual app modification).
There's a lot more info in the HTTP Toolkit docs here: https://httptoolkit.tech/docs/guides/android/
Related
I just got a mail from the Firebase support that my current API key restrictions for the Firebase API key lead to malfunctions for the Firebase Installation API. Since, I have a web application and not an iOS or an Android app, I´m assuming that this is not a real issue for me at the moment.
However, this got me wondering if I enabled all necessary HTTP referrers (websites) in the Google Cloud Platform to ensure a working environment for my web application. Let´s say my domain is called www.domain.com and my Firebase project is called projectx. I currently have these two entries in the HTTP referrers for the Application restrictions:
www.domain.com/*
projectx.firebaseapp.com/*
Is there anything else I should enable? Because I saw that Firebase also enables multiple domains such as projectx.web.app by default.
It's fairly simple: you need to enable the domains that your app uses.
The two domains you have are the defaults for cases where you have a common domain:
www.yourdomain.com/* is the custom domain that you typically share out with people.
projectx.firebaseapp.com is the default domain generated by Firebase, and is typically also used in sign-in screens (although you can change this).
You may also want to add:
projectx.web.app, which is a newer default domain that Firebase creates. But this is not required, so only add it if you expect to hand it out to folks.
localhost, which is handy for local testing
"Trusted" and "Privileged" server environments are frequently mentioned in the docs for Firebase, but there's no formal definition. What are they?
How do I make my server trusted or privileged?
While what "priveleged" or "trusted" server environments are is not explicitly searchable (prior to the creation of this Q&A), it can be inferred from the following excepts.
In the docs for FCM setup, is the following excerpt:
The server side of Firebase Cloud Messaging consists of two components:
The FCM backend provided by Google.
Your app server or other trusted server environment where your server logic runs, such as Cloud Functions for Firebase or other cloud environments managed by Google.
Your app server or trusted server environment sends message requests to the FCM backend, which then routes messages to client apps running on users' devices.
And in the docs for general setup:
Firebase projects support Google service accounts, which you can use to call Firebase server APIs from your app server or trusted environment. If you're developing code locally or deploying your application on-premises, you can use credentials obtained via this service account to authorize server requests.
Important to notice is that both explicitly say "app server or trusted environment" which implies the two are different things.
Further, the first excerpt (though somewhat semantically ambiguous)
that examples of trusted environments are "Cloud Functions for Firebase or other cloud environments managed by Google."
Finally,
in the second excerpt is the information "If you're developing code locally or deploying your application on-premises, you can use credentials obtained via this service account to authorize server requests"
From all of this it can be inferred that:
Trusted and Priveleged Environments are generally things internal to google and therefore intrinsically trustworthy
App servers are generally anything which has access to the right credentials
And finally, you do not need to take any steps beyond having the correct credentials to make your server a "Trusted Environment." It does not need to be a "Trusted Environment," because what that term really means is "Owned by Google."
A trusted environment is an environment where you control what code runs on it. In the context of apps built using Firebase, this sets them apart from the devices your regular app runs on as malicious users can take your app configuration data and run their own code with that.
I often explain trusted environment, as:
Your development machine, since you're usually the only one working on that.
A server (or VM, container, etc) that you control. Only you (and people you trust) should have access to the server, so shared servers are not a good fit.
Cloud Functions, since only collaborators on your Firebase project can deploy code there.
I've been trying to use AWS SNS service to send notifications to Apple Sandbox environment . I think I setup everything ok and my dev iPhone can get notification without trouble.
But when I start to send notifications to others who install the test app , I keep seeing error message state that
Platform token associated with the endpoint is not valid
With a messageId :147975e0-8a09-5223-8537-256320ab3733
From what I understand , if one device can success, others can success too.
Could anyone tell me how to debug this probelm.
Thanks.
I believe that the apps that the other people are installing were not built with a dev cert (probably built with an adhoc or production provisioning profile), so you probably should use the production certificate.
You could try adding another application on SNS using the production certificate (or the same one, but not using Sandbox, depending on how you generated it), if it works, that this is it.
Also make sure you are using the correct bundle id associated with the certificate.
I have developed an app for an open source home security solution (ZoneMinder). The app I developed is called zmNinja (open source again) - and it works rather well. I am now implementing a mechanism to push notifications (motion detection alarms) to people who will use the app.
After going through the APNS and GCM documents, it looks like the "server" which sends the push to devices must integrate with SSL certificates and API keys generated from Apple and/or iOS. And this, specifically for apple requires a developer account.
Therein lies the predicament. Users of 'zoneminder' install their own servers. There is no central server. I've developed a event server that works with 'zoneminder' on web sockets that can be installed along with zoneminder and it sends notification when there are new alarms. This works very well on Android because Android allows the web socket to be open in background but iOS kills it (I can't treat the socket as VoIP/Location/content-news as its none of the above). Hence I am thinking of how to support APNS in the server. In other words, even if I can't do GCM for Android, there is still a way to receive alarms. No such joy for iOS users.
The problem is that like I described above, I won't be hosting the server. The users of the app will own their own server.
Given this, is there any way to support push notifications in IOS without requiring everyone who has their own servers to have apple developer accounts? I assume I can't give my certificates to them either as that would compromise my account.
Thanks
I have built an application with Firebase and I've also made a desktop version available with nw.js. The point of this being to allow for better offline usage in areas with bad or no internet (and it will sync when the user gets internet again). Now, I can disconnect just fine and reconnect while the app is running, but I want to be able to fully close and reload the application. I've seen this blog post from firebase, but it appears this only works for mobile platforms.
Is this currently possible on the web platform, too?
All Firebase SDKs will handle intermittent loss of connectivity (driving through a tunnel). But disk based persistence, which allows the data to survive an app restart, is currently only available in Firebase's iOS and Android SDKs.