Related
Is android truly opensource?
As I understand it, some of androids code is released under Apache License version 2.0, and some is released under GNU General Public License, both opensource licenses.
But in a discussion, someone has claimed that the core code of android is held by Google only, and is not released to public, and that only some of the code around the android core code is opensource, other code around the android core code is not opensource.
Is he right, or am I right in my thinking, that ALL of the android code is opensource, either under Apache License version 2.0 or under GNU General Public License?
Nobody to answer this one?
I would very much like to put the guy in place, if possible
I don't know but I do believe that Google have reserved the right to keep or delay what they want to.
For example, they never and have no intend to release Honeycomb source codes.
Are they violating??? I don't know but if they do, things already heat up.
AkkerDK said:
Is android truly opensource?
As I understand it, some of androids code is released under Apache License version 2.0, and some is released under GNU General Public License, both opensource licenses.
But in a discussion, someone has claimed that the core code of android is held by Google only, and is not released to public, and that only some of the code around the android core code is opensource, other code around the android core code is not opensource.
Is he right, or am I right in my thinking, that ALL of the android code is opensource, either under Apache License version 2.0 or under GNU General Public License?
Click to expand...
Click to collapse
Android is true open source, and the code is widely available on the web, buts that's aosp. Proprietary things like radio binaries, and custom guis from manufacturers (eg touchwiz from Samsung) are not, so the code for thses is not
votinh said:
I don't know but I do believe that Google have reserved the right to keep or delay what they want to.
For example, they never and have no intend to release Honeycomb source codes.
Are they violating??? I don't know but if they do, things already heat up.
Click to expand...
Click to collapse
I know about HC source code, and also know that Google claims that to be a special situation ... Have no idea whether Google are violating license terms or not, they very well could be.
But that's not what I'm after, not for such one time situation, it's the general situation I'm interested in.
When Google releases source code, do they release everything, or are they withholding something, core code or other, or both?
What I have read so fare, Google releases ALL code under the 2 different opensource licenses, but I can't really be sure.
My thoughts are also, that CM wouldn't be possible, if Google don't release all android code ... The only thing I have ever read, is that the problems with CM releases is specific hardware related code, that has nothing to do with android code itself ... But again, I can't be really sure, I'm not a developer and don't have the technical knowledge to proper argue this point.
I would very much like, if someone could provide me with the proper arguments to put this guy in place, maybe even direct me to sites, that will show him the error of his ways
icenight89 said:
Android is true open source, and the code is widely available on the web, buts that's aosp. Proprietary things like radio binaries, and custom guis from manufacturers (eg touchwiz from Samsung) are not, so the code for thses is not
Click to expand...
Click to collapse
I guess that those things are hardware specific or specific to the phone manufacturers, and has to do with the hardware manufacturers and not with android itself?
Here you go mate: http://source.android.com/source/downloading.html
Extra info in the side bar on the left as well.
All of Android is Open Source; however as others have stated - manufacturers will develop their own radios and such (eg: Imagine buying a laptop with Ubuntu installed on it - the OS is open source, but the firmware for your WLAN adapter inside the laptop might not be)
One thing that bothers me about my Android phone is the opaque, closed-source baseband firmware ("radio" as it's often called here). Since the baseband is interposed between the OS and most hardware functions, its firmware presents a major unknown in the total security of the device.
It's unlikely that the source code for any of this baseband firmware is going to be released, and the open source OsmocomBB baseband is a long way off from supporting Android or the dominant Qualcomm chips. But I would settle for decompiling an existing baseband firmware image, so that I can start to understand some things about it's behavior, and perhaps compile modified versions.
Does anyone know where to begin with this? Many thanks.
I wish somebody participated in this with you. I need it also /
funkydaemon said:
One thing that bothers me about my Android phone is the opaque, closed-source baseband firmware ("radio" as it's often called here). Since the baseband is interposed between the OS and most hardware functions, its firmware presents a major unknown in the total security of the device.
It's unlikely that the source code for any of this baseband firmware is going to be released, and the open source OsmocomBB baseband is a long way off from supporting Android or the dominant Qualcomm chips. But I would settle for decompiling an existing baseband firmware image, so that I can start to understand some things about it's behavior, and perhaps compile modified versions.
Does anyone know where to begin with this? Many thanks.
Click to expand...
Click to collapse
Good idea. Although most probably it'll all be native C code compiled into binary form, not amenable to decompiling.
So you'd probably need a very good debugger and a system call tracing facility in strace.
I guess hell might also break loose because SIM encryption(?), voice encoders(?), network locking(?) and god knows how many of those proprietary tidbits may be sitting in there.
SIM encryption broken leading to duplication of SIMs and leading to smartcard encryption and open source tools to reprogram your credit cards with more money.
That's not hell. That's hell in a hand basket with us enjoying the ride
Keep us posted. It's guys like you who think outside the radio that gave us the TV
For Qualcomm based devices you need to decompile Hexagon code.
For other Intel XMM6260 etc based devices suffice IDA (ARM).
In both cases the raw binary blobs may be encrypted, but extractable from running machine.
I'm working on it, in a fashion, and am writing up a document compiling everything that has been done on cellphone radio hacking. I've not found much on baseband firmware; there's a lot of info out there but it's been tough to find amongst all the other hacking that has similar keywords. Currently most quality info around this subject involve an extra (and depending on desired features; expensive) bit of hardware and two open source software packages with their decencies. As the hardware is currently outside my budget ($300 for the best bang for buck) I'll be working on getting the software to recognize the hardware built in my Android devices. Provided that all goes well I should be able to read and write on the frequencies that the in-built hardware supports and hopefully, as I always get an identical device when getting one, read and write with my backup android device. Be warned if you decide to follow me down this path; there are laws restricting what non-licensed persons/companys can do on certain RF frequencies and this depends on where you live, I'm no expert only a person capable of reading lots of dry informative documents, provided I do achieve direct contact between devices this hack could (and likely will) fry one of my antennas so be warned you'll likely do the same :banghead: so do this on an old device that you don't care about before ever trying on something you use daily. With the warning out of the way lets get down to the quick version.
~~~~~~~~~~~~
Currently all the developing I've found educational has involved the before mentioned "expensive hardware" known as software defined radio, shortened to SDR, go a head and pop open a new tab and Google search either. You'll eventually find that cellphone manufacturers have likely already put these into many devices. You'll also hopefully find the two kickstarters, HackRF ~$300 and bladeRF ~$400, these are likely what I'll be saving up for; HackRF for sure as the next release will likely be able to send and receive at the same time instead of switching quickly between modes. If you dig deep enough you'll find a blog post from a hacker that plugged an Android into a much more expensive SDR and was able to place calls and send/receive text; the blog poster stated something to the effect that this was not a useful hack but I believe that it's a great proof of concept and totally worth another look. However, this hacker has also almost been sewed for some of the demonstrations with this kind of technology involving the capture and description of calls and texts so tread carefully.
The software I mentioned before boil down to GNU Radio and Open BTS; there's dependencies for each but all seem to be installable on Linux running on top of Android. Furthermore I see that someone (I'll edit your name in in a sec Edit: idcrisis ) previous mentioned wanting c or c++ support, GNU Radio uses these languages perhaps I can ask for some help when I get a little further in porting this to run without Linux in the middle so much? I think if we use the GPS to set the time then the signal shouldn't drift to much.
I'm using an app called Debian Kit to give me a flavor of Linux called Squeeze for testing the software. If you choose to try what I'm doing then make use of the readme that the developer wrote or the guide I wrote for general Linux on Android installation and interaction fund in my sig to get started. If you want access to the document I'm compiling then you'll want to PM me at this moment as the chances of hardware frying is high and I'll share a link to Google docs; I'll be releasing a full guide when I've figured out how to avoid damage.
Eventually I hope to port many of the functions in GNU Radio into an app that makes use of internal hardware. Currently I've found a few that make use of hardware plugged into Android through USB "on the go" or "host mode" just search "RTL SDR" in the app store and you'll see'em, but, currently nothing making use of internal hardware. If any are interested in joining forces and helping figure out how to do all this I'd be glad to offer any support I can.
Other things related to cellular antenna hacking other than the above mentioned software and hardware that I'm compiling into the same document. Well this is where we get into the parts I'm hitting the wall on. It looks like I'll have to get into Kernel modification as this is one of the things used to communicate between software and hardware. There's also the flashable files known as radios and I'll be digging further in how these files are modified.
Basically this is a very tough question to answer and has taken many months of reading, searching, and more reading to get this close bit if we all work together I know that we'll be able to modify how the antennas in our devices work.
Edit 01142014- Found a guide on reverse engineering embedded device firmware, the guide is on a router but as the chips in our phones are embedded perhaps the steps are similar
http://www.devttys0.com/2011/05/reverse-engineering-firmware-linksys-wag120n/
Sent from either my SPH-D700 or myTouch3gs or M470BSA
Guide for running Linux on Android that I'm writing:
http://forum.xda-developers.com/showthread.php?t=2240397
^^ NO! The embedded chips in the Linksys routers are MIPS based and not ARM like all our Androids. Very different, although technique is the same.
But thanks, for taking time to check up on all this.
Any updates ?
Hey Guys,
I'm looking into this, I've successfully extracted files from the OnePlus One's baseband, its running RtOS called REX, QC calls it AMSS.
Have a look at the thread here: http://forum.xda-developers.com/oneplus-one/general/discussion-hlos-reverse-engineering-t3292829
Waiting for the OsmocomBB update it projects
QCOM modem leaked sources.
Type in google/bing: "AU_LINUX_ANDROID_JB_MR1_RB1.04.02.02.050.116_msm8974_JB_MR1_RB1_CL3904528_release_AU"
Greetings XDA Forum,
This is a general question that should be in everyone's mind who might want to root a phone or tablet or any Android or other mobile OS device:
Is this root exploit or bootloader going to be spyware and collect any and all data of mine (login credentials, keylog my every character, account/bank numbers, identity information, use your evil imagination)?
So, I searched this forum for key words like "trust root" "secure root" "security" and found nothing related to this topic.
So, how am I to trust ANY of the root exploits or bootloaders created and posted to this forum for ANY device?
Have any of the developers developed an audit process using firewall rules to ensure that a posted root exploit or bootloader does not attempt to keylog, report captured information to some obscure IP address (thief/hacker's machine of course)?
Do any of these root exploits or bootloaders or custom unofficial builds of entire android (like Cyanogenmod and the 3rd party variants) get Security Audited?
How am I to believe that the whole lot of you making the root exploits and bootloaders are not a big community of identity thieves and financial fraudsters?
Am I just supposed to trust you?
Answer me that, folks
Aknor
I've never seen any root exploit that did as you say, if your concerned pick apart the code and look for this, I've never seen anything of the like
As for bootloaders, there are very few devs that actually make or tweak bootloaders as a misstep will nearly for certain result in a brick. Almost every bootloader you will find is made by the OEM, if its not, again feel free to pull apart the code and look for an issue, but I doubt it as this is far more advanced than most will ever become
As for custom ROMs, well this is the most possible out of all your worries, but again most ROM chefs here are not capable of inserting malicious code, and if its an official build of a major team (cm, aokp, slim, etc) you are damn near 100% certain there is no issue, as for random ports made in the former USSR by KGB spies, well just don't flash their ROM and you'll be fine
But of course no one is forcing you to root your phone, flash their bootloader, or download their ROM, so if youre the paranoid type just get an iPhone, at least they're upfront about most of their evil ways
Sent from my Nexus 4 using xda premium
demkantor said:
I've never seen any root exploit that did as you say, if your concerned pick apart the code and look for this, I've never seen anything of the like
As for bootloaders, there are very few devs that actually make or tweak bootloaders as a misstep will nearly for certain result in a brick. Almost every bootloader you will find is made by the OEM, if its not, again feel free to pull apart the code and look for an issue, but I doubt it as this is far more advanced than most will ever become
As for custom ROMs, well this is the most possible out of all your worries, but again most ROM chefs here are not capable of inserting malicious code, and if its an official build of a major team (cm, aokp, slim, etc) you are damn near 100% certain there is no issue, as for random ports made in the former USSR by KGB spies, well just don't flash their ROM and you'll be fine
But of course no one is forcing you to root your phone, flash their bootloader, or download their ROM, so if youre the paranoid type just get an iPhone, at least they're upfront about most of their evil ways
Sent from my Nexus 4 using xda premium
Click to expand...
Click to collapse
Okay, I can see that on the boot loaders, but more than just a few make the root exploits and custom builds of cyanogen or android for many, many devices. So, how am I to pick apart the code of these projects when they do not provide the source code for the builds? How would I even trust those builds after they are built? They could slip some malicious code in that they intentionally do not show in the public repository for the code and no one would ever know.
Sure this sounds very paranoid, but no one has really answered how or if at all any of these builds of unofficial android or cyanogenmod or the root exploits or the bootloaders can/would be tested for malicious code.
Think of it, something as small and innocuous as a keylogger with a simple, non threatening name, and all the while, it logs your every username and password, credit card number, 3-digit security code, bank account numbers, anything. How bad would that be, eh?
Any you're not concerned these builds/exploits are not somehow security audited and we're all just supposed to trust them like blind sheep?
As more and more of these get built, it's only a matter of time before someone slips something like this into their build to take advantage of all those people who want to root their phone/tablet, or put an unofficial build of android on their device. Shame on that person who does it, of course, but to think somehow we could have audited the software and found out as a matter of course?
-- Aknor
Well there aren't that many root exploits and depending on the device you will be changing most if not all firmware and software directly after exploiting, but again just look at the code before you use it
As for keyloging etc from flashing a ROM, you would be surprised how many OEMs actually have somethings that many would consider malicious and or a brief of privacy.
As for a worry about flashing a custom ROM with bad code just stick to official builds or mod your own ROMs, no one is forcing you to flash anything in particular. But there are apps that are meant to look for malicious code. Feel free to use these to help protect you
I have flashed oh so many ROMs over the past 4 years or so and have never seen anything malicious, but I flash a lot of my own source built ROMs and mostly use ROMs on the higher end which tend to be from trusted sources such as recognized developers and people I work with. Also I'm not a paranoid person so I don't look into this sort of thing much, this means unfortunately I can't really give you much more than this
But best of luck to you and happy flashing!
Sent from my Nexus 4 using xda premium
I've gone through several rooting procedures on the XDA forums over the years. In the most recent one I tried to root my HTC Desire C (CDMA). It turns out that I nearly hosed the phone when I installed bootloaders that some senior members on here promoted with full confidence to users, yet neglected to ask if the user had a CDMA phone.
There is a thread on the HTC Desire C where a senior member provides a hacked version of a bootloader and ROM. The user then responds (on page 2 or 3 of 11+ pages) that their phone can't get beyond the 'dev bootloader', and effectively the senior member has provided a patch which hosed at least a few phones.
Subsequent threads appear which show users in the same situation I was in after applying the XDA hacks. After hours of researching I found a workable bootloader and managed to get it flashed, and get my phone rooted. I doubt many people will be able to reproduce my results and get the phone rooted. I expect most people will give up on rooting, consider the phone locked, and just avoid going anywhere near the bootloader again.
Furthermore, the bootloader I downloaded in at least one thread for the HTC Desire C has an HTC Legal Message that causes concern on how the uploaded patch was originally obtained - i.e. was it obtained legally?
After spending ~12 hours learning all of the above, I embarked on seeing what XDA developers say is involved with creating a custom ROM. I was shocked. Even the most well-documented processes are incredibly horrid. They involve hacking binary files, fudging package names, and more sketchy procedures that any Android Engineer would expect to leave the OS in an unstable state; for example not using zipalign on system apps.
Any software engineer using binary-file hacking would expect to be unable to fix bugs in the software. To fix bugs efficiently and reliably (i.e. test and prove the bug is fixed), a software engineer needs source code.
But worst of all, the custom ROM and bootloader binaries have code that not even the author knows the origin of, as demonstrated in the Custom ROM developer guides/postings. If HTC or Google have tracking code in a binary, the custom ROM will have it too. If there is malware in the binary that might steal their passwords or other identification, the user has no way of knowing.
I've seen at least three (3) instances of supposedly popular XDA ROMs where a hacker has taken an existing ROM, hack it's binary files for the new target device, fix no bugs in the previous ROM, and introduce new ones in theirs. I've even seen ROM developers criticize other ROM developers for not fixing bugs, and then when I investigated the ROM from the complainant, I found they didn't fix any bugs either. Of course not, it appears to me the majority (all) of the hackers on XDA use binary files to create custom ROMs, with some hacking of text, XML (layouts, values, assets), and other text files - but not any actual JNI-C or Java code.
These custom ROMs are not open source. I'm skeptical they're even legally complying with the open source licenses in the original code. It is certain that any and all files used for the development of a custom ROM available from XDA are also obligated to follow the Apache2 license that governs the OS build (I'm not sure which licenses cover the bootloaders), yet it's quite difficult on XDA to find links to custom ROM source files.
That latter point makes the entire process of hacking binary files to generate a custom ROM completely untrustworthy. Contrast this with CyanogenMod which provides (or attempts to provide) techniques to build custom Android ROMs from source, and which provides a lineage of ROMs with stability ratings.
It doesn't benefit an open-source community to propagate software with bugs, lacking sources, and possibly in violation of licensing. Since this forum is not a Q&A thread, I won't ask people to stop, I'll demand it. Since that never works, I would have to wish XDA the shortest lifespan possible. Delete this thread and I'll post it elsewhere, where XDA users can't comment.
Although I agree with 95% of your post, it seems a bit harsh to condemn the entire community. Maybe you could actively participate in setting a higher standard?
Sent from my LG-MS840 using xda app-developers app
Well, lets say we have approximately 2 new persons attempting development. Which means, they are trying to be future developers which also mean, they may not know certain things on development. On the past, the standard was high because, there were only 5 devs per device and the rest the users. They never cared how the dev made the rom.
But the case today is, everybody needs to know everything. Which naturally makes them to attempt. So naturally, there are increasing number of imperfect works which will gradually get perfect when the dev gains knowledge from his experience.
And for licensing, android is made open source by google and gives permission to edit the source and release them as long as the brand "Android" is used. It never states that the Works should be opensourced always. Example: android gives source to samsung,HTC and sony. And these OEM's make use of that code and adds it own code and releases its own software on new phones. But do they provide source?No. Do they include malwares?No.
But how do you believe them that its not malacious or legal? Because you pay them $$$$ for their work and not even a $ for the custom rom developer? At last, it only depends on you and how you think.
And for CM being open source, CyanogenMod works on android source code and make custom roms (Just as OEM) and it has chosen to go open source and hence it is. But other custom roms than AOSP/AOKP people work on roms provided by OEM's. In that case, they cannot provide source though they wish to do it because, they don't have source of OEM rom. Instead, they work on dalvik code, already compiled apk, already compiled framework etc...
Hope I have made you clear?
Sent from my GT-N7000 using xda app-developers app
Catharsis much?
Sigh... (Lip bit. And, edited..)
Sent from my MB865 using XDA Premium 4 mobile app
Why is there such alot more development and forum activity on for example the Xiaomi Redmi phones than on this one? The p9000 got excellent hardware for a great price but the community is really small somehow and the software is still buggy? How come? Do you think its still worth to wait for more activity and responses from developers for this phone or is it a "dead cow" already and better to swap to another brand to get support from developers on for example CM or RR?
furchtlos76 said:
Why is there such alot more development and forum activity on for example the Xiaomi Redmi phones than on this one? The p9000 got excellent hardware for a great price but the community is really small somehow and the software is still buggy? How come? Do you think its still worth to wait for more activity and responses from developers for this phone or is it a "dead cow" already and better to swap to another brand to get support from developers on for example CM or RR?
Click to expand...
Click to collapse
Development for this device is far from dead, we have a stable device tree for building custom ROM's, CM and RR ROM's already released, a fully source built TWRP and work on custom kernels is just beginning. That's a lot more development already than an awful lot of devices see in their entire lifetime.
I would rather say it has just begun. Development for this MTK chip is not a matter of course and the outcome so far is pretty exciting. This opens the way for other devs who work on other devices with the same chipset. It's just that many devs simply prefer Snapdragon which leads to higher dev count on those devices, faster bug fixing etc. I am pretty excited what the future brings not only for our P9000 but MTK devices in general as far as flashing and development goes.
Development is dead? What gave you that impression? For starter this phone already has a working twrp recovery. That is more then some Chinese phones get in their whole lifetime. Kernels is the area of development next and elephone has been kind to release the source code for the phone. Again more then most developers even bother with.
well, it got twrp,root and xposed working. More than some name brand phones that stop official updates after a year.
But i admit it is easier to update my old nexus 4 with cm downloader. Just click the update notification and latest cm gets installed.
It is also getting nougat in November hopefully
mangoman said:
well, it got twrp,root and xposed working. More than some name brand phones that stop official updates after a year.
But i admit it is easier to update my old nexus 4 with cm downloader. Just click the update notification and latest cm gets installed.
Click to expand...
Click to collapse
That's because Nexus 4 is an officially supported device by CM.
It's very difficult for MTK devices in general to get official CM support because we have to patch some things in the framework to make camera, RIL (mobile data) etc working.
The official stance is that these things should be done in device tree as no proprietary code is allowed in CM framework.
Initially when our patches were submitted to CM Gerrit they were rejected because of this, Leskal is working on minimising the patch work needed and getting more of the generic MTK code accepted on Gerrit.
Not helped by the fact that MTK themselves aren't helpful or willing to support developers as it doesn't suit their replace and force upgrade business model. Technically how they operate and their refusal to release official development tools or code is a violation of the open sources nature of Android. But google has yet to do anything serious about it. As far as I know, any code we have is from reverse engineering and leaks.
Android-UK said:
Not helped by the fact that MTK themselves aren't helpful or willing to support developers as it doesn't suit their replace and force upgrade business model. Technically how they operate and their refusal to release official development tools or code is a violation of the open sources nature of Android. But google has yet to do anything serious about it. As far as I know, any code we have is from reverse engineering and leaks.
Click to expand...
Click to collapse
Not true, I've met up with MTK engineers at DevCon and they do actually encourage development, they just seem to lately be wanting to protect their HAL's and drivers which as pointed out on the XDA portal article about this is sort of ridiculous. But then again it's proprietary code and not under the GPL so whilst we can say it's stupid we can't really contest it, it's their choice.
The code we have is completely official and not gotten from reverse engineering.
Jonny said:
Not true, I've met up with MTK engineers at DevCon and they do actually encourage development, they just seem to lately be wanting to protect their HAL's and drivers which as pointed out on the XDA portal article about this is sort of ridiculous. But then again it's proprietary code and not under the GPL so whilst we can say it's stupid we can't really contest ot, it's their choice.
The code we have is completely official and not gotten from reverse engineering.
Click to expand...
Click to collapse
I have seen many a leak before. But OK they support developing but at the same time they don't help provide any decent tools for troubleshooting or development.
Android-UK said:
I have seen many a leak before. But OK they support developing but at the same time they don't help provide any decent tools for troubleshooting or development.
Click to expand...
Click to collapse
Why do they need to? There's already great tools around for that, I know Qualcomm certainly used to provide a package for debugging the lower system levels but it wasn't widely available as the lower levels of the device booting process are not needed to be modified outside of OEM labs and manufacturing.
The lowest level we need is kernel debugging and the kernel already provides that via last_kmsg and desmsg etc, all other tools are already available as part of ADB, logcat etc. There are also a plethora of other tools readily available.
I would call it pretty dead now Well, if not dead then dying.
Let's hope for a Christmas special