RootTools: a library to run commands as root - Android Software Development

A bit surprised that I haven't seen this mentioned on XDA yet...
Stephen (Stericson,) Adam Shanks (ChainsDD) and I have been working on this new library for a few days.
You can find more about it here: http://code.google.com/p/roottools/
Several other people have already enrolled as committers so I expect to see even more activity shortly.
In a nutshell, this library currently:
checks whether you have root access
checks whether BusyBox is installed
Helps you install BusyBox if necessary
Runs series of arbitrary shell commands as root
Checks partition space
Mount/unmount partitions
Installs binaries created from C/C++ for you
Anyone who wishes to pitch in is welcome!

very cool, thanks

Very interesting, i will keep an eye on that

Interesting. Seen a couple things I could have done better in my own attempts. So for me it seems like a good reference for future projects.
One question though: in the installBinary() function you are creating a bogus file in order to get the /files directory created. may I ask if there's a particular reason why you're not just doing a mkdir?

Creation of files/ is delegated to the Android SDK itself; this way, we avoid as much as possible assuming the location of that directory.
I know we do not avoid it completely (when we need to invoke the newly created binary, for instance) but I have hope that in the future we can figure that one out as well.

Just Uploaded version 1.4
http://code.google.com/p/roottools/...ols-1.4-sdk3-generic.jar&can=2&q=#makechanges
Although the library has grown a lot since this post was made and now can handle a lot more for the developer.

Please compile the latest version 4.4.

Related

Can we try EVO's new root method for 1.49?

Ran across this thread in the evo section, seeing how we also have htc's flash lite. It made me hopeful of attaining root. Ive tried every card mentioned as being successful on three different systems:-(
http://forum.xda-developers.com/showthread.php?t=718889
bowtieduece said:
Ran across this thread in the evo section, seeing how we also have htc's flash lite. It made me hopeful of attaining root. Ive tried every card mentioned as being successful on three different systems:-(
http://forum.xda-developers.com/showthread.php?t=718889
Click to expand...
Click to collapse
Even though I didn't really think it would work, I gave it a shot anyway. Naturally, it was unsuccessful. The Eris take FOREVER to load that website, and it never triggers the shell script to ask for a reload, therefore permission is denied for the second part when you reboot with adb shell.
Interesting exploit, though. I wonder if there is some way to modify it for the Eris. Maybe you could contact the devs.
Really, nobody else is interested in this?
MyFixofAndroid said:
Yep that's what I expected. Yea there's gotta be someone here that can do the changes to the EVO files so they work with Eris, and upload the proper files to file sites and have us downloading in no time, so we can get root finally. Yes please anyone here up and willing
Click to expand...
Click to collapse
Toastcfh used to do some work for the Eris someone may want to start there since he provided what looks to be a pretty main part of the EVO root.
sickbox said:
Toastcfh used to do some work for the Eris someone may want to start there since he provided what looks to be a pretty main part of the EVO root.
Click to expand...
Click to collapse
Thanks for the tip. I sent him a PM. Will report back when I find something.
Anyone with an Eris can help out - rooted or unrooted.
I looked at those scripts last night - what seems like the necessary conditions for the beginning of the exploit (part1) are:
(1) there is a directory read/write/traversal permission security flaw in the data area for flash-lite;
(2) apparently, when flash-lite is running it must have root privilege at a moment when it performs a file "chmod" operation
So, an unprivileged user goes in, and makes a symlink (at the correct moment in time) in flash-lite's data area that points to a mtd partition - moments later, flash-lite "chmods" what it thinks is a file in it's data area, but instead, it is chmod'ing the target of a symlink - the normally protected mtd partition.
This allows use of flash_image to write whatever is wanted to that partition - even as an unprivileged user.
It should be easy enough for someone with Linux/Unix command line scripting experience to test to see if these conditions prevail on the Eris. You don't even need to be root - make your symlink point to something in /data/local if you are worried about something bad happening to a mtd partition. Chmod it initially to 600, and see if it get's changed by flash-lite when (and if) you drop the symlink into place.
I would do it, but I've got to go buy all the parts for ( & build) a new computer (no dev station as of last night ).
bftb0
bftb0 said:
Anyone with an Eris can help out - rooted or unrooted.
bftb0
Click to expand...
Click to collapse
Thank you for the detailed explanation. I'll have a look at the scripts, though it's more about learning new things for me, as this exceeds the current state of my unix knowledge. Hope others with more immediate knowledge of the subject will take a crack at it.
The shell script points to sharedobjects within /data/data/com.android.browser/flashlite, but sharedobjects, nor any folder for that matter, exists within that directory on the Eris. Is there a different place this could point; does the Eris have the same objects stored in a different location?
UPDATE: I'm searching my filesystem on my Eris right now to find it. I will report back later with results.
Also If we find a sharedobjects folder (and the right one) then we can point the script in the proper direction and have root very soon.
MyFixofAndroid said:
Maybe the "sharedobjects" folder and other missing folders are really on the Eris, one of you should look for them. Use ASTRO or a different file manager and search most of the whole filesystem and see if you can find "sharedobjects" on your Erises.
In the meantime I'll try the same thing. Maybe there's a search engine for the file system of the Eris that you can get in the Android Market, that would do the trick. A file and/or folder search engine.
If we find a sharedobjects folder (and the right one) then we can point the script in the proper direction and have root very soon.
Click to expand...
Click to collapse
From what I see (and this may just be my eris), the directory probably does exist but we can't touch it:
ls -l
...
drwxrwx--x system system 2010-04-15 02:23 data
...
No read or write permissions to the directory using adb or Astro.
I do have permissions for /sdcard/data on my Eris:
d---rwxr-x system sdcard_rw 2010-06-26 13:26 data
but it doesn't contain the referenced folders and I don't think the browser downloads temporary files to the SD card.
I checked on my other Eris which is rooted. It seems that these may be the directories that we are looking for. However I don't find anything in an app-cache directory.
# find / -name *flashlite
find / -name *flashlite
/data/data/com.android.browser/flashlite
find: /proc/851: No such file or directory
# find / -name com.android.browser
find / -name com.android.browser
/data/data/com.android.browser
Well this appears to be the deal breaker then. Because non-root users of Eris cannot access /data as non-root, they cannot see anything in app-cache, and therefore cannot root yet, at least with this particular method unless there's another way to do it.
We should think of a way to still exploit Flash Lite on Eris, but use a different folder/folders in the Part? scripts that they point to for the operations of the script. This may be possible to do, however, still unlikely to work, and it is still going to be hard at this point.
But does anyone want to give my modified EVO method but for Eris a try? One of you should, so that we can root this thing and get it over with.
jimbonj said:
From what I see (and this may just be my eris), the directory probably does exist but we can't touch it:
ls -l
...
drwxrwx--x system system 2010-04-15 02:23 data
...
No read or write permissions to the directory using adb or Astro.
I do have permissions for /sdcard/data on my Eris:
d---rwxr-x system sdcard_rw 2010-06-26 13:26 data
but it doesn't contain the referenced folders and I don't think the browser downloads temporary files to the SD card.
Click to expand...
Click to collapse
I dont think we would need read write permissions to begin with to use this root, if we had them to start we would be rooted
Because is he using a exploit in flash lite to write to a restricted folder, hes not just found a folder where the permissions aren't set correctly.
If flash lite can invoke admin access and we can exploit it there should be a way to root this.
I am going to the bar going to get some beers for my friends birthday, when I get home I am going to see if I can modify this into an eris root
Yeah JVWARD!
On your rooting effort, all the better, try modifying it for Eris and let all of us know if you succeed, hope you can, so we can get root too. Keep trying it with different changes until you get it to work.
Thanks.
You are able to cd directly into /data/data/com.android.browser/ and then ls, so all hope may not be lost yet. The flashlite directory does not show up, I'm guessing because I haven't used my browser yet so I need to try and get to a flash site and see if it is created. I'm having some problems with the touch screen my leak Eris right now that I'm trying to fix right now if anyone else wants to give it a shot.
You are able to cd directly into /data/data/com.android.browser/ and then ls, so all hope may not be lost yet. The flashlite directory does not show up, I'm guessing because I haven't used my browser yet so I need to try and get to a flash site and see if it is created. I'm having some problems with the touch screen my leak Eris right now that I'm trying to fix right now if anyone else wants to give it a shot.
Click to expand...
Click to collapse
Yes sickbox, by all means, keep trying stuff, and finding that "flashlite" directory etc. till you get it to root. Hope your touchscreen returns to normal, and that you can create the directory that you mentioned in your previous post by using a flash site.
Hey guys, I know this is a tall order, but I want to help. Any chance you could do a "step by step" set of instructions, or at least copy & paste the Evo instructions with the appropriate changes to try this on the Eris? I'm still not rooted, and the SD card Timing root method isn't working for me. I'd like to try something different.
hey can someone with a rooted Eris using a an almost 100% stock Rom setup dump there file system and post it. Anyone using a highly customized Rom don't bother.
Sent from my Eris using Tapatalk
lostpilot28 said:
Hey guys, I know this is a tall order, but I want to help. Any chance you could do a "step by step" set of instructions, or at least copy & paste the Evo instructions with the appropriate changes to try this on the Eris? I'm still not rooted, and the SD card Timing root method isn't working for me. I'd like to try something different.
Click to expand...
Click to collapse
Link to the Evo instructions is in the OP. Currently working to see if it's possible on the Eris, so that's a no-go for now.
Stay tuned.
Team,
I've been working with the scripts with the awesome folks on IRC and have currently gotten thus far:
Part1 - http://pastebin.com/FUJWM3zW
Part2 - http://pastebin.com/6h07zrdm
I believe at this point I've screwed up my FlashLite plugin with my testing, so I'm going to try to recover that and keep moving along.
LR

