Understanding the objcopy command in a book [on hold]

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
0
down vote

favorite












I am reading a book and it's talking about ELF's. I understand it's a file format for executable files.
There's a command that I executed on a VM and I'm having trouble understanding what it does.



objcopy -O binary -j .interp /bin/ls /dev/stdout


I opened the /dev/stdout file after executing and it just looks like a log information of some sort.










share|improve this question









New contributor




MintCollie is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











put on hold as too broad by Scott, RalfFriedl, Thomas, sourcejedi, X Tian Nov 21 at 11:18


Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.














  • How did you open /dev/stdout ?
    – sai sasanka
    Nov 20 at 6:29










  • On the parrot os vm I’m running I opened the file with The Pluma text editor
    – MintCollie
    Nov 20 at 6:31










  • Run 'man objdump'
    – Rui F Ribeiro
    Nov 20 at 6:36










  • When I run the command, I see /lib64/ld-linux-x86-64.so.2[alan@alan-laptop ~]$. This means the ELF interpreter is ld-linux-x86-64.so.2. Normally /dev/stdout should be a "special" file that writes the output e.g. to your terminal. It almost sounds as if your /dev/stdout was accidentally created as a regular file - by some previous program. AND, the /dev/stdout file was created by a different user like "root", so you did not have permission to overwrite the existing file at /dev/stdout with the contents /lib64/ld-linux-x86-64.so.2.
    – sourcejedi
    Nov 21 at 10:35










  • In this case, objdump should have printed an error message. On my system, the error message looks like objcopy:/dev/stdout: Permission denied.
    – sourcejedi
    Nov 21 at 10:38














up vote
0
down vote

favorite












I am reading a book and it's talking about ELF's. I understand it's a file format for executable files.
There's a command that I executed on a VM and I'm having trouble understanding what it does.



objcopy -O binary -j .interp /bin/ls /dev/stdout


I opened the /dev/stdout file after executing and it just looks like a log information of some sort.










share|improve this question









New contributor




MintCollie is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











put on hold as too broad by Scott, RalfFriedl, Thomas, sourcejedi, X Tian Nov 21 at 11:18


Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.














  • How did you open /dev/stdout ?
    – sai sasanka
    Nov 20 at 6:29










  • On the parrot os vm I’m running I opened the file with The Pluma text editor
    – MintCollie
    Nov 20 at 6:31










  • Run 'man objdump'
    – Rui F Ribeiro
    Nov 20 at 6:36










  • When I run the command, I see /lib64/ld-linux-x86-64.so.2[alan@alan-laptop ~]$. This means the ELF interpreter is ld-linux-x86-64.so.2. Normally /dev/stdout should be a "special" file that writes the output e.g. to your terminal. It almost sounds as if your /dev/stdout was accidentally created as a regular file - by some previous program. AND, the /dev/stdout file was created by a different user like "root", so you did not have permission to overwrite the existing file at /dev/stdout with the contents /lib64/ld-linux-x86-64.so.2.
    – sourcejedi
    Nov 21 at 10:35










  • In this case, objdump should have printed an error message. On my system, the error message looks like objcopy:/dev/stdout: Permission denied.
    – sourcejedi
    Nov 21 at 10:38












up vote
0
down vote

favorite









up vote
0
down vote

favorite











I am reading a book and it's talking about ELF's. I understand it's a file format for executable files.
There's a command that I executed on a VM and I'm having trouble understanding what it does.



objcopy -O binary -j .interp /bin/ls /dev/stdout


I opened the /dev/stdout file after executing and it just looks like a log information of some sort.










share|improve this question









New contributor




MintCollie is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











I am reading a book and it's talking about ELF's. I understand it's a file format for executable files.
There's a command that I executed on a VM and I'm having trouble understanding what it does.



objcopy -O binary -j .interp /bin/ls /dev/stdout


I opened the /dev/stdout file after executing and it just looks like a log information of some sort.







elf






share|improve this question









New contributor




MintCollie is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











share|improve this question









New contributor




MintCollie is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









share|improve this question




share|improve this question








edited Nov 20 at 11:27









Jeff Schaller

36.4k952120




36.4k952120






New contributor




MintCollie is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









asked Nov 20 at 6:04









MintCollie

31




31




New contributor




MintCollie is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.





New contributor





MintCollie is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.






MintCollie is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.




