Add support for loading Core files #152

radare · 2013-07-19T08:16:03Z

plain core files
/proc/kcore support r2 /proc/kcore issues/enhancements #5164

XVilka · 2014-02-05T22:52:08Z

and exporting them into elf/pe/whatever.

radare · 2015-08-25T17:52:07Z

See t.formats/elf/core

XVilka · 2015-10-16T15:37:40Z

Could be helpful http://backtrace.io/blog/blog/2015/10/03/whats-a-coredump/

Maijin · 2016-02-27T18:19:35Z

See also this issue @z03 you may be interested

leberus · 2016-03-21T16:33:53Z

Hi! Is there anyone taking a look at this? If not, I'd like to take a look into it!

alvarofe · 2016-03-22T18:03:26Z

afaik there is no one working on this. So go ahead @leberus :)

leberus · 2016-03-23T14:42:05Z

Ok, then I'll take it ;)

radare · 2016-03-24T13:42:11Z

👍

On 23 Mar 2016, at 15:42, leberus [email protected] wrote:

Ok, then I'll take it ;)

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub

radare · 2016-04-12T13:20:06Z

This is already supported for OSX and iOS

leberus · 2016-05-03T15:24:33Z

leberus@4e11f62

It's working on Linux x86_64. Unfortunately is still missing thread support (didn't have so much time).
Another thing which is missing is NT_X86_XSTATE NOTE. I still need to find out from where should I take that.
There also some minor things to be fixed(like pr_psargs is not being set because i didn't know if radare stores the exec's args somewhere, if not we can take that from proc, the cursignal neither and some other variables).

Much more work is still to be done, but i'd say that something is showing up. I'll add the support for threads in the next days and fix the errors as well.

Maijin · 2016-05-03T15:35:02Z

Can you do a Pull request ?

radare · 2016-05-03T17:39:29Z

i added some comments in your commit, please, fix them and send a PR for further review

On 03 May 2016, at 17:35, Maijin [email protected] wrote:

Can you do a Pull request ?

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub #152 (comment)

leberus · 2016-05-03T18:37:02Z

Thanks for the comments! I'll write down it and I'll fix all in the next days ;)

radare · 2016-05-03T19:36:59Z

👍

On 03 May 2016, at 20:37, leberus [email protected] wrote:

Thanks for the comments! I'll write down it and I'll fix all in the next days ;)

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub

radare · 2016-05-16T21:22:11Z

ping

radare · 2016-05-21T14:19:58Z

it is merged now. still needs more work, but at least it generates a dump. the implementation is not yet complete, and r2 is not able to load properly those dumps yet. so the task is not complete

leberus · 2016-05-21T14:57:28Z

I know, it's missing PC state which is being saved in X86STATE. I will work
on it in the next days, so r2 could load it. That would be great :).
Thanks for.all :)
El dia 21/05/2016 16:20, "radare" [email protected] va escriure:

it is merged now. still needs more work, but at least it generates a dump.
the implementation is not yet complete, and r2 is not able to load properly
those dumps yet. so the task is not complete

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#152 (comment)

radare · 2016-05-21T15:17:04Z

👍 would be great if that would be ready before the release (aka monday)

I'll do more reviews to your code since then and remove many debug printfs which should not appear.

On 21 May 2016, at 16:57, leberus [email protected] wrote:

I know, it's missing PC state which is being saved in X86STATE. I will work
on it in the next days, so r2 could load it. That would be great :).
Thanks for.all :)
El dia 21/05/2016 16:20, "radare" [email protected] va escriure:

it is merged now. still needs more work, but at least it generates a dump.
the implementation is not yet complete, and r2 is not able to load properly
those dumps yet. so the task is not complete

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#152 (comment)

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub

leberus · 2016-05-21T18:41:18Z

I'll try my best! ;)
El dia 21/05/2016 17:17, "radare" [email protected] va escriure:

👍 would be great if that would be ready before the release (aka monday)

I'll do more reviews to your code since then and remove many debug printfs
which should not appear.

On 21 May 2016, at 16:57, leberus [email protected] wrote:

I know, it's missing PC state which is being saved in X86STATE. I will
work
on it in the next days, so r2 could load it. That would be great :).
Thanks for.all :)
El dia 21/05/2016 16:20, "radare" [email protected] va
escriure:

it is merged now. still needs more work, but at least it generates a
dump.
the implementation is not yet complete, and r2 is not able to load
properly
those dumps yet. so the task is not complete

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#152 (comment)

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#152 (comment)

