Add command to generate coredump in MACH0 or ELF

[radare]

• Generate ELF coredumps on Linux
• Generate ELF coredumps on BSD
• Load ELF coredumps
• Generate MACH0 coredumps (linux/bsd)
• Load mach0 coredumps
• Support mach0 threads
• load region names/filepaths

related #152

[z03]

I'm interested to work on this but need to be pointed in the right direction, should the implementation to generate the core dumps depend on gathering information collectively from the os (aka /proc on linux for elf coredumps) in addition to the r2_debug api? or should the os be used to auto generat coredumps through signals such as SIGABRT/SIGHUP etc..? or should the implementation be left up to the backend debugger, for example use "generate-core-file" if gdb was specified as a backend?

[radare]

The implementation of this must follow different approaches, but focusing on a
generic and portable way by default. This is:

if the system provides a generic way to create a core file:

• add a new callback on debug plugin

if not, just go for the generic way:

• add api in r_debug, like: r_debug_gcore(RDebug *dbg, const char *newcorefile);

I think its safe to go this way, but maybe we can generate a core file in
memory and then

I think windows and linux ( and haikuOS ) provide system primitives to
generate a core file. so this will be implemented in the debug plugin like
this: if (dbg->h && dbg->h->gcore) return dbg->h->gcore(dbg, newcorefile);

after this, the generic way to generate a core file depends on the file format
and architecture. so this needs to be implemented for each architecture, and
delegeate the format-specific api in RBin.

Right now RBin have support for creating tiny binaries, but this is not enough
to create a core file. after understanding the needs of the CORE generation we
can create a new api in rbin for that, or just extend the current one.

For iOS, just download http://www.newosxbook.com/files/procexp.tgz?v099 and
disassemble the sym._doCore function which contains all the code that
iterates over all process segments, registers and creates a handcrafted MACH0
binary that holds all that information.

Actually r2 is able to dump and restore memory and registers using the
snapshots thing, but the dumps are stored in disk in separate files and such,
not using that CORE structure.

Some related links:

https://people.redhat.com/anderson/extensions/gcore.c

https://docs.oracle.com/cd/E19424-01/820-4814/gegxx/

http://osxbook.com/book/bonus/chapter8/core/

http://osxbook.com/book/bonus/chapter8/core/download/gcore-1.3.tar.gz

Once we are able to generate core files, it will be great if we can add
support for loading them into r2.

On Feb 27 2016, at 4:48 pm, z03 <[email protected]> wrote:

I'm interested to work on this but need to be pointed in the right
direction, should the implementation to generate the core dumps depend on
gathering information collectively from the os (aka /proc on linux for elf
coredumps) in addition to the r2_debug api? or should the os be used to auto
generat coredumps through signals such as SIGABRT/SIGHUP etc..? or should the
implementation be left up to the backend debugger, for example use "generate-
core-file" if gdb was specified as a backend?

—
Reply to this email directly or [view it on GitHub](https://github.com/radare/
radare2/issues/4124#issuecomment-189671187).![](https://github.com/notificatio
ns/beacon/AA3-lpcPktW5aFoQo23hTuKpdxIGtfaRks5pobzOgaJpZM4Hc_qU.gif)

[0xddom]

I was reading this links

http://osxbook.com/book/bonus/chapter8/core/
http://osxbook.com/book/bonus/chapter8/core/download/gcore-1.3.tar.gz

And the code for generating the core files in OSX needs superuser privileges. Does the debug plugin has those privileges? I have never written a debugger before, so I can't tell for sure.

[radare]

you need the same permissions than for debugging, aka signing the binary or be root on osx, or add entitlements and be root on ios

On 16 Mar 2016, at 16:29, Kur0 [email protected] wrote:

I was reading this links

http://osxbook.com/book/bonus/chapter8/core/ http://osxbook.com/book/bonus/chapter8/core/
http://osxbook.com/book/bonus/chapter8/core/download/gcore-1.3.tar.gz http://osxbook.com/book/bonus/chapter8/core/download/gcore-1.3.tar.gz
And the code for generating the core files in OSX needs superuser privileges. Does the debug plugin has those privileges? I have never written a debugger before, so I can't tell for sure.

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

[0xddom]

A function for generating the core for mach0 binaries

host_get_host_priv_port (host_name_port_t host, host_priv_t host_priv)

only works if it's run with sudo privileges, even if the binary is signed.

Should I add a check for superuser privileges and refuse to run in case of not superuser? I don't know what's the prefered way to handle this situations.

I'm using El Capitan, maybe in older versions of OSX this function doesn't require superuser privileges. I don't know that either.

[radare]

The important part is to make it work. Being root or not is something that can be solved later, and i dont get why do you need to use that api

On 19 Mar 2016, at 21:01, Kur0 [email protected] wrote:

A function for generating the core for mach0 binaries

host_get_host_priv_port (host_name_port_t host, host_priv_t host_priv)
only works if it's run with sudo privileges, even if the binary is signed.

Should I add a check for superuser privileges and refuse to run in case of not superuser? I don't know what's the prefered way to handle this situations.

I'm using El Capitan, maybe in older versions of OSX this function doesn't require superuser privileges.

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

[0xddom]

The header of the corefile (acording to http://osxbook.com/book/bonus/chapter8/core/) needs the cpu type and subtype. To obtain that info the function is needed.

I could be wrong, but that's the conclusion I reach.

[radare]

you can get this info by parsing the header in memory, to create the core file you just need to read memory and enumerate the maps which is already done.

On 21 Mar 2016, at 11:30, Kur0 [email protected] wrote:

The header of the corefile (acording to http://osxbook.com/book/bonus/chapter8/core/ http://osxbook.com/book/bonus/chapter8/core/) needs the cpu type and subtype. To obtain that info the function is needed.

I could be wrong, but that's the conclusion I reach.

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

[radare]

Support for mach0 is working (lacks thread support), so, let's move this issue for 0.10.3 and cleanup a bit to clarify whats missing..

[leberus]

I'm working on "Generate ELF coredumps on Linux/BSD", hope to have something useful next week

[radare]

Awesome! Looking forward your pr

On 12 Apr 2016, at 19:49, leberus [email protected] wrote:

I'm working on "Generate ELF coredumps on Linux/BSD", hope to have something useful next week

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

[leberus]

Hi! I was quite busy this week, so I couldn't go much further, but I started to do some things:

leberus@037dd72

It's still incomplete, but I hope the next days to do a long jump ;)

[radare]

Cool!

On 20 Apr 2016, at 18:23, leberus [email protected] wrote:

Hi! I was quite busy this week, so I couldn't go much further, but I started to do some things:

leberus/radare2@037dd72

It's still incomplete, but I hope the next days to do a long jump ;)

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

[leberus]

I'm still moving forward! I'm able to dump all the load sections(without
the content) together with the notes. I'm still missing the content,
support for threads(that can be easily solved) and some checks to see if
the machine is x86 or x86_64, but I think that things are getting better
and better. I hope have something to show before monday.

2016-04-20 18:48 GMT+02:00 radare [email protected]:

Cool!

On 20 Apr 2016, at 18:23, leberus [email protected] wrote:

Hi! I was quite busy this week, so I couldn't go much further, but I
started to do some things:

leberus/radare2@037dd72

It's still incomplete, but I hope the next days to do a long jump ;)

—
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 commented.
Reply to this email directly or view it on GitHub
#4124 (comment)

[radare]

awesome! :D

On 26 Apr 2016, at 19:43, leberus [email protected] wrote:

I'm still moving forward! I'm able to dump all the load sections(without
the content) together with the notes. I'm still missing the content,
support for threads(that can be easily solved) and some checks to see if
the machine is x86 or x86_64, but I think that things are getting better
and better. I hope have something to show before monday.

2016-04-20 18:48 GMT+02:00 radare [email protected]:

Cool!

On 20 Apr 2016, at 18:23, leberus [email protected] wrote:

Hi! I was quite busy this week, so I couldn't go much further, but I
started to do some things:

leberus/radare2@037dd72

It's still incomplete, but I hope the next days to do a long jump ;)

—
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 commented.
Reply to this email directly or view it on GitHub
#4124 (comment)

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

[radare]

@leberus ping

[leberus]

I did a pull request. I wrote there what is still missing too. I was half of the last week on holidays so I didn't have so much time.
I'll continue to add what is missing from tomorrow on ;)

[Maijin]

Awesome !

[radare]

code is merged, need to port to BSD and add support for threads

[radare]

ping @leberus any will to continue working on this?

[leberus]

Yep! Sorry for the lateness. I started today porting the code to ARM,
actually it's almost done. The only thing left is compile it and try it.
Once this is done i'll do a PR. Tomorrow should be working (unless I find a
spooky thing)

El dia 15/08/2016 21:02, "radare" [email protected] va escriure:

ping @leberus https://github.com/leberus any will to continue working
on this?

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

[radare]

Awesome, thats probably a bit late for 0.10.5, but will fit perfectly in the next release with time for review and such.

that’s great to hear that :)

thanks, looking forward your PR!

On 15 Aug 2016, at 22:12, leberus [email protected] wrote:

Yep! Sorry for the lateness. I started today porting the code to ARM,
actually it's almost done. The only thing left is compile it and try it.
Once this is done i'll do a PR. Tomorrow should be working (unless I find a
spooky thing)

