Can't flash USB3380-EVB about pcileech

[ufrisk]

It seems like the module is unable to reserve the memory mapped device memory for some reason. Possibly due to the net2280 driver already using it.

Are you able to unload the net2280 driver/.ko? Alternatively if you could try to flash it on another linux distro or computer; live ubuntu or such after installing kernel headers might work.

There are obviously some issues in the kernel module due to lack of error checking if the memory maping operation failed; but even if I change that so the error message looks better it won't help in getting the device flashed.

I think the easiest way to flash it is to try to do it on a live image or so, otherwise try it on another computer or as a last resort register at PLX/Avago/Broadcom and download their SDK.

Please let me know how it goes.

[ccaralegall]

I think the problem is the adapter I'm using, this net2280 driver seems to be from a PCI USB Controller - the adapter I'm using (miniPCI-e to PCI-e) is a routerboard, when I connect the adapter with the USB3380 that driver is loaded. But even unloading it I can't flash.
dmesg says:
net2280 0000:01:00.0: unbind
PCILEECH FLASH: Module init called.
PCILEECH FLASH: Found USB3380 not flashed as PCILeech.
PCILEECH FLASH: ERROR: Firmware write/verify not successful.

So, maybe I have to buy the ADP from bplus.
thanks.

[ufrisk]

net2280 is the driver name for the USB2280; which is the predecessor (usb2) variant of the USB3380. I don't think it has with your mini-PCIe to PCIe adapter; any cheap $5 adapter should work. It would be interesting to see if you could try to flash it on the most recent vanilla ubuntu, or alternatively if that doesn't work on another computer.

[ccaralegall]