leberus · 2016-05-22T07:30:37Z

Hi @radare, could you tell me how are you loading the coredump on r2?

leberus · 2016-05-22T17:03:36Z

ping

leberus · 2016-05-22T19:01:51Z

Hi, I was checking, and I saw something spooky:

With the last changes, I saw that some maps which should be dumped are not dumped anymore.
With my last pull request, that was working, but I cloned the last git from radare2, and some maps are missing within the corefile.

This is a test with the same exec, with my code:

$ ls -l
total 480
-rw-r--r-- 1 leber leber 232436 May 22 20:45 corefile2

$ readelf -l corefile2

Elf file type is CORE (Core file)
Entry point 0x0 
There are 17 program headers, starting at offset 64

Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  NOTE           0x00000000000003f8 0x0000000000000000 0x0000000000000000
                 0x00000000000007fc 0x0000000000000000  R      1
  LOAD           0x0000000000000bf4 0x0000000000400000 0x0000000000000000
                 0x0000000000000000 0x0000000000001000  R E    1
  LOAD           0x0000000000000bf4 0x0000000000600000 0x0000000000000000
                 0x0000000000001000 0x0000000000001000  RW     1
  LOAD           0x0000000000001bf4 0x00007f980411f000 0x0000000000000000
                 0x0000000000000000 0x00000000001a2000  R E    1
  LOAD           0x0000000000001bf4 0x00007f98044c0000 0x0000000000000000
                 0x0000000000004000 0x0000000000004000  R      1
  LOAD           0x0000000000005bf4 0x00007f98044c4000 0x0000000000000000
                 0x0000000000002000 0x0000000000002000  RW     1
  LOAD           0x0000000000007bf4 0x00007f98044c6000 0x0000000000000000
                 0x0000000000004000 0x0000000000004000  RW     1
  LOAD           0x000000000000bbf4 0x00007f98044ca000 0x0000000000000000
                 0x0000000000000000 0x0000000000020000  R E    1
  LOAD           0x000000000000bbf4 0x00007f98046bb000 0x0000000000000000
                 0x0000000000003000 0x0000000000003000  RW     1
  LOAD           0x000000000000ebf4 0x00007f98046e7000 0x0000000000000000
                 0x0000000000003000 0x0000000000003000  RW     1
  LOAD           0x0000000000011bf4 0x00007f98046ea000 0x0000000000000000
                 0x0000000000001000 0x0000000000001000  R      1
  LOAD           0x0000000000012bf4 0x00007f98046eb000 0x0000000000000000
                 0x0000000000001000 0x0000000000001000  RW     1
  LOAD           0x0000000000013bf4 0x00007f98046ec000 0x0000000000000000
                 0x0000000000001000 0x0000000000001000  RW     1
  LOAD           0x0000000000014bf4 0x00007fffbe527000 0x0000000000000000
                 0x0000000000021000 0x0000000000021000  RW     1
  LOAD           0x0000000000035bf4 0x00007fffbe5fc000 0x0000000000000000
                 0x0000000000002000 0x0000000000002000  R      1
  LOAD           0x0000000000037bf4 0x00007fffbe5fe000 0x0000000000000000
                 0x0000000000002000 0x0000000000002000  R E    1
  LOAD           0x0000000000039bf4 0xffffffffff600000 0x0000000000000000
                 0x0000000000001000 0x0000000000001000  R E    1

And this is the corefile which is generated with the same exec, but with your changes:

$ ls -l
-rw-r--r-- 1 leber leber  15348 May 22 20:26 corefile

$ readelf -l corefile

Elf file type is CORE (Core file)
Entry point 0x0
There are 17 program headers, starting at offset 64

Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  NOTE           0x00000000000003f8 0x0000000000000000 0x0000000000000000
                 0x00000000000007fc 0x0000000000000000  R      1
  LOAD           0x0000000000000bf4 0x0000000000400000 0x0000000000000000
                 0x0000000000000000 0x0000000000001000  R E    1
  LOAD           0x0000000000000bf4 0x0000000000600000 0x0000000000000000
                 0x0000000000000000 0x0000000000001000  RW     1
  LOAD           0x0000000000000bf4 0x00007fcfbcc6c000 0x0000000000000000
                 0x0000000000000000 0x00000000001a2000  R E    1
  LOAD           0x0000000000000bf4 0x00007fcfbd00d000 0x0000000000000000
                 0x0000000000000000 0x0000000000004000  R      1
  LOAD           0x0000000000000bf4 0x00007fcfbd011000 0x0000000000000000
                 0x0000000000000000 0x0000000000002000  RW     1
  LOAD           0x0000000000000bf4 0x00007fcfbd013000 0x0000000000000000
                 0x0000000000000000 0x0000000000004000  RW     1
  LOAD           0x0000000000000bf4 0x00007fcfbd017000 0x0000000000000000
                 0x0000000000000000 0x0000000000020000  R E    1
  LOAD           0x0000000000000bf4 0x00007fcfbd208000 0x0000000000000000
                 0x0000000000000000 0x0000000000003000  RW     1
  LOAD           0x0000000000000bf4 0x00007fcfbd234000 0x0000000000000000
                 0x0000000000000000 0x0000000000003000  RW     1
  LOAD           0x0000000000000bf4 0x00007fcfbd237000 0x0000000000000000
                 0x0000000000000000 0x0000000000001000  R      1
  LOAD           0x0000000000000bf4 0x00007fcfbd238000 0x0000000000000000
                 0x0000000000000000 0x0000000000001000  RW     1
  LOAD           0x0000000000000bf4 0x00007fcfbd239000 0x0000000000000000
                 0x0000000000000000 0x0000000000001000  RW     1
  LOAD           0x0000000000000bf4 0x00007fff18775000 0x0000000000000000
                 0x0000000000000000 0x0000000000021000  RW     1
  LOAD           0x0000000000000bf4 0x00007fff187fc000 0x0000000000000000
                 0x0000000000002000 0x0000000000002000  R      1
  LOAD           0x0000000000002bf4 0x00007fff187fe000 0x0000000000000000
                 0x0000000000002000 0x0000000000002000  R E    1
  LOAD           0x0000000000004bf4 0xffffffffff600000 0x0000000000000000
                 0x0000000000001000 0x0000000000001000  R E    1

Something is wrong. This is easy to test if you try the code from radare2, and the code you can get from https://github.com/leberus/radare2.git in the coresupport branch.

PD: Don't take this as a blame please, it justs that I think it should not work in that way.
PD2: I tried to load the corefile I generated with gdb, and I can see a valid entry point. Could you tell me how are you loading the corefile in r2 (just the commands :))
PD3: If you think I'm the right one I'd be glad to fix this.

radare · 2016-05-23T07:09:50Z

r2 corefile

On 22 May 2016, at 09:30, leberus [email protected] wrote:

Hi @radare, could you tell me how are you loading the coredump on r2?

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub

leberus · 2016-05-23T07:11:39Z

Please see the comment above

radare · 2016-05-23T07:13:56Z

There were some really strange conditionals which looked wrong so maybe i missunferstood them. Gcc was complaining about dead code and such.

The way to load a core file is just r2 corefile. This will set the register state and the stack must be visible and disassembling in the program counter address should show real code to work. This is how it works with apple cores at least. Never tried with windows minidumps, but the process should be similar.

We will have time to think and discuss about better ways to load corefiles when all this stuff works

On 22 May 2016, at 21:01, leberus [email protected] wrote:

Hi, I was checking, and I saw something spooky:

With the last changes, I saw that some maps which should be dumped are not dumped anymore.
With my last pull request, that was working, but I cloned the last git from radare2, and some maps are missing within the corefile.

This is a test with the same exec, with my code:

$ ls -l
total 480
-rw-r--r-- 1 leber leber 232436 May 22 20:45 corefile2
$ readelf -l corefile2

