> I know radare can attach to pids... but what about core dumps? Is it > working?
Nope, it's not working because is not implemented :) The parsing of coredumps is architecture and a bit of SO depend, so portability is pseudohard, btw. it would be very cool to implement support for them. Have you ever read the gdb's source for it? It's almost ugly, but I would like to understand why this code is there. So, theorically this code is in the kernel, probably with less bugs :) I'll have to take a look on it. Would you like to do it? > Here I state my problem: I have core dumps of binaries (without > symbols, -O2) in a special _undesired_ state (segfault, assertion > failed, etc.). I need to know the function parameters and the values > in structs. Umf. without symbols and -O2 hardly damages the "readibility" of a program, so, all the info of these structs are defined by DWARF. (not supported by radare), but as xscript told me one time, DWARF sux, and it's hard to implement, and the current GNU implementation is full of bugs, but it works(R). BTW, if you walk thru the binary you can use "spcc" to visualize these structures (I supose, you know how they're defined) mapping them directly from memory. Using radare is easy to do that, but you just need to find the correct where this struct lives in memory. A core stores the register state of the process of the crash, so you'll be able to find the EIP, disassembly the previous bytes and be able to locate the structure pointer in %esp, so you can use spcc there. BTW, a minimalistic program for handling cores would not be hard to do and I recommend you to disable the randomized VA space before running these programs. it will ease the debugging and the readability of the core. $ sysctl -a | grep random| grep va O:) > What I need: > - I'd like an easy way of seeing the function parameters, maybe giving > the proper $esp address to a radare script, given a function > prototype. I could use some of your per/c-compiler combinations for > that. if you get the pointer to the structure the rest is easy. function arguments live in the stack, you they must be there, you can get some constant as delimiter to find where's everything, (between %ebp and %esp) > - I'd like an easy way of resolving values of structures. I know you > have some script for that, but I can't remember which. $ rsc spcc -t > my-struct.spcc $ vim my-struct.spcc $ rsc spcc my-struct.spcc -o my-struct Then you should use this program to parse the current data block, use PRINTCMD and pU command for this. > gdb question: > Is there a variable for the frame pointer when I'm "in a frame"? (f 1, f > 2...) hehe, nope, but there's a glibc symbol that allows you to guess that, no idea if this is in runtime or also dumped when the program dies. I implement this in libsfp (stack frame protector), no idea where's the, source, but I'll look for it, if google doesn't. Cheers. --pancake _______________________________________________ radare mailing list [email protected] https://lists.nopcode.org/mailman/listinfo/radare
