Jump to content


Active Members
  • Content Count

  • Joined

  • Last visited

About mrt0mat0

  • Rank

Recent Profile Visitors

2,520 profile views
  1. Yeah, so after hearing about the new firmware release, I've decided to do basically what Dave-ee said. I will also be moving it to an extension instead of modifying the bash bunny software. that way it won't be wiped going forward. I'll let you guys know when I'm all done. I can't guarantee it will work as I plan though. We'll see
  2. I will create a branch soon, and push it. I'm setting up configuration files to allow to enable it so it doesn't always have to be active if you don't want to. that has created a problem, as each payload is actually moved to tmp and ran from there. i'll have to do the same with the config. once i finish all of that, I don't think i'd be able to abstract the whole functionality, but adding a helper would be possible. my initial install breaks up the bash bunny into smaller pieces. once that's done, you could manipulate the listener and the payload activation independently.
  3. yes. that's what it currently does. it saves about 4 seconds from just popping it out. you'd think it would be instant, but it has to disable dhcp, mounts, and all that stuff, so it takes a bit of time. i'm working on speeding it up. I also want to add a feature that will pause the payload until you hit the switch. allowing you to possibly pretend that it's a usb flash drive, and then when they step away, switch it and make it run the payload. still deciding what would be worth doing.
  4. So, I've made a payload to upgrade the bash bunny to allow for switching on the fly. I'm not posting it yet, because it seems that the PRs are piling up and don't want it lost in the shuffle. i currently have it so that it runs the payload on the switch you switch it to, but feel it could eventually be used to register commands to the script. Would anyone find this useful? Any ideas on other uses detecting the switches could do?
  5. a quick and dirty way to force a recovery is to delete the bash_bunny.sh - every time it loads, it deletes a counter that is incremented by the system. if that counter makes it to 3, it will force a recovery from a backup partition. ssh root@ *********** rm bash_bunny.sh
  6. So, the original way the BB works is just fine. copy your files, run. save, done. but why bother copying? With my new "payload" called ConfigPayloads, you can use a config.txt file simply supply the directory of the payload you want to run, and presto manifesto, you're all done. On top of that, the old way left you wondering which payloads you have where. No longer! with one file to show you the directory you are pointing to, you can quickly see your configuration! quickly swap out payloads and easily see which payloads will be ran! The best part is that this change is COMPLETELY BACKWARDS COMPATIBLE! That's right folks! If you want to go back to using the switch1, switch2 folders you can! just rename or remove the handy dandy config.txt and you're right back to basics! Enjoy! https://github.com/hak5/bashbunny-payloads/pull/106 (pull request pending)
  7. the wiki doesn't actually show how to use it. I've seen it done this way: ATTACKMODE HID VID_0X05AC PID_0X021E not even sure if that works. would be nice to have it do an example. hope that helps.
  • Create New...