Frida(-gadget) on phone only: is it possible? - Upgrading, Modifying and Unlocking

Is it possible to inject an Apk with Frida-Gadget (no root, just an apk modified with objection for example), and then use it standalone on the phone, with no computer attached (no Frida cli on computer, I guess it would mean running it as a side app or shell withing the phone? Is there any automated way to achieve this? Or any project working on this kind of approach?
TaiChi kinda seem to allow this (being compatible with Xposed Modules, not Frida, but it achieves the se more or less of what I'm looking into), but TaiChi is closed source AFAIK, so I'd prefer Frida which is open-source.

Related

[IDEA] One-click .apk app for rooting Nokia X (and X+/XL)

I've finally managed to root my Nokia X, which is a prerequisite for installing the Xposed Framework and some modules for it (which is something I've been wanting to do for a while). After trying out various tools, starting with the more open-source ones (like Kernelchopper), I ended up using Framaroot. Why? Because Framaroot doesn't require a computer and is extremely simple to use (and it works ); personally I don't mind if a rooting method requires the usage of a PC, but ideally all you'd need to do would be to download and execute an .apk.
Now, Framaroot is hardly the ideal solution, because it's not (free and) open source and not even source-available (reference). What's more, the superuser app that Framaroot installs -- SuperSU -- is not free and open source software either. There are open-source alternatives, such as Koush's Superuser.
I'm sure some of you are thinking, "but Framaroot's/SuperSU's developer is a great and trustworthy person!"; while I don't have a good reason to doubt that, I still have a reason to be wary of what code I execute on my mobile device; it's not like you go clicking around every single .exe on a Windows computer either. When the source code is free and open, people are able to see what it does, compile it and submit improvements to it.
I therefore propose that we create an easy-to-use, one-click rooting app for devices like the Nokia X family (Qualcomm chipset, Android 4.1.2 or otherwise vulnerable to CVE-2013-2595). How? From what I've gathered, the "Framaroot Gandalf exploit" source is on GitHub (also see this Tweet by Pau Oliva), so it shouldn't be too hard for an expert Android developer -- which I'm sure we have plenty of in this forum -- write a graphical front-end for it and have it drop Koush's Superuser onto the device after a successful exploit (instead of SuperSU or $your_favorite_proprietary_superuser_app).
Thoughts?
towelroot is opensourced
https://github.com/f0go/Towelroot-by-Geohot
Jack Phoenix said:
I've finally managed to root my Nokia X, which is a prerequisite for installing the Xposed Framework and some modules for it (which is something I've been wanting to do for a while). After trying out various tools, starting with the more open-source ones (like Kernelchopper), I ended up using Framaroot. Why? Because Framaroot doesn't require a computer and is extremely simple to use (and it works ); personally I don't mind if a rooting method requires the usage of a PC, but ideally all you'd need to do would be to download and execute an .apk.
Now, Framaroot is hardly the ideal solution, because it's not (free and) open source and not even source-available (reference). What's more, the superuser app that Framaroot installs -- SuperSU -- is not free and open source software either. There are open-source alternatives, such as Koush's Superuser.
I'm sure some of you are thinking, "but Framaroot's/SuperSU's developer is a great and trustworthy person!"; while I don't have a good reason to doubt that, I still have a reason to be wary of what code I execute on my mobile device; it's not like you go clicking around every single .exe on a Windows computer either. When the source code is free and open, people are able to see what it does, compile it and submit improvements to it.
I therefore propose that we create an easy-to-use, one-click rooting app for devices like the Nokia X family (Qualcomm chipset, Android 4.1.2 or otherwise vulnerable to CVE-2013-2595). How? From what I've gathered, the "Framaroot Gandalf exploit" source is on GitHub (also see this Tweet by Pau Oliva), so it shouldn't be too hard for an expert Android developer -- which I'm sure we have plenty of in this forum -- write a graphical front-end for it and have it drop Koush's Superuser onto the device after a successful exploit (instead of SuperSU or $your_favorite_proprietary_superuser_app).
Thoughts?
Click to expand...
Click to collapse
TBH, it is a good idea. But there is already a Rooting procedure so creating an app would be useless. No?
mdfzhi said:
towelroot is opensourced
[GitHub link I had to remove because xda is stupid and thinks everything posted by "new" users is spam, no matter what]
Click to expand...
Click to collapse
Thank you for the suggestion, but unfortunately there are multiple issues here:
It doesn't work. I tested out a variety of different rooting methods, of which one was Towelroot. The concept is great, but it just wouldn't work on my Nokia X, running the original firmware. lifehacker.com/towelroot-roots-android-kitkat-devices-in-one-tap-no-p-1592226618 notes that "[Towelroot] works on phones running Android KitKat", and the Nokia X isn't running KitKat.
Towelroot is actually not FOSS. Someone took the original tr.apk file from towelroot.com, ran it through apktool (code.google.com/p/android-apktool/) and posted the result on GitHub. It was not released there by its author, which makes it effectively a blatant copyright violation, tool. Furthermore the resulting thing won't compile either. Several sources (such as tinyhack.com/2014/07/07/exploiting-the-futex-bug-and-uncovering-towelroot/ and clevcode.org/cve-2014-3153-exploit/) note that "TowelRoot is closed source and heavily obfuscated" and that there are (or rather, weren't) any public exploits of CVE-2014-3153 (Joel Eriksson rectified that, though).
Of course it'd be great to see tools like Framaroot and Towelroot go open source, but I don't see that happening anytime soon. Why the developers cling to the source so hard when they're distributing their work entirely for free is beyond me; I'm no big fan of freeware personally.
All that being said, I'm not proposing we reinvent the wheel, but rather invent the wheel and release the invention under a suitable license for everyone to study, amaze and contribute to. That's something you can't do with tools like Framaroot and Towelroot.
(Sorry about the lack of clickable links, btw; I blame that on XDA. Sorta ironical that the initial post can contain links, but subsequent replies cannot. Makes total sense...not.)
Dom3616 said:
TBH, it is a good idea. But there is already a Rooting procedure so creating an app would be useless. No?
Click to expand...
Click to collapse
If by "procedure" you refer to the fact that you can flash a recovery firmware or whatnot, then no, I don't think creating an app would be useless at all. Flashing requires a computer (unless I'm horribly mistaken here) and it can seem intimidating for, well, someone who hasn't done it before (like me!). I'm still somewhat of a smartphone newbie, and definitely an Android newbie, although I have plenty of programming experience and IT experience in general.
Framaroot was really simple to use and you really can't go wrong with it, but as I wrote in the original post, the sad truth is that it's still proprietary and that's at least a major ideological concern for some (like me), but also a practical concern. When the source code is available, you can look at it and see what it does, or if you lack the skills, you can ask an experienced (Android) dev to check it for you. When the app is closed-source, all you have is the dev's word on it, and occasionally that of the app's users. It's something, but it's not ideal -- for anyone, I believe.
Google Play Store and other app stores are full of Flappy Bird clones and whatnot, and despite Play Store not accepting apps meant to root the device, I firmly believe that this utility should be built, for it serves a practical purpose and essentially hasn't been done before: there are rooting utilities that are easy-to-use, there are FOSS implementations (well, at least the one I linked in my original post) of the CVE-2013-2595 exploit, but there isn't a FOSS version of the CVE-2013-2595 exploit that would have a GUI and be easy to use.
It's all about choices, and I wish there are options available to the users, and not just "which proprietary rooting app you want to use?".
well if u really must use opensource tool to root the nokia x family, that too can already happen.
first just flash custom recovery, eg cwm or twrp. both are foss. both can be flash using fastboot, not closed source tool needed.
then just boot into the custom recovery and flash either chainsdd superuser flashable zip or koush superuser flashable zip, both are foss too.
mdfzhi said:
well if u really must use opensource tool to root the nokia x family, that too can already happen.
first just flash custom recovery, eg cwm or twrp. both are foss. both can be flash using fastboot, not closed source tool needed.
then just boot into the custom recovery and flash either chainsdd superuser flashable zip or koush superuser flashable zip, both are foss too.
Click to expand...
Click to collapse
This is indeed true, but flashing can be intimidating for newbies and as mentioned in my original post (and also in the thread title), an .apk is so much better. My main motivation for gaining root access was so that I could install Xposed Framework and the resOverloader module for it, which enables to make the device support a language not supported by default, as the X's language selection is not like that of your average Android device's.
Should you sacrifice functionality if you want to be free and stay free? While the answer way too often is "yes", it obviously shouldn't be that way, given the obvious advantages of free and open source software. Admittedly this proposal's scope is somewhat narrow in that the initial target would be devices equipped with Qualcomm chipsets and running Android 4.1.2 (or older), and I probably should have posted this in a more generic Android app development section of the forum instead of the Nokia X subforum. However, it certainly wouldn't hurt anyone if this app would be built, as community members could then contribute to it and add support for other devices, SoCs and versions of Android...which, in the long run, would have the potential to become something like a free and open source clone of Framaroot.

