Jump to content
squish

Install Tools

Recommended Posts


Ever wish you could retract a post... :/

feel free to ignore the 'observations' in the post above...  Will continue digging and provide updates if I find anything valuable..

Share this post


Link to post
Share on other sites

I've rewritten the install.sh script with the following changes and the tool installation is now completing as expected.

  • Created a new variable for the target directory
  • Replaced directory creation command to reference new variable
  • Inverted the install logic after the tool copy to validate the new directory has content rather than checking that the source directory is now empty.
# Check to ensure that the tools_to_install directory isn't empty. 
# Exit with solid red LED if it is, otherwise note tools in log.
TOOLSDIR=$(find /root/udisk/payloads/ -name tools_to_install)
TARGETDIR=/pentest/
if [ "$(ls -A $TOOLSDIR)" ]; then
    cd $TOOLSDIR
	echo "Available Tools:" > /tmp/tools_installer.log
	echo "----------------" >> /tmp/tools_installer.log
	for i in $(ls -d */); do echo ${i%%/} >> /tmp/tools_installer.log; done
else
    LED R
	exit 1
fi

# Set LED to purple blinking and move tools
LED R B 100
mkdir -p $TARGETDIR
mv $TOOLSDIR/* $TARGETDIR

# Set LED to purple solid and check that move completed
LED R B
if [ "$(ls -A $TARGETDIR)" ]; then
	# Setup impacket
    cd /pentest/impacket
    python ./setup.py install
	
	# Additional tool setup goes here
	
	# List installed tools in /pentest and save to tools.txt on USB disk
	cd /pentest/
	echo "Installed Tools:" > /root/udisk/installed-tools.txt
	echo "----------------" >> /root/udisk/installed-tools.txt
	for i in $(ls -d */); do echo ${i%%/} >> /root/udisk/installed-tools.txt; done
	sync && sleep 1 && sync
	
	# Set LED to white on success
	LED R G B
    exit 0
else
	# Set LED to red on fail and exit
	LED R
	exit 1
# Set LED to amber blinking on setup
	LED G R 100

fi

 

  • Upvote 1

Share this post


Link to post
Share on other sites

Just letting you know that you might run into issues later on... because any file could now exist in /pentest/ and you will attempt to install. Both ways will work the Hak5 code does allow for some error checking as it makes sure that the files you expect to move actually moved. Not saying your wrong just be careful. Ps maybe it would be easier to read this way?

if [ ! $(ls -A $TOOLSDIR) ]; then
    install stuff
else
    stop files still remain
fi

all three ways will work.

Share this post


Link to post
Share on other sites

Thanks @Cpt.Pickles. That makes sense - I didn't consider reusing the script for subsequent installations.

My bash programming is still weak and I'm not sure what would be causing the code <if [ "$(ls -A $TOOLSDIR)" ]; then> to evaluate true and stop installation when manually checking that directory returns no content.

Is there a way to evaluate a statement manually in bash?  For instance, in PowerShell, if I create an if statement that evaluates (4 -eq 4), I can test that evaluation manually from the PS prompt by simply typing "4 -eq 4" and PS will return True as a result.  I was hoping for something similar in bash to help me work through understanding syntax logic.

Share this post


Link to post
Share on other sites
Just now, maehko said:

Thanks @Cpt.Pickles. That makes sense - I didn't consider reusing the script for subsequent installations.

My bash programming is still weak and I'm not sure what would be causing the code <if [ "$(ls -A $TOOLSDIR)" ]; then> to evaluate true and stop installation when manually checking that directory returns no content.

Is there a way to evaluate a statement manually in bash?  For instance, in PowerShell, if I create an if statement that evaluates (4 -eq 4), I can test that evaluation manually from the PS prompt by simply typing "4 -eq 4" and PS will return True as a result.  I was hoping for something similar in bash to help me work through understanding syntax logic.

