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.
Is there any way someone could explain what is the meaning of 'signed' update (for android) means?!
I know the meaning of a cryptographic signature, and I tend to confuse understanding whether this sort of images are digitally signed (by whom?) or just checked against a hash within the image, which means to protect the update against some sort of corruption along its transit (and not against unofficial distributions).
Appreciate your feedback.
There are different keys used to sign an update. Test keys are what rom updates are signed with because it's the most generic and doesn't require a developer account. When you sign-up with google to put a application on the market, they give you a developer key to sign your application with. Every developer key is unique and allows for authentic updates and not just someone with an application with the same name. You will get a key mismatch error or certificate error when you try to replace an application with one that is not signed with the same key as the one you have installed currently.
To my knowledge it does not provide any md5 verification features, unless the update has a corrupt signature.
Thanks for the educated answer!!!
If possible - I’d like to understand this a little bit more:
Can any developer sign ROMs (not just applications)?
How can I tell between images that signed with test keys and ones that are signed with individual keys? (Where is this information embedded?)
How do I associate between a ROM distribution and an individual?
Where is the root of trust that is made to validate these certificate (chains) ?
thanks
Anyone can sign roms. The custom recovery allows one to flash roms with test keys. The way to sign an apk/zip is just a java program, OS independant. Perhaps looking at the jar will give you a little more understanding of how it works against the zip/apk.
You can tell a factory rom from a custom rom from the build.prop file. The chances are slim that the factory rom would use a test key.
ie. "ro.build.fingerprint=google/passion/passion/mahimahi:2.2/FRF50/38042:user/release-keys" is in the FRF50 update.
The signature is stored in the META-INF directory in the zip file.
http://java.sun.com/j2se/1.4.2/docs/guide/jar/jar.html
evilkorn said:
Anyone can sign roms. The custom recovery allows one to flash roms with test keys. The way to sign an apk/zip is just a java program, OS independant. Perhaps looking at the jar will give you a little more understanding of how it works against the zip/apk.
You can tell a factory rom from a custom rom from the build.prop file. The chances are slim that the factory rom would use a test key.
ie. "ro.build.fingerprint=google/passion/passion/mahimahi:2.2/FRF50/38042:user/release-keys" is in the FRF50 update.
The signature is stored in the META-INF directory in the zip file.
http://java.sun.com/j2se/1.4.2/docs/guide/jar/jar.html
Click to expand...
Click to collapse
Do you know know many verification checks are needed for an update or ROM to be able to flash? Does the recovery just check the cert in the manifest/cert files? I think the image files are hashed, but are they also signed?
Also does the actual hardware have any keys installed or is all through software/firmware?
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.
https://github.com/JackpotClavin/Android-Blob-Utility
The purpose of this program is to help AOSP-based ROM developers quickly and easily find out which proprietary blobs need to be copied into the ROM's build, or built using source. How the program works is you do a /system dump into a folder on a Linux computer. Then you make the program using the 'make' command; then you can run it.
First off, the program will ask you what the sdk version of the /system dump you pulled happens to be. For example, if your /system dump is Android 4.3, and intend port a 4.3-based ROM, then enter 18 and press enter.
When it prompts you for location of the /system dump you pulled, if the location of the build.prop of the /system dump is under:
Code:
/home/user/backup/dump/system/build.prop
then just use:
Code:
/home/user/backup/dump/system
The program will now ask you for your device's manufacturer's name, and the device's name. For my Verizon LG G2, I entered "lge" and "vs980" respectively.
The utility then will ask you how many files you wish to run through the program. In the case of my LG G2, the KitKat build requires two main proprietary camera-related libraries to run (/system/bin/mm-qcamera-daemon and
/system/lib/hw/camera.msm8974.so).
So I typed in 2 and pressed enter (because I'm running two proprietary files through the program)
Then simply typed in:
Code:
/home/user/backup/dump/system/bin/mm-qcamera-daemon
and pressed enter and it printed out *every* file needed to get /system/bin/mm-qcamera-daemon running (the file might be proprietary, or it can be built from source).
Then it asked for the final proprietary file, so I simply typed in:
Code:
/home/user/backup/dump/system/lib/hw/camera.msm8974.so
and pressed enter and it printed out *every* file needed to get /system/lib/hw/camera.msm8974.so running (the file might be proprietary, or it can be built from source).
An example usage of this program can be found here: https://raw.githubusercontent.com/JackpotClavin/Android-Blob-Utility/master/Example_Usage.txt
That's 106 proprietary blobs done in a flash!
The beauty of this program is that it's recursive, so if proprietary file 'A' needs proprietary file 'B' to run, but proprietary file 'B' needs proprietary file 'C' to run, which in turn needs 'D' to run, then simply entering proprietary file A to run will print out all A, B, C, and D nicely formatted so that you can simply copy the output and place it in a file under vendor/manufacturer/codename/codename-vendor-blobs.mk file in your AOSP build source tree's root.
Another great thing about this program is that it doesn't just catch the libraries needed to satisfy the linker, but rather, it will also print out those libraries that are called within the actual code of the library itself, like:
Code:
dlopen("libfoo.so", RTLD_NOW);
libfoo.so is not marked as a shared library, so the linker won't complain that libfoo.so is missing, and there might be no sign that libfoo.so missing and needed, but when it's time for the daemon or library to run, it won't show any sign that something is wrong, until you see that it doesn't work. This program will catch and display that libfoo.so is needed.
So basically:
1. Extract /system dump image
2. Tell program the SDK version of your /system dump
3. Tell program the location of your /system dump
4. Tell the program your device's manufacturer's name
5. Tell the program your device's codename
6. Tell program how many files you wish to run through the utility
7. Tell program the location of the file(s) you wish to run through the program.
8. Copy the output of the utility to a text file under vendor/manufacturer/codename/codename-vendor-blobs.mk
reserve
Hi,
I'm a noob and don't worry about my silly question.
I'm trying to build my first cm-rom and tested your tool. Thanks a lot for your work, it worked for me.
I'm a little bit curios about your point 5. Where can I find all the files I need for my own source-tree/device?
It would be nice if you can give me a hint.
Thanks a lot and greetings from germany
Greetings from the US
Do you mean the device folder the ROM? You can look at similar devices to your device and see what they did and make the changes to build Android.
This is the device folder for the Nexus 5 -> https://android.googlesource.com/device/lge/hammerhead
This tool is under-recognized. I think it's a really great way to find which blobs are dependencies!
Codename13 said:
This tool is under-recognized. I think it's a really great way to find which blobs are dependencies!
Click to expand...
Click to collapse
Thanks! Are you developing a ROM? Let me know if it helps!
Sent from my LG-VS980 using XDA Free mobile app
Could this be updated to Lolipop?
2GigayteSD said:
Could this be updated to Lolipop?
Click to expand...
Click to collapse
What do you mean? I added support for SDK version 20 if that's what you're asking.
Sent from my LG-VS980 using XDA Free mobile app
Does that mean I can port AOSP to any device just by getting all the necessary blobs? I'm not sure but I'm trying to port Lollipop to my device but I don't really have a clue how to do it/what's needed to do it. Will this be useful for me? Thanks.
cikoleko said:
Does that mean I can port AOSP to any device just by getting all the necessary blobs? I'm not sure but I'm trying to port Lollipop to my device but I don't really have a clue how to do it/what's needed to do it. Will this be useful for me? Thanks.
Click to expand...
Click to collapse
It helps with making ROMs for devices that don't have support (either the model is brand new or the device never gained AOSP ROM support for whatever reason)
Basically, in the early stages of porting ROMs, certain things won't work (graphics, camera, radio) and this is mostly due to not having the correct proprietary files needed for the OS to interact with the hardware. The proprietary files have dependencies (they rely on other libraries, which in turn may rely on other libraries, and so on and so forth until all proprietary libraries are satisfied).
In the case of my LG G2, there were a total of 92 proprietary files that needed to be pushed to the device in order to get just camera working. Instead of pushing one library at a time and getting a logcat or strace dump of what the daemons are calling or depend on, I wrote this program to recursively search for all proprietary libraries needed to satisfy a proprietary library (or in the case of the camera for my G2, there were two proprietary libraries needed that required those said 90 other proprietary blobs).
So rather than pushing libraries, (then gathering logs and stracing) and hoping that the one you just pushed is the one that will get your camera, radio, etc to work, you run your known proprietary daemons or libraries through this program and it will print out the necessary libraries to get it working, in a fraction of a second
Can you go through the actual "porting" process because from what I understand you have done it? If I'm correct to port a ROM you need to have working ROM from other device? If yes, does that device have to be same manufacturer? Lets say I do have working AOSPA kitkat for my device so I need to get AOSPA lollipop and exchange the certain files and then I'll able to run it? Once again if it's like that then I use your tool and get necessary blobs? I don't have a clue about this stuff, I only build ROMs but now time has come that my device is unsupported so can you give me some tips, thanks.
This is interesting. Going to have to try this out tomorrow.
cikoleko said:
Can you go through the actual "porting" process because from what I understand you have done it? If I'm correct to port a ROM you need to have working ROM from other device? If yes, does that device have to be same manufacturer? Lets say I do have working AOSPA kitkat for my device so I need to get AOSPA lollipop and exchange the certain files and then I'll able to run it? Once again if it's like that then I use your tool and get necessary blobs? I don't have a clue about this stuff, I only build ROMs but now time has come that my device is unsupported so can you give me some tips, thanks.
Click to expand...
Click to collapse
If you don't have a clue then dont do it, please! Work your way up. First step in this hypothetical is to wait for aospa 5.0
Thanks a lot for this tool
just one thing.. i cant get the blobs for my wireless (wl12xx)
Rest all done
andynoob said:
Thanks a lot for this tool
just one thing.. i cant get the blobs for my wireless (wl12xx)
Rest all done
Click to expand...
Click to collapse
Is it possible that each wl12xx library only relies on AOSP libraries (has no dependencies?)
See if they can be built from source!
Sent from my LG-VS980 using XDA Free mobile app
JackpotClavin said:
Is it possible that each wl12xx library only relies on AOSP libraries (has no dependencies?)
See if they can be built from source!
Sent from my LG-VS980 using XDA Free mobile app
Click to expand...
Click to collapse
Manufacturer hasnt provided the source code(Kernel) . Anyways thanks a lot for this tool :good: :good:
how to use it?
by reading the detailed instructions?
Sent from my LG-VS980 using XDA Free mobile app
JackpotClavin said:
by reading the detailed instructions?
Sent from my LG-VS980 using XDA Free mobile app
Click to expand...
Click to collapse
should we adb pull /system first?
*edit
I did it! but where is the directory out?
J,
You are a life saver ! Subscribed. Will add link of thread to my signature. Will dance happily for some hours! :good:
Will seek therapy. :silly:
m
I've got an XQ-AS72 and have been trying to build an AOSP rom based on instructions from Sony Developer.
The first go-round, I couldn't find the proper "vendor image" a.k.a. software binaries a.k.a. "oem partition" from the site, and I ended up flashing oem (a/b) with the UNSINned version of oem_X-FLASH-CUST-2389.sin that came with the 58.1.A.3.87 firmware that I downloaded with XperiFirm, along with the output of the build. No boot.
I then tried flashing a few different things to the oem partition (among them a couple of official images from other phones from this page (CAUTION! DO NOT USE!!)), which didn't work because of, I guess among other things, a kernel version mismatch (binaries built for 4.14, I built against 4.19). Stupid, stupid me
I ended up having to put the phone in FLASH MODE and using Xperia Companion to do a system restore after multiple failed attempts at re-flashing partitions in fastboot, which gave me 58.1.A.5.55. I was able to get the thing booted. Using NewFalsher with the last known good firmware I had downloaded didn't help me in this case.
I have now re-unlocked the bootloader, cleaned my local repo structure, found the proper binaries from the proper page and am awaiting the long slog of the build process.
So, my question is: has anyone successfully built AOSP for this device before? Is there a lot of fenaggling that needs to be done? Or can the build be run against the files as they come down from the repos?
One thing that worries me, going through the manifest XMLs, is that the build target doesn't distinguish between the different variants, only giving one target (the AS52 variant with a smaller onboard mmc). Is there a need to manually create a new device .mk file and modify other .mk or .xml files to get a proper build?
TL;DR have you successfully built AOSP for the Xperia EDO platform, and do you have any tips to share?