Jump to content

Green led blinking


ZZZ_

Recommended Posts

Hi, as you may saw, I had a lot of troubles with my bashbunny.

 

Now, I can access it in arming mode, I can connect to the lil' debian inside, but when I try to run any payload (on switch1 or switch2, it doesn't matter), I only see a green led blinking, and nothing else happen.

 

**

Please, answer to this post only if you can help, I d'ont want this topic to have 45 answers, and not any answer that could help, dev won't care about a topic if there's to much answers

**

 

What i did :

 * Had some problems with install_tools (Input/Output error, everything was in read-only)

 * Used gparted to format the partition where payloads are saved

 * Used windows to make sure that it was formated (someone told me to try it)

 * Copied the loot/payloads/library/switchX directories

 * Bought a rope and a stool, just in case if nobody can help me :happy:

Any dev could have an idea to save me ?

Thx

Link to comment
Share on other sites

This happened to me too (a few times) while developing a payload. Seb and others helped me on irc and I was able to consistently bring my bunny back from this failure state. Here's what I did:

  • Set to arm mode and screen in to bunny
  • Unmount storage from host os (eject)
  • Unmount storage from bunny: `umount /dev/nandf` 
  • Zero out storage: `dd if=/dev/zero of=/dev/nandf bs=4096` (be careful with this one...)
  • Exit and eject the bunny
  • Still in arm mode, connect to a windows pc (mkfs didn't work for me): format the bunny using fat32 (original label "BashBunny")
  • Still in arm mode, screen back into the bunny
  • Make sure drive is mounted: `mount -o sync /dev/nandf /root/udisk`
  • Rebuild directory structure: payloads->(library, switch1, switch2)
  • Copy payload.txt into one of the switch folders
  • Exit and eject
  • Run bb.sh and pause at main menu
  • Flip switch to match the folder you put payload.txt in and plug it in
  • After 5 seconds of a white LED, type 'c' to share the internet connection
  • If you see a solid green light (after a few minutes), everything is back to normal, and you have the newest payloads from github!

This might be fixed as the firmware is updated, but it works for now. 

Link to comment
Share on other sites

On 2017-03-16 at 4:53 PM, Draxiom said:

This happened to me too (a few times) while developing a payload. Seb and others helped me on irc and I was able to consistently bring my bunny back from this failure state. Here's what I did:

  • Set to arm mode and screen in to bunny
  • Unmount storage from host os (eject)
  • Unmount storage from bunny: `umount /dev/nandf` 
  • Zero out storage: `dd if=/dev/zero of=/dev/nandf bs=4096` (be careful with this one...)
  • Exit and eject the bunny
  • Still in arm mode, connect to a windows pc (mkfs didn't work for me): format the bunny using fat32 (original label "BashBunny")
  • Still in arm mode, screen back into the bunny
  • Make sure drive is mounted: `mount -o sync /dev/nandf /root/udisk`
  • Rebuild directory structure: payloads->(library, switch1, switch2)
  • Copy payload.txt into one of the switch folders
  • Exit and eject
  • Run bb.sh and pause at main menu
  • Flip switch to match the folder you put payload.txt in and plug it in
  • After 5 seconds of a white LED, type 'c' to share the internet connection
  • If you see a solid green light (after a few minutes), everything is back to normal, and you have the newest payloads from github!

This might be fixed as the firmware is updated, but it works for now. 

Thanks. I followed those steps and I was able to regain access to the /dev/nandf partition and write to the bunny again. I tried the payload.txt file but it didn't do anything but that was, perhaps, too early in the process. Instead, I moved the payload.txt and payloads that I had copied from the github earlier on. So now, next step is to try to do a few simple experiments to check and see if everything is running. I wish there was a couple tutorials for idiots just to confirm successful operations.  

Link to comment
Share on other sites

I am trying the payload right now @Draxiom. I don't know what's happening as a red light is showing steady (not blinking) It did look sort of white or maybe purple for a bit when it started. I shared my internet connection before (or rather while) I ran the payload. Not sure how long I should wait for the the red light to change,..  It's been about 5 minutes now. I'll come back in 10 minutes and check on it.

after at least half an hour, nothing seems to be changing.  Actually, I haven't had any other  internet traffic so I am wondering if the internet sharing isn't actually internet monopolizing. Definitely seems to be something wrong with this picture. Time to start over (again)

 

 

 

Link to comment
Share on other sites

@michael_motorcycle, if you get a solid red light, you can just unplug it, as it failed and stopped. Are you on pc/linux?

First, test connection:
If on linux, you have to run bb.sh (not on arming mode, and with the correct "attack mode" in the payload for your system) first, to get your internet sharing working. Once you have successfully "connected" (don't forget that last step to type 'c', once you get to the main menu of bb.sh), ssh into the bunny, and test the connection with ping.

Next run the payload:
Unplug everything, and run bb.sh, pausing at the main menu. Plug in the bunny, and wait for about 5 Mississippi's on the white light before typing 'c' in the bb.sh script. It should give you some 'connected' ascii art if you did it right, and a bunch of dots if you did it wrong. If the bunny can detect an internet connection it will go from a white LED directly to an amber light to indicate processing. If no internet connection can be found, it will give you that solid red light. 

Finally:
Verify everything worked, or see what the errors were, by cat'ing the log: `cat /var/log/git.log`

Link to comment
Share on other sites

I just checked my git.log and I am not connecting to the internet. Clearly that's the issue. It's odd because bb.sh sees the bunny and seems to be connecting.  I guess I have a bit more research ahead of me. That's enough for today. I'll start over in a day or two. Thanks for all the help. Any further advice would be greatly appreciated!

Link to comment
Share on other sites

  • 2 months later...

Entering late into this.  Had to backtrace.  So with some fancy maneuvering of switches your Bunny is back.  Before I go try to run full payloads, I would test functionality.  Try editing one of the switch payloads to do just HID and do the hello world default payload people do for the quack commands which is to open notepad and type something and try running it.  If it works, HID works.  Next do one for just the network type for the OS you are connected to and try SSHing into the bunny.  If you are in, network for that part is working.  While inside, use python to launch a SimpleHTTPServer and see if you see it on your host machine through a browser at its port.  If so, definitely network communication between the bunny and the host works.  Only thing left is to troubleshoot the payloads and make sure you have all depend tools installed and bash extensions those payloads use.

Link to comment
Share on other sites

@PoSHMagiC0de ive just recently gotten my BB and have yet to get any payload to work. it just flashes green constantly. ive changed the payload to only change the color of the LED and nothing. still just flashing green. but I suppose I should get the payloads working before tackling the RNDIS driver error. the hid, storage and serial are working fine.

ive tried all the steps above posted by Draxiom. and did a facotry reset just before that. not sure what else to try from here? I feel like I must be missing some thing simple.

 

Link to comment
Share on other sites

I know a lot of the people have been updating their payloads to utilize the newer firmwares over time.  If you are factory reset, you are back on the original so will need to find a 1.0 payload to test payloads.  Check their payload.txt, usually the version of firmware needed to run it is in there.  If you are on the original that is.  If you are going to do a firmware upgrade, remember to be patient with it, have a good connection and power.  It can take 10mins or sometimes more.

Also, if you are having RNDIS driver issue, make sure the payloads you are testing do not use the ethernet attack modes.  Also remember the BB ethernet rule of thumb, RNDIS for windows and ECM for *NIX and Mac.

Last, if first time using BB, experiment on a Windows 7 machine first until you have it down.  Windows 10 has been recently hardened with new protections nullifying some payloads.

Link to comment
Share on other sites

  • 2 weeks later...

@PoSHMagiC0de Thanks for your help. I believe I got it working. I cant seem to crack the hashes yet even with the actual password from the pulled hashes when I got quickcreds to work but thats another issue. I ended up getting the payloads working.

 

I think the green flashing light issue I was having was due to the out of date firmware. so I did the

1. factory reset from hidden partition. by pulling out BB just after boot light turns off.

2. updating firmware to newest firmware.

3. installed tools. (which was a whole other adventure in itself to get to work correctly)

4.  payloads working!

 

Im still having issues with I think the drivers installing? the BB fails payload until 2 or 3 sometimes even 4 re-inserts. but these issues probably belong on the QC post.

Link to comment
Share on other sites

  • 4 months later...

Archived

This topic is now archived and is closed to further replies.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...