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

Add a simple navigation drawer (WIP) #492

Open
wants to merge 22 commits into
base: develop
Choose a base branch
from

Conversation

fat-tire
Copy link
Contributor

@fat-tire fat-tire commented Nov 9, 2015

Very basic and doesn't yet persist across the whole app. This is because we should:

(1) decide what goes in the navigation drawer (vs. menus in action bar)
(2) stop starting activities and start loading in fragments instead (to preserve drawer)
(3) think about how to use fragments in a cool way (tablet layouts, etc.)

This was added pretty quick but it's a start

doesn't yet perisist across the whole app.  This is because we should:

(1) decide what goes in the navigation drawer vs. menus
(2) stop loading activities and start loading in fragments
(3) think about how to use fragments in a cool way.
@fat-tire
Copy link
Contributor Author

Okay new changes make menu items work across both main fragment and settings fragment...

next is the wifi selection I guess. We really need to figure out why we want the drawer :P

OH IDEA! Maybe the wifi items can go there instead of in their own activity? There's space for it right now... What does everyone think?

@tux-mind
Copy link
Member

Hi @fat-tire sorry for manage this PR so late.

I'm actively working in the MSF branch.
right now I'm integrating the new msf library into cSploit.
it will be awesome to start using the drawer now, making a MSF entry in the drawer.

I can freeze my work to help you with the drawer, do you agree ?

I think that the drawer should contain:

  • Network: our useful stuff to sniff/scan hosts
  • WiFI: scan wireless network and try default passwords
  • MSF: so cute

any other suggestion is appreciated 😊

I'm looking forward for your reply 😁

@fat-tire
Copy link
Contributor Author

@tux-mind cool. Do you mean to put LINKS to network/wifi/msf or to put the actual list of networks in there? Either works for me.

Also-- any progress with the MITM issue #480 ? I still don't have MITM on Nexus 4.

Finally-- looks like cSploit made it to fdroid

@tux-mind
Copy link
Member

@fat-tire I want away from home in these days, so I didn't had access to IRC logs.

I'll work on #480 today, but I need that you test out the changes I'll make on the issue-480 branch.

good news for f-droid, really appreciated 😊
I thought that we must switch to botbrew before having cSploit on f-droid.

about the drawer, I think that you got another great idea, using the interfaces names instead of Netowork.

I'm gonna merge @gainan PRs ( with ❤️ ) in the next few hours, than I'll work on #480 .
after reaching a stale point with issue-480 I'll checkout this PR ( with ❤️ ).

@ETeissonniere
Copy link
Member

First, sorry for not being here for months, but I was preparing a big
contest 😄.
Secondly, I might be able to work more on cSploit next year (will have a
computer, yeah !!).
Finally, I have a solution to your IRC problem, you can use a ZNC bouncer,
if you want one, come in #simpleznc, or ask here & I will contact the staff
😄.
Le 19 nov. 2015 11:52, "tux-mind" notifications@github.com a écrit :

@fat-tire https://github.com/fat-tire I want away from home in these
days, so I didn't had access to IRC logs.

I'll work on #480 #480 today,
but I need that you test out the changes I'll make on the issue-480
branch.

good news for f-droid, really appreciated [image: 😊]
I thought that we must switch to botbrew before having cSploit on f-droid.

about the drawer, I think that you got another great idea, using the
interfaces names instead of Netowork.

I'm gonna merge @gainan https://github.com/gainan PRs ( with [image:
❤️] ) in the next few hours, than I'll work on #480
#480 .
after reaching a stale point with issue-480 I'll checkout this PR ( with [image:
❤️] ).


Reply to this email directly or view it on GitHub
#492 (comment).

@fat-tire
Copy link
Contributor Author

@tux-mind I didn't submit to fdroid-- no idea who did (or maybe they just found it themselves.) I use fdroid and I noticed it came up on its own.. I'll take a look at what you did above... I just did a merge so we should be even with the develop branch now

@developpsoft what contest?

@ETeissonniere
Copy link
Member

@Fattire, the prologin contest.
Le 20 nov. 2015 11:36, "Fattire" notifications@github.com a écrit :

@tux-mind https://github.com/tux-mind I didn't submit to fdroid-- no
idea who did (or maybe they just found it themselves.) I use fdroid and I
noticed it came up on its own.. I'll take a look at what you did above... I
just did a merge so we should be even with the develop branch now

