As this question is quite general, it'll be difficult to provide a very technical answer.
You've asked quite a few questions here, so please let me start with a general overview and then proceed to answer all of your specific questions.
The difficulty of pulling firmware images from an embedded device really depends on the firmware device itself, and the access you have to that firmware device.
I would say there are a few different alternatives depending on your actual goal (just getting as many firmwares as possible verses getting firmwares for specific devices you're in possession of or interested in, for example). I'll list the general options in ascending difficulty:
Getting a firmware image/update online
Since a lot of devices support some kind of firmware update mechanisms, firmware images are often made available by the manufacturer either via a manual web page download for manual update or via a web service that will serve over-the-air updates. Although those updates may sometimes be encrypted, in most cases they are just signed - because the actual threat landscape is modifying a firmware and not reading it.
As the format of a firmware update may be more complex to understand than a raw
dd dump, for example, you'll need to spend extra efforts in understanding the format, extracting the firmware asset(s) from the firmware update file and optionally implementing some firmware-loading logic to get the in-memory image / addressing available. Tools like binwalk are a decent starting point.
If firmware is only available over-the-air, you'll also need to spend time understanding the over-the-air protocol and any server side limitations on serving assets. A server may refuse offering an old version you're particularly interested in or require some kind of a per-device identification/authentication.
Using an application info-leak vulnerability
The simplest example that comes to mind is information disclosure vulnerabilities in web applications that often exist on many embedded devices, however there may be other relevant targets. Unlike native information disclosure vulnerabilities where often pointers, addresses and memory data may be leaked, web information disclosure vulnerabilities often expose files and stored data. This may either allow you to pull other relevant information (for example, probing for hardware devices/interfaces) or even access to the firmware if it is either stored on the same storage or mounted (all the time or when an update runs).
Reading a firmware by software when shell access is available
Shell or root access may be available to you without looking at the firmware because of a known vulnerability or one that is easy enough to discover without actually reading any code. A device may also offer some kind of terminal access for debugging purposes. Instead of a full-blown terminal, one can have the ability to just execute a single shell command using command injections, for example.
Once you have access, this is mostly a matter of probing for any available assets and recovering whatever you can.
Reading a firmware by hardware when physical access if available
As this can often be the most challenging way of extracting firmware images, you may occasionally be lucky to the point that this approach can be as easy as pulling a SD card and plugging it into a computer. This isn't often the case, though. Since this specific topic is quite huge and you seem to be looking for an overview, I will not dive deep into the specifics.
When physical access to a device is available and any debug ports, uarts, or serial ports are available, you may often find them very useful for extracting details about the firmware. Some of those features may also be available through an ethernet port. These debugging interfaces often provide raw access to different components, such as the storage or controlling the boot sequence.
Although sometimes identifying such a port can be easy thanks to exposed unconnected pinheads and existing pin label printouts depicted below:
Unmounted pinheads on the left, pin labels on the right. Click to enlarge
The different debug ports could also be harder to recognize when no labels are printed and there are no pinheads connected. A walk-through example for identifying both exposed and hidden debug ports is available here.
When debug ports are insufficient, the next step further is directly reading the firmware from the storage chip. This often includes either taking it out of the board and using your own electronic circuit to read memory out of the chip or hooking to the chip while it's still connected to the original board but either passively listening to data as it's read by the device or issuing your own read instructions. You'll first need to identify the circle components and their purpose, and manufacturer datasheets. This will obviously also require dedicated hardware. Generic boards exist for that purpose (some specifically for firmware extraction and hardware reverse engineering like GoodFET and BusPirate) and you can also get some development equipment from chip manufacturers that use proprietary In Circuit Serial Programming, if they'll be willing to sell those to you.
You can go even as far as reading the data directly from the chip using electrical and optical analysis of the chips' die layers, but that seems unlikely for your case.
Answering your specific questions
Is it in general possible to gather firmware images from legacy embedded devices?
As mentioned earlier, this greatly depends on the specific device and how protected it may be. It tends to be doable for most cheap devices but as a device becomes more expensive you can assume it'll be more complex and indirectly incur more difficulties.
It is also important to note that excluding the really expensive and/or often targeted devices (smartphones is a good example of those), most difficulties will not come from a manufacturer actively trying to make firmware extraction harder, but will more often come from design decisions and product choices and just happen to impact the difficulty of extracting a firmware image.
- I am aware that many embedded devices disable the debug port
Although this can sometimes be the case for either increased security or to reduce costs, removing a debug port completely makes repairs and QA more difficulties. Often, although the debug port may to be included a convenient pinout may be laid out for easy access, either heads for easy access or without as seen in the following picture:
Picture taken from this step by step hardware reverse engineering tutorial
- embedded system have the so-called "Code Readout Protection" mechanism to prevent users from downloading the firmware
The cheaper devices will generally not bother with code readout protection, and there are some ways to bypass it although those tend to be relatively difficult and specific. One such method is to remove the storage chip and interact with it directly to extract the firmware image, as I previously mentioned in Reading a firmware by hardware when physical access if available.
- Firmware could be extracted from embedded devices by abusing busybox, for instance its
wget command. Something like: Limited BusyBox shell
This approach is an example of what I've discussed under Reading a firmware by software when shell access is available above. In the example you linked,
wget is used to exfiltrate the data after you get it, but there's no limit to the creativity of that (one can even go as far as use available LEDs to encode binary data).
- The "code readout protection" could be bypassed, so as the "debug port" issue
Yes, through slightly more advanced hardware reverse engineering tools and abilities it is possible to extract software from chips that have readout protection, use a device port although it isn't mounted, avoid the need of a debug port, using the chip's datasheet to recognize how to properly read the data out, snarfing it while it's being read by the existing circuit, etc...
is it generally considered easy or not to extract legacy firmwares from embedded devices? What is the common procedure and best practice?
As shown by this post, and repeated several times, this can be relatively easy or relatively difficult, depending on specific case. Common procedures also vary heavily.
The topic of hardware reverse engineering is big an wide, and it is hard to cover it all in an SO post. You should spend more time reading, watching talks and following walkthroughs to gain more knowledge on the subject. Here are a few resources:
- A survey of The State-of-the-Art in IC Reverse Engineering
- Keep your tentacles off my bus and other talks by Dmitry Nedospasov.
- This hardcore example of firmware extraction by decapping by Travis Goodspeed.
- This introductory level, five part hardware/firmware reverse engineering walkthrough.
- A presentation about practical extraction using a Null dereference bug.
and many other resources available online.