Does anyone know what filesystem the mk2 sd card is meant to be formatted to?

[cader]

I thougth that I would try vfat first because it *should* be able to read it. 

I ran several default payloads as well as one that was just $echo "test" >> /root/udisk/test.txt

The sd has yet to be written to. 

Any ideas?

[chrizree]

well, just try to format it in different ways and see which one that works (fat32, ext4, etc.)

[cader]

Well it's pretty obvious that it needs a vfat (this includes fat 12, 16, and 32) compatable file system for cross compatability. 

If the card is formatted as ext4, attack mode storage just presents the internal storage.

The sd card is never mounted by the BB, it appears it just offers it as passthrough. 

I guess this is *fine* but the total abcence of new feature documentation is a little frustrating on a product launch.

[chrizree]

if it's obvious, why do you ask?

[cader]

Because I was hoping that I was doing something wrong and that passthrough was not the only option for the SD card. 

[cader]

Ya know? Like restricting the device to fat is a little sucky. It would be nice if the sd card was mounted to /root/udisk at attack time like the 1 sentence documentation says it should be. But it doesn't mount at all. If the card isn't a fat fs, the bb just ignores it completely. MEGA LAME.

[chrizree]

what file system do you want then if you don't like ext4 or any FAT variants (VFAT isn't actually a file system type either, it's an extension to FAT12/16 and 32)

[jholbrookftl]

I am seeing similar results, if I put a SD card into this unit the payload runs, however it does not write to the SD card. you can also see the SD card being mounted as a drive in windows.

[Darren Kitchen]

A few key points to note when using a MicroSD card with the Bash Bunny Mark II:

Arming Mode

• Payloads are executed from internal storage only.
• If a MicroSD card is present at boot in arming mode, it will be passed through to the host.
• To load payloads, boot the Bash Bunny without a MicroSD card present.

Payload Modes

• If the STORAGE ATTACKMODE is active, the udisk will be presented to the target as a mass storage device.
  • In the case that a MicroSD card is present, the udisk presented to the target will be the MicroSD card
  • In the case that a MicroSD card is not present, the udisk presented to the target will be the internal udisk partition.
• By default the udisk is not mounted on the Bash Bunny regardless of the ATTACKMODE specified.
• To mount the udisk from the perspective of the Bash Bunny, issue the command `udisk mount`.

Mounting Considerations

• The udisk partition — whether internal or MicroSD — can only be mounted on one device at a time.
• By default in all switch positions the udisk is not mounted on the host (the Bash Bunny itself).
• The /root/udisk directory will appear blank unless `udisk mount` has been executed.
• Writing to /root/udisk when unmounted will have no effect on the actual udisk partition.
• If both ATTACKMODE STORAGE and `udisk mount` are used — unexpected behavior may occur as the partition cannot be handled by both the target and host simultaneously.

Formatting Considerations

• The MicroSD card should be partitioned with a single partition formatted with a filesystem appropriate to the target
  • e.g. for Windows targets: FAT32, ExFAT, NTFS
  • e.g. for Mac targets: FAT32, ExFAT, APFS
  • e.g. for Linux targets: FAT32, ExFAT, EXT
• While the target may support various filesystems, the host (Bash Bunny) currently only supports EXT and FAT32. Additional filesystems (ExFAT) may be included in future firmware versions.

[jholbrookftl]

19 hours ago, Darren Kitchen said:

 

Thanks for the clarification Darren, I'll go and look at the payloads to see if they are referencing this or if I need to update to use them. Also thank you for the info on FAT32 for the BB, i had exFAT formatting and have since changed it to FAT32.

[Irukandji]

42 minutes ago, samarth said:

how to execute payloads from the sd card?

You can't do it yet. I'm not a dev.

[PoSHMagiC0de]

12 hours ago, samarth said:

how to execute payloads from the sd card?

Not supported but we have been talking about the MKII microSD storage on Discord.  To put it procedural like, the BBMKII will never launch a payload.txt from the microSD.  By default, it mounts nandf to /root/udisk.  That is what you see when in arming with no microSD.  This is always the case.  Even in storage with the microSD in, you will see the microSD as USB but internally via the payload.txt context it only has nandf mounted as udisk.  MicroSD will only be mounted to the usb storage gadget driver as the drive, not to the OS.  Now, if you want to turn stuff off the microSD or use it for storage, here is what I am using and came up with.

One way and the non-modify way is after your attackmodes are set...or before and if a microSD is mounted then in the payload.txt put in udisk mount.  This will mount the microSD, if inserted, as udisk.  I do not know what witchcraft is happening here the udisk command doesn't do a umount before mounting so I do not know how the nandf is being unmounted but it happens.

This will make it so if you have other stuff in the payload.txt referencing the /root/udisk, it will now be referencing the microSD.  So, make sure your directory structure is in order.

Second way, involves adding a folder to the /root folder of he BBMKII system drive.  You can create a udisk2 folder under /root on the bunny system drive.  You can then have a mount command to mount the microSD to that udisk2 so your udisk is not replaced.  Now you can reference /root/udisk2 for the second storage to run payloads or (what I use it for) to store loot.

mount_udisk2() {
	if [ -b /dev/mmcblk0p1 ]; then
    	mkdir -p /root/udisk2
        mount -o sync /dev/mmcblk0p1 /root/udisk2
}

 

[PoSHMagiC0de]

On 7/16/2021 at 5:46 AM, samarth said:

 

so the path of sd card is same in every device right? and in short i can store loot and execute payloads from the sd card right? 

could you please also provide a payload executing files from the sd card that will be really helpful as im very confused pls 🙂

Without taking all day to make payloads, here is a quick example.

 

Make a file called qcmd.txt and put it on the root of the MMC card.  You will need to load the BB in arming mode with MMC inserted to do this.

Make a payload.txt file in the root of the switch position on the bunny you are going to use.  You will have to load the BB in arming mode with the MMC NOT inserted to do this part.

Now, the normal way with no modifications with normal operation, here is how the payload.txt should look.

LED SETUP
ATTACKMODE HID
# The below will mount the MMC if it is inserted at the time.
udisk mount
# After mount, nandf (where your payloads are located) will not be accessible from /root/udisk nor the loot of anything for that drive. /root/udisk now points to root on MMC.

LED ATTACK
QUACK /root/udisk/qcmd.txt
LED FINISH

#The above will quack the qcmd.txt you put on the root of the MMC.

 

Now if you want access to nandf still and MMC then that is where my extension comes into play.  Create bash file from the function above in previous post and put in extension folder and keep everything else the same.

 

LED SETUP
ATTACKMODE HID

#Now we are going to mount the MMC into a separate path.
mount_udisk2
#now /root/udisk still contains your nandf drive with all the payloads, extension and what not and MMC is mounted to a new path at /root/udisk2

QUACK /root/udisk2/qcmd.txt
LED FINISH

# The above accesses the quack file that was created from the MMC at its new path.  You can still access what is on the internal nandf with the $SWITCH_POSITION variable and what not but anything on the MMC will have to be referenced directly with /root/udisk2.

It is that straight forward.