[Q] Low-level camera access

Not sure if this question really fits in here but here it goes.
As Linux kernel is running under Android, how would one write applications that would run native (without Java overhead)? Additionally to the first question, I would like to access camera in that arrangement, like one would for example use v4l2 on PC or similarly?
Thanks,
Damjan
damjandakic said:
Not sure if this question really fits in here but here it goes.
As Linux kernel is running under Android, how would one write applications that would run native (without Java overhead)? Additionally to the first question, I would like to access camera in that arrangement, like one would for example use v4l2 on PC or similarly?
Click to expand...
Click to collapse
It really depends on the camera and the kernel the device is running.
If kernel > 2.6.26 (which it should be, as Android 1.5 was using 2.6.27 already) and your camera is supported by UVC, then it's easy (V4L being the best choice). Otherwise, you will need the source and/or binary SDK, which is usually quite difficult to get ahold of.

[CM13 question] Using ALSA instead of tinyalsa?

Hey guys
Right now I've succesfully built CM13 from sources for the Z00A but I need to change a few things for a project here at work. We need to use ALSA instead of tinyalsa because of some hard-coded things in that mentioned project, that doesn't work with tinyalsa but with ALSA.
Till now I used alsa-lib and alsa-utils from the Marshmallow branch of Android x86 project as external packages. They compiled without any big bug and here comes my problem: All of those little ALSA tools (aplay, amixer, arecord, etc) aren't build through the make-process and won't be integrated into the image as a result. When I compile them separately and copy them into /system/bin with corresponding access rights, they can't be used in the shell. It tell's me they cant be found - even with correctly installed libasound.so.
Any hint or tipp what I'm doing wrong?

