Hi all,
I’m trying to deliver a USB payload in a windows BIOS enviroment but the Flipper Zero is not recognized in the BIOS enviroment. The payload script works fine when the pc is booted up, but the Flipper is not recognized at all by the laptop when in BIOS. It’s an HP Elitebook 850 G6. Does anyone have any ideas? All feedback is welcomed!
BadUSB is just a Keyboard for the system. No difference if you are in Linux, Windows or the BIOS.
On one hand the BIOS could have a security option, to allow only a specific Vendor:Device ID. On the other hand maybe you need special Character input …
In every case, you gave us very little to work with. What is your expectations as answer? A fully working BIOS control RubberDuck script?
My suggestion to get a better answer:
Have you tried using an external keyboard attached via USB while in the BIOS? My first guess is that the BIOS may only be accepting keyboard inputs from the laptop’s built in keyboard.
An external keyboard does seem to work
Ok… It’s my first time on this forum and also the first time I’m trying to work with BadUSB scripts… I’m sorry if you found my description to be insufficient, but I think inexperience is to blame.
The BIOS is HP R70 Ver.01.03.00 with release date 09/12/2019 But the issue is with every HP BIOS environment I tested.
Here is the BadUSB payload I made, It’s supposed to fill out the BIOS password and press enter which does work in a logged in computer:
REM first attempt delivering BIOS payload
DELAY 750
STRING Bal00n1!
DELAY 500
ENTER
I obviously changed the password before posting, but that shouldn’t make a difference
Okay, understood, for the BIOS password it should be easier to reproduce. Unfortunately I don’t have any system with me right now.
But one question to the timing:
Right?
I don’t know if it is important for the BIOs if the kbd is plugged in already or will be plugged in during the dialog. We need to check this first.
There is some simplified USB HID boot protocol, and and many BIOSes rely on it, and if Bad USB does not implement it it won’t work.
Sounds interesting, Dou you have a source for this?
In my understanding there is a USB HID support over the USB chipset in the BIOS, that is accepting any keyboard. And BadUSB is just any keyboard.
I don’t see the point where BadUSB needs to support BIOS keypress different from the system keypress.
I am really interested in learn more about this.
Interesting read. It should be seen with a logic Analyzer if the boot protocol is supported. I’ll try to connect my flipper at home.
Since it is common knowledge, maybe I am too uneducated. This was new for me.
I’ve tried it at my Lenovo, and indeed, Load the BadUSB script works, hit run and the display says ‘Wait for connection’, until the Boot will reach the LUKS Passphrase.
So, BadUSB can enter the LUKS boot password, but not in BIOS. Not even during the setup of the password.
The solution would be, to implement BIOS USB HID in Flipper BadUSB. Does not sound easy to me.
Of course, knowing the search keyword requires prior experience.
However, ‘USB HID boot protocol’ is not obscure, there is a lot of documentation about it on the web.
Yes, right. It is written as well in your reference link. Bios USB HID is simpler as the system USB HID …
But not in my talents to write such low level code.
It’s nothing difficult, there is just a lot of details that you have to read from the specification and then put into code so it takes some time. You will probably want to have a debugger available, too.
Looking at the device description it indeed does not support boot protocol:
Bus 003 Device 120: ID 1234:5678 Brain Actuated Technologies Keyboard
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 239 Miscellaneous Device
bDeviceSubClass 2
bDeviceProtocol 1 Interface Association
bMaxPacketSize0 8
idVendor 0x1234 Brain Actuated Technologies
idProduct 0x5678
bcdDevice 1.00
iManufacturer 1 Apple
iProduct 2 Keyboard
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x0031
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xc0
Self Powered
MaxPower 100mA
Interface Association:
bLength 8
bDescriptorType 11
bFirstInterface 0
bInterfaceCount 1
bFunctionClass 0
bFunctionSubClass 0
bFunctionProtocol 0
iFunction 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 3 Human Interface Device
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
HID Device Descriptor:
bLength 9
bDescriptorType 33
bcdHID 1.00
bCountryCode 0 Not supported
bNumDescriptors 1
bDescriptorType 34 Report
wDescriptorLength 138
Report Descriptors:
** UNAVAILABLE **
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0010 1x 16 bytes
bInterval 2
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0010 1x 16 bytes
bInterval 2
Device Status: 0x0000
(Bus Powered)
And a device that does has two descriptors, one for boot protocol and one for the full hid protocol:
Bus 003 Device 006: ID 258a:0049 BY Tech Gaming Keyboard
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x258a
idProduct 0x0049
bcdDevice 1.01
iManufacturer 1 BY Tech
iProduct 2 Gaming Keyboard
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x003b
bNumInterfaces 2
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xa0
(Bus Powered)
Remote Wakeup
MaxPower 500mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 3 Human Interface Device
bInterfaceSubClass 1 Boot Interface Subclass
bInterfaceProtocol 1 Keyboard
iInterface 0
HID Device Descriptor:
bLength 9
bDescriptorType 33
bcdHID 1.11
bCountryCode 0 Not supported
bNumDescriptors 1
bDescriptorType 34 Report
wDescriptorLength 67
Report Descriptors:
** UNAVAILABLE **
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0008 1x 8 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 3 Human Interface Device
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
HID Device Descriptor:
bLength 9
bDescriptorType 33
bcdHID 1.11
bCountryCode 0 Not supported
bNumDescriptors 1
bDescriptorType 34 Report
wDescriptorLength 227
Report Descriptors:
** UNAVAILABLE **
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0010 1x 16 bytes
bInterval 1
Device Status: 0x0000
(Bus Powered)
For anyone interested, here a snippet of code of how it was implemented with the USB Boot Protocol: