Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Android Application #485

Open
ghost opened this issue Apr 4, 2022 · 14 comments
Open

Android Application #485

ghost opened this issue Apr 4, 2022 · 14 comments

Comments

@ghost
Copy link

ghost commented Apr 4, 2022

I'm thinking about simple Android application.
We can pack armv6-compatible ELF binary and just run it inside for PoC.
Your thoughts?

@arriven
Copy link
Owner

arriven commented Apr 4, 2022

I'm not sure if it would be very useful but I certainly wouldn't mind if someone were to make a mobile version. The only note I have is that it would be best to keep it as a separate repository to simplify management of the code

@ghost
Copy link
Author

ghost commented Apr 4, 2022

Not much progress, but I started to work on Android app, because friends asked about it: https://github.com/FPavlovskiy/Dzida

@roman-kruglov
Copy link
Contributor

roman-kruglov commented Apr 6, 2022

I would run it on my phones too, just imagine the possible number of additional.. load testers. Everybody has one (a phone). Provided easy instructions.. the army of testers would grow significantly.

But imo it would be easier to see the releases here than to follow another repo. Also for every release of the app there should ideally be a release of an android app, right? so, it would be logical too.

Maybe it would be possible to have the android specific code separately if required, but to use it as a submodule or something and automatically build a version with each release here?

@ghost
Copy link
Author

ghost commented Apr 7, 2022

But imo it would be easier to see the releases here than to follow another repo. Also for every release of the app there should ideally be a release of an android app, right? so, it would be logical too.

I think that it makes sense to download arm binary in the Android app and check for updates as well, so in that case you don't need to updated an Android app frequently.

@arriven
Copy link
Owner

arriven commented Apr 7, 2022

The way I see it: you download android app once (or at least less frequently) and maintainer of that app regularly check for compatibility between the app and latest version of db1000n and just updates some centralized manifest if everything works well making the android app fetch the new "attacking binary"

@roman-kruglov
Copy link
Contributor

@FPavlovskiy maybe this discussion could help #465

@Andrii-Asiox
Copy link

Andrii-Asiox commented May 9, 2022

Not much progress, but I started to work on Android app, because friends asked about it: https://github.com/FPavlovskiy/Dzida
@FPavlovskiy
I use termux and arm version of db1000n on android devices

@roman-kruglov
Copy link
Contributor

I'm intending to look into making an android app, but one which even a grandma could use - using termux is imo too complicated for non technically astute folks.

I would prefer to make a simple wrapper which would run dn100n and just show an emulated console with messages. Guys in the referenced discussion had some success with fyne, but I would prefer minimal external components, like maybe go mobile instead.

@ghost
Copy link
Author

ghost commented May 30, 2022

@roman-kruglov , I managed to build fyne app from #465 and contacted code owner. Probably it is quickest solution and we will be able to merge it to upstream. @arriven what do you think? It shouldn't affect CI pipeline and codebase a lot.

@arriven
Copy link
Owner

arriven commented May 30, 2022

@roman-kruglov , I managed to build fyne app from #465 and contacted code owner. Probably it is quickest solution and we will be able to merge it to upstream. @arriven what do you think? It shouldn't affect CI pipeline and codebase a lot.

I think it's better to have it as a different repo and I can leave a reference to it in the main repo. The benefits of this approach are that you wouldn't have to pass all the maintenance via myself and also you could have different release timeline from the main repo (similar to how db1000nX100 author has an option to auto update to latest compatible version that he manages)

@ghost
Copy link
Author

ghost commented May 30, 2022

Ok, in this case it makes sense to use db1000n as submodule, but not as a monorepo to simplify patching

@roman-kruglov
Copy link
Contributor

roman-kruglov commented May 31, 2022

@FPavlovskiy @arriven I was just working on it for several days. Had to use fyne too, no support for even a minimal GUI in gomobile. But my findings are - I can't embed a terminal emulator written in fyne into db100n code outside - it has to be called from the code. Good news is that I managed to add only one file and just capture / redirect all std streams to the terminal emulator without any modifications of any other code.

I probably waited for too long to publish this, I guess I'll create a draft pr - at least to share the approach and discuss stuff there.

@roman-kruglov
Copy link
Contributor

here it goes #547

@ghost
Copy link
Author

ghost commented May 31, 2022

@roman-kruglov it was my plan as well.

  1. Fork an OSS terminal emulator
  2. Add code to download armv7 or armv8 db1000n binary
  3. Run elf binary on the app start

But then I started to investigate fyne solution because it looks like a ready one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants