Start the pull with small reads. You won't be able to use the FTDI cable until you install the drivers linked above. If you see it pop up with dmesg and assigned a TTY you should be good. Here is my dmesg.
[2509927.167517] usb 1-4: new high-speed USB device number 19 using xhci_hcd
[2509927.337226] usb 1-4: New USB device found, idVendor=0403, idProduct=6014, bcdDevice= 9.00
[2509927.337229] usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[2509927.337230] usb 1-4: Product: C232HM-DDHSL-0
[2509927.337231] usb 1-4: Manufacturer: FTDI
[2509927.337233] usb 1-4: SerialNumber: FT1K75R7
[2509927.680056] usbcore: registered new interface driver usbserial_generic
[2509927.680069] usbserial: USB Serial support registered for generic
[2509927.684627] usbcore: registered new interface driver ftdi_sio
[2509927.684643] usbserial: USB Serial support registered for FTDI USB Serial Device
[2509927.684738] ftdi_sio 1-4:1.0: FTDI USB Serial Device converter detected
[2509927.684780] usb 1-4: Detected FT232H
[2509927.695387] usb 1-4: FTDI USB Serial Device converter now attached to ttyUSB0
[2510038.796607] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
Now, you should be able to use the cable with the clip. Assuming you have it all hooked up correctly, it could be good to pull. It can be useful to pull a small amount at a time to make sure its working. Generically, the command below would be "read data from the SPI flash to file named fileName, read s bytes worth and verify it is a good pull by pulling it twice and doing a diff of the two pulls.
$sudo spiflash -r <fileName> -s <bytes> -v
Once confident, you can also pull at a higher clock rate. The default is 15MHz, but as mentioned before this should go up to 30MHz.
$ spiflash -r 25Q80DVNIG.bin -s 1000 -f 30000000 -v
FT232H Future Technology Devices International, Ltd initialized at 30000000 hertz
Reading 1000 bytes starting at address 0x0...saved to 25Q80DVNIG.bin.
Verifying...reads are identical, verification successful.
From the above we can see that it took the data rate, read 1000 bytes, and was able to do so two times, thus 'verifying' a good pull.
An important note here, is that the flash is an 8M-bit flash. The program operates in bytes. That is ok though, you can use bash to figure it out for you. Let's go ahead and try to pull all of the memory as fast as we can.
$ spiflash -r 25Q80DVNIG.bin -s $((0x800000)) -f 30000000 -v
FT232H Future Technology Devices International, Ltd initialized at 30000000 hertz
Reading 8388608 bytes starting at address 0x0...saved to 25Q80DVNIG.bin.
Verifying...reads are identical, verification successful.
Great, now the interesting business starts to take place. We can run strings, binwalk, xxd to look at the bytes, pull it into ghidra if it is flash...all manner of things to start to see if it is what we think. More on those topics in future episodes.
Some places to look for datasheets:
Look on fcc.io (depending on the part) to see if there is more information to glean from the FCC number(s) on the device.
If the device is older and you come across a broken link, the Internet Archive's Wayback Machine is clutch.
Sometimes https://www.manualslib.com is great. Same is true with https://www.datasheetarchive.com/ or http://www.datasheetcatalog.com
For oldddddd parts, the old IC master volumes can be found here: http://www.bitsavers.org/components/icMaster/
Depending on the part, some google dorking with the part number or emailing support and asking nicely can work.
Jameco, Digikey, Mouser can have some if they sell the chip.
Despite your best efforts, sometimes the part was sold with an NDA and the datasheet is just not forthcoming. You may have to traipse around some forums and ask. Some I know have occasionally asked
Google Dorking Tips (using Google's built-in keywords to sift quickly for specific search results)
site:websitethatmayhavedatasheets.com filetype:pdf
<name of chip> filetype:pdf
If you search around for some doking cheat sheets there are many other possibilities.
This process doesn't just apply to flash, it also applies to any chip on the board, especially the uC. The reason being is that when you pull the memory, the next step is going to be pulling it into Ghidra and starting the software RE process. During that process you're going to run into functions which are driving certain uC pins in some fashion and you'll need the data sheet to understand what pin is going where. Chances are you're going to have to be tracing some PCB leads as well. Things escalate quickly.
Different Flash Form Factors:
There are too many for one sitting. Generally speaking, memory has different logical as well as physical forms. The one above of course was SPI, but there are others (SPI, NOR, NAND, eMMC). Physically these come in different forms too. One is thin small outline package (TSOP), there are different pin counts for these. There are also small-outline initgrated circuits (SOIC), plastic small-outline packages (PSOP), shrink small-outline packages (SSOP), thin-shrink small outline packages (TSSOP) and more. In addition to TSOP, there are also ball-grid array (BGA). With those there are many sub-types too (CABGA, DSBGA, LBGA, TABGA, VFBGA). Generally speaking, SPI has few pins and is easiest to get-after in my opinion. NOR has separate address/data pins and pin maps differ by vendor. NAND is typically 8 or 16 pins and address/data are multiplexed; pin mpas for them regardless of the form factor are mostly standard. Finally, eMMC is basically NAND but you typically talk to the controller to interface with them.
As you can see from the screenshot below, looking on mouser.com for TSOP-48 NAND flash yields a huge amount of additional results not mentioned.