Elf file type is CORE (Core file)
Entry point 0x0
There are 17 program headers, starting at offset 64

Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
NOTE 0x00000000000003f8 0x0000000000000000 0x0000000000000000
0x00000000000007fc 0x0000000000000000 R 1
LOAD 0x0000000000000bf4 0x0000000000400000 0x0000000000000000
0x0000000000000000 0x0000000000001000 R E 1
LOAD 0x0000000000000bf4 0x0000000000600000 0x0000000000000000
0x0000000000001000 0x0000000000001000 RW 1
LOAD 0x0000000000001bf4 0x00007f980411f000 0x0000000000000000
0x0000000000000000 0x00000000001a2000 R E 1
LOAD 0x0000000000001bf4 0x00007f98044c0000 0x0000000000000000
0x0000000000004000 0x0000000000004000 R 1
LOAD 0x0000000000005bf4 0x00007f98044c4000 0x0000000000000000
0x0000000000002000 0x0000000000002000 RW 1
LOAD 0x0000000000007bf4 0x00007f98044c6000 0x0000000000000000
0x0000000000004000 0x0000000000004000 RW 1
LOAD 0x000000000000bbf4 0x00007f98044ca000 0x0000000000000000
0x0000000000000000 0x0000000000020000 R E 1
LOAD 0x000000000000bbf4 0x00007f98046bb000 0x0000000000000000
0x0000000000003000 0x0000000000003000 RW 1
LOAD 0x000000000000ebf4 0x00007f98046e7000 0x0000000000000000
0x0000000000003000 0x0000000000003000 RW 1
LOAD 0x0000000000011bf4 0x00007f98046ea000 0x0000000000000000
0x0000000000001000 0x0000000000001000 R 1
LOAD 0x0000000000012bf4 0x00007f98046eb000 0x0000000000000000
0x0000000000001000 0x0000000000001000 RW 1
LOAD 0x0000000000013bf4 0x00007f98046ec000 0x0000000000000000
0x0000000000001000 0x0000000000001000 RW 1
LOAD 0x0000000000014bf4 0x00007fffbe527000 0x0000000000000000
0x0000000000021000 0x0000000000021000 RW 1
LOAD 0x0000000000035bf4 0x00007fffbe5fc000 0x0000000000000000
0x0000000000002000 0x0000000000002000 R 1
LOAD 0x0000000000037bf4 0x00007fffbe5fe000 0x0000000000000000
0x0000000000002000 0x0000000000002000 R E 1
LOAD 0x0000000000039bf4 0xffffffffff600000 0x0000000000000000
0x0000000000001000 0x0000000000001000 R E 1
And this is the corefile which is generated with the same exec, but with your changes:

$ ls -l
-rw-r--r-- 1 leber leber 15348 May 22 20:26 corefile
$ readelf -l corefile

Elf file type is CORE (Core file)
Entry point 0x0
There are 17 program headers, starting at offset 64

Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
NOTE 0x00000000000003f8 0x0000000000000000 0x0000000000000000
0x00000000000007fc 0x0000000000000000 R 1
LOAD 0x0000000000000bf4 0x0000000000400000 0x0000000000000000
0x0000000000000000 0x0000000000001000 R E 1
LOAD 0x0000000000000bf4 0x0000000000600000 0x0000000000000000
0x0000000000000000 0x0000000000001000 RW 1
LOAD 0x0000000000000bf4 0x00007fcfbcc6c000 0x0000000000000000
0x0000000000000000 0x00000000001a2000 R E 1
LOAD 0x0000000000000bf4 0x00007fcfbd00d000 0x0000000000000000
0x0000000000000000 0x0000000000004000 R 1
LOAD 0x0000000000000bf4 0x00007fcfbd011000 0x0000000000000000
0x0000000000000000 0x0000000000002000 RW 1
LOAD 0x0000000000000bf4 0x00007fcfbd013000 0x0000000000000000
0x0000000000000000 0x0000000000004000 RW 1
LOAD 0x0000000000000bf4 0x00007fcfbd017000 0x0000000000000000
0x0000000000000000 0x0000000000020000 R E 1
LOAD 0x0000000000000bf4 0x00007fcfbd208000 0x0000000000000000
0x0000000000000000 0x0000000000003000 RW 1
LOAD 0x0000000000000bf4 0x00007fcfbd234000 0x0000000000000000
0x0000000000000000 0x0000000000003000 RW 1
LOAD 0x0000000000000bf4 0x00007fcfbd237000 0x0000000000000000
0x0000000000000000 0x0000000000001000 R 1
LOAD 0x0000000000000bf4 0x00007fcfbd238000 0x0000000000000000
0x0000000000000000 0x0000000000001000 RW 1
LOAD 0x0000000000000bf4 0x00007fcfbd239000 0x0000000000000000
0x0000000000000000 0x0000000000001000 RW 1
LOAD 0x0000000000000bf4 0x00007fff18775000 0x0000000000000000
0x0000000000000000 0x0000000000021000 RW 1
LOAD 0x0000000000000bf4 0x00007fff187fc000 0x0000000000000000
0x0000000000002000 0x0000000000002000 R 1
LOAD 0x0000000000002bf4 0x00007fff187fe000 0x0000000000000000
0x0000000000002000 0x0000000000002000 R E 1
LOAD 0x0000000000004bf4 0xffffffffff600000 0x0000000000000000
0x0000000000001000 0x0000000000001000 R E 1
Something is wrong. This is easy to test if you try the code from radare2, and the code you can get from https://github.com/leberus/radare2.git in the coresupport branch.

PD: Don't take this as a blame please, it justs that I think it should not work in that way.
PD2: I tried to load the corefile I generated with gdb, and I can see a valid entry point. Could you tell me how are you loading the corefile in r2 (just the commands :))

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub

leberus · 2016-05-23T07:17:51Z

mmm, maybe would be a nice ide to set it up as it was before? at least for dumping the good maps, because now most of the maps are missing and this lead to a wrong behaviour.
Anyway I'll do some test loading the corefile which my code generates and I'll come to you again.
Thanks.

radare · 2016-05-23T07:44:48Z

Fix the maps thing i bet this is the oneliner conditional thats on top of the loop. I dont know which is the expected condition to be in there

I also moved all the isValidSection checks into separate functions for readabiliy and reusability. So the fix should be easy if you know what must be cloned and what not. See the comments i added.

Btw release is today, so it will be great if you could fix this "if" at least.

I have a mail from coverity with a lot of errors on this code, i will address them this morning but this shouldnt conflict with your patch, so go ahead

On 23 May 2016, at 09:17, leberus [email protected] wrote:

mmm, maybe would be a nice ide to set it up as it was before? at least for dumping the good maps, because now most of the maps are missing and this lead to a wrong behaviour.
Anyway I'll do some test loading the corefile which my code generates and I'll come to you again.
Thanks.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub

leberus · 2016-05-23T07:46:55Z

I did a quick test. The process can you see it under http://pastebin.com/rcJEVJ0W
I generate two corefiles, one with r2 and another one with gcore(from the same exec), and then I load both with gdb, and from there I could see the stack, the registers and so on.
But with "r2 corefile", if I do a "> dr" I don't se anything.

radare · 2016-05-23T07:57:22Z

The regs must be loaded and your code doesnt do that yet. The arw command is the one that sets the reg arena

On 23 May 2016, at 09:46, leberus [email protected] wrote:

I did a quick test. The process can you see it under
I generate two corefiles, one with r2 and another one with gcore(from the same exec), and then I load both with gdb, and from there I could see the stack, the registers and so on.
But with "r2 corefile", if I do a "> dr" I don't se anything.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub

leberus · 2016-05-23T08:02:14Z

I fixed it in https://github.com/radare/radare2/compare/master...leberus:mapping?expand=1, was just a small typo error.
So now r2 is generating the corefile correctly with all dumps that should be dumped.

In the other hand, just put all errors which coverity is pointing out, and I'll fix them. I'd like to do it so I learn from mistakes.

A another thing:as I said, I was not writing this with the though that r2 could load the corefile, my intention was just that r2 was able to dump a corefile from memory and registers, but not load anything. I'd like to do it of course, but this was not my first though. I think this was a misunderstanding from my part with the Task. I mixed this task with the task of #4124 so I apologize for it.

radare · 2016-05-25T13:09:23Z

Also, core support should be implemented for 32 bits, as well as arm and mips. Yesterday i removed the use of a syscall that its only available from kernel 3.2 to just use the io api, doesnt seems to break anything. Also i disabled it for android and non x86-64 linux targets

On 23 May 2016, at 10:02, leberus [email protected] wrote:

I'll fix the maps thing first, and later I'll come to this because I have some questions.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub

leberus · 2016-05-25T13:23:55Z

I'm working on enabling thread support and dump the extended state register as well. Once this is working in a proper way, I'll add support for 32 bits because just minor checks must be put in place.
On the way I'll recheck the code to synthesize it as much as possible.
Thanks.

PD: Would be also nice for me if you find something more, to tell me, i'd like to fix it.

radare · 2016-05-25T14:15:53Z

awesome! feel free to remove the debug messages as soon as they are not needed

thanks!

On 25 May 2016, at 15:23, leberus [email protected] wrote:

I'm working on enabling thread support and dump the extended state register as well. Once this is working in a proper way, I'll add support for 32 bits because just minor checks must be put in place.
On the way I'll recheck the code to synthesize it as much as possible.
Thanks.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub #152 (comment)

zlowram · 2016-06-02T10:49:16Z

