In a sense would it be possible for both devices to find the correct files and code and manipulate it to point to an ip address of your choice, also you would have to have the offline versions or complete data on your device? Just a thought. And question
- "I keep fingering my tablet"
Related
Sorry if this has been answered earlier.
Recently I have been paying great deal of attention to reversing and debugging applications on the Android platform.
Coming to the point I'm interested in reversing the android apks but don't want to get lost in the creepy smali instructions. For a start I want to begin with some big social apps (you know what I'm talking about) and get a starting point, to begin look into its code, based on any interesting strings in the network traffic.
What I realized so far is that if set a network proxy (I'm using the Windows Emulator) in the Settings>Wirelesss & Networks>Mobile Networks>Access Point Names>your-apn-name>Proxy & Settings>Wirelesss & Networks>Mobile Networks>Access Point Names>your-apn-name>Port, only the traffic generated by the browser (both HTTP/HTTPs) is redirected though my proxy (Fiddler, in my case, 10.0.2.2:8888).
However when I try to debug traffic generated by any other app (say Yahoo Mail), the app doesn't respect the proxy settings and it seems to be a transparent network.
I'm using Android SDK Rev. 11 with SDK Platform ver. 2.2 API 8, rev. 2 on Windows 7 x64. One solution I can guess for is to do a iptables based redirect to my dev machine IP. But where do I get the ARM binary of iptables?
In short all I mean to do is vulnerability research. When I say I want to sniff network traffic on my own emulator, on own machine I'm basically sniffing data that belongs to me, in full, and the intention is purely for research purpose.
Please share your thoughts.
Just install Shark for Root to capture all your network traffic and view it with Wireshark on your PC.
This is truly a general question! I have a new requirement to use a "mobile device" to connect a field laboratory device to a server. Since nothing has been developed, the whole world is open and I'm interested in what "those in the know" might suggest.
Based on input from a user interface, the mobi device must read a small amount of data (less tha 1KB) from the field laboratory device, transfer this to a server. The server will accept the data, save it in a database, and then crunch some numbers which will be returned to the mobile device for display to the user.
I titled this question as "all things to all people" in that the objective is to be able run this application on as many different devices as possible. It is not in our interest to require that the user have "just one more" mobile device.
With that background, what local communications is most widely used - Bluetooth, NFC, WiFi, USB, etc. (A simple serial port would suffice, but apparently that's no longer an acceptable standard!)
My presumption is that the application would be written in Java, but that may be naive. I also presume that the "server" is just a device on the internet, but not necessarily an HTTP application.
I'm open to suggestions...
If you're designing both the server and the laboratory device, USB, Bluetooth and wifi are all viable choices. If you have to interface to an existing device, the device will determine the interface.
If the device is to run on the user's choice of mobile device, you'll most likely have to write the mobile app in both Java (Android) and C++ (iOS).
Hello All,
I originally posted this question in the Android general forum but I didn't get any traction so I'm posting here in the hopes of finding some folks in the community with ideas for this project. I work for a not-for-profit children's hospital. The idea is to create a patient entertainment system (think the LodgeNET style systems in hotel rooms) using less expensive and more open hardware/software. We've purchased a few Android based set top boxes such as the EnjoyTV (I'd post the link but it won't let me) and have managed to get them configured the way we want.
The situation we're struggling with now is managing 200+ of these boxes out in the field. I have a few ideas but no one here really with the Android experience to bounce them off of.
Some thoughts:
- We would like to be able to completely reset the device to 'factory' defaults when patients leave rather than worry about locking down the devices too much.
- We would need the defaults to be our configuration, specific applications installed and perhaps even some hospital branding involved.
- I know I can reconfigure the ADB daemon on the device to listen on the ethernet port as opposed to USB.
- In doing so there is no security but I can handle security in the network layer using ACLs etc.
- I should then be able to use remote ADB commands to reset the device which I can script but what will get reset? Will my cusotmizations/apps go away? Will I have to compile a custom ROM?
- Is there a better direction to go in entirely?
Any help or even just a jab in the right directly would be GREATLY appreciated, both by myself and the kids who will benefit while they're here.
Hi,
I think you need MDM solution.
Ideally you might want to get Device admin rights and then reset it from remote easily.
Dear Members,
Imagine: An Android Black Box without any screen but only USB Power+Data and Wi-Fi ports to be connected with a Lap- /Desk- top computer and the combo used as a Superphone
I have been planning for a long time to use internet — like the thread I had posted in Unix StackExchange in
unix.stackexchange.com/questions/86380/reading-sim-data-via-file-managers-using-usb-datamodem, around September 2013.
There I had posted the links of an idea: If Mobile-> Internet access Modem, why not datacard->mobile, posted in both Knoppix and Debian forums, around March 2013.
A killer of an idea came to me while I began using web.whatsapp.com
I have been doing research on the alternatives of the Android OS available on the web. These two links are sufficient for what I am going to present:
beebom.com/android-alternative/
itsfoss.com/open-source-alternatives-android/
Won't it be easier if, rather than to build free and Open-source alternatives to Android, Android itself is enhanced for its use with a computer, keyboard and mouse, using an app like the Whatsapp Digital Optical Code scanner, to have the display and button- and touchscreen- controls transferred to our lap- / desk- top computers, like we can in Whatsapp via web.whatsapp.com?
In Linux there already are ways to remotely control a desktop via appropriate permissions with a GUI interface.
This way, Google remains happy, while we too remain free from restrictive policies.
There are many emulators already available on the Open Source Linux systems, like QEMU, VirtualBox, and so on, not to mention the proprietary VMWare.
The app needs to have two parts:
(1) A rudimentary functionality of a Transceiver/Emulator, to slip right between the Hardware and the Android OS, creating a "What You Ask Is What You Get" one to one virtual communicator, and side by side, relaying the signals to the main app.
(2) A virtualisation of the user input signals and transceiving the same with the Android OS.
The main application having all the remaining functionalities to connect the Android OS with the Lap- / Desk- top via Wi-Fi, internet and its in-built optical scanner.
Of course, the App needs to have a cloud application to store all the data of the users on the cloud securely via SSL security like Whatsapp.
The App could earn its profits from the revenue structure Google has erected to have the app paid via advertisements. Interested users like us would also be more than willing to pay for the app, I believe.
In the end, again, a device could as well be developed to combine an Android SmartPhone Black-Box (without screen) Hot-plugged with a standard lap- / desk- top and forming a seamless combination of the two into one super-unit via Free and Open Source Software.
To conclude, I seek this opportunity to inform that I am a very empowering closet-entrepreneur, but I have my own limitations because of my inability to accept certain existing structures. So rather than forming an entrepreneurship venture, I like freely to share information. FOSI instead of FOSS, I for Ideas.
What is the best way to watch HTTPS traffic from apps now? I will collect what I have found so far, but hoping someone more knowledgeable will add some points. Feel free to correct or point out other ways of accomplishing this. It feels like regardless of the options, the root of the problems are how to get around certificate pinning.
Emulator vs Phone
This is the first question and probably the most dependent on what you want to achieve. Working on a real device gives more space between your device and the proxy which makes things easier. The extra space is costly in other ways. For example, I would prefer to have a single instance running on the computer to collect information, but using a phone is easier but has the physical requirement of a device connected to the network.
Phone
Physical separation allows for clearer testing. Fully functional device means your input and output work as expected.
Emulator - Waydroid
Emulator running on the same computer causes more complicated networking to ensure you don't block your own traffic. Troubleshooting is trickier as it's more difficult to easily access parts of the emulator that a phone is easy to access. For example, I spent much more time than I would have expected to move a VPN configuration file from my computer to the virtual machine emulator than I would have ever expected. Adding the same configuration to the phone was a simple QR code scan.
Emulator running in a virtual machine allows for a future use case of running the whole thing in the cloud without a physical device.
Proxies
As far as I know, the only way to capture the HTTPS traffic is to use a proxy. This is in the form of an application running on a separate (virtual or physical as mentioned above) device. The hardest part here is the Certificate Authority which signs the HTTPS traffic when it leaves the app. More sophisticated apps, to prevent fraud, do a variety of actions to prevent the user or 3rd parties from capturing the data in each HTTPS request.
mitmproxy
open source, link
I tried this first as it comes with Python library which would make capturing data for later analysis much easier. Mitmproxy has a few different modes, and ultimately I found that `mitmproxy --mode wireguard` which runs via VPN captured a good amount of traffic, but still had target SDK traffic unable to be opened. Mitmproxy has a built in tool to help installing the certificate in Android as a user certificate. This will capture some HTTPs traffic, but for some apps and many SDKs this does not capture their traffic. Traffic can be captured in several ways: CLI tool for analysis of live traffic in memory, CLI dump to file and in memory live in browser of choice.
Charles Proxy
free for 30 days, shareware, link
I first used Charles nearly 10 years ago, and it doesn't feel like it's changed much, but is actively maintained. When I first started using Charles it was a breeze to use, CA was less of a problem. But as Android changed it also now has the problems of CA needing to be installed, and helps the user by providing it's own signed certificate which can be installed as a user certificate. Charles is a standalone program that you run and as such it does have a fair amount of issues on my linux environment related to it's display sizes. .
Burp Suite - Community Edition
paid/free, link
Community edition that is free to use. Runs in browser and comes with it's own CA tool.
Android Certificate Authority
These are the certificates used to sign HTTPS traffic to keep it secure. In Android there are three levels: User, System (root) and App Pinned Certificates. In Android settings you can add a CA which will be considered "user". Apps can choose whether to ignore this certificate. System CAs can only be set by a root user. While a user can install user CA's, apps do not have to use these. CAs can be set by users as root certificates. I believe this must be set regardless of device or VM. The majority of the certificates provided by the proxies don't seem to open a lot of HTTPS traffic. This is likely because Android N (API level 24) certificate pinning was introduced in 2016 and at this point most SDKs and Apps use this for transferring traffic.
JustTrustMe
open source, link
This is installed on a device or emulator. An Xposed addon that can be installed to force apps to use root authorities and prevent them from pinning their own CA.
apk-mitm
open source, link
This can be installed in a separate linux environment and is used to modify an app's apk before being installed into a VM emultator or phone. It attempts to get around the app's certificate pinning by patching the APK to disable certificate pinning.
This is just my notes on what I'm looking into. I figured I'd post here to see if anyone has some advice or pointers. Please feel free to correct / add to this! Meanwhile I'll also keep my notes here if it helps anyone.
To anyone later who is interested in this topic, I was able to finally get a working solution using Magisk + LSPosed and two certificate modules which unpinned certificates and set my user certificate to system. I wrote my detailed steps here if anyone needs the help.