How are you checking the content in the directory to determine if it's empty?   When I ran the exact command being used "ls -A" in the tools_to_install directory I noticed there were still results for ._impacket and ._responder,  which caused it to fail.  Perhaps remove the "-A" from the command, since we really only need ls?

  • Upvote 1

Share this post


Link to post
Share on other sites

Anytime, 
if you are attempting to run the code manually I would follow some of the steps outlined in previous comments. mount, run though each line and verify your assumptions when running the if statements. If you think its empty just run the code inside the [   ] to see if its is true or not. 
I did not have the same issue as wrewdison, but to his/her point we could also replace the -A with -a and it would still check for files but evade checking for anything .* ...again many possibilities.

Share this post


Link to post
Share on other sites

Is this still an issue after a recent code merge? Seems to be working OK for me now. There was an issue with CLRF line terminators that was addressed last night.

Share this post


Link to post
Share on other sites

I'm still having issues with this part old/new still getting the red solid led. I've tried with scripts under both switches, if I ssh in and look in the pentest directory it will have the tools_to_install directory so it's not copying what's in the folder to pentest it's copying the whole folder. Please let me know if maybe I'm doing something wrong 

Thanks 

Share this post


Link to post
Share on other sites

That doesn't sound right... if you look inside of tools_to_install is there another tools_to_install? The code looks for the folder then copies all the items inside of that folder. If you cat /tmp/tools_installer.log after it fails what is the output? If you are seeing tools_to_install it sounds like you might have put the wrong parent folder in the payload... and so it sees the parent folder and then says the only folder is tools_to_install. Copy all the items from inside of tools_installer folder to the switch you want and run it.

Share this post


Link to post
Share on other sites

Just as a note - I found that if you have tools_installer in your library the install script will pick that up first and will do the install from there and NOT from the switch directory. 

 

 

Share this post


Link to post
Share on other sites

I have had the same problem with install tools. The very first time I ran it on switch one messed with some stuff then put it in recovery mode and noticed that after recovery was done both payloads were still the same as before the recovery. When I tried to install the tools again it failed Everytime and looking in /pentest both tools were there but impackt was not installed. I have to run it manually, but after that the bunny worked just fine  

Share this post


Link to post
Share on other sites
On 3/4/2017 at 10:54 PM, Darren Kitchen said:

What OS are you using? This is odd -- 3 reports now of this issue and yet I'm unable to reproduce it with a fresh Bash Bunny and a fresh copy of the payloads repo. 

I had this issue as well. After going into the shell and looking at the /pentest directory, the two tool folders were there. Also, it appears that the "tools to install" folder itself was moved from payloads/library/tools_Installer to the /pentest directory. Based on where the state that they payload left my BB, I looked at the install.sh file and it looks like it copies the files plus runs an installer python script in one of those. I went into that directory via the shell and ran the python install script manually.

Share this post


Link to post
Share on other sites

Im still running into the redlight problem, what I did was similar to someone posting above

  • Copied all files from tools_installer into payloads/switch1 and ejected the bunny
  • switched to position 1 and plugged in

When I'm using serial I can see it doesn't even create a /pentest folder.. on Kali and win10..

Share this post


Link to post
Share on other sites

By default the installer doesn't work if you *copy* the content of /payloads/library/tools_installer to /payloads/switch1/

you have to *move* the content of /payloads/library/tools_installer to /payloads/switch1/

 

But before doing that you need to clean any previous installation attempt by logging into the serial console as root and typing :

rm -rf /pentest

 

The explanation of the failure is in the install.sh script. The following line

TOOLSDIR=$(find /root/udisk/payloads/ -name tools_to_install)

returns 2 entries instead of just one.

 

  • Upvote 4

Share this post


Link to post
Share on other sites

Thanks Quack!!!!!! Totally missed that! Worked for me!.

Is it normal that when you plug the USB it gives an error now? It works normal but it gives an error, would it be safe to let windows fix the errors?

Share this post


Link to post
Share on other sites