Hey @leberus! Glad to see that you are working on enable coredump support for linux x86. How is it going? I'm currently needing it and wanted to avoid using GDB (r2 is way cooler :P). Thanks for your efforts!

leberus · 2016-06-02T16:03:14Z

Hi @zlowram! I'm almost done with thread support and x86 support as well. Just minor things are left(like cleanup a little bit and do the final tests).
Once I'm done with that (I'm talking about "generate a coredump" feature), I'll put my hands on the "load a coredump" feature :D.
I

zlowram · 2016-06-02T16:13:37Z

Whoa, sounds great! Looking forward to it :P

leberus · 2016-06-03T13:26:34Z

hi @radare, I have a couple of questions:

1- While cleaning my code, I decided to use dbg->maps to get all maps, instead of parsing /proc/pid/maps myself, so I'm not reinventing the weel. But unfortunately I found that r2 does not include the offset field within RDebugMap structure (which a important field for at least coredump). I though about create a new field within RDebugMap to include "offset" value, and then do something like this in r_debug_native_map_get function:

Create a region3[100](as region and region2 are being used for start_addr and end_addr)
Change the code a little bit:

sscanf (line, "%s %s %s %*s %*s %[^\n]", &region[2], &region3[2], perms, path);
region[0] = region2[0] = region3[0] = '0';
region[1] = region2[1] = region3[1] = 'x';
map = r_debug_map_new (path, r_num_get (NULL, region),
                                r_num_get (NULL, region2), r_num_get (NULL, region3), perm, 0);

This might be a little bit messy because this function is being called by:

debug/p/native/xnu/xnu_debug.c
debug/p/native/maps/darwin.c
debug/p/native/maps/windows.c
debug/p/debug_bf.c
debug/p/debug_native.c
debug/map.c

So maybe that's too much, and if that is the case I could parse the /proc/pid/maps myself as I did.

2- That's one thing I spotted during the final tests about thread support:

file = r_str_newf ("/proc/%d/maps", mypid);
buff = r_file_slurp (file, &size_file);

This is not enough for a process which has a large number of maps (f.i my iceweasel), and buff is being truncated by the size of 65536 by this check that r_file_slurp performs.

if (sz==0)
                sz = 65536;

So I'm wondering how I should solve this without bypassing the sandbox file utils. (maybe there is a function which gets a char one by one? I didn't see it)

Thanks in advance

radare · 2016-06-05T21:34:49Z

Hi

On 03 Jun 2016, at 15:26, leberus [email protected] wrote:

hi @radare, I have a couple of questions:

1- While cleaning my code, I decided to use dbg->maps to get all maps, instead of parsing /proc/pid/maps myself, so I'm not reinventing the weel. But unfortunately I found that r2 does not include the offset field within RDebugMap structure (which a important field for at least coredump). I though about create a new field within RDebugMap to include "offset" value, and then do something like this in r_debug_native_map_get function:

Good. This is how I was expecting to do it. For offset you mean the paddr? Personally i would like to use vaddr/paddr than the confusing offset/addr names. What do you think?

But.. I didnt knew you could get the paddr when listig the maps

Create a region3100
Change the code a little bit:
sscanf (line, "%s %s %s %_s %_s %[^\n]", &region[2], &region3[2], perms, path);
region[0] = region2[0] = region3[0] = '0';
region[1] = region2[1] = region3[1] = 'x';
map = r_debug_map_new (path, r_num_get (NULL, region),
r_num_get (NULL, region2), r_num_get (NULL, region3), perm, 0);
This might be a little bit messy because this function is being called by:

Well main issue here is that overflows may halpen pretty easily if the user controls the contents in /proc, or the kernel changes the field lengths. Both are rare cases but is better not to assume things that are not under our control

debug/p/native/xnu/xnu_debug.c
debug/p/native/maps/darwin.c
debug/p/native/maps/windows.c
debug/p/debug_bf.c
debug/p/debug_native.c
debug/map.c

So maybe that's too much, and if that is the case I could parse the /proc/pid/maps myself as I did.

2- That's one thing I spotted during the final tests about thread support:

file = r_str_newf ("/proc/%d/maps", mypid);
buff = r_file_slurp (file, &size_file);
For a process which has a large number of maps, this is not enough (f.i my iceweasel) and buff is being truncated by the size of 65536 by this check that r_file_slurp performs.

if (sz==0)
sz = 65536;

