Understanding the objcopy command in a book [on hold]
Clash 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.
elf
New contributor
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.
|
show 1 more comment
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.
elf
New contributor
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 isld-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 likeobjcopy:/dev/stdout: Permission denied
.
– sourcejedi
Nov 21 at 10:38
|
show 1 more comment
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.
elf
New contributor
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
elf
New contributor
New contributor
edited Nov 20 at 11:27
Jeff Schaller
36.4k952120
36.4k952120
New contributor
asked Nov 20 at 6:04
MintCollie
31
31
New contributor
New contributor
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 isld-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 likeobjcopy:/dev/stdout: Permission denied
.
– sourcejedi
Nov 21 at 10:38
|
show 1 more comment
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 isld-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 likeobjcopy:/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
|
show 1 more comment
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.
add a comment |
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.
add a comment |
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.
add a comment |
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.
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.
answered Nov 20 at 7:16
telcoM
14.4k11842
14.4k11842
add a comment |
add a comment |
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 isld-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