@developpsoft https://github.com/DeveloppSoft what contest?


Reply to this email directly or view it on GitHub
#492 (comment).

created a progress dialog that will show up only if
a certain amount of time has been elapsed and disappear if
has been shown for at least another certain time.

show such progress dialog when changing interface
( stopping and starting network radar may require some second ).

another way is to asynchronous stopping the network-radar but
we should deregister receivers and we lost the STARTED/STOPPED
intents.

in a far future we will support more running instances of
network-radar, so you can be notified ( say, with a small icon over the interface name )
that new hosts appearead on interfaces that you are not watching.
@tux-mind
Copy link
Member

tux-mind commented Dec 1, 2015

screenshot_2015-12-01-15-33-34

Dynamic networks ;)

@fat-tire
Copy link
Contributor Author

fat-tire commented Dec 1, 2015

Hey, just tried it.. Looking even better--- though there are some issues I found:

  • The blue sidebar mixing with the notification bar along the top gets kind of weird. I cant' remember what the colors were before, but this is something we should look at..
  • When I click a target and get the next "Action" item, there is a gigantic header that seems wrong... I'll include a screenshot later today as I can't at the moment.
  • Selecting MITM on the network ...0/24 gets this:
E/ACRA    (16257): ACRA caught a IllegalArgumentException for org.csploit.android
E/ACRA    (16257): java.lang.IllegalArgumentException: No view found for id 0x7f0e0086 (org.csploit.android:id/mainframe) for fragment MITM{c1f94e #3 id=0x7f0e0086 MITM}
E/ACRA    (16257):  at android.support.v4.app.FragmentManagerImpl.moveToState(FragmentManager.java:1059)
E/ACRA    (16257):  at android.support.v4.app.FragmentManagerImpl.moveToState(FragmentManager.java:1248)
E/ACRA    (16257):  at android.support.v4.app.BackStackRecord.run(BackStackRecord.java:738)
E/ACRA    (16257):  at android.support.v4.app.FragmentManagerImpl.execPendingActions(FragmentManager.java:1613)
E/ACRA    (16257):  at android.support.v4.app.FragmentManagerImpl$1.run(FragmentManager.java:517)
  • selecting an individual host gets this:
E/ACRA    (29881): org.csploit.android fatal error : Attempt to invoke virtual method 'void android.support.v4.app.Fragment.setMenuVisibility(boolean)' on a null object reference
E/ACRA    (29881): java.lang.NullPointerException: Attempt to invoke virtual method 'void android.support.v4.app.Fragment.setMenuVisibility(boolean)' on a null object reference
E/ACRA    (29881):  at android.support.v4.app.FragmentStatePagerAdapter.instantiateItem(FragmentStatePagerAdapter.java:116)
E/ACRA    (29881):  at android.support.v4.view.ViewPager.addNewItem(ViewPager.java:870)
E/ACRA    (29881):  at android.support.v4.view.ViewPager.populate(ViewPager.java:1086)
E/ACRA    (29881):  at android.support.v4.view.ViewPager.populate(ViewPager.java:952)
E/ACRA    (29881):  at android.support.v4.view.ViewPager.onMeasure(ViewPager.java:1474)

Unfortunately I can't look in more detail now but I can try to track these down possibly tonight. Just wanted to let you know about 'em.

@tux-mind
Copy link
Member

tux-mind commented Dec 1, 2015

Yeah, thanks for the report fattire, working on ;)

I made a new target detailed view, with a pager and other stuff. It's
designed to be used in a master detail flow ( to be implemented ).

Feel free to change all the stuff as you wish, you are the designer ;)

Back to keyboard in a few minutes :)
Il 01/dic/2015 10:51 PM, "Fattire" notifications@github.com ha scritto:

Hey, just tried it.. Looking even better--- though there are some issues I
found:

The blue sidebar mixing with the notification bar along the top gets
kind of weird. I cant' remember what the colors were before, but this is
something we should look at..

When I click a target and get the next "Action" item, there is a
gigantic header that seems wrong... I'll include a screenshot later today
as I can't at the moment.

Selecting MITM on the network ...0/24 gets this:

E/ACRA (16257): ACRA caught a IllegalArgumentException for org.csploit.android
E/ACRA (16257): java.lang.IllegalArgumentException: No view found for id 0x7f0e0086 (org.csploit.android:id/mainframe) for fragment MITM{c1f94e #3 id=0x7f0e0086 MITM}
E/ACRA (16257): at android.support.v4.app.FragmentManagerImpl.moveToState(FragmentManager.java:1059)
E/ACRA (16257): at android.support.v4.app.FragmentManagerImpl.moveToState(FragmentManager.java:1248)
E/ACRA (16257): at android.support.v4.app.BackStackRecord.run(BackStackRecord.java:738)
E/ACRA (16257): at android.support.v4.app.FragmentManagerImpl.execPendingActions(FragmentManager.java:1613)
E/ACRA (16257): at android.support.v4.app.FragmentManagerImpl$1.run(FragmentManager.java:517)

  • selecting an individual host gets this:

E/ACRA (29881): org.csploit.android fatal error : Attempt to invoke virtual method 'void android.support.v4.app.Fragment.setMenuVisibility(boolean)' on a null object reference
E/ACRA (29881): java.lang.NullPointerException: Attempt to invoke virtual method 'void android.support.v4.app.Fragment.setMenuVisibility(boolean)' on a null object reference
E/ACRA (29881): at android.support.v4.app.FragmentStatePagerAdapter.instantiateItem(FragmentStatePagerAdapter.java:116)
E/ACRA (29881): at android.support.v4.view.ViewPager.addNewItem(ViewPager.java:870)
E/ACRA (29881): at android.support.v4.view.ViewPager.populate(ViewPager.java:1086)
E/ACRA (29881): at android.support.v4.view.ViewPager.populate(ViewPager.java:952)
E/ACRA (29881): at android.support.v4.view.ViewPager.onMeasure(ViewPager.java:1474)

Unfortunately I can't look in more detail now but I can try to track these
down possibly tonight. Just wanted to let you know about 'em.


Reply to this email directly or view it on GitHub
#492 (comment).

@fat-tire
Copy link
Contributor Author

fat-tire commented Dec 4, 2015

Hey @tux-mind --

Sorry-- I'm confused by what you've been doing. The commits are pretty huge. But as mentioned above the build I have now crashes all over the place when I try to do anything:

  • As i mention above, selecting the network 192.168.1.0/24 crashes when i select MITM.
  • Any host crashes.
  • choosing any discovered network interface except for wlan0 in the sidebar freezes the whole app, resulting in a ANR.

Additionally there are some UI issues:

  • the navigation bar goes over the actionbar/toolbar rather than beneath it. (Is this desired?)
  • there are mixed white/black text in the action bar
  • choosing settings and then the "back" icon quits the app rather than pops the settings off the stack. Previously it would go back and any exit would have a "are you sure" question.

Also, I'm confused by the various abstractions of fragments/activities:

  • the abstracting of the AbstractSidebarActivity-- why is this needed? There should ideally be only ONE activity for the whole app-- and it should always have the sidebar. Why would you need this more than one time?
  • why the basefragment? Is this just to set the theme? Is it worth it for that?
  • you added a lot of new classes-- "heartless" and "init" and such. I'm not sure what they're for...

I'm really afraid to make any changes now because I don't have the "big picture" with all these 50+ changed files and new additions. If you could get everything in a "working state", without the obvious crashes, I could try to help. But i'm afraid any changes I make right now are possibly going to clash with the plans you've made.

Let me quickly outline my understanding of how things are supposed to work:

  • For maximum flexibility w/layouts (tablet, phone etc.) we use ONE Activity-- MainActivity.java. It should use a single main layout file. This layout file should include the main layout, the navigation bar, etc. The navigation bar and menu and such are all therefore provided by the single Activity and do not change except as each fragment may add items.
  • Fragments will be used for everything else either via a back-stack, or with multiple panes (on tablets), or with a viewpager (either).... and there should always be only one navigation drawer and one menu to deal with.
  • If we want additional Activities at some point, we can use them-- I was actually originally thinking that for actions, we would use an activity rather than a fragment-- but you've already factored them, so I guess it doesn't matter, and this way we can have multiple actions per activity.
  • So navigation on a phone would go: NAVIGATION DRAWER ---CURRENT NETWORK INTERFACE-->MAIN AREA==TARGET FRAGMENT full of hosts ---SELECTED TARGET-->ACTION LIST--SELECTED ACTION-->ACTION SCREEN (OR MITM LIST) like this:

- As you can see, on a tablet, you can have side-by-side left to right master view->detail views. You can have multiples of these. At any point the user can switch network interfaces, which would pop a new target list to the top of the stack (without killing the ones below, so that actions can still be running on entirely different interfaces). - fragments would not be popped from the backstack unless the back button is manually pressed, canceling an in-progress action or removing a list of items. - A viewpager w/tabs would be used for those actions who have multiple "views", such as a nmap scan where a user might want to also get the raw textual output, or an action that has a wizard, configuration screen, etc. those viewpagers could be handled by the fragments themselves, so that multiple instances of the actions could exist at the same time (ie, you could initiate multiple scans of different hosts, and each one might have a summary port view as well as a raw output view) - At some point, any node/fragment in the tree of fragments could be reached directly from the navigation drawer itself.

Does this make sense? I don't want to touch anything until everything is in a semi-working order tho. The MITM is just a second-order list that pops over the "Action list", just as an individual action item fragment would.

@tux-mind
Copy link
Member

Hi @fat-tire , sorry for the late reply, I was very busy at work in the past days.

anything is crashing, I need more help to get the whole app running properly.
there are many things to change, moving into a fragmented-style app it's cool but require a lot of work, especially for those activities like MITM that have everything in one place.

let me answer some of your questions.

navigation drawer

yes the navigation drawer that get over the action bar is desired, is the new style according to many blogs.

AbstractSidebarActivity

good point, this is one of my doubts about the app design.

initially I started working with that concept in mind: one Activity for the whole App.
As I started moving into fragments I noticed that that activity must implements all fragments listeners and should known exactly how to deal with them.

than I thought a solution:

  • a NetworkActivity to manage attached networks ( detect hosts, perform scans, MITM ... )
  • a WifiActivity to manage wireless stuff ( scan, crack, todo-monitor-mode ... )
  • a MsfActivity to manage the MSF if present

in this way NetworkActivity do not have to manage wireless/msf stuff and it's more maintainable.

this is just my solution and I would really appreciate your ( and any other ) opinion.


I just read your suggestions about the layout.
I will move into that direction than, thank you for your precious time and help ❤️

UI bugs

yep, there is a lot. I need your help to kill them 😜

BaseFragment

it's scope is to provide some common stuff to all our fragments.
as now there is only one common operation: setting the right theme when the View has been created.

Heartless and Init

Those fragments are used to show a simple information to the user. do you remember the old way to do that ?

we used to change the layout of the main activity, inflating a different layout.
that it's certainly a bad thing. we now have fragments, let's use them!

when cSploit initialize itself it will show a Init fragment, in that fragment we only show a "Initializing..." sentence, nothing complex. the real advantage is to manage all the initialization problems there, not in MainActivity.

when cSploit run without an installed core (usually the first time ) it will show the Heartless fragment, as before it is simple, it just show a "Core not present" sentence. the advantage is that we manage the core update ( and all it's problems ) here, not in MainActivity.

The main purpose of this two fragments is to reduce the MainActivity complexity, making it really more maintainable.

it follow the Unix philosophy:

one program do one thing, and, hopefully, it does it well!

persistent state of network

At any point the user can switch network interfaces, which would pop a new target list to the top of the stack (without killing the ones below, so that actions can still be running on entirely different interfaces).

yep, but we need to change a lot of things, actually we have only one global target list.
I agree with you that this is the right way to work and I'll work on it to make it possible!

MITM

MITM it's very messy.
it was wrote in hurry and quickly by evilsocket and it's code it's huge and monstrous.
It require a lot of work to move to the new fragment design ( as you can see from my last commit ).
I think that we can leave it for later, focusing on the whole design concept and app behaviour.

your help

I'll work to bring cSploit into a semi-working state, leaving MITM as it is. I'll focus on applying your suggestions thus to make you able to help me.

after that I can start working on porting the MITM stuff into the core ( that was the main goal of moving to a native core ).

the road to cSploit 2.0 it's very long... but I believe that with collaborators like you it's only a long road, not an hard one 😉

thank you for your precious time ❤️

@tux-mind
Copy link
Member

should work now, at least you can reach the target details.

have to go now, let me known everything else you need 😊

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

Successfully merging this pull request may close these issues.

3 participants