put on hold as too broad by Scott, RalfFriedl, Thomas, sourcejedi, X Tian Nov 21 at 11:18


Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.






put on hold as too broad by Scott, RalfFriedl, Thomas, sourcejedi, X Tian Nov 21 at 11:18


Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.













  • How did you open /dev/stdout ?
    – sai sasanka
    Nov 20 at 6:29










  • On the parrot os vm I’m running I opened the file with The Pluma text editor
    – MintCollie
    Nov 20 at 6:31










  • Run 'man objdump'
    – Rui F Ribeiro
    Nov 20 at 6:36










  • When I run the command, I see /lib64/ld-linux-x86-64.so.2[alan@alan-laptop ~]$. This means the ELF interpreter is ld-linux-x86-64.so.2. Normally /dev/stdout should be a "special" file that writes the output e.g. to your terminal. It almost sounds as if your /dev/stdout was accidentally created as a regular file - by some previous program. AND, the /dev/stdout file was created by a different user like "root", so you did not have permission to overwrite the existing file at /dev/stdout with the contents /lib64/ld-linux-x86-64.so.2.
    – sourcejedi
    Nov 21 at 10:35










  • In this case, objdump should have printed an error message. On my system, the error message looks like objcopy:/dev/stdout: Permission denied.
    – sourcejedi
    Nov 21 at 10:38
















  • How did you open /dev/stdout ?
    – sai sasanka
    Nov 20 at 6:29










  • On the parrot os vm I’m running I opened the file with The Pluma text editor
    – MintCollie
    Nov 20 at 6:31










  • Run 'man objdump'
    – Rui F Ribeiro
    Nov 20 at 6:36










  • When I run the command, I see /lib64/ld-linux-x86-64.so.2[alan@alan-laptop ~]$. This means the ELF interpreter is ld-linux-x86-64.so.2. Normally /dev/stdout should be a "special" file that writes the output e.g. to your terminal. It almost sounds as if your /dev/stdout was accidentally created as a regular file - by some previous program. AND, the /dev/stdout file was created by a different user like "root", so you did not have permission to overwrite the existing file at /dev/stdout with the contents /lib64/ld-linux-x86-64.so.2.
    – sourcejedi
    Nov 21 at 10:35










  • In this case, objdump should have printed an error message. On my system, the error message looks like objcopy:/dev/stdout: Permission denied.
    – sourcejedi
    Nov 21 at 10:38















How did you open /dev/stdout ?
– sai sasanka
Nov 20 at 6:29




How did you open /dev/stdout ?
– sai sasanka
Nov 20 at 6:29












On the parrot os vm I’m running I opened the file with The Pluma text editor
– MintCollie
Nov 20 at 6:31




On the parrot os vm I’m running I opened the file with The Pluma text editor
– MintCollie
Nov 20 at 6:31












Run 'man objdump'
– Rui F Ribeiro
Nov 20 at 6:36




Run 'man objdump'
– Rui F Ribeiro
Nov 20 at 6:36












When I run the command, I see /lib64/ld-linux-x86-64.so.2[alan@alan-laptop ~]$. This means the ELF interpreter is ld-linux-x86-64.so.2. Normally /dev/stdout should be a "special" file that writes the output e.g. to your terminal. It almost sounds as if your /dev/stdout was accidentally created as a regular file - by some previous program. AND, the /dev/stdout file was created by a different user like "root", so you did not have permission to overwrite the existing file at /dev/stdout with the contents /lib64/ld-linux-x86-64.so.2.
– sourcejedi
Nov 21 at 10:35




When I run the command, I see /lib64/ld-linux-x86-64.so.2[alan@alan-laptop ~]$. This means the ELF interpreter is ld-linux-x86-64.so.2. Normally /dev/stdout should be a "special" file that writes the output e.g. to your terminal. It almost sounds as if your /dev/stdout was accidentally created as a regular file - by some previous program. AND, the /dev/stdout file was created by a different user like "root", so you did not have permission to overwrite the existing file at /dev/stdout with the contents /lib64/ld-linux-x86-64.so.2.
– sourcejedi
Nov 21 at 10:35












In this case, objdump should have printed an error message. On my system, the error message looks like objcopy:/dev/stdout: Permission denied.
– sourcejedi
Nov 21 at 10:38




