Jump to content

Tylor B.

Active Members
  • Posts

  • Joined

  • Last visited

Everything posted by Tylor B.

  1. Okay, I was looking at this attack more, first I fired up a wireshark, and listened while I turned on on off the robot, pair and disconnected them, and sent controls. I was able to find lots of garbled packets, things that were kinda regular with off/on actions, I was doing this at school where the network situation is terrible, there was a lot of background noise, and it was hard to find what was VEX and what was not. When we were at competition our robot did end up disconnecting during the match, and they just said too bad, you do not get any points this round because the protocol is bad, and that took up from 3rd place to 5th and top 4 advance. We think this is because interference with other robots, with like 20 teams they started disconnecting, this makes me think they may only have one mac address just on different channels or subsets? this makes me think a deauth attack would work, and I will look into packet attacks, man in the middle attacks, arp DoS, deauth DoS, and hopefully the take another robot/replay attacks!
  2. Hello people, I was recently doing some work with those VEX Robotics wireless control robots and I had some ideas about packet sniffing attacks, replay attacks, man in the middle attacks, and de-authentication attacks. The robots use the Vex cortex, which has a wireless adapter through a USB port, it says that is is 2.4 GHz, and another USB wireless adapter is plunged into a controller, like a joystick. My school did a competition with these robots, and it ended last week, now we are doing another thing just as a school, they said we were doing battle bots. When I did some research I hadn't seen anybody do anything like this and I though I would look into it. When I was doing research I found that, the robots don't use any encryption it is end to end, the controllers or create there own network an access point that the robot connects to, the network it creates is hidden it does not broadcast its SSID and has to be pared with the cortex, they are 2.4 GHz, they all have independent channels or mac addresses (many can operate at the same time without interference). The first thing I though of would be a deauth attack, where I would send out deauth frames to disconnect their robot from the controller from the cortex leaving their robot powerless, I was tinging I could do this with Aircrack-ng, put my wireless card into monitor mode with airmon-ng, find the mac address and channel of the robot with airodump-ng, deauth with aireplay-ng. The next attack I though of was if I could intercept packets from the remote to the cortex and either replay them to keep doing an operation or send in my own by finding out what commands correlated to what packets and injecting them while impersonating the robot. I have not done much with packet sniffing/replay/injection if anybody knows anything on how I could do that? or if anybody has done anything with these robots? or if you have any ideas on wireless attacks? I am all ears and I would love help and suggestions, this seems like a really cool project. I would love to hear your thoughts, thank you
  3. @terrier Was the LED working before the firmware loss and attempted recovery? If not you could try checking the pins with a Multimeter to check for continuity on the light and to check for any other physical damage, also try changing USB ports to check if there is a problem with the current draw. Also can you run a payload just LED and then the colors?
  4. If switching it back and forth does not work you could try to launch it and route it into a VM then restrict privileges to induce kernel panic, do not have mine yet but just an idea.
  5. I have not received my bunny yet (march 10th batch) but had an idea for this, because of the limited space on the bunny 8 GB SSD would it be possible to reroute the loot file directory onto another usb drive then cd /media/usr_name/drive_name/loot then store files on the other larger/faster driver? would have to have a variable for the usr_name then once found use that to cd onto the other drive I will try to develop farther once I receive mine but anybody got any ideas for this?
  6. I'm not sure but it doesn't look like there is a reset button but you could probably force it to fail to boot three times then it will reset automatically.
  7. I was wondering a few things about the Bunny's hardware, first is there any way to get more than 8GB of storage? Second if there is anything like the SD card slot on the Ducky or any other ports, hidden buttons, debugging pins, or any other notable way to interact with it other than the USB, light, and switch? And thirdly I was wondering if it is possible to get a look inside the Bunny? is it possible to open it like the Ducky's inconspicuous carrying case? and if it is sealed shut do you have any way to give us an inside look at the hardware? Thanks.
  8. It is like the USB rubber ducky in how it can act like a keyboard to exploit the computers trust in humans but it can leverage that to do much more. Along with pretending to be a keyboard it can pretend to be other devices: an Ethernet over USB adapter, a serial port and a storage device. Because of this it can preform more and more complex attacks. It is also a fully functioning computer unlike the duck and can have multiple payloads. Just for keystroke injection the duck is better because of faster times and smaller size. Ducky pros, smaller, faster, more inconspicuous (looks like your standard flash drive), cheaper. Ducky cons, needs payloads as inject.bin files made with duck encoder, only an HID keyboard, not a fully functional computer, only one payload (but can have multiple mico SD cards). Bunny pros, can act as many devices, can have multiple payloads, fully functional computer, programmed in text (not inject.bin), indicator light. Bunny cons, big unlike most flash drives, slower than the duck to start. It is better because it can do many things the duck cannot, even with the seven second delay it can do most everything the duck can. It can act as a replacement for the duck but the ducky is still better if you only plan to use it for keystroke injection. It is still worth it at least to me to have both this and The USB Rubber Ducky because of the strength's and weaknesses of both.
  9. You can use it like a HID keyboard like the ducky but it can also act as: Ethernet over USB via RNDIS or ECM, a storage device like a normal flash drive, a serial port and connection, and a human interface device like The USB Rubber Ducky. It is also a fully functional Debian based Linux box and can be programmed in a text editor not needing to be encoded to an inject.bin file. It has a three phase switch the first being arming/computing the second and third are spaces for payloads. It can also act as a "Pineapple core" where it interacts with the WiFi Pineapple.
  10. _____ _____ _____ _____ _____ _____ _____ _____ __ __ (\___/) | __ || _ || __|| | | | __ || | || | || | || | | (='.'=) | __ -|| ||__ || | | __ -|| | || | | || | | ||_ _| (")_(") |_____||__|__||_____||__|__| |_____||_____||_|___||_|___| |_|
  11. From the video it looked like you have two attack vectors and an arming mode, not sure if you could change ATTACKMODE after defining it to use multiple trusted devices in one payload.
  12. Yeah its on the store and 2 videos sale for $99.99 normal $119.99,
  • Create New...