It didn`t work, I tried with vanilla ubuntu and on another computer. After unloading the driver and reconnecting the USB3380 the dmesg says:
[ 516.832376] PCILEECH FLASH: Module init called.
[ 516.832383] PCILEECH FLASH: Found USB3380 not flashed as PCILeech.
[ 516.847316] pci 0000:02:00.0: Refused to change power state, currently in D3
[ 518.031367] PCILEECH FLASH: ERROR: Firmware write/verify not successful.

What does it mean?

[ufrisk]

It tries to flash the firmware; but it seems like it's not successful. I haven't seen the "power state currently in D3" message myself. It might have something to do with the problems.

You are using the USB3380-EVB mini PCIe board? and not the PP3380 PCIe board? The PP3380 PCIe board requires that you bridge the J3 jumper to activate the EEPROM.

Could you please try to reflash it a couple of times by trying the insmod a couple of times in a row; and if that doesn't work re-insert the card and try again.

---

If that doesn't work and it also doesn't work on another computer you could try to flash it with the PLX SDK; info are found at: https://github.com/NSAPlayset/SLOTSCREAMER (but it's quite cumbersome). If you decide to go that route please flash firmware_pcileech.bin found in the pcileech_files folder.

[ufrisk]

Was you able to resolve this issue?

If not, I also added support for flashing it in Windows (64-bit Windows 10)

[ufrisk]

I'm closing this issue due to lack of response. I'm assuming the problem was resolved. Please let me know otherwise.

[postoroniy]

having same issue

sudo insmod ./pcileech_flash.ko
insmod: ERROR: could not insert module ./pcileech_flash.ko: No such device
dmesg|tail
[    7.767845] IPv6: ADDRCONF(NETDEV_CHANGE): wlx7cdd90595c39: link becomes ready
[   14.036304] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[   14.036305] Bluetooth: BNEP filters: protocol multicast
[   14.036308] Bluetooth: BNEP socket layer initialized
[   66.242755] PCILEECH FLASH: Module init called.
[   66.242767] PCILEECH FLASH: Found USB3380 not flashed as PCILeech.
[   66.242783] net2280 0000:02:00.0: BAR 0: can't reserve [mem 0xdf128000-0xdf129fff]
[   66.242786] PCILEECH FLASH: ERROR: Cannot request regions.
[   66.242792] Trying to free nonexistent resource <00000000df110000-00000000df11ffff>
[   66.242796] Trying to free nonexistent resource <00000000df100000-00000000df10ffff>
sudo rmmod net2280
[   14.036308] Bluetooth: BNEP socket layer initialized
[   66.242755] PCILEECH FLASH: Module init called.
[   66.242767] PCILEECH FLASH: Found USB3380 not flashed as PCILeech.
[   66.242783] net2280 0000:02:00.0: BAR 0: can't reserve [mem 0xdf128000-0xdf129fff]
[   66.242786] PCILEECH FLASH: ERROR: Cannot request regions.
[   66.242792] Trying to free nonexistent resource <00000000df110000-00000000df11ffff>
[   66.242796] Trying to free nonexistent resource <00000000df100000-00000000df10ffff>
[   91.257416] Trying to free nonexistent resource <00000000df128000-00000000df129fff>
[   91.257486] net2280 0000:02:00.0: unbind
sudo insmod ./pcileech_flash.ko
insmod: ERROR: could not insert module ./pcileech_flash.ko: No such device
dmesg|tail
[   91.257486] net2280 0000:02:00.0: unbind
[   97.753499] PCILEECH FLASH: Module init called.
[   97.753503] PCILEECH FLASH: Found USB3380 not flashed as PCILeech.
[   97.753588] PCILEECH FLASH: ERROR: Firmware write/verify not successful. Error: fffffffe
uname -a
Linux mint 4.4.0-53-generic #74-Ubuntu SMP Fri Dec 2 15:59:10 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

[ufrisk]

postoroniy>
no, you are having a different issue, it's not the missing EEPROM issue. It looks like your issue is that the net2280 driver is interfering or if there is another issue. This is an issue with your OS/computer.

Can you please try to flash it on an ubuntu 16.04 or kali 2016.2 system (I've tested those ones). Just doing it on a live or persistent USB will work fine...

Also, try re-insert the device and re-flash it a couple of times if it's not working the first time... sometimes it helps.

[postoroniy]

just tried ubuntu 16.04 with the same result and error type
ERROR: Firmware write/verify not successful. Error: fffffffe

[ufrisk]

sorry, first I confused your issue with another active issue resulting in flash problems. it seems you do have the same issue as reported in this thread.
Do you have access to another computer that you can try to flash it on?

[postoroniy]

will try soon and let you know result

[postoroniy]

linux
[ 272.541329] PCILEECH FLASH: Module init called.
[ 272.541333] PCILEECH FLASH: Found USB3380 not flashed as PCILeech.
[ 272.541409] PCILEECH FLASH: ERROR: Firmware write/verify not successful. Error: fffffffe

win10
could not install the flash driver due to an unknown reason

[postoroniy]

Mine device revision
02:00.0 USB controller: PLX Technology, Inc. Device 3380 (rev ab)
what is your?

[ufrisk]

I have the very exact version, lspci gives me:
02:00.0 USB controller: PLX Technology, Inc. Device 3380 (rev ab)

[ufrisk]

can you please also try to remove the net2280 driver before (on linux) and try flashing it a couple of times?
rmmod net2280
insmod pcileech_flash.ko
insmod pcileech_flash.ko

[postoroniy]

done it before already
it didn't help
without removing net2280 it has different type of error, you should see in previous post there's
[ 91.257486] net2280 0000:02:00.0: unbind
which means I removed that driver

[postoroniy]

tried narrow down exact error and found that all operations in flasher were ok till this

	pbar0 = ioremap_nocache(pci_resource_start(pdev, 0), pci_resource_len(pdev, 0));
	ret = _action_flash_writeverify(pbar0);

pbar0 is not NULL I checked but any access by pbar0(reading) returns 0xffffffff
and for sure LED cant be controlled

[Sawen1981]

Hello everyone, Ulf, and the others thanks for your lines dropped here full of information. I use the USB3380-EVB and here is the output of the dmesg:

[68110.021425] PCILEECH FLASH: SUCCESSFUL: Please re-insert the device to use as a PCILeech device!
[68123.935153] pci_bus 0000:0b: Allocating resources
[68123.935172] pci 0000:00:1e.0: PCI bridge to [bus 0b]
[68123.935178] pci 0000:00:1e.0: bridge window [io 0x8000-0x8fff]
[68123.935187] pci 0000:00:1e.0: bridge window [mem 0xf7200000-0xf73fffff]
[68123.935192] pci 0000:00:1e.0: bridge window [mem 0xf7400000-0xf75fffff 64bit pref]
[68123.941102] pci 0000:00:1e.0: PCI bridge to [bus 0b]
[68123.941110] pci 0000:00:1e.0: bridge window [io 0x8000-0x8fff]
[68123.941119] pci 0000:00:1e.0: bridge window [mem 0xf7200000-0xf73fffff]
[68123.941126] pci 0000:00:1e.0: bridge window [mem 0xf7400000-0xf75fffff 64bit pref]
[68123.941187] pci 0000:00:1e.0: PCI bridge to [bus 0b]
[68123.941192] pci 0000:00:1e.0: bridge window [io 0x8000-0x8fff]
[68123.941200] pci 0000:00:1e.0: bridge window [mem 0xf7200000-0xf73fffff]
[68123.941206] pci 0000:00:1e.0: bridge window [mem 0xf7400000-0xf75fffff 64bit pref]
[68123.942052] pci_bus 0000:01: Allocating resources
[68123.942071] pci_bus 0000:02: Allocating resources
[68123.942092] pci_bus 0000:03: Allocating resources
[68123.942164] pci_bus 0000:05: Allocating resources
[68123.942179] pci 0000:00:1e.0: PCI bridge to [bus 0b]
[68123.942186] pci 0000:00:1e.0: bridge window [io 0x8000-0x8fff]
[68123.942196] pci 0000:00:1e.0: bridge window [mem 0xf7200000-0xf73fffff]
[68123.942205] pci 0000:00:1e.0: bridge window [mem 0xf7400000-0xf75fffff 64bit pref]
[68123.942288] pci 0000:00:1e.0: PCI bridge to [bus 0b]
[68123.942295] pci 0000:00:1e.0: bridge window [io 0x8000-0x8fff]
[68123.942305] pci 0000:00:1e.0: bridge window [mem 0xf7200000-0xf73fffff]
[68123.942313] pci 0000:00:1e.0: bridge window [mem 0xf7400000-0xf75fffff 64bit pref]
[68123.942520] pci 0000:00:1e.0: PCI bridge to [bus 0b]
[68123.942526] pci 0000:00:1e.0: bridge window [io 0x8000-0x8fff]
[68123.942536] pci 0000:00:1e.0: bridge window [mem 0xf7200000-0xf73fffff]
[68123.942544] pci 0000:00:1e.0: bridge window [mem 0xf7400000-0xf75fffff 64bit pref]
[68123.942713] pci 0000:00:1e.0: PCI bridge to [bus 0b]
[68123.942720] pci 0000:00:1e.0: bridge window [io 0x8000-0x8fff]
[68123.942730] pci 0000:00:1e.0: bridge window [mem 0xf7200000-0xf73fffff]
[68123.942739] pci 0000:00:1e.0: bridge window [mem 0xf7400000-0xf75fffff 64bit pref]
[68123.943050] pci 0000:00:1e.0: PCI bridge to [bus 0b]
[68123.943056] pci 0000:00:1e.0: bridge window [io 0x8000-0x8fff]
[68123.943066] pci 0000:00:1e.0: bridge window [mem 0xf7200000-0xf73fffff]
[68123.943074] pci 0000:00:1e.0: bridge window [mem 0xf7400000-0xf75fffff 64bit pref]

So it says reinsert to use it.

when I try to connect the board thru the USB3 port all the lights are gone. I don't get it. Is there any driver I need to install in order to get the USB3380-EVB seen? If yes how do I do it? I cannot find the driver.

I use ubuntu the last update.

I have to say that all the information I found was shooting in all direction and it is hard to really understand how this all works.

I could not find ANY topic or How To clear enough to get the thing working.

Recap:

How do I get the board recognized or mounted plugged in with the USB3 cable?
Where do we find the drivers for it?
For PCILeech with Linux ( I think I am best of getting this to work under Linux Windows does not work for me I can't even get the flash or USB working)at least under ubuntu it show the flash working.
What folder exactly do I need under Linux ( attacker machine ) - ( macOS is the target machine )
PCIleech-Master ??
LeechCore??

Y'all thank you for your help.

[Sawen1981]

So if I understood correctly PCILeech under Linux I should have, 3 folders in the directory correct?

1. PCILeech_files_and_binaries_v4.6-20200830
2. LeechCore-master
3. LeechCore-plugins-master
   Then I am lost on what to do. There isn't really any explanation on what to do.

Thank y'all.

[ufrisk]

Once re-inserted the lights are not used. The device should be working anyway. On linux libusb should be sufficient for it to work. On Windows you would need to install the google android driver for it to work - instructions with a link to the driver are found in the pcileech main readme file.

[Sawen1981]

I was able to finally do a dump and I got the reading stopped at 58% unfortunately my friend had applied the update 10.12.3 so I think that it’s dead right? Could it be that the dump even at 58% contain the password in plain text? The files has 2332032912 lines… lol I was able to read at 160-200 MB/s constent … I do not know why the dump reading stops at 58% though..

…

On Sep 1, 2020, at 5:09 PM, Ulf Frisk ***@***.***> wrote: Once re-inserted the lights are not used. The device should be working anyway. On linux libusb should be sufficient for it to work. On Windows you would need to install the google android driver for it to work - instructions with a link to the driver are found in the pcileech main readme file. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#10 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADEUMJEC4N5OI3UNOXLVKLTSDVPJRANCNFSM4CR3AHIQ>.

[Sawen1981]

The command >PCILeech.exe fv_macrecover did not work it would say reboot but then I would and it would not do anything…

…

On Sep 1, 2020, at 11:38 PM, Cash America ***@***.***> wrote: I was able to finally do a dump and I got the reading stopped at 58% unfortunately my friend had applied the update 10.12.3 so I think that it’s dead right? Could it be that the dump even at 58% contain the password in plain text? The files has 2332032912 lines… lol I was able to read at 160-200 MB/s constent … I do not know why the dump reading stops at 58% though.. > On Sep 1, 2020, at 5:09 PM, Ulf Frisk ***@***.*** ***@***.***>> wrote: > > > Once re-inserted the lights are not used. The device should be working anyway. On linux libusb should be sufficient for it to work. On Windows you would need to install the google android driver for it to work - instructions with a link to the driver are found in the pcileech main readme file. > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub <#10 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADEUMJEC4N5OI3UNOXLVKLTSDVPJRANCNFSM4CR3AHIQ>. >

[Sawen1981]

I do not even know if I got the right part, when I got that 58% reading from the memory I think, was when I booted into a recovery mode.

…

On Sep 1, 2020, at 11:42 PM, Cash America ***@***.***> wrote: The command >PCILeech.exe fv_macrecover did not work it would say reboot but then I would and it would not do anything… > On Sep 1, 2020, at 11:38 PM, Cash America ***@***.*** ***@***.***>> wrote: > > I was able to finally do a dump and I got the reading stopped at 58% unfortunately my friend had applied the update 10.12.3 so I think that it’s dead right? > Could it be that the dump even at 58% contain the password in plain text? The files has 2332032912 lines… lol I was able to read at 160-200 MB/s constent … I do not know why the dump reading stops at 58% though.. > >> On Sep 1, 2020, at 5:09 PM, Ulf Frisk ***@***.*** ***@***.***>> wrote: >> >> >> Once re-inserted the lights are not used. The device should be working anyway. On linux libusb should be sufficient for it to work. On Windows you would need to install the google android driver for it to work - instructions with a link to the driver are found in the pcileech main readme file. >> >> — >> You are receiving this because you commented. >> Reply to this email directly, view it on GitHub <#10 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADEUMJEC4N5OI3UNOXLVKLTSDVPJRANCNFSM4CR3AHIQ>. >> >

[ufrisk]

Hi, and not good that this not succeed. The particular bug was patched in macOS Sierra 10.12.2.

about the read fail at 56%; that is pretty normal for the USB3380. If the USB3380 encounters some memory addresses which are unreadable (there are sometimes small holes in memory address space) the USB3380 will hang up and freeze until power cycled.

If you disable the vt-d in recovery mode you'll be able to inject kernel modules and also remove the mac passphrase from the login prompt should the user NOT have enabled the FileVault full disk encryption. But in your case I think it's kind of moot since the user seems to have enabled the full disk encryption from what you told me.

[Sawen1981]

Yeah kind fried right now with this, but from the recovery doing an ls -R I can see the keychain.db maybe I can move the db onto a USB key and try to read the content and get the iCloud password or the admin password.

…

On Sep 2, 2020, at 11:17 AM, Ulf Frisk ***@***.***> wrote: Hi, and not good that this not succeed. The particular bug was patched in macOS Sierra 10.12.2. about the read fail at 56%; that is pretty normal for the USB3380. If the USB3380 encounters some memory addresses which are unreadable (there are sometimes small holes in memory address space) the USB3380 will hang up and freeze until power cycled. If you disable the vt-d in recovery mode you'll be able to inject kernel modules and also remove the mac passphrase from the login prompt should the user NOT have enabled the FileVault full disk encryption. But in your case I think it's kind of moot since the user seems to have enabled the full disk encryption from what you told me. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#10 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADEUMJFAARMQXVMJSWKGLBDSDZOYPANCNFSM4CR3AHIQ>.

[Mosstrow]

Hello,

I've the same error message as postoroniy when I try to flash the USB3380-EVB:
insmod ./pcileech_flash.ko
insmod: ERROR: could not insert module ./pcileech_flash.ko: No such device
dmesg
PCILEECH FLASH: Module init called.
PCILEECH FLASH: Found USB3380 not flashed as PCILeech.
PCILEECH FLASH: ERROR: Firmware write/verify not successful. Error: fffffffe

I use ubuntu 16.04, kernel 4.15.0-112
I also tried to unbind net2280 with same result.

Thanks