Issues getting either Switch 1 or 2 to activate

[Ehrm]

Hi Everyone, 

I am having issues getting my BashBunny to activate on switch 1 or 2, but Arming behaves like normal (I can activate and use the CLI and upload/remove payload.txt files) Basic Troubleshooting so far:

1) Changing Payloads to just the below, this didn't activate for both switches. When I say did not activate I mean it went Green to boot, then went to off or NO LED showing on any switches.

#!/bin/bash

LED R SINGLE
LED C DOUBLE
LED M TRIPLE

2) Tried the Dark_Pyro automation script below to determine what switch I was on: 

#!/bin/bash

clear
echo ""
echo "Testing Bunny switches"
echo ""
echo ""
echo "The output that returns a 0 (zero) represents the current switch"
echo ""
echo "Testing Switch1"
cat /sys/class/gpio_sw/PA8/data
echo "Testing Switch2"
cat /sys/class/gpio_sw/PL4/data
echo "Testing Switch3 (arming mode)"
cat /sys/class/gpio_sw/PL3/data
echo ""

This gave me the Arming mode as a 0, flipping between switches gave me no change because the USB just didn't detect as either a USB drive or Serial. 

3) Arming Mode blinks from Green to Magenta to Blue then just blinks the Blue. I note this because Magenta is not spoken about in the docs for Arming mode. 

4) Ran a Factory reset, pulled the drive out 3 times at Green and it did the BLUE/RED flash for a few minutes. Once it rebooted after being done, I had "Tools" and "Languages" folders but this was all that was on there. 

I've had to make the directories since starting to work on this a week ago, and it has always just opened the explorer window without ever actually executing any payloads. In fact, I had to manually run the two scripts above just to make sure they WOULD run, for sound mind, which was completed with the following commands. 

udisk mount
cd udisk/payloads/switch[1 or 2]
bash ./payload.txt

When this executes, the expected blinking pattern starts, then Stops half-way and locks up on the Cyan colour. At this point I'm quite at a loss, is there something that's caused it to mess up that I have done in the troubleshooting for this? 

This is a MKII and has the 1.7.332 firmware. This was tried on a Windows 11 Device, a Windows 10 1901 Device, a Kali VM, and a Kali bare metal system, no change occurred.

TL;DR:

MKII won't do anything outside of Arming mode, even with no MicroSD inserted. HALP! What did I miss?

[dark_pyrro]

1)
This should be no problem on a fully functioning Bunny. It just indicates that something's not working as intended.

2)
"This gave me the Arming mode as a 0, flipping between switches gave me no change because the USB just didn't detect as either a USB drive or Serial."

When flipping between the switches, did you run the script for each "flip"?

I don't understand the last part of that sentence though "gave me no change because the USB just didn't detect as either a USB drive or Serial". What do you mean when saying that?

3)
This is normal "procedure"
Arming mode = Green > Magenta > Blue blinking
Magenta and the slow blinking blue is controlled by the bunny_framework for arming mode.

4)
That's a bit strange since the Factory Reset procedure should leave the udisk intact/untouched.

Regarding running the payload script manually; what OS did you use when creating the payload? If Windows, you probably have to (at least) take care of the Windows carriage returns since the Bunny doesn't go along well with such in the payload script files if running the payload manually in the terminal of the Bunny (this is if accessing the Bunny while it's in arming mode, it's taken care of "automatically" when running payloads in switch position 1 or 2).
Try something like:
sed -i 's/\r//g' /root/udisk/payloads/switch[1 or 2]/payload.txt
bash -c /root/udisk/payloads/switch[1 or 2]/payload.txt

 

Not sure it helps in any way, but you could try to reformat the udisk using the "udisk reformat" command (with no Micro SD card inserted).

[Ehrm]

Thank you for the follow up on how the Bunny works for Responses 1 and 3

for response 2, I tried to test between flips, however I wasn't able to even access the serial (COM) port for the device when on the other flips as my devices aren't detecting it when flipped on a different switch, thus making it difficult to actually run it between you see. 

As for response 4, the udisk has never seen anything, I'm always having to manually mount the udisk to even get this far, I just thought there was a problem with something in the payloads, but even the basic payload.txt that it comes with isn't giving me the expected LED blinking and USB drive mounting. The default payload of:

# System default payload
LED B SLOW
ATTACKMODE SERIAL STORAGE

As for the manual testing needing to kill the returns, I have been doing it on the two Windows devices, but saving as ANSI (I suspect this is not removing the returns for the Bunny though)

I will reformat the disk again with no SD Card though and see what happens and reports.   

[dark_pyrro]

For (2) you shouldn't reboot the Bunny or anything. You should stay in the same session and run the script. For example; boot the Bunny into arming mode > access the Bunny using serial > run the script with the switch in position 3 (arming mode) > stay in the current/same serial terminal session > move the switch to position 2 > run the script with the switch in the new position > stay in the current/same serial terminal session > move the switch to position 1 > run the script with the switch in the new position. You should see the 0 (zero) move between the switch output when you run the script (if the hardware switch works as it should).

For (4), the udisk is never mounted to the Bunny itself by default. If you are in a terminal session (using either serial or SSH), the udisk directory will always be empty up until you mount it manually from the perspective of the Bunny (with "udisk mount"). The udisk always mounts to the target (if ATTACKMODE STORAGE is used).

[Ehrm]

Alright, so It's been solved by running the factory reset again and then trying to solve with the carriage return issue, I messed up thinking about the ANSI as being a solution to it. Once I set up the payload into nano, it solved the issue, Then went back with sed as suggested it solved it. I also seem to have missed the note around STORAGE needing to be entered into the ATTACKMODE to get it to at least run the payload. 

I may have a few additional questions around HID and injection payloads, but I'll enter it into the appropriate forum. 

Thank you for resolution! 

[dark_pyrro]

Just to avoid any confusion or misunderstanding; it's not mandatory to use ATTACKMODE STORAGE to get payloads working. Payloads should work even without specifying that specific attackmode. It all depends on what you expect/want the payload to do.