El dia 15/08/2016 21:02, "radare" [email protected] va escriure:

ping @leberus https://github.com/leberus any will to continue working
on this?

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

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

[leberus]

Hi :)

So far seems to work. The only thing I don't like is that every map is being dumped because /proc/[pid]/smaps on ARM platform doesn't provide VmFlags field, so I need to add another way to check if a map should be dumped or not.

Once this is done, I'll be ready for the PR :D

oski@bananapi:~/lab$ readelf -n corearm

Displaying notes found at file offset 0x000001f4 with length 0x000005dc:
  Owner                 Data size   Description
  CORE                 0x0000007c   NT_PRPSINFO (prpsinfo structure)
  CORE                 0x00000094   NT_PRSTATUS (prstatus structure)
  CORE                 0x00000074   NT_FPREGSET (floating point registers)
  CORE                 0x00000080   NT_SIGINFO (siginfo_t data)
  LINUX                0x00000104   NT_ARM_VFP (arm VFP registers)
  CORE                 0x00000090   NT_AUXV (auxiliary vector)
  CORE                 0x000001b6   NT_FILE (mapped files)
    Page size: 1
         Start         End Page Offset
    0x00010000  0x00011000  0x00000000
        /home/oski/lab/test
    0x00020000  0x00021000  0x00000000
        /home/oski/lab/test
    0xb6ebd000  0xb6f98000  0x00000000
        /lib/arm-linux-gnueabihf/libc-2.19.so
    0xb6f98000  0xb6fa7000  0x000db000
        /lib/arm-linux-gnueabihf/libc-2.19.so
    0xb6fa7000  0xb6fa9000  0x000da000
        /lib/arm-linux-gnueabihf/libc-2.19.so
    0xb6fa9000  0xb6faa000  0x000dc000
        /lib/arm-linux-gnueabihf/libc-2.19.so
    0xb6fad000  0xb6fc4000  0x00000000
        /lib/arm-linux-gnueabihf/ld-2.19.so
    0xb6fd4000  0xb6fd5000  0x00017000
        /lib/arm-linux-gnueabihf/ld-2.19.so
    0xb6fd5000  0xb6fd6000  0x00018000
        /lib/arm-linux-gnueabihf/ld-2.19.so
oski@bananapi:~/lab$ readelf -h corearm
ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 
  Class:                             ELF32
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              CORE (Core file)
  Machine:                           ARM
  Version:                           0x1
  Entry point address:               0x0
  Start of program headers:          52 (bytes into file)
  Start of section headers:          0 (bytes into file)
  Flags:                             0x0
  Size of this header:               52 (bytes)
  Size of program headers:           32 (bytes)
  Number of program headers:         14
  Size of section headers:           0 (bytes)
  Number of section headers:         0
  Section header string table index: 0
oski@bananapi:~/lab$

[radare]

yay :D that looks good!

good luck finding those vmflags :)

On 16 Aug 2016, at 15:52, leberus [email protected] wrote:

Hi :)

So far seems to work. The only thing I don't like is that every map is being dumped because /proc/[pid]/smaps on ARM platform doesn't provide VmFlags field, so I need to add another way to check if a map should be dumped or not.

Once this is done, I'll be ready for the PR :D

oski@bananapi:~/lab$ readelf -n corearm

Displaying notes found at file offset 0x000001f4 with length 0x000005dc:
Owner Data size Description
CORE 0x0000007c NT_PRPSINFO (prpsinfo structure)
CORE 0x00000094 NT_PRSTATUS (prstatus structure)
CORE 0x00000074 NT_FPREGSET (floating point registers)
CORE 0x00000080 NT_SIGINFO (siginfo_t data)
LINUX 0x00000104 NT_ARM_VFP (arm VFP registers)
CORE 0x00000090 NT_AUXV (auxiliary vector)
CORE 0x000001b6 NT_FILE (mapped files)
Page size: 1
Start End Page Offset
0x00010000 0x00011000 0x00000000
/home/oski/lab/test
0x00020000 0x00021000 0x00000000
/home/oski/lab/test
0xb6ebd000 0xb6f98000 0x00000000
/lib/arm-linux-gnueabihf/libc-2.19.so
0xb6f98000 0xb6fa7000 0x000db000
/lib/arm-linux-gnueabihf/libc-2.19.so
0xb6fa7000 0xb6fa9000 0x000da000
/lib/arm-linux-gnueabihf/libc-2.19.so
0xb6fa9000 0xb6faa000 0x000dc000
/lib/arm-linux-gnueabihf/libc-2.19.so
0xb6fad000 0xb6fc4000 0x00000000
/lib/arm-linux-gnueabihf/ld-2.19.so
0xb6fd4000 0xb6fd5000 0x00017000
/lib/arm-linux-gnueabihf/ld-2.19.so
0xb6fd5000 0xb6fd6000 0x00018000
/lib/arm-linux-gnueabihf/ld-2.19.so
oski@bananapi:/lab$ readelf -h corearm
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: CORE (Core file)
Machine: ARM
Version: 0x1
Entry point address: 0x0
Start of program headers: 52 (bytes into file)
Start of section headers: 0 (bytes into file)
Flags: 0x0
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 14
Size of section headers: 0 (bytes)
Number of section headers: 0
Section header string table index: 0
oski@bananapi:/lab$
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub #4124 (comment), or mute the thread https://github.com/notifications/unsubscribe-auth/AA3-lsqmaAL4qSHsjJjVNDjxsJSfx1ADks5qgcCbgaJpZM4Hc_qU.