I don't have any error, maybe you just forgot to safely unplug the bunny ? anyway it's safe to let windows scan and repair the bunny

 

  • Upvote 1

Share this post


Link to post
Share on other sites
On 3/6/2017 at 4:08 PM, rastating said:

I can confirm I also ran into the bug with the tools_installer payload, caused by the line endings. Removed them and tested with a clean slate (i.e. empty /pentest/) and it worked fine via one of the switches.

I've opened up a pull request to merge in the file without line endings here, if anyone wants to grab a copy of the clean file: https://github.com/hak5/bashbunny-payloads/pull/12

I am not seeing where this can be pulled down in this post.

  • Upvote 1

Share this post


Link to post
Share on other sites

I am on Windows 7 64 bit and I cannot get the install_tools payload to run either. Fresh pull down from the github. I saw a post about line feed characters being the cause; but truly removing these makes the entire script one line. Adding the path to the payload does not resolve the problem either; and since the RNDIS driver install fails I cannot get it a network connection so I can SCP the files over manually.

Share this post


Link to post
Share on other sites
9 hours ago, TeCHemically said:

I am on Windows 7 64 bit and I cannot get the install_tools payload to run either. Fresh pull down from the github. I saw a post about line feed characters being the cause; but truly removing these makes the entire script one line. Adding the path to the payload does not resolve the problem either; and since the RNDIS driver install fails I cannot get it a network connection so I can SCP the files over manually.

If you are editing on Windows and are seeing "entire script one line" I highly suggest using Notepad++

I hope this doesn't start an argument over text editors....

To your problem though: The most common mistake so far seems to be copying instead of moving the "tools_to_install" files.  If the script finds two such folders, it seems to get messed up.  Also, check to see if you have a folder /pentest on the BB already.  You may need to remove it before trying again.

As Darren has said repeatedly, this is one of the things that will change in a future (soon?) firmware release.

Share this post


Link to post
Share on other sites

Hi everybody,

I also had the installation problem, but finally found the issue:

after moving the files of "tools_to_install" to "/pentest" the install.sh tests in line 21 if there are no files left in "tools_to_install".

It seems if there are hidden-files in the directory "tools_to_install" (files beginning with an ".", which can only be seen if you use "ls -A" command, which is also used in install.sh), these aren't moved with "mv" command. So there are still files existing in the "tools_to_install" folder and therefore the BashBunny goes to fail state (red LED).

SOLUTION:

Of course you can just change the install.sh and remove "-A" from line 21, but I don't like to change the original Hak5 scripts, so I did this:

  1. change directory to "tools_to_install"
  2. test if there are any hidden files with "ls -a"
  3. if there are, then do "rm .*"
  4. test again, that all hidden files are gone with "ls -a"
  5. if so, your fine to to the installation!

 

I hope this works for you, too!

Share this post


Link to post
Share on other sites

Windows 10, x64. in switch 2 folder i have copied over in arming mode /tools to install dir along with install.sh and payload.txt. Safely ejected. flipped switch to position 2 and red light no go. Fails to install. Must have tried at least 3-4x by now.

 

Not quite buyers remorse, but Kinda depressing to throw down a Benjamin on this and have the vague feeling it was released prior to being polished more upon release. Again mean no offense to darren.  Hope these kinks get worked out and he puts up more tutorials/beginners guide that doesn't rush through everything. As i suggested being able to access a repository directly from the device itself to auto-install scripts with needed dependencies would be great

  • Upvote 1

Share this post


Link to post
Share on other sites

@peterkozmd:

You have to move all files and folder within tools_installer! So your switch folder has the payload.txt & install.sh and a folder "tools_to_install". 

Have you checked for any hidden files in within the folder "tools_to_install" in the switch folder? Please connect to it vie shell in arming mode and check with "ls -a". If there are some, just delete them and try again.

It may also be necessary (as described before by other users) to rm -r /pentest and be sure, that you don't have the "tools_to_install" folder also available within the library/tools_installer.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...