unixnerd777

One option would be to use the smb server in impacket: python /tools/impacket/examples/smbserver.py e path_to_payloads & where path_to_payloads is something like /root/udisk/payloads/$SWITCH_POSITION This allows you to use the BB as a network device instead of mass storage, I like this better as you don't have to eject it when you're done too. (see https://github.com/hak5/bashbunny-payloads/blob/master/payloads/library/credentials/DumpCreds/payload.txt)

There isn't too much that can be done with most android devices. There is a payload for the Amazon Fire TV (runs android). There is only 1 payload for android and all it does is opens a URL in the default browser. Android is difficult given there is such variety across the various versions. The Fire TV payload works because the Fire TV interface is the same across all of their devices. For example, I tried creating a payload to enable developer mode, and it works on my phone, but not an older tablet. I think the closest that will be possible to this is after someone enables developer mode, then have the BB run adb commands against it. While this isn't perfect it is quite handy - enabling USB debugging isn't too difficult to do and is fairly quick to do. Another caveat with android is that there isn't any (on most devices) ethernet drivers, so adb won't work either (the Fire TV has ethernet drivers, so adb works with the Fire TV as it requires the device work with ethernet)...

You won't be able to write directly to /root/loot, and I'm guessing you don't actually want to as /root can only be accessed from the BB side (via serial or SSH for example). I'm guessing you mean the root of the BB as it's mounted as a STORAGE device (flashdrive). If you're running firmware 1.3 (IDK about previous ones, I think this works back to 1.1?) there is a variable $SWITCH_POSITION that can be helpful too, for example, in a payload.txt script to put a file (filename) in the loot folder on the root of the flashdrive, you would write to this: /root/udisk/loot/filename if you wanted to write to the switch folder (where you put payload.txt), then write to this: /root/udisk/payloads/$SWITCH_POSITION/loot/filename. If you are wanting to write to a loot folder on the flashdrive from a Ducky Script instead of from the payload.txt, then you will need to know which OS you are running on. For example, on mac, you can probably write to /Volumes/BashBunny (assuming no major OS changes). On windows, you will need to run some powershell (most common) to figure out what path to write to: (gwmi win32_volume -f 'label="BashBunny"' | Select-Object -ExpandProperty DriveLetter) On linux, you may be able to write to write to this, but it depends on the flavor of linux: /media/`whoami`/BashBunny

I guess I didn't look hard enough, I asked about this after you did: TLDR; use ATTACKMODE RNDIS_ETHERNET RNDIS_SPEED_10000

I'm running OSX Sierra w/Chrome 58.0.3029.110 and mine is here: ~/Library/Application Support/Google/Chrome/Profile 1/Cookies (in the home folder, not the root Library. Also, keep in mind most people will only have 1 profile, so it'd probably be "Profile 1" for most instances. I'd recommend grabbing the entire ~/Library/Application Support/Google/Chrome folder.

I believe that runs automatically with payloads, given you can access /root/udisk/* during a payload.txt script. When you connect the BB as storage (or arming mode) it exposes /dev/nandf as a USB storage device to the computer it's connected to. That command is useful if you're in arming mode and need to access the USB storage from the BB itself (I.E. over serial or SSH). The -o sync part means when you change something on the BB side, it will write it right away instead of waiting a bit. This helps if the BB was unplugged without unmounting/ejecting safely (umount /root/udisk), it doesn't guarantee that there won't be any problems, but it helps. [EDIT]: it does auto-mount /dev/nandf to /root/udisk (see below): /dev/nandf on /root/udisk type vfat (rw,relatime,sync,fmask=0022,dmask=0022,codepage=cp437,iocharset=ascii,shortname=mixed,errors=continue)

That is exactly what I was looking for, thanks. Yes, the powershell works and I'm using powershell with this payload, but if I wasn't the RNDIS_SPEED will do what I want w/out needing to use powershell. I wonder if RNDIS_SPEED_10000 could be added to https://wiki.bashbunny.com/#!payload_development.md, that way others who are developing for the Bunny would know about it too. I wonder what other flags it supports that aren't (yet) on the wiki...

When I connect the Bash Bunny with ATTACKMODE RNDIS_ETHERNET it sets itself as a default network interface, which is desired in most cases. However, I would like it to show up as a secondary interface as part of my payload requires actual internet. Since the Bash Bunny doesn't have internet itself, it can't provide internet to the windows box. It would be nice if I could configure the Bash Bunny to show up as a non-default interface. It is possible to change the metric in powershell, so if my payload uses powershell, I can do this to change it: Get-NetAdapter | Where-Object -FilterScript {$_.LinkSpeed -Eq "2 Gbps"} | Set-NetIPInterface -InterfaceMetric 100

Thanks, given it's range, I think I'll get a HackRF; then if I can't figure it out, I'll get the YARDstick. I like episode 1912 "How to hack radios with brute force attacks." and would like to attempt the same.

I'm wanting to get into some of the RF world, I have a NooElec R820T SDR and a Baofeng UV-5RAX+ (w/my technical license). I'm looking at the HackRF and the YARDstick, can the HackRF do (almost) everything the YARDstick can? If the HackRF encompasses the YARDstick's frequency ranges, should I just get the HackRF or is there some things you can't do with the HackRF that you can do with the YARDstick?