Related
GApps2zip
This script makes an update.zip file that only contains the Google Apps from the HTC release of the 1.5 firmware upgrade for the ADP 1. This update.zip should be flashable on any build and it should work without a problem, but since I'm just a n00b sophomore in highschool, I am naturally poor and can't guarantee anything.
Because there are already a few alternatives to this for Linux and the majority of Android users use Windows, I decided to make this a Windows-only batch script.
You MUST have the Java Runtime Environment installed in order to run this script! The signing utility requires Java and you won't be able to flash an unsigned update. If it doesn't work even if you have Java, you may have to reinstall Java as it is not in your PATH variable for whatever reason.
UPDATE: Updated and, as far as I know, should now work fine with the 1.6 developer images from HTC as well as personal NANDroid backups of most all 1.6 Android ROMs.
INSTRUCTIONS
1) Either do a or b. It is advised to use a personal NANDroid backup (b) as it does not violate any licenses, but it has not been testeda) Google for the file "signed-dream_devphone_userdebug-img-14721.zip" It should be on the HTC support page for the ADP 1, but it wont be the first result in Google. It is not advised to use this method as you need to agree to a license prohibiting modification of the file in order to download it. Rename the file to "backup.zip"b) Restore to a regular build that has all of the Google Apps (like the regular OTA cupcake update) and then run a NANDroid backup. Then make a zip file that only has the system.img file from the NANDroid dump and name the zip "backup.zip"2) If you haven't already, unzip the entire contents of the gapps2zip.zip file into a directory. For sake of simplification, I am assuming it is unzipped to C:\gapps2zip
3) Place the "backup.zip" file in the same directory as the GApps2zip.bat file (C:\gapps2zip) and DON'T rename it or unzip it.
4) Open up a command prompt window (Hit Windows + R, type in CMD, then click OK)
5) cd to the directory in which the GApps2zip.bat file, utils directory and the backup.zip file. For example:
Code:
cd C:\gapps2zip
6)Type in "GApps2zip.bat" (without the quotes) and hit enter. Watch and wait.
7) If all goes well, you should have an update_gapps.zip folder in C:\gapps2zip. Put it on your SD card, make a NANDroid backup, and flash after flashing an AOSP (Android Open Source Project) build that doesn't include the Google Apps.
Credits
Cyanogen for his hard work and dedication
Maxisma for a similar script on which this is based
Google for their ingenious ideas (although their legal department can be a pain)
Everyone who is willing to test this script out
Everyone else xD
Redistribution
Feel free to redistribute the archive wherever you like, but please give me credit along with Maxisma and do not modify the archive in any way.
Great job unk!
amgupt01 said:
GApps2zip - Created by Ankush Gupta (twitter.com/unkzdomain and unkzdomain.com)
This script makes an update.zip file that only contains the Google Apps from the HTC release of the 1.5 firmware upgrade for the ADP 1. This update.zip should be flashable on any build and it should work without a problem, but since I'm just a n00b sophomore in highschool, I am naturally poor and can't guarantee anything.
Because there are already a few alternatives to this for Linux and the majority of Android users use Windows, I decided to make this a Windows-only batch script.
You MUST have the Java Runtime Environment installed in order to run this script! The signing utility requires Java and you won't be able to flash an unsigned update.
This script does NOT work on a build that includes the new market as there are some incompatibilities with the files for it and the ones provided by HTC (namely the MarketUpdater.apk for the new market). This is pretty much doesn't matter however, because all AOSP builds will not include ANY Android market anyways.
INSTRUCTIONS
1) Google for the file "signed-dream_devphone_userdebug-img-150275.zip" (It should be on the HTC support page for the ADP 1, but it wont be the first result in Google)
2) If you haven't already, unzip the entire contents of this zip file into a directory. For sake of simplification, I am assuming it is unzipped to C:\gapps2zip
3) Place the "signed-dream_devphone_userdebug-img-150275.zip" file in the same directory as the GApps2zip.bat file (C:\gapps2zip) and DON'T rename it.
4) Open up a command prompt window (Hit Windows + R, type in CMD, then click OK)
5) cd to the directory in which the GApps2zip.bat file, utils directory and the signed-dream_devphone_userdebug-img-150275.zip file. For example:
Code:
cd C:\gapps2zip
6)Type in "GApps2zip.bat" (without the quotes) and hit enter. Watch and wait.
7) If all goes well, you should have an update_gapps.zip folder in C:\gapps2zip. Put it on your SD card, make a NANDroid backup, and flash after flashing an AOSP (Android Open Source Project) build that doesn't include the Google Apps.
Credits
Cyanogen for his hard work and dedication
Maxisma for a similar script on which this is based
Google for their ingenious ideas (although their legal department can be a pain)
Everyone who is willing to test this script out
Everyone else xD
Redistribution
Feel free to redistribute the archive wherever you like, but please give me credit along with Maxisma and do not modify the archive in any way.
Click to expand...
Click to collapse
when it asks u to replace system.img, do you click yes or no?
Looks interesting ill test it out later
Guyver75 said:
when it asks u to replace system.img, do you click yes or no?
Click to expand...
Click to collapse
You click Yes. You shouldnt have extracted the zip though, but it won't make a difference anyways.
Looks interesting ill test it out later
amgupt01 said:
You click Yes. You shouldnt have extracted the zip though, but it won't make a difference anyways.
Click to expand...
Click to collapse
oh ok, oops. i clicked no. guess ill have to redo it
ok trying to understand this. From what i get is you download, Lets say cm 4.2 without google (made up rom dont go looking for it)
then you flash that to are phone.
next when flash update_gapps.zip
Then we will have a cm rom with google apks?
And in returns the update_gapps is kinda like a theme only adding the needed files?
xile6 said:
ok trying to understand this. From what i get is you download, Lets say cm 4.2 without google (made up rom dont go looking for it)
then you flash that to are phone.
next when flash update_gapps.zip
Then we will have a cm rom with google apks?
And in returns the update_gapps is kinda like a theme only adding the needed files?
Click to expand...
Click to collapse
Exactly. The only thing is that since this uses an official, legal source, it doesn't include the new market and stuff...
Ok cool but once 1.6 adp1 is out we will have to update the script and do this again?
amgupt01 said:
This script makes an update.zip file that only contains the Google Apps from the HTC release of the 1.5 firmware upgrade for the ADP 1.
Click to expand...
Click to collapse
I applaud your efforts to help the community. Many thanks.
For those who think this is proof modding and this community will live on, think again. What he's doing aids and abets violation of Goog's rights. This thread will be locked and the links taken down. Welcome to the new world of Android.
xile6 said:
Ok cool but once 1.6 adp1 is out we will have to update the script and do this again?
Click to expand...
Click to collapse
Well, provided that HTC distributes ADP 1.6 the same way as they are 1.5 and that the file dependencies for closed-source apps are similar, we could just reuse this same script with maybe a few minor modifications.
ytj87 said:
I applaud your efforts to help the community. Many thanks.
For those who think this is proof modding and this community will live on, think again. What he's doing aids and abets violation of Goog's rights. This thread will be locked and the links taken down. Welcome to the new world of Android.
Click to expand...
Click to collapse
How does it aid and abet to violations of Google's rights? I am basically linking to an official mirror (HTC) that is licensed by Google to distribute the files.
@ amgupt01
Thanx now all we got to do is let the builds continue.
great job mr. sophomore, you should get together with cyanogen on this although i'm sure he's probably going to do something similar.
is it safe to sign in to google with the newly created update_gapps2zip?
amgupt01 said:
How does it aid and abet to violations of Google's rights? I am basically linking to an official mirror (HTC) that is licensed by Google to distribute the files.
Click to expand...
Click to collapse
I think the issue is that Google doesnt want its closed source apps put on non google-experience phones. This guy's method allows just that.
Cyanogen's method (from what I can gather) is to run an app on your phone that backs up the apps that you have on your phone (presumably licensed copies that you acquired when you purchased your phone, or during an OTA update), and then restores them after you run his barebones ROM. In this manner, you are only using backed up copies of software you are entitled to use.
I read somewhere (maybe in Google's C&D? I'm to lazy to go look) that Google does not allow these applications to be copied or extracted or something to that affect.
Honestly, why on earth would we expect them to react any differently?! This is a growing pain. We will all be better for it when its passed.
Here's how I'm planning on riding this out:
1. When Cyanogen releases 4.2, I will unroot my phone, and get the most recent OTA update from Tmobile.
1. Install Cyanogen's 4.2 ROM, using whatever method of installation is required to back up my closed source applications and restore them.
2. Continue to update Cyanogens ROMs this way until we discover that our old closed source apps are no longer compatible with our state of the art ROM.
3. Begin to seek out alternative apps, or check progress of the new "Open Android Alliance" or whatever those guys are calling themselves since this whole fiasco started, to see how feasible that option is.
4. Buy a new phone? I mean, how far down the road are we talking here?! And yes, when the time comes, assuming Google doesn't do something completely draconian that makes us pine for the good old days when they sent a C&D to Cyanogen, it will be another Android phone (subsequently rooted, of course)
I don't really see another legal option.
Code:
Cyanogen on twitter
So I think I've come up with a solution that should work and not violate any licenses. Just need to polish it up a bit.about 14 hours ago from twidroid
Thanks for this script.. i am amazed of how fast the community is getting up from the C&D .... Open Android Alliance is kicking off, Maxima is already out with a NO Google ROM, and this script, to get google's apps... wonderful...
amgupt01 said:
How does it aid and abet to violations of Google's rights? I am basically linking to an official mirror (HTC) that is licensed by Google to distribute the files.
Click to expand...
Click to collapse
amg, I'm worried on two fronts.
1, HTC is redist'ing Goog bits. They may very well get a c&d. I can't imagine HTC has a license to freely distribute them to anyone and everyone. I have to believe the license is for use on HTC hardware, not any user worldwide as download and extraction would allow.
2, you are aiding in the grabbing of those bits that a user may not have license to.
Granted, I know the vast majority of us have license. But there a few non-Goog experience phone owners around here. I suspect the mods will lock down.
But again... I think that would be wrong. We have license to the bits and grabbing them from HTC is not a violation IMO. But we'll see.
Thank you.
amg,
From the HTC license page when you download:
-----
You may not copy (except for backup purposes), modify, adapt, redistribute, decompile, reverse engineer, disassemble, or create derivative works of the Google Software or any part of the Google Software. You may only load the Google Software onto the Android Developer Phone 1, and except in conjunction with third party software that makes up the Android system image, you may not combine any part of the Google Software with other software, or distribute any software or device incorporating a part of the Google Software.
-----
So it's clear this is illegal. I think HTC will have to pull this down sooner or later as widespread extraction starts.
btw, I think you're fine. HTC will hear from Goog and this thread will be locked. But otherwise don't worry.
Hello everyone! My name is geeksunny and I am fairly new to the community. Been a lurker for a quite a while now but I finally have something to share!
BarebonesAndroid
What it is
What I have here is a Bash script to automate backing up your /system/app directory and then steps through a list of packages offering to remove them from your device. It runs on your Linux PC and uses ADB to interface with your device.
I wrote this for myself to automate the process of trimming my system down after I flash a new ROM. I recently bought a Nook Color and have been flashing CyanogenMod 7 nightlys to it pretty frequently. I also use a Motorola Droid phone and this comes in handy for the same reason on that device as well.
Seeing as how this was written with CyanogenMod 7 in mind, I am not sure how well it will work with other ROMs. I think it would work as it uses generic uninstall commands. It is based off of the packages that come in CM7 so those packages are the only ones considered by this script.
Note: I'm pretty rusty with my Bash scripting and kinda threw this together in my spare time. It may not be the prettiest script in the world but it gets the job done!
Requirements
To use this script you must...
- Be running a Linux/Unix based OS. (I use Ubuntu for my SDK machine. I don't have a Mac and do not know for sure if this will run on OSX.)
- Have ADB set up correctly and talking with your device.
- Have read/write access to your device's /system folder. (Be rooted.)
How to use it
Unzip and run ./BarebonesAndroid.sh in your terminal.
if ./BarebonesAndroid.sh is not executable, run this command:
Code:
chmod 775 BarebonesAndroid.sh
- It will first ask you to confirm that the device is connected and recognized by ADB.
- It will then ask if you want to back up your /system/app directory before removing any packages. If yes, you can specify a directory for the script to back them up to. It will default to ./apkBackup
- After this it will begin ask you one-by-one if you want to remove a given package. Enter Y or N for each package.
- When the script is finish it will reboot your device.
Future plans
I originally wrote this for myself but thought this could be useful to others out there. Right now the requirements aren't all that accessable to the average user (Linux OS with ADB set up). If there is a demand for it, I may write a Windows batch script version, or maybe convert it into a cross-platform command-line application. Let me know what you think of this idea!
I do have a book on Android development and my eventual goal is to turn this in to a native app!
Regarding the script...
- Add support for multiple devices. Right now it asks that you only have one device connected at a time. This is because I haven't had experience with multiple devices hooked up at once. I plan to fix that in the future.
- Add more error checking and failproofing.
- Streamline the experience. Make things a little more graceful than going through a set list one-by-one.
- Sort the apps. Perhaps add categories.
- Check installed packages and only offer to remove them if they are installed.
Thats it! Thanks for looking!
Thanks dude, good work!
Inspired by SimpleSU (I really love it), which is not so simple to use after all (mainly because it is intended for shipping in the ramdisk or the likes), and closed source, I made my own superuser implementation, µSuper.
I provide it to you, mainly so you can give me some feed back or just try it, whatever you prefer.
Just like SimpleSU it uses a text file.
Unlike SimpleSU this text file contains the UIDs of the apps, not their package names (which makes µSU less vulnerable to frauds). It is also not on the hard to access /system partition, but in the private data directory of µSU, and globally set to read-only.
With only 309 SLOC (app and binary combined) I think it is safe to say that it is really tiny.
The source code is publicly available on Github.
@MarcoToo I know this has been here for ages but I'm amazed this thread has less than 600 views and You've only got 3 thanks... It's my favourite SuperUser app as it uses next to no resources. The only thing wrong is that it won't work with anything above JellyBean 4.2.2 which is a shame; I don't supposed you plan to support further Android versions? or is it easy for me to build this to support further versions?
Thanks anyway, all the people not using this are missing out
HTCDreamOn said:
@MarcoToo I know this has been here for ages but I'm amazed this thread has less than 600 views and You've only got 3 thanks... It's my favourite SuperUser app as it uses next to no resources. The only thing wrong is that it won't work with anything above JellyBean 4.2.2 which is a shame; I don't supposed you plan to support further Android versions? or is it easy for me to build this to support further versions?
Thanks anyway, all the people not using this are missing out
Click to expand...
Click to collapse
theres a reason to it, because the developer hasn't kept the app updated, while supersu is updated almost weekly. The lastest SuperSU has way more support as to this because it is outdated, and in beta at that. Safer and more compatible alternative would be SuperSU
Aiko0923 said:
theres a reason to it, because the developer hasn't kept the app updated, while supersu is updated almost weekly. The lastest SuperSU has way more support as to this because it is outdated, and in beta at that. Safer and more compatible alternative would be SuperSU
Click to expand...
Click to collapse
I see your point but I still stick with this SU: SuperSU is closed source, and even Koush' open source Superuser app is theoretically less secure than this, due to the whole granting mechanism; with µSuper the user must explicitly select which apps gain su access whether they ask for it or not, and the code is so small there's little which could go wrong. Each to their own, though , I use this because the Desire Z is lacking in memory and CPU power so every little helps, but on a more powerful device it wouldn't bother me.
HTCDreamOn said:
I don't supposed you plan to support further Android versions? or is it easy for me to build this to support further versions?
Click to expand...
Click to collapse
I think the location for app files has changed from /data/data to something else. Since µSuper's su binary uses a hardcoded path to the permissions file (using an environment variable would be quite unsafe), the only things you would have to change are the targetSdkVersion in the app's AndroidManifest.xml and (if it did change) the path to the permissions file in su.c.
MarcoToo said:
I think the location for app files has changed from /data/data to something else. Since µSuper's su binary uses a hardcoded path to the permissions file (using an environment variable would be quite unsafe), the only things you would have to change are the targetSdkVersion in the app's AndroidManifest.xml and (if it did change) the path to the permissions file in su.c.
Click to expand...
Click to collapse
Forked and synced let's see if I can fix this for later versions I don't suppose you'd know how to implement this into a ROM (using source code)? From the README I assume I'm allowed to
Edit: I've created a xposed module which works with the banking app version 1.7.1 see post below.
---------------------------------------------------
Edit: The changes needed to work with the latest version of the app (1.7.1) are listed in a post below below.
---------------------------------------------------
*There was a error in the diff file. I've uploaded the correct version. Also this patch will definitely not work with the latest version of the app.*
I managed to patch the Barclays mobile banking app version 1.4.2 to make it work with cyanagonmod 10.0 and cyanogenmod 11.
I realize that the current version on play store is 1.7.1 but I haven't updated to the latest version yet. If you do try the latest version please let me know if it differs greatly from the current version in it's root checks
I'm not going to attach the patched apk since using banking app from a stranger on the internet is really not a smart thing . Instead I will detail the work I did which hopefully someone else will find useful.
This guide is geared towards more technical people who already have some experience with android development. It will not give a detailed step by step how to, rather a general information about the process.
Obfuscation methods used in the app
The app obfuscates the names of some but not all of the namespaces/classes/methods which can stump some decompilers.
It seems to generously sprinkle useless switch statements and loops which does nothing but make the code appear way more complicated than it really is. I would guess quite a lot of the bulk in the code is coming through these dummy statements. smali2java-toolkit was of great help to figure this out.
All strings in the app have been encrypted by a simple xor algorithm which is then decrypted at run time just before they are used:
for example rather than
Code:
myfunction(“Hello world”)
the code writes something in the sort of:
Code:
myfunction(decrypt(“Juqqdxidqw”, 'x'))
The decryption function is a static method 'bЮЮЮЮЮЮ' in the class appears to be 'rrrrrr.srrrrr' (the method/class/namespace names are obfusecated)
I extracted the decompiled code from this method to write a console application which let me decrypt any string in the application:
Code:
static String decrypt(String crypStr, char keyChar) {
char[] arrayOfChar1 = crypStr.toCharArray();
char[] arrayOfChar2 = new char[arrayOfChar1.length];
for (int i = 0; i < arrayOfChar1.length; i++)
{
int j = keyChar ^ arrayOfChar1[i];
arrayOfChar2[i] = ((char)j);
}
return new String(arrayOfChar2);
}
Anti root methods used in the app
Checking for 'test-keys' string in the build tag. (/system/build.prop file)
Checking for superuser related package/apk files.
Checking for superuser hider package/apk files.
Checking for existance of 'su' binary
Attempting to execute 'su' binaryThe above checks are done both in the java/dex code and in a native code library.
Defeating the anti-root methods in Java/dex code:
The Java code is fairly easy defeat since changing the strings of the apk/file names which are checked as root related will make it think that no 'bad' apps are on the phone.
A bulk of checks happen in the isRootedDevice method of the com.barclays.android.application.BMBApplication class. While it checks for quite a lot of apk's, for my particular purpose I only needed to patch 2 lines in the method:
Smali file line 306 – which starts the checks for “test-keys” string in the build tag.
Smali file line 407 – which start the check for the string “/system/app/Superuser.apk”.The next method in the same class 'runRootCommand' attempts to execute 'su'
Smali line: 956 – which contains the string “su” which will be passed to java.lang.Runtime.exec
A (mostly?) duplicate of the isRootedDevice function exists in the com.barclays.android.container.DeviceData the relevant lines are :
smali file line 1237: "test-keys" string check
smali file line 1271: "/system/app/Superuser.apk" file checkAll of the above checks can easily be defeated by changing the the string so that it will check for a non existent package or file.
Keep in mind that all the strings listed above are in encrypted form. You can use the decrypt function listed above to decode them. I found the key char/byte needed to decrypt a given string is in the very next line to the one containing the encrypted string.
Defeating the anti-root methods in Native library
From what I can see the exact same tests which were done in the Java code is repeated in the native code library 'libtest_ndk.so'. As this check appears to form part of the authentication mechanism i don't believe it's possible to simply stop this check from being called from the Java code.
Also the com.barclays.android.container.sampler.SharedLibraryLoader which loads the native library appears to be doing some kind of checksum validation. While this probably could be easily worked around, disassembling an arm shared library was non trivial for me.
My approach was to write another native library which would hook into all the system calls such as 'system' 'stat' 'fopen', '__system_property_get' and redirect any operations to non existent targets, or change the return value. This achieves the same thing as what was done for the java code.
I put in some extra code into the smali classes to load my native library and to call it's initializer with the path to the actual native library.
Basic steps performed to patch the library:
Use apktool to decompile the original apk.
Code:
apktool d barclays.apk barclays
Use smali2java as helper to understand the code: This tool cannot decompile the critical check functions due to obfuscation. However it made it easier to understand the smali files generated by the apktool.
Patch the smali files to work around the checks as described above.
Build the hooking native library seperately
Code:
~/adt/adt-bundle-linux-x86_64-20131030/sdk/tools/android update project --path . --target android-19
ndk-build
Include the hooking shared library into the lib/armeabi of the decompiled package and change the smali files to load the new shared library.
Use apktool to rebuild the apk.
Code:
Apktool b barclays barclays.apk
Sign the apk from using your own key.
Create keystore:
Code:
keytool.exe -genkey -v -keystore my-release-key.keystore -alias release -keyalg RSA -keysize 2048 -validity 20000
Sign Keystore:
Code:
jarsigner -verbose -sigalg SHA1withRSA -digestalg SHA1 -keystore my-release-key.keystore barclays.apk release
Attached is the code for the hook library native project and the diff for the smali changes. Please note that this is for the smali files for generated by apktool (v1.5.2) for the version 1.4.2 of the Barclays mobile banking app.
For Users of other ROMs/SU applications and root hiders.
The app checks for a lot of common packages which I did not bother to patch since I don't use them, but if you do then you should put fixes for all those package/file names in both the smali and native code hook library.
A non exhustive list of files it check are:
Code:
/system/bin/amphoras
/system/bin/su
/system/xbin/su
/system/app/superuser.apk
/data/data/com.amphoras.hidemyroot
/data/data/eu.chainfire.supersu
/data/data/stericson.busybox
/data/data/stericson.busybox.donate
/data/data/com.jrummy.busybox.installer.pro
/data/data/com.jrummy.busybox.installer
/data/data/com.rootuninstaller.free
/data/data/com.rootuninstaller
Hey i will try this out shortly and post a APK (whether you use it or not thats up to you, but i am well known in the xperia play section of this website and should be trusted, Still its up to you.)
EDIT: well i am not a android developer, i can follow almost all this post except the bits about the native library any chance of a bit more information
specifically this bit "Include the hooking shared library into the lib/armeabi of the decompiled package and change the smali files to load the new shared library."
i assume that means just simply copy the built lib file in to that folder then include the file in the code somewhere? where do i do that to?
Sorry about the late reply but I just saw this message.
fma965 said:
EDIT: well i am not a android developer, i can follow almost all this post except the bits about the native library any chance of a bit more information
specifically this bit "Include the hooking shared library into the lib/armeabi of the decompiled package and change the smali files to load the new shared library."
i assume that means just simply copy the built lib file in to that folder then include the file in the code somewhere? where do i do that to?
Click to expand...
Click to collapse
That's pretty much correct. There is already a 'libtest_ndk.so' file in the lib/armeabi folder of the apk. You just have to build my code from the zip file to get the libhooktest.so, which should then be copied into the lib/armeabi folder alongside the libtest_ndk.so.
Edit: Not sure if this is enough instructions. I'm just not good at writing instructions. Steps you need to build the native library are in my post. If you need more info i suggest about building the library http://code.google.com/p/awesomeguy/wiki/JNITutorial#Setup_Environment is a good
Afterwards you have to do the modifications I've listed in the diff to the .smali files.
But i have some bad news about this patch:
The diff file i have attached in the post is wrong. I've mistakenly uploaded the patch to reverse the changes i did . I will update the post with the correct diff file.
It will only work for Barclays app version 1.4.2. it will definitely not work for the latest version of the app which is 1.7.1.
I'm currently going through the code of 1.7.1 I've made some headway into the code but there I'm quite way off from getting it to work.
If you wish I can give you a copy of the original 1.4.2 of Barclays app, the built lib file and the patched app. I would recommend against using the patched app blindly but it might make it easier to figure out the changes i did. I would rather not upload them to xda though.
HiddenRambler said:
Sorry about the late reply but I just saw this message.
That's pretty much correct. There is already a 'libtest_ndk.so' file in the lib/armeabi folder of the apk. You just have to build my code from the zip file to get the libhooktest.so, which should then be copied into the lib/armeabi folder alongside the libtest_ndk.so.
Edit: Not sure if this is enough instructions. I'm just not good at writing instructions. Steps you need to build the native library are in my post. If you need more info i suggest about building the library http://code.google.com/p/awesomeguy/wiki/JNITutorial#Setup_Environment is a good
Afterwards you have to do the modifications I've listed in the diff to the .smali files.
But i have some bad news about this patch:
The diff file i have attached in the post is wrong. I've mistakenly uploaded the patch to reverse the changes i did . I will update the post with the correct diff file.
It will only work for Barclays app version 1.4.2. it will definitely not work for the latest version of the app which is 1.7.1.
I'm currently going through the code of 1.7.1 I've made some headway into the code but there I'm quite way off from getting it to work.
If you wish I can give you a copy of the original 1.4.2 of Barclays app, the built lib file and the patched app. I would recommend against using the patched app blindly but it might make it easier to figure out the changes i did. I would rather not upload them to xda though.
Click to expand...
Click to collapse
No worries about the late reply, yeah you basically told me what i assumed it was i had to do, however when i was trying to do it i didn't have a 1.4.2 apk so was trying ot use 1.7.X and obviously failed .
Yeah the modifications to smali files is easy well when you know what your changing xD
if you could upload the apk for 1.4.2 that would be great, i would assume that as long as the signature matches the official apk its untampered, your modified one will obviously be signed with a different signature though.
:cyclops:
Good news. I've managed to get latest version 1.7.1 patched . I will try to post the patch information this weekend. In the meantime i suggest anyone interested download a copy from the play store and keep a backup of the apk in case they release a new version.
Fix for latest version of the mobile banking app (version 1.7.1)
I've figured out the changes required for the v1.7.1 of the app which is the latest version as of this post.
Changes from the old 1.4.2 are:
Almost all the classes in the app are now obfuscated, whereas before only some of the core class names were obfuscated.
The string encryption has changed. rather than a single encryption function it now uses a group of functions to perform the encryption. rrrrrr/vuuuvu class seems to manage invoking the proper decryptor based on the arguments.
All root checking is now done via the native library.
Native library now does some checks as soon as it's loaded before any methods are called.
The last change is a big problem since its not possible to do the patching of the dll after loading it as was done before. The onload/init of the dll exits the whole application as soon as it detects the phone is rooted.
My solution was to use a modified version of the 'crazy_linker' custom loader library which comes with the ndk to load the library into memory without invoking it's onload/init functions. This lets us hook into the necessary functions before they are called.
I've attached the smali changes as a diff and the new native hook library in this post.
As a side note I think the version 1.4.2 is a far better version. Why on earth would a banking app need to permissions to take pictures, who spends their time 'customizing' a banking app with personal pictures.
Edit: I've fixed a bug where the root was still being detected when used with chainfire su app. Special thanks to lil-diabo for helping me fix the issue. :good:
Xposed module for barclays banking app 1.7.1
Edit: New version (BarcPosed1.1.apk) has some support for barclays pingit. I've not tested this my self as I don't use the application personally. If anyone tries it please let me know.
I've converted my patch into xposed module. This module is compatible with the current banking app (version 1.7.1).
Please consider this as a beta version for now. I've tested it on cyanogenmod but it might have some issues with other roms. If you try it please let me know if it worked.
Assuming you already have a working xposed installation the steps to get the app working are:
1) Install banking app from playstore. Make sure it's version 1.7.1
2) Install the BarcPosed.apk from my post.
3) Run the BarcPosed app and click the 'install' button. You will need to grant it root permissions.
4) Enable the module in xposed and reboot.
5) Use the barclays app as normal.
6) Disable automatic updates for the banking app to prevent it from updating.
I've included the source code for the app.
Thanks, works perfectly. You sir (or madam) are a genius
Sent from my GT-I9300 using XDA Premium 4 mobile app
Works like a charm
Just tested it and it works!
Most excellent, Thanks again for your hard work.
So much easier than having to manually edit the files etc.
It works,excellent job, finally can use Barclays mobile, thank you very much
sent from Samsung Galaxy S4 Active
Just tested and it worked marvellously. Could you please make a fix for pingit as well?
Zell Dinch said:
Just tested and it worked marvellously. Could you please make a fix for pingit as well?
Click to expand...
Click to collapse
HiddenRambler said:
Edit: New version (BarcPosed1.1.apk) has some support for barclays pingit. I've not tested this my self as I don't use the application personally. If anyone tries it please let me know.
Click to expand...
Click to collapse
I've updated my post with version that stops the rooted warning from pingit. Don't use pingit myself so don't know how successful it is. Let me know if you try it.
Brilliant, been struggling in vain with Root Cloak Plus on my N5 but this works perfectly. Many thanks.
Sent from my Xoom Wifi using Tapatalk
Before I switched to KK, I used Barclays App 1.3 doing a small trick with SuperSU. It worked perfectly. I signed the app myself so that it wouldn't update itself from the market and so that I could still use the automatic update in the market.
Do you think it would be possible to make your AMAZING solution work with my v1.3 signed app instead?
thnx
vivelafrance said:
Before I switched to KK, I used Barclays App 1.3 doing a small trick with SuperSU. It worked perfectly. I signed the app myself so that it wouldn't update itself from the market and so that I could still use the automatic update in the market.
Do you think it would be possible to make your AMAZING solution work with my v1.3 signed app instead?
thnx
Click to expand...
Click to collapse
You could try "root cloak" or "root cloak plus" they probably will work.
Actually, what I did, is sign the app with OneClickSigner and it worked fine. Now, the app is not attached to the market anymore since the signature changed, so that means I can continue to use the "automatic update" from the market and it won't ask me to update the app all the time when Barclays upload a new version.
thnx
HiddenRambler said:
...
I've converted my patch into xposed module. This module is compatible with the current banking app (version 1.7.1).
...
Click to expand...
Click to collapse
Hello,
I have a request, can you make it compatible with GingerBread plz?
Thanks.
LoMAX_HUN said:
Hello,
I have a request, can you make it compatible with GingerBread plz?
Thanks.
Click to expand...
Click to collapse
Can you try the attached apk. It's the same code but built as an app for gingerbread version (API lvl 10). I couldn't test it as I don't have a phone for that version.
If it doesn't work please give me a logcat.
Banking Works, but Not PingIt
HiddenRambler said:
Edit: New version (BarcPosed1.1.apk) has some support for barclays pingit. I've not tested this my self as I don't use the application personally. If anyone tries it please let me know.
I've converted my patch into xposed module. This module is compatible with the current banking app (version 1.7.1).
Please consider this as a beta version for now. I've tested it on cyanogenmod but it might have some issues with other roms. If you try it please let me know if it worked.
Assuming you already have a working xposed installation the steps to get the app working are:
1) Install banking app from playstore. Make sure it's version 1.7.1
2) Install the BarcPosed.apk from my post.
3) Run the BarcPosed app and click the 'install' button. You will need to grant it root permissions.
4) Enable the module in xposed and reboot.
5) Use the barclays app as normal.
6) Disable automatic updates for the banking app to prevent it from updating.
I've included the source code for the app.
Click to expand...
Click to collapse
xposed is fantastic!
This worked for me. It's so nice to be able to update my SU binaries without fear of breaking the app.
I'm running Cyanogenmod v10.2.0 on a Samsung Galaxy S3 (International) (i9300).
I tried using the v1.1 of the BarcPosed.apk with PingIt, but it still tried to gain root and then closed itself immediately.
Disclaymer: I am not responsible by what this binary can cause to your phone.
In the past month I have been struggling with getting "rclone mount" working on my phone, and after not finding anyway to have fuse working on my phone I decided to compile the fusermount.
Yoy should copy the binary to /system/bin or add to your path "export PATH=$PATH:/path_to_fusermount"
I use the source code from: https://github.com/LineageOS/android_external_fuse/tree/cm-14.1
and https://github.com/kirbyfan64/zdata/blob/master/fs/jni/fusermount.mk to compile the binary
In my case I can now use rclone in the following way (you still need to have root access), on a terminal (termux) for android:
Code:
su
rclone mount Box:/ /storage/cloud --vfs-cache-mode minimal --allow-other --gid 1015
Tested on:
Mi4c cm14.1 (android 7.1)
Huawei Mediapad M5 (android 8)
na
Thank you very much. It's so nice that ican mount gdrive on my old phone. Helped me a lot.
Can see my mount point on termux but not see on file manager, please help??
boyrobbie said:
Can see my mount point on termux but not see on file manager, please help??
Click to expand...
Click to collapse
Are you using magisk module based rclone-mount?
darfri said:
Are you using magisk module based rclone-mount?
Click to expand...
Click to collapse
Same with me, I am using magisk module based rclone-mount.
I'm also using magisk module on android 6.0, but I get
Code:
cannot locate symbol "__aeabi_memcpy"
, because of this I can't use this module at all as intended.
Mount folders are created, but are empty. I am able to manually send files to cloud strorage, but they don't show up locally. Also, I can see the mounted folders in bot ES file explorer and Termux.
Edit: Tried it on my other phone running CarbonRom 6.1 (android 8.1.0), and I face the same issue described before me. Termux can list files when cloud storage is mounted, but file explorers show empty folders.
Edit2: Google drive seems to be working on 8.1.0 with Solid Explorer File Manager, mega folder still shows up empty :/
Has anyone got afwall? What to unblock? I'd hate to unblock multicomponent system apps.
Maybe a custom iptables script?
For people who are getting empty folders outside termux, is most likely because mount namespace seperation is enabled in their supersu or magisk. I don't use magisk so don't know the exact option but for supersu, just uncheck "Mount namespace seperation" in its settings and reboot and try after that.
I have successfully done a 64-bit on-device build inside termux for fusermount with the relevant patches. Its working fine for now and most likely will work better for people. I plan to release the binaries, the source code and tasker projects related to it hopefully in the next few days, but if someone needs the binaries earlier, let me know.
@pmj_pedro Would it be possible for you to do a static compile? It might help with the missing symbols.
Code:
cannot locate symbol "__aeabi_memcpy"
@agnostic-apollo I am interested especially if the binary(s) have no depends & can work with Android M-P outside of Termux. Would it be possible to include arm as well?
Geofferey said:
@pmj_pedro Would it be possible for you to do a static compile? It might help with the missing symbols.
Code:
cannot locate symbol "__aeabi_memcpy"
@agnostic-apollo I am interested especially if the binary(s) have no depends & can work with Android M-P outside of Termux's. Would it be possible to include arm as well?
Click to expand...
Click to collapse
I initially was attempting a static compile within a ubuntu chroot in my phone but the static flags wouldn't work and it still linked to the "lib/arm-linux-gnueabihf/libc.so" and "/lib/ld-linux-armhf.so.3", which are glibc libs... i then decided to compile within termux itself since people would be using rclone with that anyways and dynamic linkage would hopefully not be a problem. For a 32bit compilation, i would have to look more into it cause that would require 32 libs/compiler dependencies. I tried in the morning but it failed as expected.
i have attached the termux patched source and 64bit fusermount. Instructions for termux compilation are inside the source zip... the source is the same as the OP... If someone could attempt compilation on a 32 bit phone, that would be quicker.
Edit: made some patches and improvements, use new binary.
Geofferey said:
@pmj_pedro Would it be possible for you to do a static compile? It might help with the missing symbols.
Code:
cannot locate symbol "__aeabi_memcpy"
@agnostic-apollo I am interested especially if the binary(s) have no depends & can work with Android M-P outside of Termux. Would it be possible to include arm as well?
Click to expand...
Click to collapse
btw why do u need it outside termux, just curious... if u have root, u could call termux binaries from outside anyways, depending on selinux of course...
@agnostic-apollo I'm a major contributor to the rclone mount for Android Magisk module which includes the fusermount binaries posted by the OP. Nobody has complained about the missing symbols in our module yet so I was hoping to nip the issue before any reports arrive.
In any event if your source / build uses Termux's libc etc I could just grab those libs and create a wrapper script with LD_LIBRARY_PATH specified. I will attempt to compile 32 bit on my S4 using your source when I get a chance.
Geofferey said:
@agnostic-apollo I'm a major contributor to the rclone mount for Android Magisk module which includes the fusermount binaries posted by the OP. Nobody has complained about the missing symbols in our module yet so I was hoping to nip the issue before any reports arrive.
In any event if your source / build uses Termux's libc etc I could just grab those libs and create a wrapper script with LD_LIBRARY_PATH specified. I will attempt to compile 32 bit on my S4 using your source when I get a chance.
Click to expand...
Click to collapse
Ah, check it out, looks pretty cool. yeah fixing bugs before bug reports arrive is always appreciated, but if there a no bugs reports that you are fixing with time, then it may look like you are not doing any work
yeah exporting LD_LIBRARY_PATH would work and other than during compilation for makeconf.sh, termux $PREFIX patches are not needed in the source code. The hardcoded binaries are never called if mtab is disabled or platform is not BSD. Also configure.ac does need the $PREFIX patch for setting paths which are read by util/Makefile.am for installing mount.fuse, udev and init.d scripts but those are only needed when "make install" is run and we don't need to run it just to get fusermount. So basically a static compile is possible which does not have hardcoded dependencies on termux binary path, provided that a static compile actually works. You could probabky copy the libs from termux too like you said. I'll have to first have to revert the prefix patches again though.
Few questions, do u sometimes get "transport end point not connected" error while unmounting?
and any reason why the world readable /sdcard/.rclone dir is used as default for storing non encrypted rclone config files? could be a security issue for some
In your rclone-mount script, CACHE and CACHE_BACKEND dirs are created but different ones passed to rclone mount command, is that wrong or am i missing something?
@agnostic-apollo
do u sometimes get "transport end point not connected" error while unmounting?
Click to expand...
Click to collapse
Sorry for the late response I've been very busy...
I think I used to get that but not anymore since compiling using ncw's instructs for Termux, That and I unmount by killing rclone first...
any reason why the world readable /sdcard/.rclone dir is used as default for storing non encrypted rclone config files? could be a security issue for some
Click to expand...
Click to collapse
There are several reasons... Please correct me if I am wrong on any of these points.
1. Simplicity. It's easier for users to place .conf in /sdcard/.rclone/rclone.conf as opposed to /data/adb/modules/com.piyushgarg.rclone/.config/rclone/rclone.conf etc.
2. Security. While it is true the folders/files in SDcard have world read/write perms there are plenty of other security mechanisms in place to help prevent access to files on SDcard.
A. App permission can stop apps without storage permissions from accessing the SDcard & even stops some with perms from reading contents.
B. SElinux stops processes that are not in proper context from accessing SDcard.
C. Encyrption helps protect contents on SD card from physical acquisition in the event of device theft or seizure.
3. /sdcard/ is a great place to determine if device has successfully decrypted before attempting to mount remotes which can be a dangerous operation, especially if binding to internal storage is enabled.
4. Rooting completely compromises security & most users do not take any steps to properly re-secure their devices afterwards. Leaving things like persistent adb enabled, TWRP, selinux disabled, encyrption etc.
5. I actually plan on keeping the .conf entirely out of module directory in future.
If users keep security features such as selinux / encryption enabled, adb disabled & work with them instead of disabling it's a pretty safe place. Otherwise security should already be considered compromised and then it doesn't really matter where you place it at that point. If the goal is keeping a forensic analyst from obtaining data you probably shouldn't root at all. They LOVE rooted phones.
Sorry I might've started rambling. You got me started on security :cyclops:
In your rclone-mount script, CACHE and CACHE_BACKEND dirs are created but different ones passed to rclone mount command, is that wrong or am i missing something?
Click to expand...
Click to collapse
I'm not sure. Maybe it is. Caching has been one of my biggest problems due to lack of understanding. I think I may have corrected this upcoming version tho.
BTW caching is something you should probably use very sparingly. It's extremely hard on internal storage and it will eat up unecessary amounts of data.
Now my question for you... Would you be willing to help contribute the necessary static fusermount bins to our project? It's one of the last things I need to make it damn near universally compatible. At the least I would need an arm build, but prefer arm, arm64. I'm not much on building anything C from source unless it's ready to go and I don't have to touch anything. I only do those things in times of great despair . To be honest I only understood half the readme & I'm scared of it lol. If you're down for the cause let me know and we can get you onboard as contributor. Do you have GitHub?
EDIT: I decided to quit being lazy and tried a static compile with your source. Using "./configure --enable-static=yes". I first tried using your binary that you uploaded and it complained about libs. Tried the one I compiled with flag and it seems to have just worked. No modification to your src. Doesn't mean it fixes the problem tho. :/
EDIT 2:
Turns out it isn't possible to compile static using Termux? The binary must've built against local libc because I didn't need libandroid-support.so until I tried it on a different device. Anyways I'm still gonna use your bins in update with LD_LIBRARY_PATH and libandroid-support.so FROM Termux. I will definitely credit you as well & I probably still need your help.
Geofferey said:
@agnostic-apollo I'm a major contributor to the rclone mount for Android Magisk module which includes the fusermount binaries posted by the OP. Nobody has complained about the missing symbols in our module yet so I was hoping to nip the issue before any reports arrive.
In any event if your source / build uses Termux's libc etc I could just grab those libs and create a wrapper script with LD_LIBRARY_PATH specified. I will attempt to compile 32 bit on my S4 using your source when I get a chance.
Click to expand...
Click to collapse
Geofferey said:
@agnostic-apollo
Sorry for the late response I've been very busy...
I think I used to get that but not anymore since compiling using ncw's instructs for Termux, That and I unmount by killing rclone first...
There are several reasons... Please correct me if I am wrong on any of these points.
1. Simplicity. It's easier for users to place .conf in /sdcard/.rclone/rclone.conf as opposed to /data/adb/modules/com.piyushgarg.rclone/.config/rclone/rclone.conf etc.
2. Security. While it is true the folders/files in SDcard have world read/write perms there are plenty of other security mechanisms in place to help prevent access to files on SDcard.
A. App permission can stop apps without storage permissions from accessing the SDcard & even stops some with perms from reading contents.
B. SElinux stops processes that are not in proper context from accessing SDcard.
C. Encyrption helps protect contents on SD card from physical acquisition in the event of device theft or seizure.
3. /sdcard/ is a great place to determine if device has successfully decrypted before attempting to mount remotes which can be a dangerous operation, especially if binding to internal storage is enabled.
4. Rooting completely compromises security & most users do not take any steps to properly re-secure their devices afterwards. Leaving things like persistent adb enabled, TWRP, selinux disabled, encyrption etc.
5. I actually plan on keeping the .conf entirely out of module directory in future.
If users keep security features such as selinux / encryption enabled, adb disabled & work with them instead of disabling it's a pretty safe place. Otherwise security should already be considered compromised and then it doesn't really matter where you place it at that point. If the goal is keeping a forensic analyst from obtaining data you probably shouldn't root at all. They LOVE rooted phones.
Sorry I might've started rambling. You got me started on security :cyclops:
I'm not sure. Maybe it is. Caching has been one of my biggest problems due to lack of understanding. I think I may have corrected this upcoming version tho.
BTW caching is something you should probably use very sparingly. It's extremely hard on internal storage and it will eat up unecessary amounts of data.
Now my question for you... Would you be willing to help contribute the necessary static fusermount bins to our project? It's one of the last things I need to make it damn near universally compatible. At the least I would need an arm build, but prefer arm, arm64. I'm not much on building anything C from source unless it's ready to go and I don't have to touch anything. I only do those things in times of great despair . To be honest I only understood half the readme & I'm scared of it lol. If you're down for the cause let me know and we can get you onboard as contributor. Do you have GitHub?
EDIT: I decided to quit being lazy and tried a static compile with your source. Using "./configure --enable-static=yes". I first tried using your binary that you uploaded and it complained about libs. Tried the one I compiled with flag and it seems to have just worked. No modification to your src. Doesn't mean it fixes the problem tho. :/
EDIT 2:
Turns out it isn't possible to compile static using Termux? The binary must've built against local libc because I didn't need libandroid-support.so until I tried it on a different device. Anyways I'm still gonna use your bins in update with LD_LIBRARY_PATH and libandroid-support.so FROM Termux. I will definitely credit you as well & I probably still need your help.
Click to expand...
Click to collapse
I'll leave a detailed reply later, its 9 in the morning, i have to sleep now
fyi you can use "ldd util/fusermount" to find the libraries its linking against... and can run "export LD_LIBRARY_PATH=/system/lib64:/system/lib" before running a binary in termux...if it fails with library errors, it requires termux libraries... restart termux or restore LD_LIBRARY_PATH afterwards or other termux stuff wont work...
anyways i did an on-device build of fusermount binary that does not depend on termux/libandroid-support... reverted most of the previous patches and added a few more with new build instructions.... the fusermount binary still depends on /system/lib* libc.so and libdl.so but those are provided by every phone and would run fine on most phones, its basically like the OP one but symbol errors could be there in some devices... truly static might be possible but on device build might not be possible and will probably require cross-compile if even possible... will look into it later
check out the new binary on both devices and let me know...
I am using rclone mount magisk module
It cannot reach the host (its written in the log) when I have "apps running as root" blocked in Afwall
I really hate to allow all root apps to access inet. I would like to allow only rclone access only single local ip
What custom script would help?
It is ordinary iptables script
noob here. but i can follow. how to mount my google drive to my phone alongside to my sdcard i just want to use this as a failsafe to my files, so far i followed the step from rclone using google drive. since some apps has auto backup on phone only and thinking this is the best way to sync my phone and app settings without manually checking and uploading those files. but the problem is im stuck on this error. (screenshot) hope someone can help me. ty
im using magisk rclone module
@Geofferey
Well i managed to cross compile for all archs using NDK targeting API 21. Cannot target an API older than that due to missing function implementation in Android bionic older than that. But binaries will need to be tested on different archs and android versions/devices. You can download the binaries from my github release here. You or others can compile them yourself if they want, instructions are here.
Moreover I still couldn't manage to do a static compile. I doubt it is gonna be possible, atleast easily since Android bionic is probably not meant for that. mucl is the best hope i think, since it fully supports static linking.
However the binaries compiled by me have less library dependencies than the ones OP posted so it could be better for some, even though in OP's case, the binaries are linking to android system libraries so shouldn't be a problem in most cases. FYI I found that "ldd" command is not reliable for finding dynamic linking. Use "readelf -d "fusermount" | grep NEEDED"
The OP binary dynamic linking:
Code:
ARCH=arm64-v8a
0x0000000000000001 (NEEDED) Shared library: [libc.so]
0x0000000000000001 (NEEDED) Shared library: [libm.so]
0x0000000000000001 (NEEDED) Shared library: [libstdc++.so]
0x0000000000000001 (NEEDED) Shared library: [libdl.so]
ARCH=armeabi-v7a
0x00000001 (NEEDED) Shared library: [libc.so]
0x00000001 (NEEDED) Shared library: [libm.so]
0x00000001 (NEEDED) Shared library: [libstdc++.so]
0x00000001 (NEEDED) Shared library: [libdl.so]
The binary dynamic linking compiled by me:
Code:
Build Info:
NDK_FULL_VERSION=20.0.5594570
C_COMPILER=clang
HOST_TAG=linux-x86_64
BUILD_TIMESTAMP=2019-07-31 08.20.46
ARCH_SRC=arm64-v8a
API_LEVEL=21
FUSERMOUNT=fusermount-arm64-v8a
Binary Info:
fusermount: setuid ELF 64-bit LSB shared object, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /system/bin/linker64, not stripped
Shared Libraries:
0x0000000000000001 (NEEDED) Shared library: [libc.so]
ARCH_SRC=armeabi
API_LEVEL=21
FUSERMOUNT=fusermount-armeabi
Binary Info:
fusermount: setuid ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /system/bin/linker, not stripped
Shared Libraries:
0x00000001 (NEEDED) Shared library: [libdl.so]
0x00000001 (NEEDED) Shared library: [libc.so]
ARCH_SRC=armeabi-v7a
API_LEVEL=21
FUSERMOUNT=fusermount-armeabi-v7a
Binary Info:
fusermount: setuid ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /system/bin/linker, not stripped
Shared Libraries:
0x00000001 (NEEDED) Shared library: [libdl.so]
0x00000001 (NEEDED) Shared library: [libc.so]
ARCH_SRC=x86
API_LEVEL=21
FUSERMOUNT=fusermount-x86
Binary Info:
fusermount: setuid ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /system/bin/linker, not stripped
Shared Libraries:
0x00000001 (NEEDED) Shared library: [libc.so]
ARCH_SRC=x86-64
API_LEVEL=21
FUSERMOUNT=fusermount-x86-64
Binary Info:
fusermount: setuid ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /system/bin/linker64, not stripped
Shared Libraries:
0x0000000000000001 (NEEDED) Shared library: [libc.so]
Alas, the things that need to be done just get binaries to run on our phones properly. If it were only me that had to use fusermount, it wouldn't be a problem at all, i would have just run one my scripts to merge my chroot ubuntu distro's rootfs with my android's rootfs and just run the ubuntu's fusermount and it would have worked fine for me. The ubuntu's libraries would have been dynamically linked to the binary since the ubuntu libraries would be linked to /lib and I wouldn't have to do any compilation at all. Now if it were only this simple for everybody...
Btw i read your previous comments, will try replying to them once i wake up, been too busy with this stuff.
Geofferey said:
I think I used to get that but not anymore since compiling using ncw's instructs for Termux, That and I unmount by killing rclone first...
Click to expand...
Click to collapse
Interesting, I use rclone supplied by termux apt repository. I get the errors if the mount point is busy like root explorer has opened up a directory inside the mount point and I stop the rclone mount command. The rclone mount command exits with resource is busy errors as expected and if i try to unmount the mount point manually i get "transport endpoint" errors, i have run a lazy unmount to get the mount point to unmount.
Geofferey said:
There are several reasons... Please correct me if I am wrong on any of these points.
1. Simplicity. It's easier for users to place .conf in /sdcard/.rclone/rclone.conf as opposed to /data/adb/modules/com.piyushgarg.rclone/.config/rclone/rclone.conf etc.
2. Security. While it is true the folders/files in SDcard have world read/write perms there are plenty of other security mechanisms in place to help prevent access to files on SDcard.
A. App permission can stop apps without storage permissions from accessing the SDcard & even stops some with perms from reading contents.
B. SElinux stops processes that are not in proper context from accessing SDcard.
C. Encyrption helps protect contents on SD card from physical acquisition in the event of device theft or seizure.
3. /sdcard/ is a great place to determine if device has successfully decrypted before attempting to mount remotes which can be a dangerous operation, especially if binding to internal storage is enabled.
4. Rooting completely compromises security & most users do not take any steps to properly re-secure their devices afterwards. Leaving things like persistent adb enabled, TWRP, selinux disabled, encyrption etc.
5. I actually plan on keeping the .conf entirely out of module directory in future.
If users keep security features such as selinux / encryption enabled, adb disabled & work with them instead of disabling it's a pretty safe place. Otherwise security should already be considered compromised and then it doesn't really matter where you place it at that point. If the goal is keeping a forensic analyst from obtaining data you probably shouldn't root at all. They LOVE rooted phones.
Sorry I might've started rambling. You got me started on security :cyclops:
Click to expand...
Click to collapse
lolz no apologies needed, I ramble a lot too, not that anybody listens or understands
1. People in most cases are going to put the rclone file once, so going to the magisk module directory should not be a problem.
2. Most apps are granted storage permissions by users in recent android versions, and they are granted without explicit grants in old versions.... /sdcard is basically fuse/sdcardfs mounted to /storage/emulated/0, so all apps having storage permissions would have access to /storage/emulated/0/.rclone and any other directory except the /storage/emulated/0/Android of course... These popular apps are the main security risk tbh, who most likely monitor everything on the sdcard... and selinux wouldn't do anything for sdcard if storage permissions are granted.
And if a person has physical access the then it probably doesn't matter where its stored, but storing it in a root accessible would most likely still be better...
3. You could use the mount command or /proc/mounts to see active mounts to detect what has been mounted till now...
4. Yeah if your threat is a physical access than just keep your bootloader locked and encryption enabled and live a miserable life without all the benefits of rooting. I don't want to live that life, at all... I would be more worried about apps than physical access. And mostly encryption is not supported by twrp so if your device is lost, consider all the data gone if u r using a decrypted device flr using update/backup. Leaving adb enabled normally shouldn't be a problem unless you lose your authorized PC as well, then u probably have much bigger things to worry about
5. I am not familiar with magisk module access but /data/.rclone should be fine to use instead... Only root apps would have access. I'm not sure what selinux contexts magisk module directory has, it might be safer against root apps who have not been granted root access through magisk.
Geofferey said:
I'm not sure. Maybe it is. Caching has been one of my biggest problems due to lack of understanding. I think I may have corrected this upcoming version tho.
BTW caching is something you should probably use very sparingly. It's extremely hard on internal storage and it will eat up unecessary amounts of data.
Click to expand...
Click to collapse
yeah caching could be hard for the device and will need to be looked over more. Wakelocks would be an issue too. I tried using minimal mode but i need to do more testing. I was getting some lags, might be related. Mobile data issues could be there too, my tasker based projects can most likely handle those by remounting. rclone remote control commands can only drop caches currently, not change their modes. Will need to ask the dev to add it if needed.
Geofferey said:
Now my question for you... Would you be willing to help contribute the necessary static fusermount bins to our project? It's one of the last things I need to make it damn near universally compatible. At the least I would need an arm build, but prefer arm, arm64. I'm not much on building anything C from source unless it's ready to go and I don't have to touch anything. I only do those things in times of great despair . To be honest I only understood half the readme & I'm scared of it lol. If you're down for the cause let me know and we can get you onboard as contributor. Do you have GitHub?
Click to expand...
Click to collapse
yeah I'm up for contributing to the project but only after I have completed and released my projects, gonna take a few days atleast. And yeah i have got github as u already know by now...
lolz C is not for everybody, but thats how I started programming with so I can understand it at most times, understanding the purpose of the code is another issue