In this case, objdump should have printed an error message. On my system, the error message looks like objcopy:/dev/stdout: Permission denied.
– sourcejedi
Nov 21 at 10:38










1 Answer
1






active

oldest

votes

















up vote
4
down vote



accepted










Welcome to Unix & Linux SE!



An ELF file has a binary header or two, and a number of named sections. Wikipedia has a description of the structure of an ELF file, if you're interested.



Your objcopy -O binary -j .interp /bin/ls /dev/stdout command just outputs the contents of the .interp section of file /bin/ls exactly as-is (-O binary) to "file" /dev/stdout.



/dev/stdout should be a symbolic link to the current process's file descriptor #1, i.e. its standard output stream. It's basically just a way to tell a program that expects to write its output to a named file to use the standard output instead. Some programs can do that if you specify the output filename as just -, but apparently objcopy does not follow that convention.



If you're seeing "some sort of log information" when opening /dev/stdout, it might mean this symbolic link has been accidentally replaced by some program or script that has been run as root. It should look like this:



$ ls -l /dev/stdout
lrwxrwxrwx 1 root root 15 Nov 17 23:25 /dev/stdout -> /proc/self/fd/1


On a 64-bit x86 system, your objcopy command should output something like /lib64/ld-linux-x86-64.so.2. Since the output does not include a line-feed character at the end, it might appear on the same line as the next command prompt, making it harder to spot:



[my command prompt]$ objcopy -O binary -j .interp /bin/ls /dev/stdout
/lib64/ld-linux-x86-64.so.2[my command prompt]$


On a 32-bit x86 binary, the output would be something like /lib/ld-linux.so.2.



The output is the filename of the program interpreter aka the dynamic linker/loader that should be used with the examined binary. You can get more information about it using the man ld.so or man ld-linux commands on your system.






