I did some research and found out that the SATA protocol does negotiate the communication speed [1]. Some posts here and there say or imply, that SATA has a fixed speed and Arduino cannot handle it. Well, I'm not sure, that's why I am asking.
Sure, it may be impossible to provide enough processing power when using some of the smaller Arduinos - but what about let's say the ESP8266 (32 bit, 80+ MHz). To be clear: We do not need high performance communication between the Arduino and the host, we just want to use DMA for some experiments (security research) - and therefore we need PCIe or SATA for example. SATA would be much nicer. We do not want to use Firewire for that, as DMA is blocked by modern operating systems anyway.
So, any ideas how this could be done? Any papers, tutorials, other useful material?
As used in a PC, SATA connects mass storage (block oriented) devices, so that the OS disk file managment and optimization (caching...) may get into the way.
I'd guess that you have to implement a special device driver for your application, and install it for an otherwise unused SATA controller.
Hmm, ok - but do you think this is also the case, if we do not provide any storage or device driver for the OS? In some post I read that SATA device drivers are very generic anyway.
Let me elaborate our research goal a little: We want to access the RAM via DMA. This process does not need to be super fast, we just need to access the RAM from an additional piece of hardware. Any suggestions how this can be done? "Simple" solutions are preferred, of course.
Please clarify on what hardware that DMA access should occur. DMA is not related to Arduino in general, even if it may be available on some boards with 32 bit controllers. Most probably such hardware is controlled by an OS, so that this OS specific forum will be the right place for such questions.
WRT speed I'd think that it's only the device driver, which expects that a DMA transfer of a certain number of bytes is finished within some time limit. A modern DMA controller may have some watchdog feature, to timeout on broken transmissions, but else it simply waits for a device READY signal, that triggers a memory and device read/write cycle. Details again depend on a specific machine architecture.
Thanks for your answer! The hardware of the host should be as irrelevant as possible. Of course, the host is a 32 or 64 bit PC (today almost certainly 64 bit), with SATA or PCIe support (or some other DMA enabled interface, where DMA is not blocked by the OS). SATA is my preferred interface so far.
If it is really necessary to specify a certain OS, then let's assume Windows 10 x64 (or in general Windows 7 and above, all x64). But I do not understand, why this should be relevant, since DMA is a hardware feature, isn't it? Is the OS aware of DMA transfers initiated by the device? To be clear: We do not want to communicate with the host, we just want to read it's RAM.
It may be worth asking the OP... Can you pls explain your understanding / expectations of DMA.
DMA will never access an Arduino's on-chip RAM...
If a particular processor family supports DMA, it is either designed for that role, or has on on-chip DMA controller peripheral... just like a UART or RTC on chip.
An application host CPU simply sets up the memory transfer in the 'separate' DMA controller's logic, so it can be executed outside the view/control of the host CPU. After setup, and saying 'go', the host CPU never knows about the transfer until it is complete, or an exception is raised.
Thanks for your answers! I didn't know that about DMA, so I think I need further reading material about how a DMA transfer is initiated and controlled by the host CPU (more detailled than [1]). Any suggestions?
Is there really no way to access the systems RAM without initiation by the host's CPU?
@lastchancename: We do not want to access the Arduino's RAM - we want to access the hosts RAM. Without any additional software on the host, if possible. As I said, it's for a security research project, so installing custom software on the host before launching the attack is ridiculous
You keep saying "DMA" but I have no idea why. Like your Wiki article says that just refers to the hardware layer between the computer and drive; data from the disk is transferred directly into the host's RAM without CPU interference, and then the host just reads the data from RAM instead of playing some inefficient bit-banging game with the hard drive. All of this is managed by the drive controller and the motherboard chipset.
If you're going to somehow intercept a DMA transfer then you're going to need a lot more RAM and speed than any microcontroller can provide. If your objective is to trick the drive into initiating a DMA transfer with the assumption that the host is just going to slurp it up, well, good luck with that.
Hi,
we want to do something like this [1], but not over firewire and with as little hardware as possible (for the "wow"-effect). We are still in the planning phase, that's why I'm asking here, whether this idea is in general possible or not and which hardware requirements and problems more experienced people like you see.
Our primary domain is IT security and we have rather sparse in-depth knowledge in the hardware domain. Yes, we do know I2C, SPI, computer- and µC-architectures etc. (so no absolute beginners), but some detailed and understandable documentation about DMA would be helpful. So, if you can recommend anything...
About the bandwith / speed problem: Our hope was, that we could negotiate a very slow transfer speed and receive only smaller chunks of the host's RAM at a time, so that a cheap µC or ARM device (like a Raspberry Pi) could handle it. Maybe (so our thoughts) we could use some standard / generic device driver that the OS has loaded anyway (if one is needed), like for optical drives or so. But if the host's CPU initiates and controls each transfer (as you and Wikipedia tell me), then it will be rather hard because we have to abuse such a device driver somehow to get the DMA transfers initialized.
For diagnostic purposes any Arduino can be used, that can communicate (over USB-COM, Ethernet, BT, WLAN...) with the diagnostic program running on the host CPU.
A general spy attack on a PC requires an independent (PCI, CPU...) device, that can obtain bus mastership. Worse than a software installation, the installation of such a device requires physical access to the system bus (PCI slot or additional CPU socket), and means to transfer the information to the outer world. Eventually such modules exist already, for hardware diagnostics, docking stations or ICE, or as special CPU (68000...) emulator/subsystem boards.
The other commonly accessible I/O ports (Ethernet, USB, HD/DVD docking, card readers...) are under control of the CPU and its software. Even a bootable memory stick (or CD...) requires a BIOS firmware, that allows for and executes the bootstrap protocol.
Thanks again for your reply. In our scenario, physical access is no problem. We want to show, how one can undermine the security of programs running on a system without any software.
Shoot, that is easy. Turn off/interfere with the CPU fan. I installed a new CPU in my kid's computer and left a wire across the blades. We kept getting mysterious crashes until I freed up the CPU fan by moving the wire.
I've definitely heard about attacks from malicious peripherals abusing DMA - apparently it was particularly easy with firewire. I don't know any more details.
I think to have any prayer of pulling this off for SATA or PCIe, though, you should be using a much beefier microcontroller than an Arduino. I'd be looking at a decently fast 32-bit ARM-based micro, at least - maybe even something RasPi-tier....
