Hello All,
o I have written the following program to convert a core file to a
executable, and tried to execute the converted executable but my
system __HANGED__, The kernel did'nt give any messages the complete
system was stuck.
o Theoretically , the OS loader should jump into the virtual address
specified at 'ELF_HDR.e_entry and start executing instructions from
that point if the ELF_TYPE is ET_EXEC.
o So I wrote a program which
changes ELF_TYPE form ET_CORE to ET_EXEC and modifies e_entry to
virtual address of the 'main' symbol, since the core file has valid offset
to access the PHDRS, and for ET_EXEC the elf loader just need to map
the PHDRS at the vaddr specified and start jump to e_entry.
o Is there anything I'am missing, can some experts throw light on why
kernel does not load this program, could it be a bug in the kernel code ?
o The following is the program which converts core file to executable,
its simple to use just compile it with 'gcc convertcore.c -o
convertcore' , run with 'convertcore <core-file-name> <new-exec-name>
<vaddr-of-main>'
o I dump the core by CRTL+\
really appreciate your inputs
========================<BEGIN>===============================
#include<elf.h>
#include<stdio.h>
#include<sys/types.h>
#include<sys/stat.h>
#include<fcntl.h>
#ifndef __64_BIT__
#define __32_BIT__
#endif
#ifdef __32_BIT__
#define ELF_EHDR Elf32_Ehdr
#else
#define ELF_EHDR Elf64_Ehdr
#endif
ELF_EHDR place_holder;
/*Chages the elf_header in the file with ptr */
int ChangeElfHeader(int CoreFd, int WriteFd, unsigned long vaddr){
unsigned long got_len=0;
if((got_len = read(CoreFd,&place_holder,sizeof(ELF_EHDR)))
!= sizeof(ELF_EHDR)){
perror("Unable to read the ELF Header::");
exit(1);
}
/*Change the ET_CORE tto ET_EXEC*/
if(place_holder.e_type == ET_CORE) {
place_holder.e_type = ET_EXEC;
} else {
fprintf(stderr,"The file is not of ELF core file");
exit(1);
}
/*Change the entry */
place_holder.e_entry = vaddr;
/*Write back the header*/
got_len = 0;
if (( got_len = write(WriteFd,&place_holder,sizeof(ELF_EHDR)))
!= sizeof(ELF_EHDR)) {
perror("Unable to write the header::");
exit(1);
}
return 1;
}
> Hello All,
>
> o I have written the following program to convert a core file to a
> executable, and tried to execute the converted executable but my
> system __HANGED__, The kernel did'nt give any messages the complete
> system was stuck.
>
> o Theoretically , the OS loader should jump into the virtual address
> specified at 'ELF_HDR.e_entry and start executing instructions from
> that point if the ELF_TYPE is ET_EXEC.
>
> o So I wrote a program which
> changes ELF_TYPE form ET_CORE to ET_EXEC and modifies e_entry to
> virtual address of the 'main' symbol, since the core file has valid offset
> to access the PHDRS, and for ET_EXEC the elf loader just need to map
> the PHDRS at the vaddr specified and start jump to e_entry.
>
> o Is there anything I'am missing, can some experts throw light on why
> kernel does not load this program, could it be a bug in the kernel code ?
>
> o The following is the program which converts core file to executable,
> its simple to use just compile it with 'gcc convertcore.c -o
> convertcore' , run with 'convertcore <core-file-name> <new-exec-name>
> <vaddr-of-main>'
>
> o I dump the core by CRTL+\
>
> really appreciate your inputs
>
========================<BEGIN>===============================
#include<elf.h>
#include<stdio.h>
#include<sys/types.h>
#include<sys/stat.h>
#include<fcntl.h>
#ifndef __64_BIT__
#define __32_BIT__
#endif
#ifdef __32_BIT__
#define ELF_EHDR Elf32_Ehdr
#else
#define ELF_EHDR Elf64_Ehdr
#endif
ELF_EHDR place_holder;
/*Chages the elf_header in the file with ptr */
int ChangeElfHeader(int CoreFd, int WriteFd, unsigned long vaddr){
unsigned long got_len=0;
if((got_len = read(CoreFd,&place_holder,sizeof(ELF_EHDR)))
!= sizeof(ELF_EHDR)){
perror("Unable to read the ELF Header::");
exit(1);
}
/*Change the ET_CORE tto ET_EXEC*/
if(place_holder.e_type == ET_CORE) {
place_holder.e_type = ET_EXEC;
} else {
fprintf(stderr,"The file is not of ELF core file");
exit(1);
}
/*Change the entry */
place_holder.e_entry = vaddr;
/*Write back the header*/
got_len = 0;
if (( got_len = write(WriteFd,&place_holder,sizeof(ELF_EHDR)))
!= sizeof(ELF_EHDR)) {
perror("Unable to write the header::");
exit(1);
}
return 1;
}
static void finishWriting(int coreFd, int writeFd) {
unsigned char write_buffer[4*1024];
int got_len = -1;
while( (got_len = read(coreFd,write_buffer,4096)) != 0) {
if(write(writeFd,write_buffer,got_len) != got_len ){
perror("Unable to to write the length which was read:");
exit(1);
}
}
close(writeFd);
close(coreFd);
}
int main(int argc,char* argv[]){
int coreFd;
int writeFd;
unsigned long vaddr;
if( argc < 3 ) {
fprintf(stderr,"Usage core2elf core.file exe.file.name");
exit(1);
}
if( (coreFd = open(argv[1],O_RDONLY)) < 0) {
perror("Unable to open the core file:");
exit(1);
}
if ((writeFd = open(argv[2],O_WRONLY| O_CREAT)) < 0) {
perror("Unable to open the write file::");
exit(1);
}
sscanf(argv[3],"%lx",&vaddr);
ChangeElfHeader(coreFd,writeFd,vaddr);
finishWriting(coreFd,writeFd);
}
=========================<END>===========================
Best Regards,
Vamsi kundeti.
On Wed, May 24, 2006 at 10:48:31PM +0530, vamsi krishna wrote:
> Hello All,
>
> o I have written the following program to convert a core file to a
> executable, and tried to execute the converted executable but my
> system __HANGED__, The kernel did'nt give any messages the complete
> system was stuck.
>
> o Theoretically , the OS loader should jump into the virtual address
> specified at 'ELF_HDR.e_entry and start executing instructions from
> that point if the ELF_TYPE is ET_EXEC.
>
> o So I wrote a program which
> changes ELF_TYPE form ET_CORE to ET_EXEC and modifies e_entry to
> virtual address of the 'main' symbol, since the core file has valid offset
> to access the PHDRS, and for ET_EXEC the elf loader just need to map
> the PHDRS at the vaddr specified and start jump to e_entry.
Look at the program headers. Many of them probably have a file size of
zero. The code segments from the executable and shared libraries
aren't present in the core file.
Of course, the kernel shouldn't crash! It sounds like a bug.
--
Daniel Jacobowitz
CodeSourcery
Hello Daniel,
> Look at the program headers. Many of them probably have a file size of
I checked the PHDRS (readelf --segments) the following are the PHDRS
of the core.exe
===============<BEGIN>==================
Elf file type is EXEC (Executable file)
Entry point 0x8048364
There are 11 program headers, starting at offset 52
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
NOTE 0x000194 0x00000000 0x00000000 0x00a48 0x00000 0
**LOAD 0x001000 0x08048000 0x00000000 0x00000 0x01000 R E 0x1000
LOAD 0x001000 0x08049000 0x00000000 0x01000 0x01000 RWE 0x1000
LOAD 0x002000 0xf649b000 0x00000000 0x01000 0x01000 RWE 0x1000
**LOAD 0x003000 0xf649c000 0x00000000 0x00000 0x132000 R E 0x1000
LOAD 0x003000 0xf65ce000 0x00000000 0x03000 0x03000 RWE 0x1000
LOAD 0x006000 0xf65d1000 0x00000000 0x03000 0x03000 RWE 0x1000
LOAD 0x009000 0xf65e8000 0x00000000 0x01000 0x01000 RWE 0x1000
**LOAD 0x00a000 0xf65e9000 0x00000000 0x00000 0x15000 R E 0x1000
LOAD 0x00a000 0xf65fe000 0x00000000 0x01000 0x01000 RWE 0x1000
LOAD 0x00b000 0xfeffe000 0x00000000 0x02000 0x02000 RWE 0x1000
======================<END>=============
o As you said I see some of the PHDRS are having FileSiz as zero, the
first (1st **ed ) PHDR which is having virtual address 0x08048000
(this is obviously) the start of the text of the program, and its not
having any memory in the core file.
o Does the other PHDRS for which FileSiz is zero correspond to the
dynamic shared objects (.so) text ?? example in the above we see (2
**ed ) PHDR with VirtAddr as 0xf649c000 , so this means the text of
some shared .so has been mapped here right?
o I have question about the memory mapping with permissions r--s or
r--p (gconv used by glibc gets mapped like this some time) , so does
the core file contains this information of the memory mappings?
o Is there a way I can findout the standard which the OS follows to
write the core file?
o Rather than depending on the OS core file, hows your opinion on
writing out all the mappings form /proc/<pid>/maps as PT_LOAD into a
elf formatted file of type ET_EXEC, do you think this works? rather
than converting core file to exe?
>
> Of course, the kernel shouldn't crash! It sounds like a bug.
>
Yes I can reproduce this , is there a bugzilla for kernel? (or should
we report this at the buzilla of the distribution?)
Thank you,
Vamsi
On Thu, May 25, 2006 at 01:36:08AM +0530, vamsi krishna wrote:
> o Does the other PHDRS for which FileSiz is zero correspond to the
> dynamic shared objects (.so) text ?? example in the above we see (2
> **ed ) PHDR with VirtAddr as 0xf649c000 , so this means the text of
> some shared .so has been mapped here right?
Probably.
> o I have question about the memory mapping with permissions r--s or
> r--p (gconv used by glibc gets mapped like this some time) , so does
> the core file contains this information of the memory mappings?
>
> o Is there a way I can findout the standard which the OS follows to
> write the core file?
No. Core files change from time to time. David Miller recently
proposed changing these.
> o Rather than depending on the OS core file, hows your opinion on
> writing out all the mappings form /proc/<pid>/maps as PT_LOAD into a
> elf formatted file of type ET_EXEC, do you think this works? rather
> than converting core file to exe?
You might want to take a look at GDB's generate-core-file command.
--
Daniel Jacobowitz
CodeSourcery
Hello Dan,
> You might want to take a look at GDB's generate-core-file command.
>
Does gdb take care (loading) of core files generated on machine which
support ASLR (Address Space Layout Randomization)? , currently ASLR
is being shipped as exec-shield in redhat
Thanks,
Vamsi
On Thu, May 25, 2006 at 01:49:32AM +0530, vamsi krishna wrote:
> Hello Dan,
>
>
> >You might want to take a look at GDB's generate-core-file command.
> >
>
> Does gdb take care (loading) of core files generated on machine which
> support ASLR (Address Space Layout Randomization)? , currently ASLR
> is being shipped as exec-shield in redhat
Why would it matter?
--
Daniel Jacobowitz
CodeSourcery
Followup to: <[email protected]>
By author: "vamsi krishna" <[email protected]>
In newsgroup: linux.dev.kernel
>
> Yes I can reproduce this , is there a bugzilla for kernel? (or should
> we report this at the buzilla of the distribution?)
>
http://bugzilla.kernel.org/
-hpa
05/24/2006 10:06 PM, vamsi krishna wrote/a écrit:
>>
>> Of course, the kernel shouldn't crash! It sounds like a bug.
>>
>
> Yes I can reproduce this , is there a bugzilla for kernel? (or should
> we report this at the buzilla of the distribution?)
http://bugzilla.kernel.org/
Enjoy ;-)
Eric
On Thu, May 25, 2006 at 01:36:08AM +0530, vamsi krishna wrote:
> >
> >Of course, the kernel shouldn't crash! It sounds like a bug.
> >
>
> Yes I can reproduce this , is there a bugzilla for kernel? (or should
> we report this at the buzilla of the distribution?)
For security issues such as this (ability for users to crash the
kernel), [email protected] is the best address to send this to.
thanks,
greg k-h
Hi Vamsi,
> o I have written the following program to convert a core file to a
> executable, and tried to execute the converted executable but my
> system __HANGED__, The kernel did'nt give any messages the complete
> system was stuck.
>
> o Theoretically , the OS loader should jump into the virtual address
> specified at 'ELF_HDR.e_entry and start executing instructions from
> that point if the ELF_TYPE is ET_EXEC.
>
> o So I wrote a program which
> changes ELF_TYPE form ET_CORE to ET_EXEC and modifies e_entry to
> virtual address of the 'main' symbol, since the core file has valid offset
> to access the PHDRS, and for ET_EXEC the elf loader just need to map
> the PHDRS at the vaddr specified and start jump to e_entry.
>
> o Is there anything I'am missing, can some experts throw light on why
> kerOn Wed, 2006-05-24 at 22:48 +0530, vamsi krishna wrote:
> Hello All,
> nel does not load this program, could it be a bug in the kernel code ?
which kernel version do you use? What kind of Linux distribution do you
use? What hardware architecture do you use?
Regards
Marcel