Drive Badger: open source platform for covert data exfiltration operations, ranging from small computers to big servers.

contact@drivebadger.com

USB ports in HP ProLiant server are not working (or not bootable)

HP servers (all except HP Microserver G7 and G10) have the option to either completely disable all external USB ports, or disable the option to boot server from them.

Solution: go to BIOS settings (press F9 during boot) and check these 2 options:

 

Kali Linux can't detect any drives except itself and possibly DVD reader

This problem is related mostly to HP Smart Array P410 RAID controller. Fortunately, this controller is used almost exclusively for Windows+RAID1 configurations.

Solution 1: open the server front panel and remove the drive(s). Connect them to normal desktop computer and run Drive Badger there:

  • drives being part of P410-managed RAID1 should be seen as normal standalone drives (if you connect both of them, data will be exfiltrated twice)
  • drives being part of P410-managed RAID0 should be also seen, when both are connected - also manual RAID rescan using mdadm tool may be required
  • drives being part of other configuration may require additional. manual reconfiguration, which would prevent them from working with P410 anymore - so instead of trying to exfiltrate them in-field, better just make block copies of them, and reassemble into working RAID later

Or, if you don't have another computer available, connect them to Mobile Badger (if you have SATA-USB bridge with external power).

Solution 2: download and install the latest version of ssacli package from this page (latest version here), and try to assemble the original RAID manually (don't try this, if you don't know this tool).

My console on HP ProLiant ML110 G7 gets flooded with lots of error messages:

DMAR: [DMA Read] Request device [01:00.2] PASID ffffffff fault addr f1fe4000 [fault reason 06] PTE Read access is not set
DMAR: DRHD: handling fault status reg 2
dmar_fault: 18311 callbacks suppressed

Solution: switch to root on console, and run:

sysctl -w kernel.printk="3 4 1 3"

This won't fix the source problem, but should stop further flooding the console.