Open ale5000-git opened 8 years ago
..and upload it to the F-Droid repos?
Apparently it cannot be build on F-Droid, it is stated here: https://f-droid.org/wiki/page/com.nowsecure.android.vts
A new release would be great and the option or a textfile how this can be used individually to root a smartphone when towelroot-bug is fixed and Samsung locked the bootloader. So this would be a chance to succeed in rooting.
would love a new release.
Can someone build the latest relase please ?
Isn't it possible?
When I download the latest app from 2015 does it test for vulnerables from last year (2016)? If not - how can I achieve this?
Download the latest release from the official page.
aircooledcafe commented 2 hours ago
Download the latest release from the official page. https://info.nowsecure.com/VTS-for-Android.html
This release you a pointing is from Dec 15, 2015 and has logically only CVE's to this date. I wan't to figure out how to test against (new) vulnerables from last year (2016)...
download and build from source is only option I'm guessing, seems no one is release the builds any longer then.
aircooledcafe commented 2 hours ago
download and build from source is only option I'm guessing, seems no one is release the builds any longer then.
Too bad that I'm not able (like 99%) to do this...
Meanwhile I go with x-ray (https://labs.duo.com/xray). They have quite recent builds. I like Android-VTS much more but as a matter of security...
X-ray is too very old and only checks cves back to 2015.
ManuelGysin commented 5 minutes ago
X-ray is too very old and only checks cves back to 2015.
Hell... damned! The binary is from jul '16... but as you said.. no active development
Anyway... looks like security gone out of fashion. Maybe it's time to de-publish here...
I'll start a fork and doing some initial work. We are facing MIT license so there should be no problem.
If any wants to help, drop me a message.
@ManuelGysin Maybe trying to ask write access to the official repository to @dweinstein and @Fuzion24 first would be better. This is what I usually do. Forking a project and drive existing users to it is always hard: users not aware of the fork, lack of advertising, etc.
I would first the establish some progress on the fork before asking for write permissions. If the project finds back to life, maybe the original authors may continue their work.
AFAICT xray's more recent release had just been a white labeling of VTS. We were hoping that they would help by adding support/upstreaming new tests but so far that hasn't really been the case.
To be honest, in order to continue directly supporting this project we would need more support/sponsorship from perhaps another vendor that is benefiting from the project. We've heard of a number of bigger companies getting the benefit from this tool. It takes a good amount of time to bring in new CVEs and to maintain releases.
@dweinstein: What about setting an automated tool to compile nightly builds or perhaps weekly?
There are some free services for this and after setting it won't require manual intervention.
I think build the release is not the problem. The big work is to add the testing code for every CVE. In fact a lot of them are not even possible to check, because Mediatek/Nvidia/etc. do not provide usable information. So we can only add CVEs with proper description and source access.
I'm currently creating a list with CVEs we can check and one we can't. For some we can adopt PoC code directly for testing, for others we need to start from scratch.
I think we should start we the boring part and create a ToDo list. After that we can start to get help. Maybe we should write to some Linux sites too and make some noise about the current situation.
In reality a customer has no idea if the patch level is correct and all needed CVEs are fixed. It's just a string in a property file. So a real test framework is needed to verify ROM builds. This is an important topic and we should communicate this to the community.
I don't think the big players will support this project, so we need community work. In fact with a small team this should be possible.
I will open an issue later with the lists included. So we can try to organize.
Thanks
On Thu, Jan 26, 2017, 5:56 PM Manuel Gysin notifications@github.com wrote:
I think build the release is not the problem. The big work is to add the testing code for every CVE. In fact a lot of them are not even possible to check, because Mediatek/Nvidia/etc. do not provide usable information. So we can only add CVEs with proper description and source access.
I'm currently creating a list with CVEs we can check and one we can't. For some we can adopt PoC code directly for testing, for others we need to start from scratch.
I think we should start we the boring part and create a ToDo list. After that we can start to get help. Maybe we should write to some Linux sites too and make some noise about the current situation.
In reality a customer has no idea if the patch level is correct and all needed CVEs are fixed. It's just a string in a property file. So a real test framework is needed to verify ROM builds. This is an important topic and we should communicate this to the community.
I don't think the big players will support this project, so we need community work. In fact with a small team this should be possible.
I will open an issue later with the lists included. So we can try to organize.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/AndroidVTS/android-vts/issues/133#issuecomment-275570747, or mute the thread https://github.com/notifications/unsubscribe-auth/AXtz3xEXrBrWXC0MZY8hXjBFvXGIYq9eks5rWU7cgaJpZM4JZAsY .
@ManuelGysin: I agree to most of things you said but build release or beta IS a problem because code in git is updated at "9 Aug 2016" while latest release is updated at "15 Dec 2015" so there is unreleased code.
The users will likely stop using the project after seeing this.
This seems right. But building it shouldn't be that hard. If wished I can provide a cloud build VM for newer release. (We need to setup Jenkins for an other project anyway for my organization)
@ManuelGysin: I think it would be really great and it could gather interest in the project.
This issue can be resolved by simply bumping the version[Code|Name] to v.14 in build.gradle, then building the latest APK and uploading it to the Releases page here: https://github.com/AndroidVTS/android-vts/releases
ok sorry for this, I totaly forgot you but I made the change: https://releases.nailyk.fr/AndroidVTS/ The build script is here so you can check Im not modding the APK on the fly.
@nailyk-fr it shouldn't need to depend on AOSP, though
It would be nice if someone change the build script to compile the files in android-vts/app/src/main/assets/ instead of use the prebuilt binaries and submit a pull request. In this way it will be able to be included in F-Droid.
Temporary fdroid repo https://github.com/AndroidVTS/android-vts/issues/38#issuecomment-296841217 until official f-droid came back.
Now even this issue is 2 years old, and still no new APK in releases/
. Is there any chance, @m00head @Fuzion24?
The latest release is more than 1 year old, is it possible to do a new release?