Yes this looks wrong to me too, and this was probably done because slurping a harddisk results in zerosize file but with pretty huge contents. So this way at least it avoids exploding.

So I'm wondering how I should solve this without bypassing the sandbox file utils. (maybe there is a function which gets a char one by one? I didn't see it)

Maybe we should check if file is regular (no device, socket, etc) and later go read until eof. Another option would be to increase that size to 512KB or so but that limit will be still a hack

Thanks in advance

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

leberus · 2016-06-08T00:59:51Z

Hi @radare ,

Regarding the problem with the true size of a proc file:
I've put a check within r_file_slurp function which checks if the file is regular, and if it is, it gets the true size of the proc file by going through a function I created in libpr/util/file.c, which gets the size reading char after char till it reaches EOF, so this problem is solved.

Regarding the problem with offset field:
By offset I meant the offset within a file, which is the third field in a /proc/$$/maps (1. addr-addr_end, 2- maps, 3- offset, etc..).
This field is not being stored in RDebugMap, and it's important for NT_FILE note (which is the note which stores the backed-file maps).
Another thing is that the perm field just stores rwx perms, and doesn't check if it has 'p' or 's' char (privare or shared), so I couldn't rely on that field.

I could solve both problems by parsing maps file myself, but in the future I'll fix it because we could save some lines of code and have a more consistent RDebugMap structure as well.
Right now is something like this

