maybe someone more linux savvy can check into this.
a search on our kernel version 2.6.27 thats on the moment brings up a website with a program for a local root vulnerability.
http://www.milw0rm.com/exploits/9545
not sure if it can be compiled for android... Just trying to help
I compiled it, and i am trying to get it to work but its running me into a brick wall. Its weird cause it works on my computer(full linux)... so Ill keep trying
Intresting indeed. I wish i could figure it out, but i dont know anything about linux.
there is some additional info over at ppc geeks here
http://forum.ppcgeeks.com/showthread.php?t=96237
Have you rewritten the x86 assembly instructions for ARM assembly? Also, I tried one of the milw0rm exploits on my Moment...seems they patched the kernel before the release.
I managed to discover a root exploit but its not the same as we are used to thanks to Samsungs stupid RFS aka FAT16 rom file system.
I'm nor knowledgable to make a rom, but hopefully this can be used to redo the rom in yffs2 so that it will work with existing apps, because even if we COULD keep root, stuff doesnt work, like nandroid, or Root Explorer.
http://www.samsungmomentforum.com/how-to/root-access-(finally-achieved!)/
I know many devs frequent xda and with zefie's root expliot maybe someone with the knowledge can create a rom for it in yffs2 using the source code samsung released.
Link: http://phandroid.com/2009/11/24/sprints-moment-open-source-released-by-samsung/
All - following up on a post in AndroidForums which referenced a comment on the root story here. The comment (from Gee):
Correct me if I’m wrong, but I remember hearing that the drivers/kernel are either encrypted, unusable, or simply unavailable. Meaning that while you can root the Galaxy S and put custom ROMs, you still can’t put unofficial ROMs (like Cyanogen) on it without expecting to break a lot of functionality.
That means that you WONT be putting Froyo on it until Samsung officially releases the ROM which can then later be modified. And if Samsung moves away from the Galaxy S after that update, you’ll never see a fully functioning Gingerbread ROM. Ever. That’s a hard pill for me to swallow.
Click to expand...
Click to collapse
Can anyone shed further light on this?
Sounds counter productive. I heard they will be releasing source code. Would be odd if they kept the rest under wraps or took extra measures to prevent access....
Methinks this is definitely worth further investigation. Need some experienced SGS modders to find this thread...
From what I have seen, the drivers are provided in binary form only (which is basically the same as how drivers are provided on Windows). So long as there isn't some code written into the drivers that would prohibit their running on non-official ROMs, there shouldn't be any problem using the drivers in custom ROMs.
I downloaded the entire sourcecode from the samsung website. Its a 150MB zip file and everything is in there in binary form. It must be compiled. I'm certainly not a linux or android dev but it seems like thats what you need. There's even readme.txt files in there to tell you how to build new versions of software.
I'm wondering how long it'll take for someone to put out a custom ROM for the captivate based on 2.2?
I'm new to the forums and a novice programmer but here's my question:
There's an app I'd like to run on my device for work. Per the play store, the app requires Android 2.3.3 and I'm running 2.2.2. I'm running the most recent version of a custom ROM on an outdated device so can't update my device's build.
I'm wondering if it's possible to tweak the app's source code and repackage it to make it run on my device. I have downloaded the .apk file and tried to install it on my phone and get a parsing error. So with the help of google I have managed to get into the source code using dex2jar and jd-gui. Problem is I don't know much about how apks are written. I found something in the 'accessibilityservice' area that seems to check the android build version, but as far as I can tell that is checking for whether the device is running ICS (if build >= 14) whereas the app is said to be compatible with older builds as well.
Anyway - how complicated would it be to port an app backwards so that I could run it on my phone? You should assume that I'm already in over my head.
Thanks.
petegw42 said:
I'm new to the forums and a novice programmer but here's my question:
There's an app I'd like to run on my device for work. Per the play store, the app requires Android 2.3.3 and I'm running 2.2.2. I'm running the most recent version of a custom ROM on an outdated device so can't update my device's build.
I'm wondering if it's possible to tweak the app's source code and repackage it to make it run on my device. I have downloaded the .apk file and tried to install it on my phone and get a parsing error. So with the help of google I have managed to get into the source code using dex2jar and jd-gui. Problem is I don't know much about how apks are written. I found something in the 'accessibilityservice' area that seems to check the android build version, but as far as I can tell that is checking for whether the device is running ICS (if build >= 14) whereas the app is said to be compatible with older builds as well.
Anyway - how complicated would it be to port an app backwards so that I could run it on my phone? You should assume that I'm already in over my head.
Thanks.
Click to expand...
Click to collapse
A LOT of things changed from pre-2.3 to 2.3 in Android, code-wise. It was a huge upgrade, and a lot of unsupported things were implemented.
It's set to run on 2.3.3 simply because it uses functions that only exist in 2.3.3 and higher.
So to backport it you'd need to get the source code, check what functions require 2.3.3 or higher, edit them to use other functions/write the code yourself. You can't just simply remove the code that checks what version of Android you're running. That won't do a damn thing.
The last part is the near impossible one, because you'd most likely have to write code that goes deep into the Android framework.
If i were you, i'd simply look for another app that can do what you need and doesn't require 2.3.3 or higher. Though there aren't many out there. Most people base their app on 2.3.3 because like 95% or higher use that version (or a higher one).
If you were to dive into this, you'd need extensive knowledge of Android, Java & backporting.
Though i'm not able to help with that, at least the backporting part.
Moonbloom said:
A LOT of things changed from pre-2.3 to 2.3 in Android, code-wise. It was a huge upgrade, and a lot of unsupported things were implemented.
It's set to run on 2.3.3 simply because it uses functions that only exist in 2.3.3 and higher.
So to backport it you'd need to get the source code, check what functions require 2.3.3 or higher, edit them to use other functions/write the code yourself. You can't just simply remove the code that checks what version of Android you're running. That won't do a damn thing.
The last part is the near impossible one, because you'd most likely have to write code that goes deep into the Android framework.
If i were you, i'd simply look for another app that can do what you need and doesn't require 2.3.3 or higher. Though there aren't many out there. Most people base their app on 2.3.3 because like 95% or higher use that version (or a higher one).
If you were to dive into this, you'd need extensive knowledge of Android, Java & backporting.
Though i'm not able to help with that, at least the backporting part.
Click to expand...
Click to collapse
Thanks for the very helpful information. I will definitely not be attempting this.
Most likely will be getting a newer phone in a few months when I'm due for an upgrade so it'll be a moot point. Until then, I'll get by.
Hello, I'm trying to build an app called Commotion Wireless from its source code - I didn't make this app myself, so it should be a simple case of following the instructions in the README, importing into Eclipse and exporting as a .apk. However, upon attempting to build, there are 3 errors: two saying "isIBSS cannot be resolved or is not a field" and the third with "frequency cannot be resolved or is not a field". The offending pieces of code are here:
github.com/opentechinstitute/commotion-android/blob/cm/src/net/commotionwireless/profiles/Profile.java - lines 201 and 202
github.com/opentechinstitute/commotion-android/blob/cm/src/net/commotionwireless/meshtether/NetworkStateChangeReceiver.java - line 92
Now as many of you know, stock versions of android don't seem to support ad-hoc networks, this is functionality that other custom firmware such as Cyanogenmod adds. As far as I can tell, this app is intended for cyanogenmod (as the devs state in URL1 below). Therefore I think that the definitions of "isIBSS" and "frequency" are not in the stock versions of andriod (URL2 is a patch somebody wrote that adds them), and the root of my problem is that I'm trying to build the app based upon the stock version of android that doesn't understand what "isIBSS" and "frequency" mean. I have never tried to build an android app before so have little experience, but my first instinct was that I needed to install a custom version of the android SDK for Cyanogenmod that would have the needed definitions in - however as far as I can tell, no such thing exists.
Does anyone here have any idea how I may resolve this issue? Your help is much appreciated
URL1: commotionwireless.net/developer/resources/commotion-android/
URL2: thinktube.com/files/android-ibss/patches/frameworks-base-0001-Wifi-Enable-Ad-Hoc-IBSS-network-configuration.patch
Hi guys,
with reference to this interesting thread:
Strategic Alliance: bundle F-Droid, add LineageOS repository, add microG
I think that LineageOS may effectively be the reference Android ROM for people looking for privacy and timely updates (which implies more security).
In this view, it would be extremely convenient to have a working instance of microG on LineageOS, as it would add the convenience of gapps without the need to sell you soul to Google.
The only practical option to have a working instance of microG in CM/LineageOS is using an Xposed module which spoof the signature of microG. The alternative is recompiling CM/LineageOS from scratch by patching it "by hand" before. While viable, these two solutions are far from convenient, as the former depends on Xposed (which is not available for Nougat at the moment, and nobody can really tell if it will ever be) and the second... Well, in my understanding it requires a fair share of knowledge and also computing power and it is probably impractical from the point of view of view of the end user.
My question here is:
given that LineageOS will ship a separate ZIP to allow root to be enabled for apps, would it be technically possible for LineageOS developers to create (and ship ) also a separate zip to enable signature spoofing for people knowing what they are doing?
In my "vision" this could only add a permission that would have still to be manually enabled only for selected apps (microg, specifically).
In the end, only people really interested in microg would manually install the "spoofing" zip. And in this cases it would not pose any additional security risk (if you consider that enabling root may be already dangerous enough).
Let me emphatize that I don't know if this is technically feasible, nor if the developers would ever accept to do that. But in my opinion this should at least be discussed.
Thanks for reading and have a nice day!
E.
enban said:
Hi guys,
with reference to this interesting thread:
Strategic Alliance: bundle F-Droid, add LineageOS repository, add microG
I think that LineageOS may effectively be the reference Android ROM for people looking for privacy and timely updates (which implies more security).
Click to expand...
Click to collapse
I really really like this idea! It is important to give users an easy way to get rid of the intrusiveness of google, if they want to. It's a matter of freedom of choice.
More and more people are scared about (or simply don't like) mass collection of personal data, it would be nice if Lineage OS could give to these people an alternative!
enban said:
My question here is:
given that LineageOS will ship a separate ZIP to allow root to be enabled for apps, would it be technically possible for LineageOS developers to create (and ship ) also a separate zip to enable signature spoofing for people knowing what they are doing?
Click to expand...
Click to collapse
Or maybe a .zip that directly installs microG? (I don't know if it is possible...)
lamp1 said:
Or maybe a .zip that directly installs microG? (I don't know if it is possible...)
Click to expand...
Click to collapse
Installing microG is not a problem. Another user, @wdevil12 , already create an AROMA zip to install microG.
The problem is that microG NEEDS the signature spoofing to be available (it needs that so apps "think" that it is the "real" Google Play Services).
CM/LineageOS never wanted to build this option in the ROM, so one has to rely on Xposed or make one's own build by patching the sources.
Having a flashable zip enabling spoofing signature directly from LineageOS developers would be a huge leap forward and could impulse the use of microG (which, in my opinion, is the best thing happened to Android in years).
My 2 cents.
enban said:
Installing microG is not a problem. Another user, @wdevil12 , already create an AROMA zip to install microG.
The problem is that microG NEEDS the signature spoofing to be available (it needs that so apps "think" that it is the "real" Google Play Services).
Click to expand...
Click to collapse
Thank you for the explanation.
enban said:
Having a flashable zip enabling spoofing signature directly from LineageOS developers would be a huge leap forward and could impulse the use of microG (which, in my opinion, is the best thing happened to Android in years).
Click to expand...
Click to collapse
I agree with you!
+1
Is the lineage browser chromium based?
Is there a purge and replace google from android os tutorial somewhere?
micrograms without xposed
Hi,
I just wanted to share a link with you:
gabsoftware.com/tips/how-to-use-microg-on-lineageos-or-cyanogenmod-without-xposed
I haven't followed these steps yet, but am going to in a few days
enban said:
given that LineageOS will ship a separate ZIP to allow root to be enabled for apps, would it be technically possible for LineageOS developers to create (and ship ) also a separate zip to enable signature spoofing for people knowing what they are doing?
Click to expand...
Click to collapse
I share your enthusiasm and also your frustration.
Here's the thing. Enabling signature spoofing is a patch, so you apply it before building the image. This means a zip would have to provide a drop-in replacement for the files affected by the patch, in this case I believe it's only 1 file: framework.jar. I have no idea how often framework.jar changes, but it would be useful to know – the more often it changes, the more often the zip will have to be updated and distributed again, and the less probable it is that someone will want to do that job.
So here is an approach I was thinking of:
1. Extend the microG patch to not blindly disable signature spoofing, but instead disable it conditionally when a certain flag is enabled in the settings (disabled by default, obviously). Don't provide any UI, just that test in the code.
2. Include that patch in mainstream LineageOS (and other ROMs). By default it's a no-op, so that's completely harmless. This is the key point.
3. Provide a zip (OP's idea) that surfaces the modification of that flag through a "Disable signature spoofing" option in the Developer Settings.
Ideally, 3 would also be baked into mainstream LineageOS, since Developer Settings are already fairly opt-in. However, in light of what happened recently to root access, I'm assuming 3 would have to follow the same approach and live as an external zip too, which is fair enough and would still represent a huge step forward, as OP pointed out.
Thoughts?
Official answer:
We will not be enabling signature spoofing. It's a huge security hole, and breaking android's security model (for any reason) is never acceptable.
Feel free to build it yourself (it is open source) if this is a feature you want, or use one of the plethora of other roms people have generated. Our main goal is to continue passing CTS and have a production-shippable OS available for anyone who wants to use it.
@elirada
I like the idea and, frankly, I'm less concerned about the method to achieve it than on actually having signature spoofing.
Unluckily, as you can see, the official response is "No, never". Now, while I'm grateful to LineageOS developers for their hard work, I feel that their position on this point is plainly wrong. Allowing root is a bigger security issue than allowing on-demand signature spoofing for *one single* app, which would offer much more privacy to LineageOS users.
enban said:
@elirada
I like the idea and, frankly, I'm less concerned about the method to achieve it than on actually having signature spoofing.
Unluckily, as you can see, the official response is "No, never". Now, while I'm grateful to LineageOS developers for their hard work, I feel that their position on this point is plainly wrong. Allowing root is a bigger security issue than allowing on-demand signature spoofing for *one single* app, which would offer much more privacy to LineageOS users.
Click to expand...
Click to collapse
As zifnab said, we most certainly will not open up security holes like this. It would be an incredible disservice to our users.
Opening attack vectors such as this on millions of devices is "plainly wrong" as you put it.
But hey, its OSS, so fork and do it yourself! :good:
invisiblek said:
As zifnab said, we most certainly will not open up security holes like this. It would be an incredible disservice to our users.
Opening attack vectors such as this on millions of devices is "plainly wrong" as you put it.
But hey, its OSS, so fork and do it yourself! :good:
Click to expand...
Click to collapse
What disservice? You clearly didn't read the OP. One should voluntarily flash a zip and then explicitly enable the feature. It's not something that would happen by chance and would be an explicit choice of each user. And frankly, while I certainly may learn how to get the source and compile it, I (and most people willing to use microG) have not the hardware resources and the time to compile each build. To call this solution impractical would be an euphemism.
enban said:
What disservice? You clearly didn't read the OP. One should voluntarily flash a zip and then explicitly enable the feature. It's not something that would happen by chance and would be an explicit choice of each user. And frankly, while I certainly may learn how to get the source and compile it, I (and most people willing to use microG) have not the hardware resources and the time to compile each build. To call this solution impractical would be an euphemism.
Click to expand...
Click to collapse
Even if its something we'd remotely consider, its not as simple as providing a zip with a su binary in it like the root addon. This stuff is in framework which makes it a lot more difficult to supply a "bolt on" zip to do this.
Here's the patch when it was put on gerrit. You can read the comments to see the stance and reasoning on it.
It's something that will not ever be accepted in this project.
hey guys, thanks for this discussion.
i easily patched the first lineageos-build (kenzo device) with tingle. this was possible because "pre-optimization" wasnt yet enabled when built. patching took only 1 minute.
would it be possible to make any second build (or once a month) without this "pre optimization"-flag?
This way security isnt touched and everyone who wants could easily patch it himself!
We will not shipped compromised builds. It doesn't matter about how much you think it convenient...we are trusted to keep users safe.
The moment you have to use the words "spoof", "make the system think it's something else" or anything if that nature, you are lying to the system about an app, which will compromise thebuser's trust in the system.
If you think for one second that "experienced people who know what they are doing" would be the only ones to flash whatever the heck is available, you have not been on this forum or working with Android for very long.
If you "are experienced and know what you are doing", build it yourself. That's the safest bet against users not harming themselves with our stamp (release-keys) on it.
tl;dr: Nope. Not even once.
zifnab06 said:
Official answer:
We will not be enabling signature spoofing. It's a huge security hole, and breaking android's security model (for any reason) is never acceptable.
Feel free to build it yourself (it is open source) if this is a feature you want, or use one of the plethora of other roms people have generated. Our main goal is to continue passing CTS and have a production-shippable OS available for anyone who wants to use it.
Click to expand...
Click to collapse
Fair enough. Signature verification is clearly an important component of Android's security model.
I think one should never have to choose between security and convenience. Give users the choice for long enough and they'll end up falling for the latter. The minute someone provides a poorly crafted yet job-doing image, everybody will start using it. The "I won't solve your problem" answer, rather than help people, will end up pushing them into randomness.
As someone mentioned, maybe there would be a way to allow the overriding of signature checking only for a given app, in favor of another given app? This is very from just disabling the whole thing, yet would let microG work.
That idea is just an arbitrary suggestion. Generally my point is that people are expressing a use case to solve and if nobody cares they will end up doing something silly,
eli
Hi, I've finally manage to enable signature spoofing using tingle. The procedure is straightforward and very easy to follow (download script, make sure you have all needed programs, connect to rooted phone, execute the script, boom - done).
After that I was able to install microg and with Mozilla location backend it's working very well. So currently I'm running lineageos without gapps on oneplus 3t and can install apps from play store.
If any of you want I can write short instruction but all needed information can be found easily.
@alkesander
Is the patch only for LineageOS? Need patch for OxygenOS 4.0.3.
About the security implications of signature spoofing
zifnab06 said:
Official answer:
We will not be enabling signature spoofing. It's a huge security hole, and breaking android's security model (for any reason) is never acceptable.
Click to expand...
Click to collapse
I'm wondering why no one pointed to microG Signature Spoofing and its Security Implications before.
Interesting, glad I found this thread, that link, and the responses from CM/Lineage devs. Seems pretty clear that user privacy is not a priority, probably been the case since that Microsoft money started flowing in 2015..
Time to start looking elsewhere I guess