Scriptmonkey_

Thanks, I was using a pin and it just kept missing it or slipping off 🙂 Wrote up the recovery guide into another thread but yeah, looks like firmware upgrade is basically scp firmware file to /root/ boot cycle it into arming mode and wait for LEDs to stop doing the hokey cokey.

Well... snifflebiscuits. I believe I've done did broke it. Lost network connectivity as the file was transferring (not sure why, it was there, I wasn't touching it, just SCP stopped transferring the file and said connection reset by peer). Next boot, I can only assume it tried to take to the partial file that I'd uploaded and appears to have flashed that. All switch modes are unresponsive. I don't suppose there is a "Users Be Stupid, Factory Reset" magical on-off-switch-button combination in order to restore the firmware? Edit2: I've actually managed to recover this myself. I've taken the liberty of writing up the procedure I took in a forum post and deleted some of my posts from here as it was just cluttering up the place.

Can confirm I'm getting the same issue. Edit: Don't think I need to do it manually. Reviewing the binaries on the host I found /usr/bin/shark_framework which has some interesting lines in. Looks like if you copy the firmware file to /root/, have the switch in arming mode... it'll autodetect and apply the firmware. #!/bin/bash SWITCH_POSITION=$(/usr/bin/SWITCH) MODE="OFF" UPGRADE_FILE=$(ls /root/upgrade-*.bin 2>/dev/null | tail -n1) LOG="logger -t Shark [*]" LOG_ERR="logger -t Shark -p 3 [!]" function upgrade_leds() { /usr/bin/LED OFF while true do echo 1 > /sys/class/leds/shark:red:system/brightness sleep 0.2 echo 0 > /sys/class/leds/shark:red:system/brightness echo 1 > /sys/class/leds/shark:blue:system/brightness sleep 0.2 echo 0 > /sys/class/leds/shark:blue:system/brightness done } function execute_upgrade() { $LOG "Checking for firmware upgrade" [[ -f $UPGRADE_FILE ]] && { $LOG "Firmware upgrade found" upgrade_leds & led_pid=$! cp $UPGRADE_FILE /tmp/upgrade.bin rm $UPGRADE_FILE sleep 2 && kill $led_pid $LOG "Executing UPGRADE" /usr/bin/LED B && echo "sysupgrade -n /tmp/upgrade.bin" | at now exit } || { $LOG "No firmware upgrade found" return 1 } } <snipped> Giving it a shot now.

Oof! So more of a look into it, Looks like duckyscript doesn't actually have any control flow features? I can't do tests or loops? Eesh. The HID mode on the BB doesn't require ducky script only does it?

So I was in a similar situation. 1. BashBunny info populated as per the OP screenshots - You're correct, the RNDIS Ethernet adapter comes above the wifi in the stack and OSX sets the BB as the default GW for the machine, no internet for anyone but you can ssh to the BB just fine. Correcting the derp with a route -n delete default gw 172.16.64.1 command and netstat -nr confirming the routing for IPv4 is correct at least, still does not restore the internet however for some unknown reason. What did fix it... hitting "assist me" in the network settings dialog and allowing it to configure the wifi network as an internet connection. That then reordered all my network adapters in the graphical listing of the network settings pane and now I can plug the BB in without losing internet on the host. However, despite following all the instructions in the OP and deleting the crazy route for the default gw to 172.16.64.64 on the BB and replacing it with a 172.16.64.10 (the ip of my mac) still doesn't give me network connectivity. No idea why the ip on the BB for its default route is 64.64 either. Would definitely appreciate any help trying to get this working, would like to update the OS.

So managed to win a Bash Bunny as a prize in a CTF competition at a local conference over here and its day 1 of ownership. Have upgraded the firmware to version 1.3 and having a blast playing about with it over the serial console. I was thinking of porting a payload I use based on work I did with an old friend of mine called "Blinking Hell" (http://blog.scriptmonkey.eu/bsides-london-2013-blinking-hell-extracting-data-using-keyboard-lock-states/) which allows for export of data via the "lock" keystates. I'd say we got there first in 2011 using a teensy, but we didn't go public until 2013 :'( and it kinda just got left in the weeds other than our own private developments as we were using it in a very niche manner to suit our work. Any way bitter tears aside :) I'd like to port it over to the bunny. I've had a good root about using google and searching the forums and cannot see for the life of me how I can create ducky script to read the state of the various "lock" keys. I see people talking about it happening and asking "if it can" but no idea "how" to do it. I am assuming from reading the ducky script git pages its going to be some obscure command that isn't covered in the usual manual/howto. Cheers!