{TOOL}MetaMorph Builder v3-Linux Only[8-5]

This could be considered part of the development forum or the apps and theme forum depending on how you look at it. if you have an issue, just click the report button and request that it be moved. no need to flame and troll and post that you reported it, just do it and move on.
Lots of people have asked me how to put together a theme control file, and its actually VERY easy but this tool makes it even easier.
this is an example of a theme control file created by this tool
Test-Theme.xml
Code:
<themename>Test-theme</themename>
<author>tater-salad</author>
<phone>Android Phone Codename Hulk</phone>
<rom>CM 8</rom>
<item>Phone.apk</item>
<path>/system/app<path>
<item>framework-res.apk</item>
<path>/system/framework</path>
<description>Requires reboot</description>
<item>FM-Reciever.apk</item>
<path>/data/app<path>
<item>My-custom-app.apk</item>
<path>/data/app<path>
run the mm-builder script and follow the on screen directions. you will of course need to put the correct replacement files in their respective directories, but this script will make all the right folders and set up your theme.xml for you. Bash scrip means linux only. This is also a super easy script, so i may get a batch version soon.
You can extract this file to any directory
All thanks to Stericson. W/O him we wouldnt have a metamorph app to begin with
######################################################################################################
v2
includes these additions
Code:
mkdir $app
mkdir $app/res
mkdir $app/res/drawable
mkdir $app/res/drawable-mdpi
mkdir $app/res/drawable-land-mdpi
mkdir $app/res/drawable-port-mdpi
these are the commonly used directories when it comes to theming. now all the sub-folders should be set up right.
I think this tool will be very helpful for newer themers and the like, looking forward to a windows adaptation.
also, what does it matter if ban_dover was andrizoid, seems to me hes not doing any harm here now, just trying to help people out, so give a guy a chance to rectify himself before you all start the flamethrowers
snyluc13 said:
I think this tool will be very helpful for newer themers and the like, looking forward to a windows adaptation.
also, what does it matter if ban_dover was andrizoid, seems to me hes not doing any harm here now, just trying to help people out, so give a guy a chance to rectify himself before you all start the flamethrowers
Click to expand...
Click to collapse
windows version is certainly viable, but batch is SO alien coming from bash. there isnt even an ls command
im going to have to play around and get a feel for batch before i get to work on it.
v3 is up. ive put together working metamorph themes using v3, so its been pretty well tested.
How about some constructive use of this thread?
ban_dover,
I've got a question. I read through Stericson's announcement post on XDA, and also the project page, and he mentions limitations due to signing checks of market apps.
Does it actually re-sign the .apk with the test key that all the devs use, or does it merely re-zip the .apk so that the manifest and keys are broken (won't pass a jarsigner -verify test)?
If it is the 2nd alternative, I guess that would means that Android does not check "non-market app" installs for valid signatures? Or that it doesn't check system apps but does check market apps?
The reason this piques my interest is that I noticed one of the devs recently released a ROM which had all its apps de-odexed and re-signed with the test key. (Can't remember which ROM, perhaps an xtr* ROM?)
Anyone else that knows how this goes is welcome to answer as well.
bftb0
Im going to lock this thread if the flame war doesn't stop
Play nice
Edit: Thread re-opened, ban_dover and I discussed and hopefully we will not have any more issues.
Thanks
Captainkrtek
bftb0 said:
How about some constructive use of this thread?
ban_dover,
I've got a question. I read through Stericson's announcement post on XDA, and also the project page, and he mentions limitations due to signing checks of market apps.
Does it actually re-sign the .apk with the test key that all the devs use, or does it merely re-zip the .apk so that the manifest and keys are broken (won't pass a jarsigner -verify test)?
If it is the 2nd alternative, I guess that would means that Android does not check "non-market app" installs for valid signatures? Or that it doesn't check system apps but does check market apps?
The reason this piques my interest is that I noticed one of the devs recently released a ROM which had all its apps de-odexed and re-signed with the test key. (Can't remember which ROM, perhaps an xtr* ROM?)
Anyone else that knows how this goes is welcome to answer as well.
bftb0
Click to expand...
Click to collapse
to be honest im not sure. but i can say that the rom your talking about isnt going to have any issues with anything because of the re-signing.
so the those who have downloaded it, what do you think?
ive tested it by putting together a few simple MMs, and it worked fne for me. have any of you ran into any issues?

[Webtop] Webtop source code

Motorola released the source code of the Webtop application at sourceforge!!!
Does this mean devs can now easily integrate and improve webtop?
I don't know how the guys at CM7 are going about hacking it or how much they have done towards their own webtop, and even with the source it probably still depends in lots of motoblur hacks and dependencies that are not part of CM7. However, it is indeed more then a big step in the right direction and should help dev's immensely! Very good news, thank you sir
Sent from my MB860 using Tapatalk
Did some more digging, the OP meant to link this URL: http://sourceforge.net/projects/motorola-webtop.motorola/files/ which does contain jaunty jackalope 9.04 as 1.2.0 and maverick meercat 10.10 as 1.3.0...
Just ordered a lapdock so going to start hacking on this. Has anyone tired building a Maverick webtop for the atrix? I am assuming if done then it will be supported by ubuntu till april 2012, so the repositories should work?
i sure hope so, cuz I tried every web top hack on this site and none of them have worked....maybe there is a solution somewhere in those 100 pages filled with mostly noobs asking how to flash or do they need to be rooted to do it lol
Has anyone actually tried building this yet? I don't have a dev box set up that I can use yet but want to play around with this when I get a chance....
would this possibly mean, that there's a chance to port the webtop-function to other devices/smartphones that have HDMI- and USB- Ports?
For example an Xperia Arc working with the Lapdock...
I don't understand the links. From what I can tell, all of these are Jaunty. They are are listed as delta's of each other, but the build instructions all indicate they are still Jaunty.
This is from a quick lookover, not in depth. It may very well be that the readmes are wrong, but I'm not encouraged by the firefox packages I see. I'm going to try to put together the build environment they describe to see if I can build one. If so, then I'll see what can be done after that...this is very back burner, so don't be expecting anything soon no matter how much of an obsession this has become
After some wget magic I was able to download all 4 releases into independent folders, and I've tried building webtop 2.0.0 on 11.10 setup.. didn't work so well. missing dependencies...
I am confused myself on the read-me's they all seem to indicate that you seed with jaunty. and if 1.3.0 is based on maverick then their build process is wrong?!
I've had success using rootstock (slick program) and chroot getting into a emulated amr7 root environment. I've even used my current install of webtop pulled out of my phone (from webtop2sd) and put into my dev machine and got that working well. but getting the packages to build in the explained environment alludes me.
I'm going to try building 1.3.0-133 tonight using a new rootstock pull of maverick. if people are interested I'll post how I grabbed all of the packages off of sourceforge later tonight using wget in 3 easy steps. this is a side project of mine, but I would really like to try and build webtop packages from scratch so that I can build a repo to allow us to up date our webtops with just apt-get to get to the latest edition.
Has any one else had success building the packages?
cpuchip
cpuchip said:
After some wget magic I was able to download all 4 releases into independent folders, and I've tried building webtop 2.0.0 on 11.10 setup.. didn't work so well. missing dependencies...
I am confused myself on the read-me's they all seem to indicate that you seed with jaunty. and if 1.3.0 is based on maverick then their build process is wrong?!
I've had success using rootstock (slick program) and chroot getting into a emulated amr7 root environment. I've even used my current install of webtop pulled out of my phone (from webtop2sd) and put into my dev machine and got that working well. but getting the packages to build in the explained environment alludes me.
I'm going to try building 1.3.0-133 tonight using a new rootstock pull of maverick. if people are interested I'll post how I grabbed all of the packages off of sourceforge later tonight using wget in 3 easy steps. this is a side project of mine, but I would really like to try and build webtop packages from scratch so that I can build a repo to allow us to up date our webtops with just apt-get to get to the latest edition.
Has any one else had success building the packages?
cpuchip
Click to expand...
Click to collapse
I agree with all you said about the build...I just don't see any of them built on Maverick based on their instructions. Please post your wget magic. There 's lots of files and I didn't take time to figure how to do it.
I've gotten as far as you have. I've got the rootstock environment and packages installed. I haven't looked closely at everything, and I don't think the custom moto packages get installed (like I don't see Firefox installed, and what's in the repository is not firefox 8). And no, I haven't figured out from their instructions how to generate the system image to put on the phone. My first goal is to do just that...generate a stock webtop image per the instructions and get it onto the phone. If I can do that, then I was going to try new packages.
I've also downloaded the mentioned cross compiler and installed it, but I haven't gotten much further that that on figuring it out.
Eventually, I would like to get a PPA on launchpad with new packages that everyone can use. I've read that launchpad will now support armel PPAs.
Seems like we're both stuck at the same part. I was thinking of doing the same thing as you, start a PPA at Launchpad.
I believe I can help you with getting a base ubuntu.img that you could work with.
if you follow the torial on this website: https://wiki.ubuntu.com/ARM/RootfsFromScratch
it instructs you on how to build an ext2/ext3 .img file and then unpack the tar into it.
say you want an ubuntu-arm.img file that'll contain your ubuntu system.
mke2fs -F ubuntu-arm.img (we want ext2 or ext3 not ext4, android doesn't support it yet)
dd if=/dev/zero of=ubuntu-arm.img bs=1MB count=0 seek=4096
sudo mount -o loop ubuntu-arm.img /directory/to/mount/to
now finally unpack the tar into the mounted image!
sudo tar -C /mnt -zxf armel-rootfs-200904151837.tgz
sudo umount /mnt
that should get you want you want to start with.
haven't done the maverick build yet. I'll post the wget magic next after I look it up.
---------- Post added at 09:48 PM ---------- Previous post was at 09:32 PM ----------
okay now for the wget magic!
first download the index.html page of the WT-1.3.0-105 page (I assume you want 2.0.0 or 1.3.0 release)
mkdir WT-1.3.0
cd WT-1.3.0
wget http://sourceforge.net/projects/motorola-webtop.motorola/files/WT-1.3.0-X/WT-1.3.0-105_DBN-1/
next strip out everything but the table tags that make up the list of downloads, injecting a <html><body> above the <table> tag replacing what you removed
and </body></html> after the </table> tag replaceing what you removed.
next start wget with the index.html file just saved by first running wget.
wget -i index.html --force-html --content-disposition
on ubuntu I had to add the --content-disposition flag in order for it to properly save the file names. on fedora it did the right thing without that flag.
then wait an hour and you should have in that WT-1.3.0 will have all the 105 files in it!
I've got a two more scripts to unpack all the files. I'll have to look them up. but that should get you going.
AIW that and webtop-panel (and supposedly evbridge...)
those are the packages I care about in the port.
Do you know what package on the source code page contains AIW? (that's the android in window application.)
I haven't had a chance to work on this lately. However, I suspect that those components are pure Moto code, and therefore not required to release. Probably only the binaries are included. That's pure speculation, though.
The readme's say that it's not one to one for the packages they posted and the programs installed from them in our webtops. though reading the new releases on that webtop sourceforge project.. it says it's only the packages they were required to release by oss licensing... so it's probably not posted. the readme file inside of /usr/share/aiw says it's copyrighted and proprietary. So that really only gives us a few options... the easiest of which is isolated the packages we want to maintain and find all the libraries they link/load to dynamically and create a motorola/compatibility/lib/folder to put them all in, and make their execution start up using a change of library path, that way we can update the operating system without affecting those packages.... not my favorite method, but doable.
I've attached an lsof and an ldd of the aiw program. It'd be no small feat to isolate that package.. but it might not be so bad to take the webtopscripts1.6 and find out what packages they hold back.. and then use that list to find what libraries to move across the system. just ideas at this point.
after looking around, it looks like we do not have the source to the motorola specific software (webtop parts). If we do want to move to a later version of ubuntu but still keep things like aiw (android in window) then my thinking would be to jail the current applications that we like (aiw, webtop-panel) those with which we do not have the source to. and then move us to the latest ubuntu (11.10)
My hope is though that the new update to the Atrix will be the latest webtop. That would be much less painful because I believe it's based on 10.10 and we have current support for that through april and then I wont have to bother with this until then............
but I think I'll create a few scripts and automate the whole process of jailing the critical parts of webtop, and see if I can get them to work through the jailed environments.
what do you think?
Yes, definitely we will need to somehow isolate the pieces that have library dependencies moving forward.
Also, in trying to get a non-gnome xfce4 environment while still using webtop-panel, I've come to the conclusion that webtop-panel is a modifed gnome-panel application. It seems to need gnome-settings-daemon, and doesn't like it when you kill gnome-settings-daemon. So I would love to see the source for that to see what they are really doing...probably not going to happen.
Hey are you running a newer webtop then stock 1.2
I see that you're running 2.3.6 (is that from fruitcake derivitive? or 4.5.140?) if so is the firefox/ubuntu newer in it?
I kinda can't wait for the new update to push, I really hope we're getting an update to webtop that would move us to 10.10 or better. That would make my day.
There is another thread where this was discussed, but in short:
webtop 2.3.4: original firefox
webtop 2.3.5: firefox 6 or 7 (I think 6, nut I don't remember offhand)
webtop 2.3.6: firefox 8
Sorry if this is answered elsewhere (and please point me to the correct thread) but does webtop use some kind of modified xorg or some custom x11 derivative? If it's modified that should be published and could help with building our own app.
Sent from my HTC Desire using XDA App
Parastie said:
Sorry if this is answered elsewhere (and please point me to the correct thread) but does webtop use some kind of modified xorg or some custom x11 derivative? If it's modified that should be published and could help with building our own app.
Sent from my HTC Desire using XDA App
Click to expand...
Click to collapse
It looks like they are using a custom xorg install:
http://sourceforge.net/projects/motorola-webtop.motorola/files/WT-1.3.0-X/WT-1.3.0-105_DBN-1/
http://sourceforge.net/projects/mot....3.0-105_DBN-1/xorg-7.5+6ubuntu3.tgz/download
I don't know how far different it is, but there should be a changelong inside that .tgz file.

[GAPPS][DAILY] Open GApps for Android; All Android Versions & Devices

​Questions? Use Q&A!
Please read the FAQ before reporting any bugs or errors!
If you post in the main thread not having read the FAQ or error message itself, not included a debug log when reporting a malfuction or reporting a Force Closure without a logcat, your post will be ignored by the developers!
Not because we are evil, but because the same questions keep popping up over and over again and too often we get a "X doesn't work, plz fix" without any clue what is happening. We don't have telepathic connection to your device and all the time unnecessarily wasted on this can't be spend on development of Open GApps itself.
The Latest builds of Open GApps for Android can easily be downloaded from the:
Open GApps Homepage -> All architectures & download options​
Open GApps App
FAQ @ GitHub
Package comparison @ GitHub
Advanced Features and Options @ GitHub
Development Repository @ GitHub
I work on this project for FREE and putting in a lot of hours into it. While not mandatory, donations encourage me to continue to further pursue this project and I'd deeply appreciate them, if you feel generous.
Donate to The Open GApps Project
Are you a ROM developer and want to hotlink to the latest Open GApps package? Then check this wiki entry for details.
Please don't publicly mirror the prebuilt packages without explicit consent of @MastahF, to ensure that users will always be directed to the very latest version and the source code of the project.
About The Open GApps Project
Open GApps is a Google Apps package completely developed by writing buildscripts which allow for the automated creation of new up-to-date packages automatically.
The development process is completely open-source (GPLv3) and the goal is to have multiple contributors involved, to secure and reinforce the sustainability of Open GApps development.
Builds are generated every (European) night automatically (if there are any changes) and uploaded to GitHub.
Official AROMA Open GApps package is developed in collaboration with long-time LP-AROMA-developer @raulx222 and has a dedicated XDA thread
For any questions about the AROMA installer development, please refer to that thread. Of course, general support questions can also be asked in our own Q&A thread.
Official Open GApps For Stock support is developed in collaboration with @Rapper_skull and has a dedicated XDA thread
For any questions about the GApps for Stock development, please refer to that thread. Of course, general support questions can also be asked in our own Q&A thread.
The x86 package branch of the package is focused on Zenfone support and is maintained by @deadman96385 of the famous Zenfone GApps packages and has its own topic for x86 related questions
For those that cook their own ROM, an AOSP-build mechanism for Open GApps has been developed by @blystad and can be found at GitHub, remember that you should not bundle any pre-packaged Google Apps with any ROMs you want to distribute further though.
To gather all the various APKs that are necessary for the packages our master of the APK Universe @MNBooZe has written a tool called APKCrawler that scrape these from the internet, e.g. from APKMirror, it can be found at GitHub too.
Characteristic of Open GApps:
Some highlights about the characteristics of the Open GApps packages:
All platforms and and all Android versions are supported
DPI-optimized support for all Google packages (unlike other GApps)
Frequently updated Google Apps: The pre-built OpenGApps.org packages are updated every (European) night (if there are any updated Google Apps available)
Strong compression, allowing for relatively small downloads of even the most complete packages
Automatic backup: It is not necessary to re-flash Google Apps when you flash a ROM update. Most ROMs support this (addon.d) function
The installer checks your device’s capabilities, like the system partition size. It will notify you, before making any changes, if it finds any problems
Several package variations, from a Google Super Package (includes all applications that ever shipped on a Google device), to a Stock package that equals the set of applications found on the most current and complete Nexus, to smaller, minimalist packages and an AROMA package that allows graphically selection of what to install
A special ‘for Stock ROM’ installation mode that allows to update the Google Apps on Stock ROMs that conform to the original Google Nexus filesystem structure
All package installations can be customized to your individual preferences using our Advanced Features and Options
The idea behind this project:
I believe a big source of the problem for many GApps packages to stay up-to-date (or not be forfeited) is the lack of time for developers to do labour-intensive repetive every time a new google-app apk is released.
That is why I have taken it upto myself to write some Linux shell scripts to automate the packaging and to share these efforts with the world with the goal to create a team to continue this package together under the name Open GApps.
This project should not be managed by a person, but by a team, so volunteers willing to help are more than welcome!
Team management and projectleader: @[COLOR="blue"]MastahF[/COLOR]
Writing of the scripts: @[COLOR="blue"]MastahF[/COLOR] & @[COLOR="blue"]Rapper_skull[/COLOR] or check the team on GitHub and many other contributors
Updating GApp sources: @[COLOR="blue"]MNBooZe[/COLOR] & @[COLOR="blue"]DJAlik[/COLOR] & @[COLOR="blue"]bgiesing[/COLOR] & @[COLOR="blue"]mc1100[/COLOR] & @[COLOR="blue"]deadman96385[/COLOR] or check the team on GitHub
AROMA installer: @[COLOR="blue"]raulx222[/COLOR] using LibAroma
Custom compiled commandline tools: @[COLOR="blue"]YashdSaraf[/COLOR]
Website: @[COLOR="blue"]raulx222[/COLOR] & @[COLOR="blue"]MastahF[/COLOR] & signalv hosted by GitHub and created with Material Design Lite and JQuery
Artwork: @[COLOR="blue"]Yeti12[/COLOR]: Yeti-Designs website
Documentation: @[COLOR="blue"]Trafalgar-Square[/COLOR] and @[COLOR="blue"]MastahF[/COLOR] and many other contributors.
Open GApps installer uses open source third-party tools, like busybox and xzdec, compiled by @YashdSaraf; See his busybox thread for more info.
Open GApps is originally based on the now discontinued PA GApps package of @TKruzze and @osm0sis
I suggest to @hellowasif and @sir*mez to take a look at this
Hi, @provolinoo suggested me to take a look at this topic.
I made my own GApps, derived from PA GApps by TKruzze and without knowing I solved some problems that the people that were trying to continue the PA GApps are having.
I completely removed the sizes.prop file and now I measure the sizes of the apps on the fly using unzip. I took a look at your scripts and they're really useful, and reminded me that the APKs need to be zipaligned, which I forgot.
Maybe we can join your scripts, my changes, and a fast internet connection to bring PA GApps back to life.
If you're interested here's the link to my topic, please take a look at it: http://forum.xda-developers.com/android/general/alpha-gapps-stock-t3093389
Well i wanted to say thankyou so much for such wonderful work you did, Before this i was maintaining the PA-Gapps Packages PA Gapps 4.4.4 and PA-Gapps 5.X everything was going great and i must say i learned a lot by maintaining these Gapps packages and that was very wonderful experience but i was only updating Gapps and Libs, But than i realized that they weren't as perfect as the original gapps packages because the original Gapps package uses two important files which were size and libs list which the packages uses and they were the most important part of PA-Gapps. I tried to update these two files manually but they were two time consuming so i decided to drop this project due to lack of resources but by these scripts it will very easy to create Gapps Packages so i wanted to say thankyou again
Rapper_skull said:
Hi, @provolinoo suggested me to take a look at this topic.
I made my own GApps, derived from PA GApps by TKruzze and without knowing I solved some problems that the people that were trying to continue the PA GApps are having.
I completely removed the sizes.prop file and now I measure the sizes of the apps on the fly using unzip. I took a look at your scripts and they're really useful, and reminded me that the APKs need to be zipaligned, which I forgot.
Maybe we can join your scripts, my changes, and a fast internet connection to bring PA GApps back to life.
If you're interested here's the link to my topic, please take a look at it: http://forum.xda-developers.com/android/general/alpha-gapps-stock-t3093389
Click to expand...
Click to collapse
Hey, I looked at your work. Some things are indeed good improvements and I will try to incorporate them into my work if you don't mind.
I also looked at your sizes.prop solution, but honestly I don't like it that much, because although the calculation will be very exact, I don't think it is a good idea to unzip large files and pipe all this data through on our small little phones . I prefer to keep the sizes.prop estimations on the generating-side rather than on the execution-side.
I really would like you to be involved in the project, somebody else also already PMed on the forum, wanting to be involved. I described which tasks and roles are very welcome to be fulfilled within a joint team effort.
MastahF said:
Hey, I looked at your work. Some things are indeed good improvements and I will try to incorporate them into my work if you don't mind.
I also looked at your sizes.prop solution, but honestly I don't like it that much, because although the calculation will be very exact, I don't think it is a good idea to unzip large files and pipe all this data through on our small little phones . I prefer to keep the sizes.prop estimations on the generating-side rather than on the execution-side.
I really would like you to be involved in the project, somebody else also already PMed on the forum, wanting to be involved. I described which tasks and roles are very welcome to be fulfilled within a joint team effort.
Click to expand...
Click to collapse
Thank you for your appreciation. The files however are not extracted but I used "unzip -l" that lists the content of the archive with the file sizes. Keep me informed about this project.
hellowasif said:
Well i wanted to say thankyou so much for such wonderful work you did, Before this i was maintaining the PA-Gapps Packages PA Gapps 4.4.4 and PA-Gapps 5.X everything was going great and i must say i learned a lot by maintaining these Gapps packages and that was very wonderful experience but i was only updating Gapps and Libs, But than i realized that they weren't as perfect as the original gapps packages because the original Gapps package uses two important files which were size and libs list which the packages uses and they were the most important part of PA-Gapps. I tried to update these two files manually but they were two time consuming so i decided to drop this project due to lack of resources but by these scripts it will very easy to create Gapps Packages so i wanted to say thankyou again
Click to expand...
Click to collapse
Hi hellowasif,
would you be interested in collaborating then together with other people in a team to bring back PA Gapps using these scripts?
MastahF said:
Hi hellowasif,
would you be interested in collaborating then together with other people in a team to bring back PA Gapps using these scripts?
Click to expand...
Click to collapse
Yes that will be wonderful to work as a team and you count me in. :highfive:
Rapper_skull said:
Thank you for your appreciation. The files however are not extracted but I used "unzip -l" that lists the content of the archive with the file sizes. Keep me informed about this project.
Click to expand...
Click to collapse
Ah, then i misread your code, I will take a look at it then again. Anyhow, since the files in the package are static, I think at moment of generation is a good moment to get the file sizes
I have btw a question for you, a problem I was not able to resolve myself yet, even though trying a lot.
When creating the .zip-package to be signed and afterwards flashed, I am at the moment not using any compression (but use the -Z store flag).
If I use *any* kind of compression, the package refuses to flash at my phone (GT-i9300) with the message error executing update binary error.
I tried a lot of combinations, like using a different zip-application, compressing only the files outside META-INF etcetera, but nothing seems to work.
So my question is: how do you generate and sign your zip file? On which platform? With which application? With which parameters?
MastahF said:
Ah, then i misread your code, I will take a look at it then again. Anyhow, since the files in the package are static, I think at moment of generation is a good moment to get the file sizes
I have btw a question for you, a problem I was not able to resolve myself yet, even though trying a lot.
When creating the .zip-package to be signed and afterwards flashed, I am at the moment not using any compression (but use the -Z store flag).
If I use *any* kind of compression, the package refuses to flash at my phone (GT-i9300) with the message error executing update binary error.
I tried a lot of combinations, like using a different zip-application, compressing only the files outside META-INF etcetera, but nothing seems to work.
So my question is: how do you generate and sign your zip file? On which platform? With which application? With which parameters?
Click to expand...
Click to collapse
You will maybe laugh at my reply, but I simply use WinRAR, on Windows, with maximum compression. I do not yet sign the ZIPs because I wanted to generate my own private key instead of using the generic test-key. What you can try to do is update your recovery (if it's not updated) to see if the problem is solved.
dowloaded your GitHub project and ran through the scripts to create the signed zip file. So far everything is running smoothly. Did a full wipe. Great Job!
Question I have. Do you know why the com.android.vending is still installed in the user space (/data/app) vs system space?
Chrome doesn't seem to be working. It crashes every time I try to run it.
DJAlik said:
dowloaded your GitHub project and ran through the scripts to create the signed zip file. So far everything is running smoothly. Did a full wipe. Great Job!
Question I have. Do you know why the com.android.vending is still installed in the user space (/data/app) vs system space?
Click to expand...
Click to collapse
Thank you for your feedback, at the moment I was extracting the Play Store from a Nexus Image under the cryptic name of Phonesky.
I only found out just now that this Phonesky is the same as android.vending (the Play store) and updated this.
DJAlik said:
Chrome doesn't seem to be working. It crashes every time I try to run it.
Click to expand...
Click to collapse
Also thank you for your feedback. Using your feedback I discovered some nasty typos in my script which were breaking Chrome and Talkback.
I fixed those and will be uploading a new package later today. The fixes are already on github.
hellowasif said:
Yes that will be wonderful to work as a team and you count me in. :highfive:
Click to expand...
Click to collapse
Nice
Very happy to hear that! Tomorrow I will be heading for an island for a week, for holidays, so lucky for me, but unlucky for those interested in updates .
After that holiday I will set-up the basic infrastructure for the team.
I also thought about how to make packages for older android versions and I came up with the following solution that I will be then implementing next week:
*Within the SourceAPKs folder we will put some meta-data or an overlay that specifies the minimal SDK/API version that the package requires
*I will update the scripts in such a way that you can target various android versions, including such a sdk/api version.
*When building for a target, the highest version of the APK that still support that sdk/api version will be selected
*A seperate output directory will be created for each target
*All scripts will be executed from a single Makefile
E.g., the directory structure will look like:
SourceAPKs/18/com.google.android.apps.maps-9.8.1-908101124-minAPI18.apk
SourceAPKs/14/com.google.android.apps.books-3.3.41-30341-minAPI14.apk
Scripts/extract_sources.sh
Output/4.4/pa_unsigned.zip
Output/5.0/pa_unsigned.zip
Output/pa_gapps-4.4-20150504.zip
Output/pa_gapps-5.0-20150504.zip
Makefile
If anybody has any feedback on these ideas, you are welcome!
MastahF said:
Nice
Very happy to hear that! Tomorrow I will be heading for an island for a week, for holidays, so lucky for me, but unlucky for those interested in updates .
After that holiday I will set-up the basic infrastructure for the team.
I also thought about how to make packages for older android versions and I came up with the following solution that I will be then implementing next week:
*Within the SourceAPKs folder we will put some meta-data or an overlay that specifies the minimal SDK/API version that the package requires
*I will update the scripts in such a way that you can target various android versions, including such a sdk/api version.
*When building for a target, the highest version of the APK that still support that sdk/api version will be selected
*A seperate output directory will be created for each target
*All scripts will be executed from a single Makefile
E.g., the directory structure will look like:
SourceAPKs/18/com.google.android.apps.maps-9.8.1-908101124-minAPI18.apk
SourceAPKs/14/com.google.android.apps.books-3.3.41-30341-minAPI14.apk
Scripts/extract_sources.sh
Output/4.4/pa_unsigned.zip
Output/5.0/pa_unsigned.zip
Output/pa_gapps-4.4-20150504.zip
Output/pa_gapps-5.0-20150504.zip
Makefile
If anybody has any feedback on these ideas, you are welcome!
Click to expand...
Click to collapse
The idea of automating all the process is certainly good, but we have to keep in mind that things changes really fast. For example in an update Google can add a library to an application that previously didn't have one. We have to check if there's a lib folder inside the APK instead of assuming that all the APKs that now don't have libs will never have them. Also the idea of various app versions is very good, but also error prone. Maybe we can just put all the APKs in one folder and use the filename to determinate the app name and the minAPI (if we don't want to make a step further and read directly from the AndroidManifest.xml, using aapt).
MastahF said:
Thank you for your feedback, at the moment I was extracting the Play Store from a Nexus Image under the cryptic name of Phonesky.
I only found out just now that this Phonesky is the same as android.vending (the Play store) and updated this.
Also thank you for your feedback. Using your feedback I discovered some nasty typos in my script which were breaking Chrome and Talkback.
I fixed those and will be uploading a new package later today. The fixes are already on github.
Click to expand...
Click to collapse
latest commit:
$ sh make_package.sh
rm: missing operand
DJAlik said:
latest commit:
$ sh make_package.sh
rm: missing operand
Click to expand...
Click to collapse
You can ignore that error-message. I just delete all the temporary files of my text editor (ending with a ~) before packaging using this 'rm' command.
Rapper_skull said:
The idea of automating all the process is certainly good, but we have to keep in mind that things changes really fast. For example in an update Google can add a library to an application that previously didn't have one. We have to check if there's a lib folder inside the APK instead of assuming that all the APKs that now don't have libs will never have them. Also the idea of various app versions is very good, but also error prone. Maybe we can just put all the APKs in one folder and use the filename to determinate the app name and the minAPI (if we don't want to make a step further and read directly from the AndroidManifest.xml, using aapt).
Click to expand...
Click to collapse
Very good comments. I have been looking into the possibility of using aapt. With 'aapt d badging file.apk' I will be able to retrieve the API information and app/packagename from any apk.
Using this information I could make an add-script or an 'add-directory' that would scan any new apks and archives them automatically in a storage. This could help to maintain overview, and to automatically discard older versions of the app if the api-level is not changed. It could also allow for adminstation of x86 and arm64 packages in the tree.
So a 'storage' filetree could become in that case like:
/arm/packagename/api14/maps2.apk
/x86/packagename/api11/maps1.apk
/x86/packagename/api14/maps2.apk
My goal is also to indeed in the future to (more) automatically process the existence of a 'lib' and automatically incorporate into the output process. For this I will have (as within my goals set out for next week) to upgrade the process of generating the output folder. Because at this very moment the scripts still assume availability of (most of the) outputfolders to be there already.
MastahF said:
Very good comments. I have been looking into the possibility of using aapt. With 'aapt d badging file.apk' I will be able to retrieve the API information and app/packagename from any apk.
Using this information I could make an add-script or an 'add-directory' that would scan any new apks and archives them automatically in a storage. This could help to maintain overview, and to automatically discard older versions of the app if the api-level is not changed. It could also allow for adminstation of x86 and arm64 packages in the tree.
So a 'storage' filetree could become in that case like:
/arm/packagename/api14/maps2.apk
/x86/packagename/api11/maps1.apk
/x86/packagename/api14/maps2.apk
My goal is also to indeed in the future to (more) automatically process the existence of a 'lib' and automatically incorporate into the output process. For this I will have (as within my goals set out for next week) to upgrade the process of generating the output folder. Because at this very moment the scripts still assume availability of (most of the) outputfolders to be there already.
Click to expand...
Click to collapse
Exactly, in this way it would be possible to easily maintain arm64 and x86 packages too. The scripting is not complicated, it just requires some time. If you want I can contribute too (I had some experience with shell scripting). If the final scripts are not too long or complicated we can plan a Windows port too, if some future team member is not used to Linux.
We can also try to contact AP to request an RSS feed for new APKs on APKMirror.
EDIT: It seems that adding /feed to any URL will give you the corresponding RSS feed. Good to know.
Rapper_skull said:
Exactly, in this way it would be possible to easily maintain arm64 and x86 packages too. The scripting is not complicated, it just requires some time. If you want I can contribute too (I had some experience with shell scripting). If the final scripts are not too long or complicated we can plan a Windows port too, if some future team member is not used to Linux.
We can also try to contact AP to request an RSS feed for new APKs on APKMirror.
Click to expand...
Click to collapse
I've been using Cygwin on Windows and the scripts work great.

Janus Vulnerability Allows Attackers to Modify Apps without Affecting their Signature

In various thread scattered around the Fire and Kindle forums here on XDA, I talked about the possibility of decompiling an Amazon system APK, modifying the contents such as settings for the framework or changing permissions in an attempt to escalate privileges to some degree, maybe even root. I ran into several issues when attempting such a thing:
1) Using a PC, I found it almost impossible to successfully recompile a modified APK. Many of the tools like APKtool are just too complicated and missing even the slightest step will cause it to fail.
2) Surprisingly, I've had the opposite outcome using two apps. Using APK Export, I was able to export an APK from the system and use APK Editor Pro to modify permissions. I have been able to, on a consistent basis, use APK Editor Pro to decompile the Android Live Wallpaper system APKs to add or remove any permission from the APKs manifest. Installing the APKs did not result in getting them into /system/priv-app on my HD 8, but all modifications held over and over. But every time the signature is ruined, and installing as a system app fails again.
Janus can help escalating permissions even further when using the above method and maybe others, to modify system APKs. The question is: Can we use Janus to modify an APK in some form, to install an update to an Amazon system app, which would on install, execute code that would install SU binaries? What about any other known exploit patched or not? Could we fake the system into thinking a one-click-root app is a system app and install it? Link to XDA article.
Janus takes advantage of the fact that extra bytes go unnoticed in APK files and DEX files. The GuardSquare report explains that an APK file is a ZIP archive which can contain arbitrary bytes at the start, before and between its ZIP entries. The JAR signature scheme only takes into account the ZIP entries, ignoring any extra bytes when computing or verifying the application’s signature.
It goes on to explain that a DEX file, on the other hand, can contain arbitrary bytes at the end – after the regular sections of strings, classes, method definitions, etc. Therefore, a file can be a valid APK file and a valid DEX file at the same time.
GuardSquare also mentions that a key element of the vulnerability is a “harmless” feature of the Dalvik/ART virtual machine. The report states that in theory, the Android runtime loads the APK file, extracts its DEX file and then runs its code. However, in practice, the virtual machine (VM) can load and execute both APK files and DEX files. The issue is that when the VM gets an APK file, it still looks at the magic bytes in the header to decide which type of file it is: DEX or APK. On finding a DEX header, it loads the file as a DEX file. If it doesn’t find a header, it loads the file as an APK file containing a zip entry with a DEX file. Thus, it can misinterpret dual DEX/APK files.
GuardSquare says that an attacker can leverage this duality feature of the VM to add a malicious DEX file to a normal APK file without affecting its signature. The Android runtime will accept the APK file as a valid update to a legitimate earlier app version, but the Dalvik VM will load the code from the DEX file, which has been injected with malicious code.
Click to expand...
Click to collapse
This is a good point. I brought up something similar a few months ago in another thread.
With all the exploits discovered this year where's someone trying these exploits on this hw sw combo we have with FireOS.
Where's the fuzzer for all the system calls while trying the known exploits?
Where is the systematic approach to testing these from the pedants on the forum?
Sure you can reply with the usual comebacks, but try a different approach instead of more of the same.
With
Sent from my iPhone using Tapatalk
Robius said:
Where is the systematic approach to testing these from the pedants on the forum?
Click to expand...
Click to collapse
Totally agree! Those selfish tech elitists who put real life above the desires of strangers. They should dedicate themselves (without compensation) and their community resources to methodically crack this very important nut. Ya know, because exploiting a $50 entertainment gizmo should rise to the top of THEIR priority list. Sorry sweetie, daddy won't becoming to any of your soccer games this year; he has important work to do.
My point exactly.
You spent enough energy to respond to this in a sarcastic manner. Thank you
Sent from my iPhone using Tapatalk
Robius said:
My point exactly.
You spent enough energy to respond to this in a sarcastic manner. Thank you
Click to expand...
Click to collapse
Time well spent; appreciate the opportunity to respond in kind.
I have seen a bunch of hashes running through the terminal last time. Amazon may compare the hashes of the apks against a whitelist.
All right, I am ready to take this exploit on my 5th Gen. What I have to do??
Adyatan said:
All right, I am ready to take this exploit on my 5th Gen. What I have to do??
Click to expand...
Click to collapse
I haven't sat down and looked into this too much so I'm not sure how to execute the exploit yet.
The idea I had been working on months ago was to somehow insert SU binaries into an Amazon system APK, and get it to install the modified APK as an update to an existing system app. The issue back then was the signature getting destroyed. If we can modify an Amazon system APK to contain a script to execute installation of SU binaries, the exploit might allow the APK to install as an update to an existing Amazon app and in theory install the SU binaries. Based on what little I've read, we would have to either 1) modify the existing DEX file of an Amazon system APK to contain code/script to install SU binaries or 2) create a new DEX file with the code and replace it with the original. My opinion is a better chance at the first method.
Now how to do all that using the Janus exploit? I do not yet know.
"An attacker exploiting the flaw could replace a trusted application that already has high privileges, such as a system app, with one of their updates to abuse the permissions that have already been granted. This could enable the attack to access sensitive information stored in the devices or enable the attacker to seize control over the device completely."
https://www.scmagazine.com/janus-vu...-android-50-devices-and-newer/article/713449/
So how would one go about updating a DEX file to contain 1) SU binaries that install upon 'updating' the app on installation? Or 2) clone a system app and edit or change the DEX file? 3) add an exploit script to a DEX file that would gain root (then you would install SU binaries and app)?
It seems the editing of the DEX file itself doesn't damage the signature and that's the nature of the exploit?
Hey is it possible to modify the permissions ota updater and remove the internet permissions so it can't update
I just found this https://github.com/odensc/janus don't have a computer anymore or would try it
Asadullah said:
Hey is it possible to modify the permissions ota updater and remove the internet permissions so it can't update
Click to expand...
Click to collapse
I cannot recall if I've ever tried with that APK. I have tried with others, unsuccessfully. Either the APK will fail to recompile into a proper installation file, or it would 'install', but with none of the modifications holding.
Android Flaw Lets Hackers Inject Malware Into Apps Without Altering Signatures
While installing an Android app or its update, your device checks APK header information to determine if the archive contains code in the compressed DEX files. If header says APK archive contains DEX files, the process virtual machine decompiles the code accordingly and executes it; otherwise, it runs the code as a regular APK file.
It turns out that an APK archive can contain DEX files as well as regular application code simultaneously, without affecting its validity and signatures.
Researchers find that this ability to add extra bytes of code due to lack of file integrity checking could allow attackers to prepend malicious code compiled in DEX format into an APK archive containing legitimate code with valid signatures, eventually tricking app installation process to execute both code on the targeted device without being detected.
In other words, the hack doesn't require attackers to modify the code of legitimate applications (that makes signatures invalid)—instead, the vulnerability allows malware authors to merely add some extra malicious lines of code to the original app.
Click to expand...
Click to collapse
So we would need to write a script or other code that would be placed into a Amazon System APK. Now would we be able to add SU binaries to an APK? What about a root script like DirtyCow. Although DC is patched, would that be different if the exploit was installed into the /system-priv-app and then executed? I really don't want to sound dumb here so please help me pout guys. Any feedback, negative or not is appreciated.
Maybe this tool can help https://forum.xda-developers.com/android/software/tool-dex-manager-v1-0-designed-to-play-t2988532
Robius said:
Maybe this tool can help https://forum.xda-developers.com/android/software/tool-dex-manager-v1-0-designed-to-play-t2988532
Click to expand...
Click to collapse
I can't find a working download link. Apparently it has been discontinued and i was directed to this: Uret Android Reverser Toolkit v1.6. I downloaded it.
I did find the other one but it says it's for a Galaxy Note. Not sure if that's really the case though.
DragonFire1024 said:
Android Flaw Lets Hackers Inject Malware Into Apps Without Altering Signatures
So we would need to write a script or other code that would be placed into a Amazon System APK. Now would we be able to add SU binaries to an APK? What about a root script like DirtyCow. Although DC is patched, would that be different if the exploit was installed into the /system-priv-app and then executed? I really don't want to sound dumb here so please help me pout guys. Any feedback, negative or not is appreciated.
Click to expand...
Click to collapse
It's beyond my knowledge but if you were to maybe add a script to the dex giving it the permisions I gotta look more into this
---------- Post added at 04:13 PM ---------- Previous post was at 03:54 PM ----------
DragonFire1024 said:
I can't find a working download link.
Click to expand...
Click to collapse
here's smali baksmali for editing dex files https://github.com/JesusFreke/smali I havent used it in a while but used to work good
Asadullah said:
It's beyond my knowledge but if you were to maybe add a script to the dex giving it the permisions I gotta look more into this
---------- Post added at 04:13 PM ---------- Previous post was at 03:54 PM ----------
here's smali baksmali for editing dex files https://github.com/JesusFreke/smali I havent used it in a while but used to work good
Click to expand...
Click to collapse
Editing DEX is pretty much out of my league too. I wouldn't know where to start. I don't even know how to install or use the tool you posted.
DragonFire1024 said:
Editing DEX is pretty much out of my league too. I wouldn't know where to start. I don't even know how to install or use the tool you posted.
Click to expand...
Click to collapse
https://github.com/JesusFreke/smali/wiki/DeodexInstructions
It's really pretty simple used to use it take out the ads from angry birds and what not when it first came out. But it's easier said than done. If you do try first thing I would suggest is that you decompile then recompile to see if it works right the dependencies sometimes will get you or we can try and beg another developer to make us a modified apk..... Please pretty please with sugar on topwe'll like all your posts???
Check this thread for root possibility:
https://forum.xda-developers.com/hd8-hd10/general/complete-guide-root-hd7-8-106th-gen-t3545411
Robius said:
Check this thread for root possibility:
https://forum.xda-developers.com/hd8-hd10/general/complete-guide-root-hd7-8-106th-gen-t3545411
Click to expand...
Click to collapse
FYI - nothing new in that thread. Same familiar tools/techniques targeting a different gen/suite of Amazon devices. Similar outcomes too. Vulnerability patched in FireOS 5.3.2.x as so far proven impenetrable by generic rooting tools of common origin (KingRoot, KingORoot, etc).
Davey126 said:
FYI - nothing new in that thread. Same familiar tools/techniques targeting a different gen/suite of Amazon devices. Similar outcomes too. Vulnerability patched in FireOS 5.3.2.x as so far proven impenetrable by generic rooting tools of common origin (KingRoot, KingORoot, etc).
Click to expand...
Click to collapse
Not sure if the following report is true: (HD10 7th Gen on 5.6.0.0)
https://forum.xda-developers.com/hd8-hd10/general/rooted-fire-hd-10-7th-generation-t3718629

Categories

Resources