share|improve this answer



























    1 Answer
    1






    active

    oldest

    votes








    1 Answer
    1






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes








    up vote
    4
    down vote



    accepted










    Welcome to Unix & Linux SE!



    An ELF file has a binary header or two, and a number of named sections. Wikipedia has a description of the structure of an ELF file, if you're interested.



    Your objcopy -O binary -j .interp /bin/ls /dev/stdout command just outputs the contents of the .interp section of file /bin/ls exactly as-is (-O binary) to "file" /dev/stdout.



    /dev/stdout should be a symbolic link to the current process's file descriptor #1, i.e. its standard output stream. It's basically just a way to tell a program that expects to write its output to a named file to use the standard output instead. Some programs can do that if you specify the output filename as just -, but apparently objcopy does not follow that convention.



    If you're seeing "some sort of log information" when opening /dev/stdout, it might mean this symbolic link has been accidentally replaced by some program or script that has been run as root. It should look like this:



    $ ls -l /dev/stdout
    lrwxrwxrwx 1 root root 15 Nov 17 23:25 /dev/stdout -> /proc/self/fd/1


    On a 64-bit x86 system, your objcopy command should output something like /lib64/ld-linux-x86-64.so.2. Since the output does not include a line-feed character at the end, it might appear on the same line as the next command prompt, making it harder to spot:



    [my command prompt]$ objcopy -O binary -j .interp /bin/ls /dev/stdout
    /lib64/ld-linux-x86-64.so.2[my command prompt]$


    On a 32-bit x86 binary, the output would be something like /lib/ld-linux.so.2.



    The output is the filename of the program interpreter aka the dynamic linker/loader that should be used with the examined binary. You can get more information about it using the man ld.so or man ld-linux commands on your system.






    share|improve this answer
























      up vote
      4
      down vote



      accepted










      Welcome to Unix & Linux SE!



      An ELF file has a binary header or two, and a number of named sections. Wikipedia has a description of the structure of an ELF file, if you're interested.



      Your objcopy -O binary -j .interp /bin/ls /dev/stdout command just outputs the contents of the .interp section of file /bin/ls exactly as-is (-O binary) to "file" /dev/stdout.



      /dev/stdout should be a symbolic link to the current process's file descriptor #1, i.e. its standard output stream. It's basically just a way to tell a program that expects to write its output to a named file to use the standard output instead. Some programs can do that if you specify the output filename as just -, but apparently objcopy does not follow that convention.



      If you're seeing "some sort of log information" when opening /dev/stdout, it might mean this symbolic link has been accidentally replaced by some program or script that has been run as root. It should look like this:



      $ ls -l /dev/stdout
      lrwxrwxrwx 1 root root 15 Nov 17 23:25 /dev/stdout -> /proc/self/fd/1


      On a 64-bit x86 system, your objcopy command should output something like /lib64/ld-linux-x86-64.so.2. Since the output does not include a line-feed character at the end, it might appear on the same line as the next command prompt, making it harder to spot:



      [my command prompt]$ objcopy -O binary -j .interp /bin/ls /dev/stdout
      /lib64/ld-linux-x86-64.so.2[my command prompt]$


      On a 32-bit x86 binary, the output would be something like /lib/ld-linux.so.2.



      The output is the filename of the program interpreter aka the dynamic linker/loader that should be used with the examined binary. You can get more information about it using the man ld.so or man ld-linux commands on your system.






      share|improve this answer






















        up vote
        4
        down vote



        accepted







        up vote
        4
        down vote



        accepted






        Welcome to Unix & Linux SE!



        An ELF file has a binary header or two, and a number of named sections. Wikipedia has a description of the structure of an ELF file, if you're interested.



        Your objcopy -O binary -j .interp /bin/ls /dev/stdout command just outputs the contents of the .interp section of file /bin/ls exactly as-is (-O binary) to "file" /dev/stdout.



        /dev/stdout should be a symbolic link to the current process's file descriptor #1, i.e. its standard output stream. It's basically just a way to tell a program that expects to write its output to a named file to use the standard output instead. Some programs can do that if you specify the output filename as just -, but apparently objcopy does not follow that convention.



        If you're seeing "some sort of log information" when opening /dev/stdout, it might mean this symbolic link has been accidentally replaced by some program or script that has been run as root. It should look like this:



        $ ls -l /dev/stdout
        lrwxrwxrwx 1 root root 15 Nov 17 23:25 /dev/stdout -> /proc/self/fd/1


        On a 64-bit x86 system, your objcopy command should output something like /lib64/ld-linux-x86-64.so.2. Since the output does not include a line-feed character at the end, it might appear on the same line as the next command prompt, making it harder to spot:



        [my command prompt]$ objcopy -O binary -j .interp /bin/ls /dev/stdout
        /lib64/ld-linux-x86-64.so.2[my command prompt]$


        On a 32-bit x86 binary, the output would be something like /lib/ld-linux.so.2.



        The output is the filename of the program interpreter aka the dynamic linker/loader that should be used with the examined binary. You can get more information about it using the man ld.so or man ld-linux commands on your system.






        share|improve this answer












        Welcome to Unix & Linux SE!



        An ELF file has a binary header or two, and a number of named sections. Wikipedia has a description of the structure of an ELF file, if you're interested.



        Your objcopy -O binary -j .interp /bin/ls /dev/stdout command just outputs the contents of the .interp section of file /bin/ls exactly as-is (-O binary) to "file" /dev/stdout.



        /dev/stdout should be a symbolic link to the current process's file descriptor #1, i.e. its standard output stream. It's basically just a way to tell a program that expects to write its output to a named file to use the standard output instead. Some programs can do that if you specify the output filename as just -, but apparently objcopy does not follow that convention.



        If you're seeing "some sort of log information" when opening /dev/stdout, it might mean this symbolic link has been accidentally replaced by some program or script that has been run as root. It should look like this:



        $ ls -l /dev/stdout
        lrwxrwxrwx 1 root root 15 Nov 17 23:25 /dev/stdout -> /proc/self/fd/1


        On a 64-bit x86 system, your objcopy command should output something like /lib64/ld-linux-x86-64.so.2. Since the output does not include a line-feed character at the end, it might appear on the same line as the next command prompt, making it harder to spot:



        [my command prompt]$ objcopy -O binary -j .interp /bin/ls /dev/stdout
        /lib64/ld-linux-x86-64.so.2[my command prompt]$


        On a 32-bit x86 binary, the output would be something like /lib/ld-linux.so.2.



        The output is the filename of the program interpreter aka the dynamic linker/loader that should be used with the examined binary. You can get more information about it using the man ld.so or man ld-linux commands on your system.







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Nov 20 at 7:16









        telcoM

        14.4k11842




        14.4k11842












            Popular posts from this blog

            How to check contact read email or not when send email to Individual?

            Bahrain

            Postfix configuration issue with fips on centos 7; mailgun relay