ret = r_debug_map_sync (dbg);
    if (!ret) return NULL;
    r_list_foreach (dbg->maps, iter, map) {
        linux_map_entry_t *pmentry = R_NEW0 (linux_map_entry_t);
        if (!pmentry) goto error;
        pmentry->start_addr = map->addr;
        pmentry->end_addr = map->addr_end;
        pmentry->name = strncmp (map->name, "unk", strlen ("unk")) ? strdup (map->name) : NULL;
        /* Since RDebugMap does not provide an offset field (offset within the file), and the perms field
            does not contain if is share or private, we need to check that ourself */
        get_map_perms_and_offset (pmentry->start_addr, pmentry->end_addr, buff_maps, &flags_perm, &offset);
        pmentry->perms = flags_perm;
        pmentry->offset = offset;

is much less than before since I'm using RDebugMap structure.
I plan to do the PR tomorrow.

Thanks

radare · 2016-06-08T06:40:22Z

Sounds good

On 08 Jun 2016, at 02:59, leberus [email protected] wrote:

Hi @radare ,

Regarding the problem with the true size of a proc file:
I've put a check within r_file_slurp function which checks if the file is regular, and if it is, it gets the true size of the proc file by going through a function I created in libpr/util/file.c, which gets the size reading char after char till it reaches EOF, so this problem is solved.

Regarding the problem with offset field:
By offset I meant the offset within a file, which is the third field in a /proc/$$/maps (1. addr-addr_end, 2- maps, 3- offset, etc..).
This field is not being stored in RDebugMap, and it's important for NT_FILE note (which is the note which stores the backed-file map).
Another thing is that the perm field just stores rwx perms, and doesn't check if it has de 'p' or 's' char (privare or shared), so I couldn't rely on that field.

I could solve both problems by parsing maps file myself, but in the future I'll fix it because we could save some lines of code and have a more consistent RDebugMap structure as well.
Right now is smth like:

ret = r_debug_map_sync (dbg);
if (!ret) return NULL;
r_list_foreach (dbg->maps, iter, map) {
linux_map_entry_t pmentry = R_NEW0 (linux_map_entry_t);
if (!pmentry) goto error;
pmentry->start_addr = map->addr;
pmentry->end_addr = map->addr_end;
pmentry->name = strncmp (map->name, "unk", strlen ("unk")) ? strdup (map->name) : NULL;
/ Since RDebugMap does not provide an offset field (offset within the file), and the perms field
does not contain if is share or private, we need to check that ourself */
get_map_perms_and_offset (pmentry->start_addr, pmentry->end_addr, buff_maps, &flags_perm, &offset);
pmentry->perms = flags_perm;
pmentry->offset = offset;
is much less than before since I'm using RDebugMap structure.
I plan to do the PR tomorrow.

Thanks

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

leberus · 2016-07-04T13:28:36Z

Hi @radare, here you mentioned some work you did about being able of "loading" a coredump file and then the need to copy a line in order to check the regs. Could you point me to your work?
Now that I'm back I'd like to return to this point.

Thanks

radare · 2016-07-04T13:29:45Z

it just works out of the box, r2 corefile

git log | grep core may help

On 04 Jul 2016, at 15:28, leberus [email protected] wrote:

Hi @radare https://github.com/radare, here #5104 (comment) you mentioned some work you did about being able of "loading" a coredump file and then the need to copy a line in order to check the regs. Could you point me to your work?
Now that I'm back I'd like to return to this point.

Thanks

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub #152 (comment), or mute the thread https://github.com/notifications/unsubscribe/AA3-ljGrS5oF4TZfLBWInXpo0eqrJx7wks5qSQqGgaJpZM4A1Fbd.

leberus · 2016-07-04T13:38:09Z

I got the commit 2702c3f
Thanks

2016-07-04 15:29 GMT+02:00 radare [email protected]:

it just works out of the box, r2 corefile

git log | grep core may help

On 04 Jul 2016, at 15:28, leberus [email protected] wrote:

Hi @radare https://github.com/radare, here <
https://github.com/radare/radare2/pull/5104#issuecomment-225016066> you
mentioned some work you did about being able of "loading" a coredump file
and then the need to copy a line in order to check the regs. Could you
point me to your work?
Now that I'm back I'd like to return to this point.

Thanks

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <
https://github.com/radare/radare2/issues/152#issuecomment-230290851>, or
mute the thread <
https://github.com/notifications/unsubscribe/AA3-ljGrS5oF4TZfLBWInXpo0eqrJx7wks5qSQqGgaJpZM4A1Fbd
.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#152 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AH3YFawu81KVq40AReVELn5HW3Nm9Nowks5qSQrQgaJpZM4A1Fbd
.

radare · 2016-08-08T10:11:20Z

i think its all fixed now. closing for now

jvoisin added debug-info labels May 6, 2014

Maijin added the hackaton label Nov 20, 2015

radare added this to the 0.10.3 milestone Apr 12, 2016

radare mentioned this issue Apr 12, 2016

Add command to generate coredump in MACH0 or ELF #4124

Open

7 tasks

radare modified the milestones: 0.10.4, 0.10.3 May 21, 2016

radare modified the milestones: 0.10.5, 0.10.4 Jun 25, 2016

radare self-assigned this Aug 8, 2016

radare closed this as completed Aug 8, 2016

Add support for loading Core files #152

Add support for loading Core files #152

Comments

radare commented Jul 19, 2013 • edited Loading

XVilka commented Feb 5, 2014

radare commented Aug 25, 2015

XVilka commented Oct 16, 2015

Maijin commented Feb 27, 2016

leberus commented Mar 21, 2016

alvarofe commented Mar 22, 2016

leberus commented Mar 23, 2016

radare commented Mar 24, 2016

radare commented Apr 12, 2016

leberus commented May 3, 2016

Maijin commented May 3, 2016

radare commented May 3, 2016

leberus commented May 3, 2016

radare commented May 3, 2016

radare commented May 16, 2016

radare commented May 21, 2016

leberus commented May 21, 2016

radare commented May 21, 2016

leberus commented May 21, 2016

leberus commented May 22, 2016

leberus commented May 22, 2016

leberus commented May 22, 2016 • edited Loading

radare commented May 23, 2016

leberus commented May 23, 2016

radare commented May 23, 2016

leberus commented May 23, 2016

radare commented May 23, 2016

leberus commented May 23, 2016 • edited Loading

radare commented May 23, 2016

leberus commented May 23, 2016 • edited Loading

radare commented May 25, 2016

leberus commented May 25, 2016 • edited Loading

radare commented May 25, 2016

zlowram commented Jun 2, 2016

leberus commented Jun 2, 2016

zlowram commented Jun 2, 2016

leberus commented Jun 3, 2016 • edited Loading

radare commented Jun 5, 2016

leberus commented Jun 8, 2016 • edited Loading

radare commented Jun 8, 2016

leberus commented Jul 4, 2016

radare commented Jul 4, 2016

leberus commented Jul 4, 2016

radare commented Aug 8, 2016

radare commented Jul 19, 2013 •

edited

Loading

leberus commented May 22, 2016 •

edited

Loading

leberus commented May 23, 2016 •

edited

Loading

leberus commented May 23, 2016 •

edited

Loading

leberus commented May 25, 2016 •

edited

Loading

leberus commented Jun 3, 2016 •

edited

Loading

leberus commented Jun 8, 2016 •

edited

Loading