The STM32 has a read-out protection level 2 feature adjusted from ST-LINK Utility App (Options Bytes) so code cannot be read out via the debug interface (SWD) or any other way.
There was an explanation,ST Electronics website. I tried the proposed app named as Device Firmware Update (DFU). However, it did not work.
This is the MCU I work on.
In read out protection, Level 2 is selected and applied. After that, MCU cannot be seen or communicated.
RDP Level 2 can't be disabled.
It is in a permanent state, debug interfaces are disabled, the factory bootloader is disabled.
In RDP L2 only a custom bootloader (ie code running from the chip FLASH memory) can modify the FLASH, But it cant disable the protection.\
You need to physically replace the microcontroller. At the moment your board is bricked and there is no way of unbricking it
Related
ThunderBolt firmware is stored in its own SPI flash and is updatable from the OS. The system's UEFI firmware is also able to access its configuration data in the flash - users are able to change the ThunderBolt Security Level (SL) from the firmware setup menu during pre-boot. This means there is definitely some way to access the ThunderBolt firmware via some UEFI protocol, but nothing I've tried seems to work.
What I've Tried
I'm able to successfully identify the ThunderBolt device based on its vendor ID and device ID using the EFI_PCI_IO_PROTOCOL.
I initially thought the firmware is an option ROM, so it should be accessible via EFI_PCI_IO_PROTOCOL.RomImage. However the value is 0. I then thought the Expansion ROM Base Address Register (XROMBAR) that's inside the PCI Configuration Space may have it. But the XROMBAR is also 0. Extracting the firmware by reading the SPI flash using a hardware programmer, I found that it doesn't have the option ROM's signatures of 0xAA55 and "PCIR" anywhere. So it seems like the firmware is not an option ROM.
I then thought it could be stored in a firmware volume and thus should be accessible via the EFI_FIRMWARE_VOLUME2_PROTOCOL. I searched through all the firmware volumes and found a few option ROM, but none of them belong to ThunderBolt (as seen from their vendor ID and device ID).
Background
I was looking at the ThunderSpy exploit and the report states that the ThunderBolt firmware is not verified during boot. I thought this was unusual since my thinking then was that the firmware should be an option ROM, and option ROMs must be signed and verified by Secure Boot during every boot. From my findings so far, it seems like the firmware isn't an option ROM and is most likely executed directly on the ThunderBolt controller chip and not on the CPU, hence it is outside the purview of Secure Boot. I'm trying to programmatically access the firmware so as to see if there are ways to defend against ThunderSpy-like attacks where malicious modifications were made to the firmware.
I want to know who fills the configuration space of a particular device of PCI
at the first place when a new device is connected to the PCI bus. I know both bios and operating system can configure the PCI space but who gives the information of the device to both of them.
The read-only fields of the PCI configuration space, identifying the device and its capabilities, are built-in to the device, not filled in by software.
Some fields, such as the BARs, are configured by the BIOS, as part of its responsibility to set up the address map of the system. The rest of the fields are programmed by the OS or the device driver. (The BIOS may also have a driver for the device, if the device may be used to boot the system.)
Decisions of these three software components (BIOS, OS, and driver) are based on rules and policies built into the software by its designers and/or configured by the system installer or user. For example, BIOS setup menus often have settings to control where the BAR regions may be placed. In Windows, information used to configure devices may come from the registry.
I am designing a USB keyboard with special capabilities. What information can such a HID device receive from the host?
Can I via USB:
Read data from a form on the screen?
Find out what OS the user is on?
Find out if there's been an error message?
Even 'know' what's going on visually on the screen, i.e. what program is selected or whether the program is windowed or fullscreen?
Thank you!
The device can't get any of this information from a standard driver that the operating system supplies because that would be a security issue. It can receive any information that your own driver or application sends it. There are many ways to communicate with it - your device could present multiple interfaces (which will appear as separate devices), multiple endpoints, or use the control channel. You will definitely need to study the spec, and I also found this tutorial helpful.
I have done something similar and used the control channel to exchange feature data with a Windows application (over the standard Windows driver). On Windows, the API calls are HidD_SetFeature() and HidD_GetFeature().
On the device side, my hardware ran embedded Linux and I used the GadgetFS library to create a user-mode driver - much easier to debug than a kernel driver.
As others have said, you'll run into issues if you try this with a normal HID. However, there is a project called the USB Rubber Ducky. From their description:
The USB Rubber Ducky isn't your ordinary HID (Human Interface Device).
Coupled with a powerful 60 MHz 32-bit processor and a simple scripting language
The USB Rubber Ducky looks like a usb-device and is recognized as a HID, but is programmable. You can make a small script that will be typed onto the screen which will allow you to performs the queries you seek.
With the USB Rubber Ducky you can:
Read data from a form on the screen? Yes
Find out what OS the user is on? Yes
Find out if there's been an error message? Yes
Even 'know' what's going on visually on the screen, i.e. what program is selected or whether the program is windowed or fullscreen? Yes
If you aren't hoping to buy this device, at least their firmware is on github so it can provide you a starting point
I have some starter kit board based on Atmel ARM926 400MH. Powered by linux.
And I need to control power of USB, i.e. switch it off and switch it off.
I try to research for use sysfs, but there is no information about switching on/off.
You either can’t control USB power, or the OS will control it for you. As noted in this comment, “... users shouldn't be conscious of this layer.”
Port power might be hardwired to be always present, but more often hardware allows control by the driver. One example I’ve seen, host port through a 3320 USB PHY should have port power automatically enabled by CPEN output.
This area was enhanced with runtime power management framework introduced in 2.6.32 kernel. Details can depend on SoC and specific board support. New features can allow user space control to prevent auto suspend and resulting powerdown; otherwise, by default, USB should power down in suspend modes.
Lots more info in Regupathy.
I'm trying to create an app which powers an external accessory but I am not sure how to do it. Any hints or ideas?
All i plan on doing right now is have a UIView app that sends power to an external accessory.
Is this something that you would even code?
I would have thought that you just have a small amount of power to the device, regardless of the software running on the iphone/ipad/itouch.
That's going to be tricky and probably not in the scope of coding. First, you'd probably need to be a member of the Apple Made For iPhone (MFi) program and have to build your device to work in those specs.
Then you'd need to have the iOS device become the master USB device and your device become a slave (if I remember my USB controller configurations correctly - it's been 6 years).
But your first step is to get into the MFi program.
http://developer.apple.com/programs/mfi/