4

I'm reversing a closed platform to try gain execution using an exploit, a stack overflow. I've been told that (since there are no debuggers) the best way is to use RAM dumps (that I have) to try understand how long the buffer is, where the Link Register after the buffer is, how the calling convention works... so I can create a exploit successfully.

More info about the platform.

  • ARM Architecture (ARM9 and ARM11 processors)
  • NX bit but no ASLR (That's why I need to know also which memory pages are executable to get ROP gadgets)
  • I have no debuggers. Only RAM Dumps

I would like to know how can I identify the stack in memory (although there may be more than one) and how to identify also memory pages, and know which ones are executable.

  • 1
    How many dumps do you have ? What is the timeline of getting these dumps (are there dumps that were taken closely? What is the size of these dumps ? – w s Dec 25 '16 at 9:54
  • I can have as much dumps as we need. They are 128mb in size and I can take them closely. Also I can make changes In the system if needed. – Pedro Javier Fernández Dec 25 '16 at 12:33
  • How do you get the dumps ? Is it JTAG ? Do you know what is the memory map of the device ? – w s Dec 25 '16 at 12:48
  • In a real situation, I would rely on hardware hackers to obtain RAM dumps, but In this case I'm using the same exploit to dump the whole FCRam. Basically I'm trying to understand the exploit by myself(as if I were told, there's an exploit In X, no more info) not sure what the memory map is but surely I don't know it. – Pedro Javier Fernández Dec 25 '16 at 12:53
  • so any thoughts or ideas @ws ? – Pedro Javier Fernández Dec 26 '16 at 19:51
5

The only idea I have is to compare the dumps. The places that are same in all dumps are code or read only data. The places that are changing from dump to dump are either stack or section like .bss. After finding places that are not changing I'd try to disassemble these places in order to divide between code and data.

I think that the places with the code should have higher entropy then places with the data but I can not prove it formally.

In addition you probably should take in consideration the following:

  • There is a possibility that executed code comes from flash and is executed from from the flash directly. The code in RAM may be not complete.
  • There is a possibility that the code is unpacking itself during startup. I've seen such a things with itcm and dtcm memory areas.
  • There are memory mapped registers, intended to work with different devices, so you'll probably see a lot of accesses to these memory areas. The best way to find the information about these addresses is to find a datasheet and read it carefully, it probably contains the memory map of the system.

Generally speaking I'm not pretty sure that working with RAM is the best solution, and if I'd be tasked with such a thing I'd try to solder out the flash memory with initial image, read it and reverse engineer it statically.

  • You have good ideas, lets see if we can get something. Firstly RAM Dumps is the only thing I have to work with. The platform has a NAND chip, with its contents crypted. Also when I said FCRam I just mean RAM, but the chips are actually Fast Cycle DRams. No flash or similar apart from the NAND. If you had to reverse / discover an exploit in such platform (cryptography is done w/ special hardware so don't even try to static reverse the contents of the NAND), and you Know RAM dumps are not encrypted, what would you do? My idea is to analyze RAM dumps, but maybe there are other ways. – Pedro Javier Fernández Dec 27 '16 at 18:56
  • The next point, is that it has both an ARM9 and ARM11 Processors. I just guessed that stacks have patterns that would allow us to identify them in memory, this happens on some platforms and I believed it could be a thing on ARM too. Also, there may be multiple stacks, since the system runs several processes and applications. Just to make something clear; I would like to learn how would someone exploit a closed platform if he doesn't have any technical details of the system, not depending on others' work. – Pedro Javier Fernández Dec 27 '16 at 19:00
  • In addition. When you say that code sections may have higher entropy than data, it is because code should be "always the same" and data can change, right? – Pedro Javier Fernández Dec 27 '16 at 19:04
  • Generally speaking I have no other ideas in such a case. If your NAND is encrypted (by the way, how did you arrive to this conclusion ? From spec ? From analyzing the content of the NAND ?) the only easy way is really analyzing RAM dumps. Regarding entropy: the code should look more random then data. I know it from my own observations (it was always so in all dumps/binaries/firmwares I worked with) and the intuition behind this conclusion is as follows: processor designers trying to pack instruction definitions as effective as possible, but programmers never trying to store data efficiently. – w s Dec 28 '16 at 7:21
  • Actually this vulnerability has been exploited, but no public info has been published. That's why I'm trying to learn and exploit it by myself. An example that demonstrate that the NAND is encrypted and probably signed too is that you can dump a device NAND using hardware hacks but if you inject it to another device it won't run it. So yes they are somehow encrypted w/ unique keys per device. The entropy subject is really interesting and extensive too. Is there any way we can message? Comments are not enough for this subject. This would speed up finding the solution. – Pedro Javier Fernández Dec 28 '16 at 14:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.