Add a simple navigation drawer (WIP)

[fat-tire]

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

[fat-tire]

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]

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]

@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]

@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]

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]

@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]

@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).

[tux-mind]

Dynamic networks ;)

[fat-tire]

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]

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]

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]

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]

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

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