I want to generate exactly the same than that :
but in an HTML document (whatever the locale is)!
Is there a way to do this?
Here's the solution coming from a mate who is good when it comes to this kind of problems.
Using shell command ps -Hef, I could see gkbd-keyboard-display -g 1 running.
There's no man page.
$ man gkbd-keyboard-display
No manual entry for gkbd-keyboard-display
See 'man 7 undocumented' for help when manual pages are not available.
Looking for this program:
$ type gkbd-keyboard-display
gkbd-keyboard-display is hashed (/usr/bin/gkbd-keyboard-display)
$ file /usr/bin/gkbd-keyboard-display
/usr/bin/gkbd-keyboard-display: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
...dynamically linked (uses shared libs),
...for GNU/Linux 2.6.26, BuildID[sha1]=0xc4e, [...]
So looking for the packet:
$ dpkg -S /usr/bin/gkbd-keyboard-display
gkbd-capplet: /usr/bin/gkbd-keyboard-display
$
Looking in the Web, found https://packages.debian.org/gkbd-capplet
Add sid because it's the most up-to-date version: https://packages.debian.org/sid/gkbd-capplet
From there, I clicked on the right option (Developer's information (PTS)) to see the source packet: it's this link: http://packages.qa.debian.org/libgnomekbd
In the right column, "Links" I clicked on the link "Browse source code" https://sources.debian.net/src/libgnomekbd/unstable/
I went into the debian folder then in the file watch, and from there I get the URL of the source code:
https://sources.debian.net/src/libgnomekbd/3.6.0-1/debian/watch/
From now on I'll have to understand how it works, and how to output all configurations in a way that I can read it in JSON format. Lots of work to do, but very interesting!
Related
If I compile this simple program fn main() { println!("Hello"); } with rustc test.rs -o test then I can run it with ./test, but double clicking it in the file manager gives this error: Could not display "test". There is no application installed for "shared library" file. Running file test seems to agree: test: ELF 64-bit LSB shared object....
How can I get rustc, and also tools that use it such as cargo, to produce executables rather than shared objects?
I am using 64-bit Linux (Ubuntu 14.10).
EDIT: I have posted on the Rust forum about this.
EDIT#: So it turns out this is an issue with the file executable.
I don't have the rust compiler and can't find its docs on the internet, but I know how to do shared obkect vs executable in C, so maybe this info will help you out in solving it.
The difference is the -pie option to the linker. With a hello world C program:
$ gcc test.c -ohello -fPIC -pie
$ file hello
hello: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), not stripped
If we remove the position-independent flags, we get an executable:
$ gcc test.c -ohello
$ file hello
hello: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), not stripped
Both generated files work the same way from the command line, but I suspect the difference file sees is changing what your GUI does. (Again, I'm not on Ubuntu... I use Slackware without a gui file manager, so I can't confirm myself, but I hope my guesses will help you finish solving the problem yourself.)
So, what I'd try next if I was on your computer would be to check the rustc man page or rustc --help and see if there's an option to turn off that -pie option to the linker. It stands for "position independent executable", so look for those words in the help file too.
If it isn't mentioned, try rustc -v test.rs -o test - or whatever the verbose flag is in the help file. That should print out the command it uses to link at the end. It'll probably be a call to gcc or ld. You can use that to link it yourself (there's probably a flag -c or something that you can pass to rustc to tell it to compile only, do not link, which will leave just the .o file it generates).
Once you have that, just copy/paste the final link command rustc called and remove the -pie option yourself.... if it is there... and see what happens.
Manually copy/pasting isn't fun to do and won't work with tools, but if you can get it to work at least once, you can confirm my hunch and maybe ask a differently worded question to get more rust users' attention.
You might also be able to tell the file manager how to open the shared object files and just use them. If the manager treated them the same as programs file identifies as executables, as the command line does, everything should work without changing the build process. I don't know how to do that though, but maybe asking on the ubuntu stack exchange will find someone who does.
What you have described is not entirely consistent with what I observe:
$ rustc - -o test <<< 'fn main() { println!("Hello"); }'
$ ./test
Hello
$ file test
test: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=99e97fcdc41eb2d36c950b8b6794816b05cf854c, not stripped
Unless you tell rustc to produce a library with e.g. #![crate_type = "lib"] or --crate-type lib, it will produce an executable.
It sounds like your file manager may be being too smart for its own good. It should just be trusting the executable bit and executing it.
I'm trying to do CMU's binary bomb as an independent project to learn some x86 Assembly and reverse engineering. (It's not an auto-graded version tied to a class.)
I downloaded bomb.tar from http://csapp.cs.cmu.edu/public/labs.html.
From CMU's lab description:
A "binary bomb" is a program provided to students as an object code
file. When run, it prompts the user to type in 6 different strings. If
any of these is incorrect, the bomb "explodes," printing an error
message and logging the event on a grading server. Students must
"defuse" their own unique bomb by disassembling and reverse
engineering the program to determine what the 6 strings should be. The
lab teaches students to understand assembly language, and also forces
them to learn how to use a debugger. It's also great fun. A legendary
lab among the CMU undergrads.
Here's a Linux/IA32 binary bomb that you can try out for yourself. The
feature that notifies the grading server has been disabled, so feel
free to explode this bomb with impunity.
After saving it into an appropriate folder I ran this command in the Terminal:
tar xvf bomb.tar
It did extract a file called bomb (no file extension), but I thought it would also give me bomb.c, which would also be helpful for reference.
I can't get "bomb" to run. Here's what I've tried:
bomb
bomb: command not found
./bomb
bash: ./bomb: No such file or directory
While I realize solving it requires stepping through it in gdb, I can't even run it in BASH and blow myself up with wrong answers yet! A little help would be fantastic.
As the other answers have suggested, this appears to a CPU architecture compatibility issue. I was able to resolve this on Ubuntu 15.04 64-bit by installing the packages located at AskUbuntu.com How to run 32-bit programs on a 64-bit system [duplicate]
Specifically, the following command helped.
sudo apt-get install lib32z1 lib32ncurses5 lib32bz2-1.0
Since Fabio A. Correa ran file on the bomb and found out that it was a 32-bit LSB executable, it seems that is is caused by some missing LSB scripts which should be loaded at startup.
Simply running sudo apt-get install lsb-core will fix this. After doing so, ldd bomb will also work.
Update:
Further ldd (after getting the LSB things ready) shows that it is actually caused by some inexist libc.so.6 => /lib32/libc.so.6, which is the libc of the i386 architecture. You can try installing the libc6-i386 package directly instead.
After that, you can run disassemble func_name in your gdb directly. With all the symbols preserved, you can see the names of the functions directly. strings might help you too.
Btw, this question should be placed in Unix&Linux, I guess.
file bomb informs:
ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.0.0, not stripped
You should be able to run it on bash by typing:
tar xvf bomb.tar
chmod +x bomb
./bomb
It worked in my 64-bit Kubuntu 14.04.
I recently heard about Breach, a Node.js based browser. I was following the instructions on http://codeforgeek.com/2014/08/download-install-breach-browser-ubuntu-14-04/ to install it but got the following error :
breach-v0.3.22-alpha.6-linux-x64/__AUTO_UPDATE_BUNDLE__/exo_browser/exo_browser: cannot execute binary file: Exec format error
After some googling, I found that it is because I am trying to install the 64 bit package on the 32 bit Ubuntu installation. I tried to find 32 bit package of the same but ended up with no luck. The browser is only available in 64 bit packet(as far as i know).
So, My question is :
Is it possible to somehow install it on the 32 bit OS or if any program available which can run 64 bit applications on the 32 bit OS.
I have been googling around and found no help. Can anyone help me?
I am using Ubuntu 14.04 (32 Bit).
Thank You
I have faced similar problem with c files .I think it has some thing to do with the compiler which we use
My kernel version is
3.13.0-40-generic
which you get by executing the command uname -r in terminal .
I had a code file which does file operations. When I used GCC with appropriate flags and created an object file called "fileop" and tried running it
I got the following error .
"bash: ./fileop: cannot execute binary file: Exec format error"
My executable linkable file was 32bit which you can see by using command
"file fileop"
fileop: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped
But when I used "CC" instead of GCC, It created a out file called a.out and I was able to execute it without any issues.
The "file" operation yielded the following ouput
a.out: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1] =13b7ad302580a0c7f5c7931ec2d80155d7915fa9, not stripped
Hope the above Description sheds more light in to the issue.
It is not possible to (directly) run 64 bit binaries on the 32 bit system.
You could try to use VMWare to run 64 bit Linux on the 32 bit host. See this answer for details.
Also, by inspecting Breach's landing page, I found this:
if(arch === 'ia32') {
$('#download').html('Available on <span class="fa fa-linux"></span> x64');
$('#download').attr('href', '#');
/*
$('#download').html('<span class="fa fa-linux"></span> Download Breach Alpha v0.3 (ia32)');
$('#download').attr('href', 'http://bit.ly/1kWWjmF');
*/
}
This indicates that they are working on the 32 bit Linux support. Maybe ask developers on Twitter/Github on status of that?
Is there a way to extract in bash or python file description from file manager (ex. PCManFM in lubuntu or any other like nautilus), because when I use command "find" or python-magic pkg or filemagic pkg, i do not get so accurate results like in file manager?
(for ex. when file contains gif header and php code under it, only file manager recognizes the file as PHP script, and other as gif image)
found that mimetypes is good choice. Nautilus uses it's database in /usr/share/mime/, python-magic and filemagic use libmagic, find uses something else i guess.
Use the linux file command. I assume that file managers do the same (but I'm not 100% sure).
Examples:
file test.php
# output: test.php: PHP script, ASCII text
file test.gif
# output: test.gif: GIF image data, version 89a, 32 x 32
file /bin/ls
# output: /bin/ls: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=0x37cdd635587f519989044055623abff939002027, stripped
I hope someone can help me with this :)
I am running Arch Linux and am trying to get a game to work (Penumbra Overture). I have downloaded the executable, checked the md5 and they match, installed it in a directory. However when I try to execute the file an error appears saying:
bash: ./penumbra.bin: No such file or directory
It does exist, I am in the right folder and it is set as executable:
-rwxr-xr-x 1 kumagoro users 6814000 Apr 15 2010 penumbra.bin
file penumbra.bin says:
penumbra.bin: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.2.5, stripped
ldd penumbra.bin says:
not a dynamic executable
So, is this a problem with my distro or the application?
Thanks
You are missing the interpreter for the binary. Check with
readelf -a penumbra.bin | grep -i program.interp
what it wants.