VirtualXposed Analysis/Module Development Thread

This thread is intended as an All-in-one discussion of VirtualXposed (https://forum.xda-developers.com/xposed/virtualxposed-xposed-root-unlock-t3760313), how it works, its safety/security issues, what works on it, its limitations and how to develop modules on it.
What is VirtualXposed?
An OPEN-SOURCE Container-like environment for running apks on Android, which allows the use of (some) xposed features without the need for root/xposed/unlocked bootloader etc. If this can be made trustable and stable, it has the potential to bring Xposed mods to a much wider community.
How VirtualXposed works, based on a review of the source code and dev response -
All apps run inside VirtualApp (https://github.com/asLody/VirtualApp) - A containter-like library (like docker) that wraps around some android system calls to allows to run apks as plugins inside the original app. The project is also mostly open-source, but there seem to be some propreitary code blocks as well (such as https://github.com/asLody/VirtualApp/tree/master/VirtualApp/app/libs/armeabi-v7a). Its not free for commercial use though, that requires the purchase of a license. The dev maintains and independent fork of VirtualApp, without these closed-source blobs. The docs for VirtualApp can be found here - https://github.com/prife/VirtualAppDoc
Uses Epic (https://github.com/tiann/epic) to actually process xposed hooks - This is an open-source library, actually inspired from xposed itself, for developer to "hook" into their own Java methods in their own apps.
Uses a simple compatibility layer Exposed (https://github.com/android-hacker/exposed/ ) - Fully open source, Compatibility layer for Xposed, it loads Xposed modules and does some basic services (such as dealing with unsupported feature: initForZygote/resource hooks)
For the UI, uses this Launcher (https://github.com/android-hacker/Launcher3) - This is a fork of the popular (and open source) Rootless Pixel Launcher, modified for multi-user scenarios
Launcher3 and VirtualApp are project dependencies in VirtualXposed, exposed and epic are depended by aar.
Safety/Security Issues
The app requests a ton of permissions - Seems legit given that it has to emulate all of those APIs. Perhaps these can be changed to runtime permissions?
Possible proprietary blobs (Not sure yet - waiting for dev response) The app is fully open source.
Noone knows in detail how it works - Well, I am starting to get an idea of how it works
Virus Scan results - 1 virus detected by VirusTotal. See developer rant - https://github.com/android-hacker/VirtualXposed/issues/10#issuecomment-377295527, I think is a false positive
What works so far -
Hooking into a virtual app's own java functions (hooked using findAndHookMethod())
Hooking into SOME base Android APIs (I tried TextView.setText()) - I have published a working sample here - https://github.com/akhilkedia/VirtualXposedSamplePOC
Limitations of VirtualXposed so far that I know -
Module hooks sometimes work, sometimes dont. I tested AllTrans 5 times, and it only worked once was because of change in Application.onCreate() - see below.
Hooking Application.onCreate and casting it to Application returns and error see below
New modules are seemingly often not changed even after re-installing. Un-installed virtual apps are sometimes detected as still being present by the xposed module (?!)
Cannot hook apks outside of VirtualApp (including possibly SystemUI).
No Resource Hooks
No Google Play Service yet.
Epic library's readme says not supported for arm32, x86_64 and mips device architectures for ART.
Logging to logcat doesnt seem to work. Logging to logcat works. @#$*%$ Android studio log filters.
How to develop modules on it.-
Some utilities for developers (translated wiki page from VirtualXposed) - https://translate.googleusercontent...700201&usg=ALkJrhhSn_e_4E8NyifibMpfzUV70sy_fg I have not tried any of the steps mentioned here. These steps work.
Application.onCreate/attachBaseContext is transformed to ContextWrapper.attachBaseContext
Here is what I am currently doing, which seems to be a more stable way of getting consistent results - Erase application data of VirtualXposed, install xposed module, enable xposed module in xposed installer, force-stop VirtualXposed, start VirtualXposed. If you have enabled an Xposed Module outside of VirtualXposed, it will still affect apps inside it - So its recommended to turn the module off outside.
The original developer seems to not speak perfect English, and the current users are mostly all Chinese.
Note - I intend to keep updating this post as we get more/new information.
@ Forum Moderators - Please feel free to move this thread if this is not the correct forum for it.
Edits - updated with more information from dev.
*reserved*
Hi, akhilkedia94, Thank you for your hard work
I am the maintainer of VirtualXposed, sorry for my poor English. I will try to translate all the wiki and documents to English, If the translation is not good, please let me know
And there are some facts that need clarification:
1. https://github.com/asLody/VirtualApp...bs/armeabi-v7a this library is a map/location library provided by Tencent, But i have remove it in VirtualXposed, it only exist in VirtualApp.
2. hook of Application.onCreate/attachBaseContext is transformed to ContextWrapper.attachBaseContext.
3. VirtualXposed is more stable on Android 8.0 than before ( i didn't update the document in time, sorry
VirtualXposed is consist of four modules:
1. https://github.com/asLody/VirtualApp provides the ability of container(works like docker, not virtual machine); It is closed source from 2017/12/31. I maintain a standalone branch in VirtualXposed. VitualApp also have a inline hook module, which can hook native methods.
2. https://github.com/tiann/epic provides the ability of Hook Java Method.
3. https://github.com/android-hacker/exposed is the compatibility layer of Xposed, it loads Xposed modules and do some clutter things(such as dealing with unsupported feature: initForZygote/resource hooks)
4. https://github.com/android-hacker/Launcher3 is the UI, it is modified for multi-user in VirtualXposed.
Launcher3 and VirtualApp are project dependencies in VirtualXposed, exposed and epic are depended by aar.
Welcome to any questions, Although I may be hard to explain it clearly : )
weishu said:
Welcome to any questions, Although I may be hard to explain it clearly : )
Click to expand...
Click to collapse
Thank you so much for your response! This is truly a wonderful project!
At this point, is there any part of the source code of VirtualXposed (or any of its dependecies) that is proprietary/closed-source?
If you have some free time later, can you explain in some detail (such as with links to relevant folders/files in Github) how VirtualApp, Epic and VirtualXposed work?
If you are not comfortable with English, you can use https://translate.google.com/ or http://fanyi.baidu.com/ to translate Chinese to English. If you cannot access those websites, please feel free to post your response in Chinese and we will translate it for you.
https://github.com/asLody/VirtualApp/issues/388
As linked in the original thread..
Besides here (before re-editing everything), the dude said something along the line of project's original author having quit from development and it originally not having had any retarded licensing condition.
Indeed, until this everything was totally just under GPL 3, so forking is an option too.
p.s: docs https://github.com/prife/VirtualAppDoc
The code for VirtualApp and Epic dependecy seems to have been folded into VirtualXposed.
Analysis of clean files
I scanned VirtualXposed and all of its dependencies.
A license scan reveals a mix gpl, lgpl, apache, bsd facebook and mit licenses. Nothing too bad, this project is definitely forkable.
I scanned for URLs in the code, and everything is clean. (ofcourse it is possible that some URL may be encoded in hex or base64 or some other form)
The only file which could not be accounted for is this file from VirtualApp, still present in VirtualXposed - https://github.com/asLody/VirtualAp.../jni/HookZz/tools/ZzSolidifyHook/solidifyhook This file can be built by compiling the solidifyhook.cpp file.
This suggests the VirusTotal scan is almost surely a false positive.
mirhl said:
https://github.com/asLody/VirtualApp/issues/388
As linked in the original thread..
Besides here (before re-editing everything), the dude said something along the line of project's original author having quit from development and it originally not having had any retarded licensing condition.
Indeed, until this everything was totally just under GPL 3, so forking is an option too.
p.s: docs https://github.com/prife/VirtualAppDoc
Click to expand...
Click to collapse
The docs are interesting, thanks for that!
mirhl said:
https://github.com/asLody/VirtualApp/issues/388
As linked in the original thread..
Besides here (before re-editing everything), the dude said something along the line of project's original author having quit from development and it originally not having had any retarded licensing condition.
Indeed, until this everything was totally just under GPL 3, so forking is an option too.
p.s: docs https://github.com/prife/VirtualAppDoc
Click to expand...
Click to collapse
There's still a branch from June 17th on the repo with the GPL v3 license. It's newer than the one you linked https://github.com/asLody/VirtualApp/tree/revert-327-revert-326-master
Edit: Here's one from October 30th, which is the last one with a GPL v3 license https://github.com/asLody/VirtualApp/tree/5d1a620e324643edbc99a7155cb4238e69f9254f
Since it got remove here https://github.com/asLody/VirtualApp/commit/aa64bed92a5b4a757574968d922c5283f7eb95ab
I'm also not a lawyer but it's still under GPL v3 and as far as I understand, commercial use, among other things is allowed. https://tldrlegal.com/license/gnu-general-public-license-v3-(gpl-3)
Edit: Here's some discussion about the license. I'm not sure if he can just add that commercial line in there and it applies. They talk about dual-licensing and stuff but I don't know. I don't think that the usage and modification of this would count as commercial if it's released for free to a community.
I'm saying that if they added the non-commercial clause (even if still retaining the GPL license text), I'm not sure what comes out.
One prevails the other? Dual licensing?
Besides, most of commits come from the same two guys, but there are thirty more that contributed to the repo. And I'm not sure how legit unilateral relicensing is then.
mirhl said:
https://github.com/asLody/VirtualApp/issues/388
As linked in the original thread..
Besides here (before re-editing everything), the dude said something along the line of project's original author having quit from development and it originally not having had any retarded licensing condition.
Indeed, until this everything was totally just under GPL 3, so forking is an option too.
p.s: docs https://github.com/prife/VirtualAppDoc
Click to expand...
Click to collapse
You can refer https://github.com/android-hacker/VirtualXposed/issues/138 for the License of VirtualXposed.
I am planning to make a fork of GPL-v3 branch of VirtualApp ( it was completed nearly), But i don't know is it permitted.
akhilkedia , I have heard from you at github, Thank you ! !
I've put together some information, and I hope this will help.
Q: The app requests a ton of permissions
A: All thre permission are used for app inside VirtualXposed, i don't know what apps will be added to VirtualXposed, so i must request all the permission in advance. If VirtualXposed doesn't have a permission of one app, the app may can not work properly in VirtualXposed.
I am planning to upgrade the targetSdkVersion to 23, then there are little permission requests when install it (VirtualXposed will request permission dynamicly, but if you refuse some permission of one app in VirtualXposed, all the app in VirtualXposed won't grant that permission; this is truly frustrating, XPrivicyLua can not work properly in VirtualXposed: https://github.com/android-hacker/VirtualXposed/issues/7, I am trying to add a built-in permission control in VirtualXposed: https://github.com/android-hacker/VirtualXposed/issues/33, but there are lot of work to do...
Q: New modules are seemingly often not changed even after re-installing. Un-installed virtual apps are sometimes detected as still being present by the xposed module (?!)
A: This is a bug, the state of installation and launcher3 are not the same.
Q: Epic library's readme says not supported for arm32, x86_64 and mips device architectures for ART.
A: Yes, Epic doesn't support arm32, x86. you can install it on x86 device, but Xposed won't work.
Q: If you have enabled an Xposed Module outside of VirtualXposed, it will still affect apps inside it - So its recommended to turn the module off outside.
A: Yes, Xposed in system will take effect in VirtualXposed, and sometimes may cause conflicts if you enable the same module both in Xposed outside and VirtualXposed.
Q: The original developer seems to not speak perfect English, and the current users are mostly all Chinese.
A: Yes, my English speaking is poor, but my reading skills is good, there are no obstacles to understand what you say
The current users are mostly all Chinese, in fact, there are more than one million users in total If you think it is useful, please tell it to your friends, this is the best way to encourage me to make VirtualXposed better and better.
Q: is there any part of the source code of VirtualXposed (or any of its dependecies) that is proprietary/closed-source
A: No, VirtualXposed is fully open source, but the License is complex. I have no idea of it totally.
Q: If you have some free time later, can you explain in some detail (such as with links to relevant folders/files in Github) how VirtualApp, Epic and VirtualXposed work?
A: See below
Q: How VirtualApp works?
A:
First, you can read my blog and follow my tutorial:
My Blog: http://weishu.me/2016/01/28/understand-plugin-framework-overview/
My Tutorial: https://github.com/tiann/understand-plugin-framework
These articles tell you how Android Framework works and how Plugin-Framework hooks into system to establish a virtual environment.
If you are familar with Android Framework, you can read the source code of demo.
But sorry, it is fully Chinese, lots of Chinese say it is the best way to understand DroidPlugin/VirtualApp
Then, you can read the VirtyalAppDoc: https://github.com/prife/VirtualAppDoc.
In VirtualXposed, source code of VirtualApp lies in https://github.com/android-hacker/VirtualXposed/tree/license/VirtualApp/lib
The structure of VirtualApp:
JNI:
https://github.com/android-hacker/VirtualXposed/tree/exposed/VirtualApp/lib/src/main/jni/Foundation and https://github.com/android-hacker/VirtualXposed/tree/exposed/VirtualApp/lib/src/main/jni/Jni :mainly for IO redirect to make app inside VirtualApp access the corret file system, and also, it do some native hooks for special API(for example, Camera must be hook in native, disable JIT, etc..)
https://github.com/android-hacker/VirtualXposed/tree/exposed/VirtualApp/lib/src/main/jni/HookZz: This is an inline hook library, it is fully open source, this is the project: https://github.com/jmpews/HookZz
https://github.com/android-hacker/VirtualXposed/tree/exposed/VirtualApp/lib/src/main/jni/Substrate: Another inline hook library, it seems to be closed source, but i don't know how the author of VirtualApp get the source code...
https://github.com/android-hacker/VirtualXposed/tree/exposed/VirtualApp/lib/src/main/jni/fb: the JNI framework of facebook.
Java:
https://github.com/android-hacker/VirtualXposed/tree/exposed/VirtualApp/lib/src/main/java/mirror: the reflection framework of VirtualApp, it is used for use reflection conveniently, it is really elegant.
https://github.com/android-hacker/VirtualXposed/tree/exposed/VirtualApp/lib/src/main/java/android: some hidden API of Android Framework, copy it here for compile.
https://github.com/android-hacker/V...pp/lib/src/main/java/com/lody/virtual/server: the server process of VirtualApp, for example, Android Framework has ActivityManagerService, PackageManagerService, in VirtualApp, there are VActivityManagerService, the procedure of a process to communicate with Android Framework is: Client process -> VitualApp's server process(Virtual System servier) -> Android Framework's system service.
https://github.com/android-hacker/V...pp/lib/src/main/java/com/lody/virtual/client: mainly for hooks in client process(App run inside VirtualApp are all client process); There are four type of process in VirtualApp: 1. Virtual Server process(with hook of AMS & PMS) 2. Virtual client process(with hook of All Android System Service) 3. UI process(a normal process) 4. other process(such as native process)
https://github.com/android-hacker/V...ualApp/lib/src/main/java/com/lody/virtual/os: the multi-user system of VirtualApp and the some envionment variants, such as directory structure.
https://github.com/android-hacker/V...pp/lib/src/main/java/com/lody/virtual/remote: Parcel data stucture for IPC between Virtual client process and virtual server process.
If you want to read source code of VirtualApp, this class is the best entry:
https://github.com/android-hacker/V...com/lody/virtual/client/core/VirtualCore.java.
Q: How Epic works?
A:
You can refer my design procedure of Epic: http://weishu.me/2017/11/23/dexposed-on-art/
The article introduces many way to hook and tells you how epic solve the problems in the past and why epic does it that way.
Sorry for it is Chinese again...
And then, yon can read the paper : https://publications.cispa.saarland/143/ It is strongly recommended to read that!
In fact, Epic was inspired by https://github.com/mar-v-in/ArtHook, you can also read the source code.
Q: How VirtualXposed work?
VirtualXposed loads Xposed Modules in the entry of VirtualApp's client process, and inject the Xposed ClassLoader to that process to make Xposed module can call Xposed API, and epic provides the abilities to hook, That's all.
All this work is done in https://github.com/android-hacker/exposed
If you have any doubt with VirtualApp/Epic/exposed, feel free to ask me
In addition, I made an origination named android-hacker when i create VirtualXposed, if you want to contribute to VirtualXposed, welcome to join it!(tell me to invite you)
weishu said:
You can refer https://github.com/android-hacker/VirtualXposed/issues/138 for the License of VirtualXposed.
I am planning to make a fork of GPL-v3 branch of VirtualApp ( it was completed nearly), But i don't know is it permitted.
Click to expand...
Click to collapse
It is allowed to fork something with a GPL-v3 lisence. You can either do it from the GPL-v3 branch or the commit from 27/10-2017 and start from there.
weishu said:
You can refer https://github.com/android-hacker/VirtualXposed/issues/138 for the License of VirtualXposed.
I am planning to make a fork of GPL-v3 branch of VirtualApp ( it was completed nearly), But i don't know is it permitted.
Click to expand...
Click to collapse
As I was saying in the post, the only question would be where you'd be allowed to make it. Either:
https://github.com/asLody/VirtualApp/tree/58d0a7893f915ea191f0fa7e5f7c726652c29e8e or
https://github.com/asLody/VirtualApp/tree/00f152f98a922ced0d858c31e1a9c2f0afb53ab6 (if nevertheless specifying terms incompatible with GPL, they couldn't be interpreted as an additional separate license, rather than in place of it)
Since rovo89 hasnt been on a while, I dont think xposed will ever be developed again. So this will be the new standard.
amakuramio said:
Since rovo89 hasnt been on a while, I dont think xposed will ever be developed again. So this will be the new standard.
Click to expand...
Click to collapse
Don't be too sure about that - rovo has been missing for quite a while earlier as well, and still continued to develop Xposed. I see no reason to give up so soon on comparison.
s0me0ned96 said:
This is a magical project and can be a replacement for xposed !
Click to expand...
Click to collapse
Read carefully. This is in no way a replacement for xposed.
someone linked this virus scan in the other thread showing 18 "hits": https://www.virustotal.com/#/file/f...1f5f718e9325a2cba4d8524a73f4d0dac0b/detection
I went over it and there's 17 vague "I don't know, maybe" results(pup/gen), which are almost always false positives unless accompanied by actual identified malware results.
DrWeb was more specific saying it installs things without going through the package manager or showing a normal installation UI, but that's an intended and advertised function of this app.
weishu said:
akhilkedia , I have heard from you at github, Thank you ! !
I've put together some information, and I hope this will help.
-snip-
Click to expand...
Click to collapse
Thanks for your hard work on this! Was just wondering; is EXposed/TaiChi also your work? And will you make it open-source? I understand VirtualXposed is safe but we don't know much about this upgraded version.
CarteNoir said:
Thanks for your hard work on this! Was just wondering; is EXposed/TaiChi also your work? And will you make it open-source? I understand VirtualXposed is safe but we don't know much about this upgraded version.
Click to expand...
Click to collapse
EXposed/TaiChi is created by me, and i won't make it open-source.
VirtualXposed is open-source, but there are still so many people think it is dangerous. Open-source can not give me any revenue.
weishu said:
EXposed/TaiChi is created by me, and i won't make it open-source.
VirtualXposed is open-source, but there are still so many people think it is dangerous. Open-source can not give me any revenue.
Click to expand...
Click to collapse
What revenue do you make with it closed source? Also, will it ever support XInsta?

KVM Kernel

Hello everyone.
As in subject, I'm looking for a KVM Enabled Kernel, to flash on my device.
I'm looking for:
1) File to download
2) Commands to FastBoot
3) A way to ensure it works
Thanks in advance for any help.
Bye, Ivano.
P.S.: I forgot to mention, it's a ZE551ML Z00AD
P.P.S.: Nevermind, I successfully flashed KVM on device, but I can't use it on Limbo yet (I get an error about missing modules, but they're there).
Any help greatly appreciated.
I never got limbo to work, I have exact same model you have (Z00AD) and I've got kvm working with QEMU.. Limbo doesnt detect kvm properly it doesn't see the kernel modules loaded..
Theres a few guides on here how to use QEMU but as a VERY rough idea on what you need to do is:
Install a chroot linux on the phone (I used Linux Deploy to set up Ubuntu with Xterm)
After chroot setup, install qemu-kvm with apt. And on the Android OS install aSpice client from play store
Move the install images/hdd images to the phone storage (if preinstalled os hdd with Virtualbox or something)
Launch qemu with --enable-kvm and -cpu host to get kvm working, adjust other options as needed
Sorry for such a quick write up I'm busy atm, can help more later
My problem is that gpu won't work with chroot
You wont get gpu access with chroot, some devices have GPU's that have some support but unfortunately our
specific PowerVR chips dont have support.. using QEMU with kvm will allow you to still use all other parts of your hardware, and using spice will allow the use of the QXL video driver that provides some basic acceleration in the guest.
Either that or in the chroot compile and build your own version of qemu with -virglrenderer enabled, but the virgl option is very beta and may not work
Edit: Limbo is just a front end to QEMU so you wont have any new features that qemu doesn't have.. just Limbo is a port of qemu that's stripped down to work on Android
In this case, I don't need this anymore.
Thanks for your help.
What kind of 3D software/GPU needy task are you needing? Because in theory I've read that a linux chroot may still have some graphics acceleration on android devices due to some linux device firmware has OpenGL ES support (which is what runs on android devices, a subset of standard OpenGL) but how I personally am not sure.. I know there is GL4ES that supposed to allow OpenGL calls to be converted/linked to OpenGL ES calls but you would have to compile it from source as it's aimed at arm hardware..

Categories

Resources