RPi support - PCILEECH: Failed to connect to the device. on raspberry pi

[xssuser]

hi ufrisk I used pciescreamer R02,When i running pcileech under Windows, everything was fine.

and I compiled pcileech,leechcore,ft60x under the raspberry pi

lsmod uio_pdrv_genirq 16384 0 uio 20480 1 uio_pdrv_genirq ft60x 20480 0 ip_tables 24576 1 iptable_nat x_tables 32768 2 ip_tables,ipt_MASQUERADE ipv6 425984 18

============================================================ lsusb Bus 001 Device 009: ID 0403:601f Future Technology Devices International, Ltd Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp. SMC9514 Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

============================================================ Once an pciescreame device is inserted the driver will create a device object in /dev/ft60x0

root@raspberrypi:~/pc/files# ls -al /dev/ft60* crw-rw-rw- 1 root root 180, 192 Apr 1 09:45 /dev/ft60x0

============================================================

when i run "./pcileech kmdload -kmd win10_x64"

give me "PCILEECH: Failed to connect to the device."

what's wrong?

By the way, how do you run pcilceech on Android, like linux? Also use ft60x?

Waiting for a reply. Thank you.

[ufrisk]

Can you please try and run: ./pcileech kmdload -kmd win10_x64 -device fpga -v and let me know the output. I haven't tested on RPi, but I assume it should be the same as any other linux.

I supported Android for USB3380 hardware, but I removed it in version 4.0 since it took work to keep it maintained and it wasn't really used.

Also as a sidenode, the win10_x64 signature is nowdays rather unstable on recent Windows 10 versions. win10_x64_2 works much better - but it requires Windows on the attacker side since it relies on the Windows-only MemProcFS vmm.dll to analyze the system before mounting the DMA attack.

[xssuser]

root@raspberrypi:~/pc/files# ./pcileech kmdload -kmd win10_x64 -device fpga -v

DEVICE: FPGA: ERROR: Unable to retrieve required functions from FTD3XX.dll [0,v0.0,0000] Failed loading LeechCore v1.0.0 PCILEECH: Failed to connect to the device.

FTD3XX.dll .............

[ufrisk]

Thanks, the ftdi message is just a bad error message - but it was helpful in localizing the error. I basically have a windows compatibility layer that emulates / acts as a facade around the Linux APIs for things like the Windows calls LoadLibrary and GetProcAddress.

The issue is most likely that your RPi OS is 32-bit. can you please confirm this is the case

---

If you're running 32-bit the issue is that:

32-bit is just not supported at the moment.

The issue here is (most likely) that I'm assigning a 64-bit "magic" value into a HMODULE which is defined as void* which is 32-bit on x86/ARM32.

Now I believe that it should work on a 64-bit Linux running upon the RPi. The HW is 64-bit capable but the Raspbian OS is not from what I understand. It would be interesting if you could confirm that this is your issue.

Also I suspect there are more places in which pointers need to be fixed both in the PCILeech and LeechCore projects. There is probably some work, not a huge work - but more than a little, to get it to work with 32-bit - if there is a real need for it I might be able to look into it at the end of May at the earliest.

[xssuser]

root@raspberrypi:~# getconf LONG_BIT 32

I'll test x64 and tell you later

[xssuser]

root@rpi3:~/pcileech-4.0/files# getconf LONG_BIT 64 root@rpi3:~/pcileech-4.0/files# ./pcileech kmdload -kmd win10_x64 -device fpga -v

Segmentation fault

what's wrong?

[xssuser]

