Hello everyone,
I wasn't sure if this topic should be here or at the Android Software Development section, so i'm gonna write it here.
I am interested in building an app, so that voice calls (not VoIP) are end-to-end encrypted. What i want is to modify an existing ROM, in order to implement a cryptographic sheme, so that when someone make a voice call, it will be encrypted, and decrypted at the receiver's android device.
The purpose of course is to keep any phone call safe from the provider. First of all i am wondering if this is possible.
As soon as it is possible, which is the best way to achieve it? Modifying the device's baseband (modem) or interfere in the audio system?
Is there a cryptographic module suitable for this kind of operation, so that information could be decryptable when reaching the other end?
The above project will be used for research purposes, so i don't mind if this kind of manipulation is illegal, yet.
Every suggestion is welcome.
Related
Hello to all on this forum.
I have a Flash application that I want to develop into an Android app. I would not require some of the bells and whistles that are currently on the application, but a simple sub-set of how it works now. The flash application can be found here:
FastFood.com/nutrition/
(Hope this URL is allowed here as it will help people understand what I want to do.)
I have all the source files and programming for this and hoped they would be of some help in developing the Android app. But of course, I have no idea if this is any help at all to whoever develops the app for me.
Anyway, before trying to source a developer to do this for me, I thought I should ask a few questions to see if this is even something practical. So I hope some of you can give me some guidance regarding my questions.
1) Are most applications stand alone in the mobile phone, or is it common for some of these apps to access the network to get the necessary data required to operate? My purpose requires a database that is currently 14 megs, and must be accessible to the app, although only small portions of it are needed at any one time.
2) Are there varying systems within the Android family, or versions of the operating system that need to be accounted for?
3) Are there good reasons to develop for both Android and iPhone together? I mean from a cost to develop point of view? Or would it likely be just as effective to develop for Android, then move on to iPhone, or others, as is appropriate?
4) I am guessing that if you have looked at the flash version of our Calorie Counter, you could probably give an educated guess as to what it might cost to replicate a scaled down version for Android. So please, take a stab at it if you can.
Thanks
Hello,
I was wondering if someone could point me in the right direction for a Bluetooth Networking Project I'd like to do.
The ultimate goal:
- Having some sort of bluetooth app with root privileges, which, when walking past someone, would allow some sort of passive communication without the users authorisation nor involvement.
This is similar to the idea on the 3DS called "SpotPass":
(I would have posted the link, but I'm not allowed to)
I do not have much experience on the subject, but suppose it would involve having root permissions to access the bluetooth module, being able to broadcast a message (to other users of this application).
I'm not sure if this might involve creating a completely different driver.
The reason is actually to create a short-distanced-passive-communication application useful for getting short messages or announcements across, with the low power consumption of bluetooth (vs wifi).
If this kind of communication if not possible, could someone please explain why, or at least give me some sort of link with the reason.
Thanks in advance
Hi.
I have read the rules of the sites but I'm not able to decide what is the best course of action here, so I need some advice please:
There is a piece of software out there, which I do like and I think it is very useful, BUT it has some serious limitation, for example is not able to run on Android 5.0 or higher and it cannot be automated. I have contacted the software developer and I have asked for support but I was turned down. After this I have reverse engineered the application and started making the modifications myself (editing smali files), now the application works on Android 5.0 and can be automated, but it does not work on anything below 5.0, plus some of the procedures have been totally rewritten. The question is in this case is it ok for me to remove the original license and share the app, or not? It is the same application, yet it isn't because it is targeting different platform.
Your input is highly appreciated.
Thank you.
No, this is not okay. You're essentially taking someone else's work and modifying that work. Without the original app, you would have nothing to begin with.
Thread closed.
borconi said:
Hi.
I have read the rules of the sites but I'm not able to decide what is the best course of action here, so I need some advice please:
There is a piece of software out there, which I do like and I think it is very useful, BUT it has some serious limitation, for example is not able to run on Android 5.0 or higher and it cannot be automated. I have contacted the software developer and I have asked for support but I was turned down. After this I have reverse engineered the application and started making the modifications myself (editing smali files), now the application works on Android 5.0 and can be automated, but it does not work on anything below 5.0, plus some of the procedures have been totally rewritten. The question is in this case is it ok for me to remove the original license and share the app, or not? It is the same application, yet it isn't because it is targeting different platform.
Your input is highly appreciated.
Thank you.
Click to expand...
Click to collapse
Let me re-ask the question in this way:
An individual is producing and distributing a vehicle called Neo-is-teh-Awesome-one, but it only runs on jet fuel. Along comes a smart individual who knows that people are starting to use water for fuel these days and it's much cheaper! This change would actually make more people want to buy and drive tehawesomeone and it would really help the other guy out a lot! However, he refuses to assist the smart guy for whatever reason about the potential modifications, yet the smart individual figures it out on his own anyway. The only problem now however, is that it now ONLY runs on water which is ok quite frankly because water is the future!
My question is this: Can he re-name the car to Water-Hydrates-FTW and go ahead and re-distribute/produce it for everyone as his own creation?
Have a pleasant day and congrats on making whatever it is work for 5.0 :good:
So I am going to post this here, because the development section is ferboten to people trying to offer useful suggestions. Geez, I hope this is the right section.
Let me set it up. ANDROID IS BASED ON THE LINUX KERNEL. Everything, and I mean everything after that fact becomes android and bloat. Given this as the basis of all things android, I have a simple set of guidelines that should be used to create a solid, reliable, bullet proof operating system for devices able to use the android operating system.
#1. Create the kernel boot section of the basic platform that supports the very basic hardware features, including touch screen, radios, power/charging/battery management, wifi, bluetooth, nearfield, audio, microphone, s-pen,etc. Basics only. Root access is standard and can be turnd on/off just like developwer functions. No special tricks or addon hoops to jump through.
#2 At this point STOP. Every single process or service to be run on the device from this point forward should be able to be individually selectable - or not. Yes, I understand that individual services or apps may have dependancies to other processes and that thouse need to be functional in order for a particular app to work. That is why, each additional service or app must list the dependencies and in the selection process, the installion will be required to verify you have the proper services installed and functioning, if not to list them and allow you to make the decision to proceed. Viola, we have NO MORE BLOAT WARE.
#3 Make selecting additional services/apps selection process a menu driven, tag selectable process. Make the unselection process smart to verify and identify the other apps dependant on the item you are killing/removing.
#4 Allow a built in snapshot option to capture the entire system as you have customized it for yourself and allow it to be backed up to external memory with the ability to bring it back, AT WILL. With no big hassles.
Those 4 items are a good start. By themselves alone, it would put all of us in the drivers seat of controlling and living with our devices.
I am aware that such a system is not for everyone. It does require some basic technical understanding of the process. But for the vast majority of users, I am certain, that an a la carte system is far superior to the bloated monstrosities being forced down our devices.
I would appreciate any refinements to my suggestions.
The silence is deafening. It has been days. Kind of says something, don't you think?
I am so very happy (not) that these boards a compartmentalized to the point where you can't get through.
Pretty much a waste of my valuable time, especially considering the fact that if my suggestions where applied, people would be clamoring for an installation with those features. I guess there is not much true "developer" in xdadevelopers anymore.
Funny guys, with the pay to remove ads spam here. Really? Why? For what.
I leave here disappointed. Not angry. Just sad.
I'm not a developer so I have nothing valuable to contribute to your suggestions in your original post but I can offer an observation regarding your perception of the level of contribution to your thread and that is the fact that is particular area of the forums probably isn't the ideal spot to have a discussion such as this. You figured that out already so sure you can call me Capt. Obvious if you wish but I'm just pointing out that yes the forums are compartmentalized (as you've stated) in such a way that development for each device is separated out. This development is centered around AOSP based ROMs or "stock" ROMs (using manufacturer released source) so if you're looking to have higher level discussions about what AOSP should look like then deep down at this device specific level probably isn't where you want to be. So there's that . . . then there's the fact that for this particular device you can basically hear a pin drop in the sub-forums as it is since nothing much is going on by way of development.
Where specifically such a discussion would see more input I'm not sure, perhaps the main general discussion section?
Thank you for your sobering reply. I get frustrated. Already had my post bounced out of "wrong" forum while trying to speak directly to "developers" (i wanted air quotes because the term does not accuratly describe its target) So I tried this. The note pro 12.0 is still the best hardware giving the ipad a run for its money. The problem its monkeyshines kiddie software running it, or not running, or barely running it. ANDROID, indian word for crappy wannabe software, developed by clueless kids.
Again, thanks for the gentle nudge. I appreciate someone willing to conduct a conversation
Are you looking for an Ubuntu or SUSE type of setup?
I think what you are looking for is similar to apt-get type of installs, I could be wrong of course. This might be helpful for many "users". I think one of the barriers is that there are slight differences between the models of tablets, and creating the logic to put in for the sub-dependencies might prove problematic. You might get more answers to this possibility by asking one of the developers directly and sharing with them. Not a developer myself.
I'm working on a personal modding project, where I take the AOSP Dialer and add some features that I'd like to have. Long story short, for a component of this, I need to figure out how Google has been able to inject arbitrary audio into the conversation/call audio stream.
For years, discussion online, and especially on Stack Overflow, has insisted that:
There are too many upstream limitations, this is impossible
This is impossible, you have to play it over the speaker and hope the microphone picks it up
You can't do this, even Google says so
Indeed, even Google's up-to-date MediaPlayer documentation clearly shoots this down and doesn't mince words:
You cannot play sound files in the conversation audio during a call.
Click to expand...
Click to collapse
However, we know this isn't true. At least, not anymore, and not on Pixel devices. Google's Call Screening feature can "talk" to someone calling your phone, but that synthesized audio is never played audibly to the user. In other words, Google has been able play a Text-To-Speech stream of audio to someone calling your device, doing so silently, clearly to the listener, and without requiring the handset speaker or user's microphone to be "on."
Despite the fact that this is "possible" by virtue of "it has already happened," I can't find any discussion, documentation, info, or anything helpful about how Google has been able to do this. So, what do you do?
The next logical step is to start decompiling the app, but that's easier said than done. I'm by no means an expert in reverse engineering Android apps. Admittedly, you could consider me a beginner. Still, I've found a few things that seem useful, so here's what I've been able to find:
First off, when compared to the AOSP Dialer, the Google Dialer requires an additional privapp-permission that may be of interest: android.permission.MODIFY_AUDIO_ROUTING. I can't find much about what this permission does or how it is used, but it's definitely used by the Google Dialer, and on a stock Pixel 3 XL ROM, that permission is defined in /product/etc/permissions/privapp-permissions-google-p.xml as a privapp-permission.
Next, when decompiling the app, one of the first things I noticed is that a special "IMPL" package containing a playInternal function is class injected/loaded dynamically, and it's adjacent to MediaPlayer code that seems to play audio over a certain channel. The class it tries to load is:
Code:
com/android/dialer/audio/impl/CallAudioPlayer
However, that package isn't present in the list of decompiled classes (there's no "audio" folder under "dialer"), and despite playInternal being explicitly called by a string, there aren't any other classes that seem to define the playInternal function.
I don't know where XDA stands on posting decompiled code, but if you're using JADX, the area of interest is in defpackage/bhk.java.
But if I'm correct, this means that:
You can use MediaPlayer to play over the call stream, contrary to Google's documentation; you just need a special IMPL that allows for that behavior
This (probably?) requires the aforementioned MODIFY_AUDIO_ROUTING permission
If one were to obtain/locate and re-implement CallAudioPlayer.java, you could probably reproduce this behavior in the AOSP Dialer, or any other system app with the necessary permissions
If I'm not correct, then chasing down CallAudioPlayer will be a dead end. Still, the fact stands that Google did this somehow, so the answer must be somewhere.
So... that's where I'm at with this. I don't feel like I'll get much further without some help from more knowledgeable people, since I don't know where this CallAudioPlayer class is located. If it's in the base apk, but obfuscated, I can't find it. And if it's in a system framework or overlay APK, it must be using a different name, since no instances of CallAudioPlayer or playInternal exists in any of the relevant .apks on my system.
If this requires more sophisticated Android system/API modifications, that's fine too. This will end up on a custom ROM, so even if part of this behavior extends outside of the APK, any potential solution can be implemented in an AOSP ROM to achieve this functionality.
If you have any advice on how this may have been done, I really appreciate any and all discussion I can get on this. And if you don't know, I encourage you to ask a friend or someone who might be more knowledgeable when it comes to reverse engineering. Even if no one outright knows the answer to this, I hope to get at least some recent discussion on this topic, so that people investigating this in the future will at least have some sort of starting point.
Thanks for reading!
Hi. I'm no expert on Android (far from that haha) or Reverse Engineering. Though, I'm making an assistant installed as system app in a rooted Android and can also be compiled with the hidden and internal methods and classes so they can be used, like ITelephony, for example (https://github.com/anggrayudi/android-hidden-api) - btw, have you tried to mess with those classes and methods? (Sorry for my ignorance, I've no idea how it is to code/recode a ROM, what you need to use and stuff.) And anyways, I found something you didn't mention up there, so I'm unsure if you already know or not. From what Google says here (https://support.google.com/phoneapp/answer/9118387) in the "Screen calls manually" section, "Your Google Assistant screens the call and ask who's calling and why. You'll get a real-time transcript of how the caller responds.". Though, if it's their assistant doing that, not sure why that permission is on Dialer and not only on the assistant. Anyways, maybe that could be a good place to look at?
EDIT: Maybe also you (or anyone, of course) could look at sending DTMF tones over the call (I only made a quick search on Google, but there may be more that could help on this?). I think it's the same thing as it's inserting audio into the call. Though I can't be sure - btw, if it's really sending audio, then any Dialer app can already do that! But may not be that simple, so no idea at all. Maybe that's hardware thing and not software (>95% probable?). Just trying to give to ideas on where more to research.
Here (https://issuetracker.google.com/issues/36906273#comment107) it's said "I found this app, that can send dtmf after the call is made and active: https://play.google.com/store/apps/details?id=mobi.drupe.app (...)" - name: "drupe - Contacts & Caller ID" (just in case the app gets deleted from PlayStore and then people don't have their name to search for, only the package). If it's audio that it's being injected then it's possible, since that app seems to do it already, and the answer could be there too and might be good to look for the keys' frequencies on the code? Again, sorry for my ignorance on anything wrong I said. As I said in the beggining, I'm far from expert/experienced on Android.
I'll also be trying to search on how to send DMFT tones over a phone call. Could help, maybe. And if only a frequency could be sent for any reason, at least it's already cool to send some beep haha (preferably different from the ones of the keys or it might be confused with a key press by the other side, depending on who we're calling).
Late reply, did you solve this? I would like to build call features on Aosp. Best!