[leberus]

I think it's ready for the PR. I will push my code and compile it and try it with my i386 and x86_64 to see that my changes didn't break anything.

Then I'll go ahead and do the PR.

PD: I've added a fix-up for issue #5540 because the commit there wouldn't be useful.

[radare]

cool! looking forward to review that pr

[leberus]

So, finally here it is: #5549 ;)

2016-08-17 12:48 GMT+02:00 radare [email protected]:

cool! looking forward to review that pr

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

[radare]

Yay :) merged because it looks good and doesnt breaks anything. Just some questions:

• will this work on android?
• an arm64 build can dump an arm process?
• this is elf/linux specific. Mach0/ios will be also great to have

Thanks!

On 18 Aug 2016, at 09:22, leberus [email protected] wrote:

So, finally here it is: #5549 ;)

2016-08-17 12:48 GMT+02:00 radare [email protected]:

cool! looking forward to review that pr

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

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

[leberus]

Hey!

• will this work on android?
• I don't really know. It should, but I can't say for sure since android sometimes does the things in another way. Anyway I'll try it on my phone and I'll let you know. If not, I'll try to fix it.
• an arm64 build can dump an arm process?
• If you're asking if this is gonna work on arm64 systems, then yes, it should. Unfortunately I don't have such board, so I don't have any chance to try it.
  But maybe in some weeks I have to chance to get an arm64 board.
• this is elf/linux specific. Mach0/ios will be also great to have
• I could give it a try, despite of I've never touched an ios system.

I'm not sure if this is the place or not, but I'd like to talk about http://radare.org/gsoc/2016/ideas.html#title_10

It'd be of my interest, and I'd like to give it a try :)

[XVilka]

@leberus come to telegram/irc and one of our RSoC students working on this task, so you both can cooperate: http://radare.today/posts/RSoC%202016%20progress/

[leberus]

@XVilka I'm not a student, may I work on it anyway? I'm already on irc. Should I talk with Rakholia Jenish directly? or do you have a procotol for this?

Thanks in advance

[XVilka]

@leberus we don't have a special protocol for that :) Of course you can talk to him directly. We have a dedicated group in telegram for this project though.

[leberus]

@XVilka ah ok, then I'll try to join it! (soz, was a misunderstood)

[XVilka]

@leberus ping us in #radare telegram channel and someone will invite you into this radare2-kernel chat.

[leberus]

Hi @XVilka I've pinged @pancake in #radare telegram channel because I didn't find you

[radare]

how do you ping? i got nothing :P anyway, im there

On 19 Aug 2016, at 10:39, leberus [email protected] wrote:

Hi @XVilka https://github.com/XVilka I've pinged @pancake https://github.com/pancake in #radare telegram channel because I didn't find you

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub #4124 (comment), or mute the thread https://github.com/notifications/unsubscribe-auth/AA3-lpB051hw7vV7K-2Q24E2NUp7u9oGks5qhWvGgaJpZM4Hc_qU.

[radare]

status of pendings ticks to be done here? any wip development?

[radare]

ping

[leberus]

after Christmas I'll try to make it work on BSD (got no time now)

[radare]

cool!

…

On 14 Dec 2016, at 12:56, leberus ***@***.***> wrote: after Christmas I'll try to make it work on BSD (got no time now) — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#4124 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA3-ljrs28tm2CsFwxfjyYo2gtR8eon9ks5rH9mDgaJpZM4Hc_qU>.

[radare]

@leberus can you update the issue with the current state of the things?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. Considering a lot has changed since its creation, we kindly ask you to check again if the issue you reported is still relevant in the current version of radare2. If it is, update this issue with a comment, otherwise it will be automatically closed if no further activity occurs. Thank you for your contributions.