Arduino Forensics - Read SRam memory

Hello! I have a project in witch i need to make forensics on Arduino boards. For that i need to extract all the memory types. I successfully extract flash, eeprom and fuses. The problem is that i can't read SRAM memory. (on arduino UNO)
I tryed:

  • ICSP
  • Serial
  • dwire (i activated the dwire mode and now i can't dezactivate it an dmy board is useless)
  • i don't have money for expensive programmers like Atmel ICE
  • I also can't upload a program to firmware to read and send me the SRAM memory because it will damage the state of the board (i need to be as i found it so i can do forensics good)

I use avrdude for the avr boards and gbd for arm boards.
Please help

Hate to break it to you, but SRAM is volatile. When the board is powered down, it's gone.

1 Like

As far as I know, there isn't a way to read the contents of the SRAM using an external device such as a PROM programmer. Removing power from the device (328P on an UNO) will loose the contents of the SRAM anyway.

I know that, but the idea is that i will build a mobile kit for forensics and there will be cases (like investigate IoT systems) that i will need to visualize SRAM memory so i can know what processes are active on the board

The UNO uses a microcontroller where all memory is internal to the device. It's not like a traditional microprocessor based system where you could hold the chip in reset and then snoop around on the address and data lines to examine the contents of the memory devices.

So i can't extract the SRAM? I was told that the dwire protocol could do that but i couldn't make it work and broke the UNO

If you know the code you will be able to reverse engineer the layout of the variables in RAM and simulate the behaviour of the code.

According to Wikipedia article on debugWIRE:

debugWIRE is activated by setting (programming to zero) of the fuse DWEN (debugWIRE enable), normally located in the high fuse byte. After this action the /RESET pin function isn't available anymore and the ISP protocol cannot be used.

You would need a way to set this fuse bit and then likely isolate the RESET pin to use the debugWIRE protocol.

You might want to read section 25 of the datasheet covering the use of debugWIRE which lists certain hardware conditions that have to be met in order to use debugWIRE.

So if i decompile the code i could simulate the SRAM memory. I will start learn a little about it and then i will try it. This still applies if my system is connectet in the internet?

I will look in that too, i surely miss something

What if i extract the flash, add a code that reads and send me the ram memory? And at the aftermath analysis i exclude the processes that i upload?

Isn't forensics about examining something without changing it?

You're right :frowning:

Maybe this code inspires (experiments from the past on AVR)

DWire should be able to extract the RAM, but the auto-reset circuitry on most Arduinos will interfere with the operation of DWire. (Also, despite a few reverse-engineering efforts, DWire is largely "proprietary.") (And you enable DWire by re-writing the fuses, which is pretty "invasive", and as you found out, if you can't use DWire thereafter to unset the fuse, you're stuck.)

Finally, DWire would only work on a subset of Arduinos. Other Arduinos (one where examining the RAM might be more interesting) use other protocols. (UPDI, "SWD", or JTAG, to name a few.)

How about a relatively cheap programmer like a Microchip SNAP?
(This sounds like a project that ought to have SOME funding behind it!)

Depending on how the fuses have been set with lock bit protection, you may not even get this far:

Some firms offer a service for extracting the flash memory contents from some types of "locked" microcontrollers. This could mean grinding away or disolving the chip package to get a direct electrical contact to it.

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.