(gdb) b oscompatibility.c:FT60x_FT_Create Breakpoint 2 at 0xaaaaaaaad0f0: oscompatibility.c:FT60x_FT_Create. (2 locations) (gdb) r The program being debugged has been started already. Start it from the beginning? (y or n) y Starting program: /root/pcileech-4.0/files/pcileech kmdload -kmd win10_x64 -device fpga -v [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1".

Breakpoint 1, main (argc=7, argv=0xfffffffffb88) at pcileech.c:233 233 result = DeviceOpen(); (gdb) c Continuing.

Breakpoint 2, FT60x_FT_Create (pvArg=0x0, dwFlags=16, pftHandle=0xaaaaaaae2e78) at oscompatibility.c:183 183 CHAR szDevice[12] = { '/', 'd', 'e', 'v', '/', 'f', 't', '6', '0', 'x', '0', 0 }; (gdb) s 184 for(i = 0; i < 4; i++) { (gdb) s 185 szDevice[10] = '0' + i; (gdb) s 186 result = open(szDevice, O_RDWR | O_CLOEXEC); (gdb) s __libc_open64 (file=0xfffffffff7a8 "/dev/ft60x0", oflag=524290) at ../sysdeps/unix/sysv/linux/open64.c:40 40 ../sysdeps/unix/sysv/linux/open64.c: No such file or directory. (gdb) s 48 in ../sysdeps/unix/sysv/linux/open64.c (gdb) s FT60x_FT_Create (pvArg=0x0, dwFlags=16, pftHandle=0xaaaaaaae2e78) at oscompatibility.c:187 187 if(result > 0) { (gdb) s 188 *pftHandle = (HANDLE)(QWORD)result; (gdb) s 189 return 0; (gdb) s 193 } (gdb) s DeviceFPGA_InitializeFTDI (ctx=0xaaaaaaae2e00) at device_fpga.c:253 253 if(status || !ctx->dev.hFTDI) { (gdb) s 257 ctx->dev.pfnFT_AbortPipe(ctx->dev.hFTDI, 0x02); (gdb) s FT60x_FT_AbortPipe (ftHandle=0x3, ucPipeID=2 '\002') at oscompatibility.c:214 214 return 0; (gdb) s 215 } (gdb) s DeviceFPGA_InitializeFTDI (ctx=0xaaaaaaae2e00) at device_fpga.c:258 258 ctx->dev.pfnFT_AbortPipe(ctx->dev.hFTDI, 0x82); (gdb) s FT60x_FT_AbortPipe (ftHandle=0x3, ucPipeID=130 '\202') at oscompatibility.c:214 214 return 0; (gdb) s 215 } (gdb) s DeviceFPGA_InitializeFTDI (ctx=0xaaaaaaae2e00) at device_fpga.c:259 259 pfnFT_SetSuspendTimeout(ctx->dev.hFTDI, 0); (gdb) s

Program received signal SIGSEGV, Segmentation fault. 0x0000000000000000 in ?? () (gdb)

[ufrisk]

Thanks. So ARM64 isn't working either.

I'm going to have to look into this myself for reasons so I'll most probably look into getting this to work on the RPi - probably 64-bit. Things are busy right now though, but I'll possibly get the opportunity to look into ARM64 support in May.

For now it seems like x64 Linux&Windows are the only supported platforms/architectures.

[xssuser]

hi @ufrisk

when i use UPCore x86 board (Intel® Atom™ x5 Z8350 Processor 64 bit - up to 1.92GHz)

root@ubuntu:~/pcileech-4.0/files# ./pcileech kmdload -kmd win10_x64 -device fpga -v Segmentation fault (core dumped)

root@ubuntu:~/pcileech-4.0/files# gdb ./pcileech core
GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./pcileech...done.
[New LWP 1814]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `./pcileech kmdload -kmd win10_x64 -device fpga -v'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x0000000000000000 in ?? ()
(gdb) backtrace
#0  0x0000000000000000 in ?? ()
#1  0x00007feb0b4fdcc0 in DeviceFPGA_InitializeFTDI (ctx=0xa92bb0) at device_fpga.c:259
#2  0x00007feb0b5002e0 in DeviceFPGA_Open () at device_fpga.c:967
#3  0x00007feb0b4fb622 in LeechCore_Open (pConfig=0xa90908) at leechcore.c:447
#4  0x0000000000403e20 in DeviceOpen2 (szDevice=0xa90038 "fpga", fFailSilent=0) at device.c:37
#5  0x0000000000403f5a in DeviceOpen () at device.c:62
#6  0x00000000004039cf in main (argc=7, argv=0x7ffd0f0faa48) at pcileech.c:233
(gdb) #0  0x0000000000000000 in ?? ()
(gdb) #1  0x00007feb0b4fdcc0 in DeviceFPGA_InitializeFTDI (ctx=0xa92bb0) at device_fpga.c:259
(gdb) #2  0x00007feb0b5002e0 in DeviceFPGA_Open () at device_fpga.c:967
(gdb) #3  0x00007feb0b4fb622 in LeechCore_Open (pConfig=0xa90908) at leechcore.c:447
(gdb) #4  0x0000000000403e20 in DeviceOpen2 (szDevice=0xa90038 "fpga", fFailSilent=0) at device.c:37
(gdb) #5  0x0000000000403f5a in DeviceOpen () at device.c:62
(gdb) #6  0x00000000004039cf in main (argc=7, argv=0x7ffd0f0faa48) at pcileech.c:233
(gdb) q
root@ubuntu:~/pcileech-4.0/files#

when use Rpi or UPCore , always in device_fpga.c file:259 error pfnFT_SetSuspendTimeout(ctx->dev.hFTDI, 0);

if delete this line and recompile to run on UPCore

root@ubuntu:~/pcileech-4.0/files# ./pcileech kmdload -kmd win10_x64 -device fpga -v

DEVICE: FPGA: PCIeScreamer R2 PCIe gen1 x1 [300,0,500] [v3.4,0500]
INFO: PA PT BASE:   0x00000000001aa000
INFO: PA PT:        0x0000000003804000
INFO: PA HAL HEAP:  0x0000000000108818
INFO: VA SHELLCODE: 0xfffff78840040210
KMD: Code inserted into the kernel - Waiting to receive execution.
KMD: Execution received - continuing ...
INFO: PA KMD BASE:  0x7fffc000
Kernel reported memory map below:
 START              END               #PAGES
 0000000000001000 - 000000000009cfff  0000009c
 0000000000100000 - 0000000000101fff  00000002
 0000000000103000 - 000000001fffffff  0001fefd
 0000000020200000 - 000000003fffffff  0001fe00
 0000000040200000 - 00000000d3d9ffff  00093ba0
 0000000100000000 - 000000021e5fffff  0011e600
----------------------------------------------
KMD: Successfully loaded at address: 0x7fffc000
root@ubuntu:~/pcileech-4.0/files# ./pcileech wx64_unlock -kmd 0x7fffe000 -0 1

EXEC: Failed writing shellcode to target memory.
root@ubuntu:~/pcileech-4.0/files#

Any idea? Thanks!

[ufrisk]

It seems like you got it to work, The failure in the last command is due to the wrong kmd address specified.

But I have no clue why the pfnFT_SetSuspendTimeout is crashing for you, I assume the problem is the same on the version I released today? I haven't noticed this problem myself, but if it remains for you in the most recent version I'll look into it next week. Anyway the pfnFT_SetSuspendTimeout is currently just a dummy function with no meaning on the Linux version at the moment so it should be safe to remove.

[ufrisk]

closing issue due to old age. the issue should also be resolved now since quite a while ago.