New answers tagged


I suggest reading Section 8.4.6 Using fork and execve to Run Programs on


Android and Linux are two different operating systems. You can't just take an executable from one and run it on the other. The first hurdle is the kernel. Android and Linux are based on the same kernel, but they have a few different features. In particular, Android provides binders, which only exist in the mainstream kernel (the one found in Linux ...


Adding more to the answers: To check for instrumentation, grep for mcount/gmon: $ readelf -s <binary> | egrep "gmon|mcount" 20: 0000000000401160 63 FUNC GLOBAL DEFAULT 12 __gmon_start__ 28: 0000000000000000 0 FUNC GLOBAL DEFAULT UND mcount@GLIBC_2.2.5 (2) 36: 0000000000000000 0 FILE LOCAL DEFAULT ABS ...


That is actually not executable code. It's simply the binary string content "Hello World" in 8bit ASCII. Since you ask for a program, you could do something like this in C: #include <stdio.h> #include <string.h> #include <stdlib.h> char *bin2str(char *binStr) { int len; int i = 0; // input cursor int j = 0; // ...


If you're asking for a way to decode that binary encoding, you could use perl -ape '$_=pack "(B8)*", @F'


Assuming the eleven sequences of eight zeros and ones are bytes, those bytes have the values: 72 101 108 108 111 32 87 111 114 108 100 This could easily represent a program, e.g., for an 8-bit processor like the MOS Technology 6502 or a 32-bit processor like the Inmos T800, but AFAIK not for any processor running Debian (the T800 can run a Unix alike). ...


That's just the binary representation of the ascii encoding of "Hello World", not an executable, there's no way to execute that.


It is most likely trying to run the commands and failing because the iwconfig executable can't be found - because there's no $PATH variable available. You should always use absolute pathnames in cron scripts and similar and not rely on a $PATH setting that might not be there.


The kernel interprets the line starting with #! and uses it to run the script, passing in the script's name; so this ends up running /bin/rm scriptname which deletes the script. (As Stéphane Chazelas points out, scriptname here is sufficient to find the script — if you specified a relative or absolute path, that's passed in as-is, otherwise whatever path ...

Top 50 recent answers are included