- nethogs
- iftop
- nettop
- ntop
- ettercap
- darkstat
- htop
- iotop
- Glances
Wednesday, May 15, 2013
How to find out all processes traffic bandwidth use with (nethogs) top like utility
How to find out all processes traffic bandwidth use with (nethogs) top like utility
find a missing library
# yum provides "*/(file)"
Is used to find out what package provides a certain file. This is especially useful when you are compiling some code and get an error like "error: libbluetooth.so.2 not found, exiting."
Example: yum provides "*/libbluetooth.so.2"
Is used to find out what package provides a certain file. This is especially useful when you are compiling some code and get an error like "error: libbluetooth.so.2 not found, exiting."
Example: yum provides "*/libbluetooth.so.2"
Monday, May 13, 2013
lint - statically checking C programs
lint - a tool for statically checking C programs for security vulnerabilities and coding mistakes.
http://en.wikipedia.org/wiki/Lint_%28software%29
http://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis
http://en.wikipedia.org/wiki/Lint_%28software%29
http://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis
Friday, May 3, 2013
How are hex sequence translated to assembly without ambiguity
8B EC 56 8B F4 68 00 70 40 00 FF 15 BC 82 40 UPDATE
The answer with most votes doesn't actually answer my question at all.
===
===
A binary doesn't have a definate set, it
has a set of definate starting points(for example, you could skip up to
four bytes of prefixes and still get almost the same output). Imo,
you'd do well looking at the info on sandpile.org and have a look at the
ollydbg & bea mini disassem engine – Necrolis Oct 13 '10 at 16:46
===
===
I'm pretty sure I've heard tales of
getting very small demos which rely on running the same bytes as
different code depending where you start; certainly anything on the x86
with has an optional lock prefix on its first instruction can be two
functions depending which instruction you jump to. – Pete Kirkham Oct 13 '10 at 22:05
===
First of all you have to distinguish between RISC and CISC architectures.
In a RISC architecture you usually have instructions of the same size, so ambiguity cannot be presented. Your CPU will fetch for example 4 bytes for every instruction, and since it will have to start from somewhere (your CPU doesn't have just a sequence like the one you presented, it will have a starting point for sure) once that it has the right alignment no problem can occur.
What happens with a CISC instruction set is essentially the same: starting from the entry point of the program it will fetch instructions accordingly to your opcodes. It doesn't need to know how to matematically distinguish ambiguities since it won't happen that it just doesn't know how long is the next instruction or where the last one finished.
So asking how to separate every instruction is like asking how to separate every word in
So if the CPU could work on the previous sentence it will find the first senseful instruction "the", then "pen", "is", "on" and the "son" couldn't never be recognized anyway.
EDIT:
To be cleared, in CISC architectures, the only contraint you have to be sure not to have ambiguities is to avoid having an instruction that is a prefix of another. Let's assume a finite alphabet composed by letters a-z instead that hex numbers (just for practical purposes).
If the program counter points to
You can extend this argumentation to the whole string. You will see that, if the CPU finds itself in a state in which the next byte of the binary points to the FIRST byte of an instruction, and there are no instruction that are prefixes of other instruction, then in the next state the program counter will point to the FIRST byte of the next, correct, instruction.
In a RISC architecture you usually have instructions of the same size, so ambiguity cannot be presented. Your CPU will fetch for example 4 bytes for every instruction, and since it will have to start from somewhere (your CPU doesn't have just a sequence like the one you presented, it will have a starting point for sure) once that it has the right alignment no problem can occur.
What happens with a CISC instruction set is essentially the same: starting from the entry point of the program it will fetch instructions accordingly to your opcodes. It doesn't need to know how to matematically distinguish ambiguities since it won't happen that it just doesn't know how long is the next instruction or where the last one finished.
So asking how to separate every instruction is like asking how to separate every word in
thepenisonthetableThere's not mathematical proof but you know which letters are correct together and which ones are not meaningful. The previous sentence contains "son" but you know that it is obtained from "is on". You wouldn't be able to say so without having a meaningful phrase, but your CPU only executes meaningful programs so what's the point?
So if the CPU could work on the previous sentence it will find the first senseful instruction "the", then "pen", "is", "on" and the "son" couldn't never be recognized anyway.
EDIT:
To be cleared, in CISC architectures, the only contraint you have to be sure not to have ambiguities is to avoid having an instruction that is a prefix of another. Let's assume a finite alphabet composed by letters a-z instead that hex numbers (just for practical purposes).
If the program counter points to
abbcbcaabdeffabd abb is a whole instruction. In that case ab wouldn't be a valid instruction, otherwise the CPU couldn't know where to stop, at the same time abbc can't be an instruction too or it may create problems. Keeping it on you can have for example that ca is the next instruction, c couldn't and cbc neither.You can extend this argumentation to the whole string. You will see that, if the CPU finds itself in a state in which the next byte of the binary points to the FIRST byte of an instruction, and there are no instruction that are prefixes of other instruction, then in the next state the program counter will point to the FIRST byte of the next, correct, instruction.
===
I would argue that your example is not
even 100% parse-able unless you assert that it is a complete sentence in
English. It could be 'the pen is on the table,' or 'the penis on the
table.' – Dave Oct 13 '10 at 13:51
===
===
It's like the example I provided with
the sentence. Let's change it to remove the hidden ambiguity of "pen
is". Assume "the cat is on the table". As long as every word (or
instruction) is not a prefix of another existing word (that is not true
for natural language, but it is for CPU instructions) a CPU that knows
where to start will always be able to split up instructions with no
ambiguity. – Jack Oct 13 '10 at 15:33
===
Knowing your starting point.
In other words, given a specific starting byte of an instruction, it is unambiguous where the instruction ends, thus giving you the starting byte of the next instruction and allowing you to continue. Given an arbitrary block of memory it is impossible to break it up into individual instructions without knowing where the first instruction begins.
From a more mathematical perspective, there is no valid instruction whose bytes are a prefix of another valid instruction. So if
===
In other words, given a specific starting byte of an instruction, it is unambiguous where the instruction ends, thus giving you the starting byte of the next instruction and allowing you to continue. Given an arbitrary block of memory it is impossible to break it up into individual instructions without knowing where the first instruction begins.
From a more mathematical perspective, there is no valid instruction whose bytes are a prefix of another valid instruction. So if
ab is valid, then you know that ab cd cannot be valid so ab must be one instruction and cd is the start of the next instruction.===
Nice :-) However, given certain
sequences it seems like it would be possible to determine the "starting
point" based upon the detection of invalid instructions (or the
detection of sequences which seem valid). If the above is true, would
you give a particular "name" to such an operation? – user166390 Oct 12 '10 at 16:57
===
As flippant as this is, it's true. There
are a number of exploits involving referencing assembly code at the
wrong offset to produce unexpected behavior. – Andres Oct 12 '10 at 16:59
===
What if there're these 4 instructions:
8B EC,,, 56 8B F4 68 ,,,8B EC 56 8B, ,,F4 68 ,how does CPU know whether 8B EC 56 8B F4 68 should be interpreted as 8B EC + 56 8B F4 68 , or 8B EC 56 8B + F4 68 ? – justnobody Oct 13 '10 at 8:26
===
@justnobody: There are no such cases. If
8B EC is an instruction, then 8B EC 56 8B is not one. That's what the ISA specification of the architecture defines uniquely. – Bahbar Oct 13 '10 at 15:55
===
The sequence you listed shows exactly 1 number. In binary, it's
100010111110110001010110100010111111010001101000000000000111000001000000000000001111111100010101101111001000001001000000.
In decimal, it's
726522768938664460674442126658667072.
These are all just different ways of writing exactly the same value. A
particular architecture's ISA will divide the bits into fields and
assign them meaning. Most processors have easy to get manuals that
describe the meaning assigned to each of the bits in those fields.
===
But the bits can be divided in various ways,how does computer figures the final segmentation? – ollydbg Oct 12 '10 at 17:03
===
@ollydbg, Do you want to know how the
hardware physically does it, or how the programmer knows what the
hardware will do with their bits? – nmichaels Oct 12 '10 at 17:06
===
Dont confuse linearly trying to disassemble
with execution order of code. The binary is decoded in execution order,
starting with a known location. Other than intentional hacks for
various reasons there is no ambiguity.
Try writing a disassembler for a variable word length instruction set. At the end of the day it has to be done in execution order, and even there you can only disassemble some of the program as some branches can be based on addresses computed at run time. Modern compiler generated code is much better than older hand assembled code. In an old standup arcade game for example there are conditional branches preceeded by an instruction that guarantees that only one of the conditions is met (why was that in there? we will never know) and the data that follows the conditional branch resembles an opcode in such a way that you run into a collision with other opcodes.
Old dos programs trying to defeat disassemblers would have self modifying code, one instruction would modify another instruction one or two instructions ahead, if single stepped that modification would happen, but if run at full speed the instruction was already fetched in the pipeline, and the modified/broken one in memory was not used. pretty neat trick.
Anyway, the answer to your question is do not look at the bytes in linear order, look at them in execution order starting at the addresses defined by the reset and other vectors in the vector table.
===
on fixed length instruction sets you can
examine the data linearly from 0 to N, so long as you remember that not
all of those bytes are instructions (and you examine them using the
correct alignment). – dwelch Oct 12 '10 at Try writing a disassembler for a variable word length instruction set. At the end of the day it has to be done in execution order, and even there you can only disassemble some of the program as some branches can be based on addresses computed at run time. Modern compiler generated code is much better than older hand assembled code. In an old standup arcade game for example there are conditional branches preceeded by an instruction that guarantees that only one of the conditions is met (why was that in there? we will never know) and the data that follows the conditional branch resembles an opcode in such a way that you run into a collision with other opcodes.
Old dos programs trying to defeat disassemblers would have self modifying code, one instruction would modify another instruction one or two instructions ahead, if single stepped that modification would happen, but if run at full speed the instruction was already fetched in the pipeline, and the modified/broken one in memory was not used. pretty neat trick.
Anyway, the answer to your question is do not look at the bytes in linear order, look at them in execution order starting at the addresses defined by the reset and other vectors in the vector table.
===
===
It sounds like the answer to your question is
the somewhat flippant "Know your starting point", but maybe you want
something a little more verbose. Given your string:
So let's say one operation is 8B EC 56 8B (Depending on your operation length, etc), then the NEXT operation is F4 68... In this case, it's impossible for the machine to try to interpret an operation 56 8B F4 68 because no operation ended at just that point.
Now, if your start point was the 56, then you can get that group but cannot get either of the ones mentioned previously.
The layout of your memory is very specific and start points/jump points are exact and unforgiving--they are required as surely as the code itself.
===8B EC 56 8B F4 68 00 70 40 00 FF 15 BC 82 40 So let's say one operation is 8B EC 56 8B (Depending on your operation length, etc), then the NEXT operation is F4 68... In this case, it's impossible for the machine to try to interpret an operation 56 8B F4 68 because no operation ended at just that point.
Now, if your start point was the 56, then you can get that group but cannot get either of the ones mentioned previously.
The layout of your memory is very specific and start points/jump points are exact and unforgiving--they are required as surely as the code itself.
If I understand your question correctly, you're trying to understand why
8B EC 56 8B F4 68 00 70 40 00 FF 15 BC 82 40
Could be split e.g. as
8BEC 568BF4 68007040 00FF 15BC 8240
Rathern than say,
8B EC568B F4 68007040 00FF 15BC 8240
This is entirely specified by the ISA of your architecture. That document describes exactly how instructions are uniquely constructed from a series of bytes.
For the ISA to be well formed, a single series of bytes can correspond to at most a single series of decoded instructions (might be less, if there are invalid instructions).
To get a bit more concrete, lets take the x86 example: If you want to know what each byte corresponds to, have a look here.
You'll see that, e.g. an instruction starting with 00 is an add (additional parameters are in the next byte, with a specific encoding).
You'll also see that some values are actually prefixes that modify the following instruction (0F - prefix to extend the opcode space, 26, 2E, 36, 3E, 64, 65, 66, 67, F0, F2, F3), and that some of them take different meaning based on the exact following instruction. Those are not opcodes, but they can alter the encoding of the arguments of the opcode, or introduce a completely new opcode space (e.g. SSE uses 0F).
Overall, the x86 encoding is very complex, thanks for disassemblers.
===
8B EC 56 8B F4 68 00 70 40 00 FF 15 BC 82 40
Could be split e.g. as
8BEC 568BF4 68007040 00FF 15BC 8240
Rathern than say,
8B EC568B F4 68007040 00FF 15BC 8240
This is entirely specified by the ISA of your architecture. That document describes exactly how instructions are uniquely constructed from a series of bytes.
For the ISA to be well formed, a single series of bytes can correspond to at most a single series of decoded instructions (might be less, if there are invalid instructions).
To get a bit more concrete, lets take the x86 example: If you want to know what each byte corresponds to, have a look here.
You'll see that, e.g. an instruction starting with 00 is an add (additional parameters are in the next byte, with a specific encoding).
You'll also see that some values are actually prefixes that modify the following instruction (0F - prefix to extend the opcode space, 26, 2E, 36, 3E, 64, 65, 66, 67, F0, F2, F3), and that some of them take different meaning based on the exact following instruction. Those are not opcodes, but they can alter the encoding of the arguments of the opcode, or introduce a completely new opcode space (e.g. SSE uses 0F).
Overall, the x86 encoding is very complex, thanks for disassemblers.
===
There might also be some clues elsewhere about
what is a valid starting address. There is always a reset vector
address, and there are usually interrupt vector addresses, which all
must be valid start points for blocks of code. More usefully, if you
come across a jump or call instruction elsewhere which references an
address in the block you are trying to decode, then that gives you
another start address.
I think I see your worry, and as far as I know its correct - if the program counter gets upset by one and that causes invalid instructions or unintended instructions to be executed, the program probably crashes. True, and also if you run into a data block and try to execute that. At least the latter can be avoided by using a Harvard architecture, where code and data are in seperate memory spaces and may be different bit widths.
===I think I see your worry, and as far as I know its correct - if the program counter gets upset by one and that causes invalid instructions or unintended instructions to be executed, the program probably crashes. True, and also if you run into a data block and try to execute that. At least the latter can be avoided by using a Harvard architecture, where code and data are in seperate memory spaces and may be different bit widths.
If you open a binary in a hex editor, copy a
portion of data and paste in a disassembler, you will very probably not
copy a complete instruction. Let's use your example.. in a Windows XP
32bits SP3 English, if I assembly
Now let's pretend that instead of assembling
you added
Now check below what a single byte did in our instructions:
As you can see it was completely modified!
The processor know where to start and what arguments to the instruction to take by the opcode instruction. In the first example our first opcode was
In our second example it start with
Imagine that inside the processor has a huge (but nano) circuit, that behave like a chain of ifs (conditions), that depending on the value of the hexcode (or opcode) it knows "where to go" or "how to behave".
===8B EC 56 8B F4 68 00 70 40 00 FF 15 BC 82 40 I'll get:Hex dump Command
8BEC mov ebp,esp
56 push esi
8BF4 mov esi,esp
68 00704000 push 407000
FF15 BC824000 call dword ptr ds:[4082bc] Now let's pretend that instead of assembling
8B EC 56 8B F4 68 00 70 40 00 FF 15 BC 82 40you added
C0 opcode at the beginning C0 8B EC 56 8B F4 68 00 70 40 00 FF 15 BC 82 40Now check below what a single byte did in our instructions:
Hex dump Command
C08B EC568BF4 68 ror byte ptr ds:[ebx+f48b56ec],68
0070 40 add byte ptr ds:[eax+40],dh
00FF add bh,bh
15 BC824000 adc eax,4082bc
As you can see it was completely modified!
The processor know where to start and what arguments to the instruction to take by the opcode instruction. In the first example our first opcode was
8B so it knows that it can be followed by another byte. If this byte is EC so the instruction ends here, and it means mov ebp, esp.In our second example it start with
C0 and it can be followed by another byte, meaning another instruction. Then C08B is the instruction, and EC568BF4 68 is the argument.Imagine that inside the processor has a huge (but nano) circuit, that behave like a chain of ifs (conditions), that depending on the value of the hexcode (or opcode) it knows "where to go" or "how to behave".
Maybe you find it interesting to think about
the other direction: How would you have to design your code to be easy
to segment for others? You could require the most significant bit of the
byte starting a sequence to be zero, and those in the middle of a
sequence to be one, like UTF-8 does it. Then if you start from a random
position – assuming you know where the bytes are – it is easy to find
the next sequence. Going one step further, how would you code a pure bit
stream such that the start of a sequence is easy to find. How many bits
were wasted by such a coding?
Since you asked about the maths, I think the relevant topics are “Coding Theory”, “Variable-length codes” or “Prefix codes”.
How do you find a gene in a sequence of base pairs?
Since you asked about the maths, I think the relevant topics are “Coding Theory”, “Variable-length codes” or “Prefix codes”.
How do you find a gene in a sequence of base pairs?
Reference:
Configure the network card on CentOS on VirtualBox
Show the name network interface:# ifconfig -a
Modify eth0's configuration file:
# vi /etc/sysconfig/network-scripts/ifcfg-eth0
ONBOOT=yes
BOOTPROTO=static
IPADDR=192.168.1.212
NETMASK=255.255.255.0
Note: if you want to use DHCP, change BOOTPROTO=dhcp
Define default gateway (router IP) and hostname:
# vi /etc/sysconfig/network
NETWORKING=yes
HOSTNAME=centos64.local
GATEWAY=192.168.1.1
Make sure you have correct DNS server defined:
# vi /etc/resolv.conf
nameserver 8.8.8.8
Restart networking:
# /etc/init.d/network restart
Modify eth0's configuration file:
# vi /etc/sysconfig/network-scripts/ifcfg-eth0
ONBOOT=yes
BOOTPROTO=static
IPADDR=192.168.1.212
NETMASK=255.255.255.0
Note: if you want to use DHCP, change BOOTPROTO=dhcp
Define default gateway (router IP) and hostname:
# vi /etc/sysconfig/network
NETWORKING=yes
HOSTNAME=centos64.local
GATEWAY=192.168.1.1
Make sure you have correct DNS server defined:
# vi /etc/resolv.conf
nameserver 8.8.8.8
Restart networking:
# /etc/init.d/network restart
Install tmux on FreeBSD Tutorial Step by step
Install tmux on FreeBSD Tutorial Step by step
Install tmux
# cd /usr/ports/sysutils/tmux/ ; make install clean ; rehash
tmux options
# make showconfig
===> The following configuration options are available for tmux-1.5:
LIBEVENT2=on "Use libevent version 2"
LIBEVENT_STATIC=off "Build with static libevent"
BACKSPACE=on "Build with tty/keys patch"
===> Use 'make config' to modify these settings
Configuration Examples:
# ls /usr/local/share/examples/tmux
By default, tmux loads the system configuration file from /usr/local/etc/tmux.conf, if present, then looks for a user configuration file at ~/.tmux.conf.
Add following lines to your tmux.conf:
# vim /usr/local/etc/tmux.conf
or
# vim ~/.tmux.conf
### Note: key meaning
### C- means ctrl-, so C-x is ctrl-x.
### M- means meta (generally left-alt or escape)-, so M-x is left-alt-x.
### Set the prefix to ^A.
### Note: the default prefix is Ctrl-b.
unbind C-b
set -g prefix ^A
bind a send-prefix
### Set the maximum number of lines held in window history.
set -g history-limit 5000
### terminal 256 colors.
### As the tmux manual suggests: for tmux to work correctly, this must be set to "screen" or a derivative of it.
### Note: modify following line and set it to the terminal supported by your system (run cat /etc/termcap | egrep 'screen-256color|xterm-256color' to verify), and uncomment it.
###set -g default-terminal screen-256color
###set -g default-terminal xterm-256color
### Instructs tmux to expect UTF-8 sequences to appear in this window.
setw -g utf8 on
### Instruct tmux to treat top-bit-set characters in the status-left and status-right strings as UTF-8;
set -g status-utf8 on
### date format: hostname weekday month day, hour:minute
set -g status-right '#H %a %b %d, %H:%M'
### Set status line background colour.
set -g status-bg black
### Set status line foreground colour.
set -g status-fg yellow
### Set status line background colour for the currently active window.
setw -g window-status-current-bg magenta
### Set status line foreground colour for the currently active window.
setw -g window-status-current-fg white
### Reload tmux.conf configuration file
### Note: alternative way to reload the configuration file:
### Method 1: Run from command line: tmux source-file ~/.tmux.conf
### Method 2: In any tmux sessions: [prefix Ctrl-b] : source-file /usr/local/etc/tmux.conf
### Method 3: bind the source-file command with a key like following line, then you type: ctrl-b-r
bind r source-file /usr/local/etc/tmux.conf
### [START] vi- and vim-like bindings
### split windows like vim
### vim's definition of a horizontal/vertical split is reversed from tmux's
bind s split-window -v
bind v split-window -h
### move around panes with hjkl, as one would in vim after pressing ctrl-w
bind h select-pane -L
bind j select-pane -D
bind k select-pane -U
bind l select-pane -R
### resize panes like vim
### feel free to change the "5" to however many lines you want to resize by, only
### one at a time can be slow
bind < resize-pane -L 5
bind > resize-pane -R 5
bind - resize-pane -D 5
bind + resize-pane -U 5
### bind : to command-prompt like vim
### this is the default in tmux already
bind : command-prompt
### vi-style controls for copy mode
setw -g mode-keys vi
### [END] vi- and vim-like bindings
Add following line to your ~/.cshrc:
# vim ~/.cshrc
### Note: modify following line and set it to the terminal supported by your system (run cat /etc/termcap | egrep 'screen-256color|xterm-256color' to verify), and uncomment it.
#setenv TERM screen-256color
#setenv TERM xterm-256color
Add following lines to your ~/.vimrc:
# vim ~/.vimrc
" To enable 256 colors in vim, put this your .vimrc before setting the colorscheme.
set t_Co=256
Use following script to test verify whether your terminal supports 256 colors:
a small perl script that outputs a grid of 256 colors in your console.
It should look like this:
To see a list of TERM values supported by the system:
# cat /etc/termcap
# cat /etc/termcap | egrep 'screen-256color|xterm-256color'
Determine the terminal capability interface:
# tput Co
8
# tput colors
115
# cap_mkdb
# setenv | grep TERM
# echo $TERM
# tmux
# tmux ls
# tmux a -d
# tmux attach -d -t 1
Move window, reorder window
The 'swap-window' command is closest to what you want. "Prefix :" (that is "Ctrl-B :" by default) brings you to the tmux-command prompt. There you enter 'swap-window -s 3 -t 1' to let window number 3 and window number 1 swap their positions.
To move the current window to the top, do 'swap-window -t 0' (if base-index is 0, as it is by default).
You can bind that command to a key (T for "top" for example) by adding
bind-key T swap-window -t 0
to your ~/.tmux.conf.
Note: if you see following error messages after run the tmux command:
csh: Cannot open /etc/termcap.
csh: using dumb terminal settings.
Make sure you set following line to the terminal supported by your system (run cat /etc/termcap | egrep 'screen-256color|xterm-256color' to verify) in your /usr/local/etc/tmux.conf:
set -g default-terminal screen-256color
or
set -g default-terminal xterm-256color
Other useful tool:
tmuxinator - Manage complex tmux sessions easily
This document released for use under the PPL license available at http://code.dayid.org/ppl/ppl.txt
Want more information about tmux and screen? Check out This page also
Reference:
http://gala4th.blogspot.com/2011/09/install-tmux-on-freebsd-tutorial-step.html
http://www.dayid.org/os/notes/tm.html
Install tmux
# cd /usr/ports/sysutils/tmux/ ; make install clean ; rehash
tmux options
# make showconfig
===> The following configuration options are available for tmux-1.5:
LIBEVENT2=on "Use libevent version 2"
LIBEVENT_STATIC=off "Build with static libevent"
BACKSPACE=on "Build with tty/keys patch"
===> Use 'make config' to modify these settings
Configuration Examples:
# ls /usr/local/share/examples/tmux
By default, tmux loads the system configuration file from /usr/local/etc/tmux.conf, if present, then looks for a user configuration file at ~/.tmux.conf.
Add following lines to your tmux.conf:
# vim /usr/local/etc/tmux.conf
or
# vim ~/.tmux.conf
### Note: key meaning
### C- means ctrl-, so C-x is ctrl-x.
### M- means meta (generally left-alt or escape)-, so M-x is left-alt-x.
### Set the prefix to ^A.
### Note: the default prefix is Ctrl-b.
unbind C-b
set -g prefix ^A
bind a send-prefix
### Set the maximum number of lines held in window history.
set -g history-limit 5000
### terminal 256 colors.
### As the tmux manual suggests: for tmux to work correctly, this must be set to "screen" or a derivative of it.
### Note: modify following line and set it to the terminal supported by your system (run cat /etc/termcap | egrep 'screen-256color|xterm-256color' to verify), and uncomment it.
###set -g default-terminal screen-256color
###set -g default-terminal xterm-256color
### Instructs tmux to expect UTF-8 sequences to appear in this window.
setw -g utf8 on
### Instruct tmux to treat top-bit-set characters in the status-left and status-right strings as UTF-8;
set -g status-utf8 on
### date format: hostname weekday month day, hour:minute
set -g status-right '#H %a %b %d, %H:%M'
### Set status line background colour.
set -g status-bg black
### Set status line foreground colour.
set -g status-fg yellow
### Set status line background colour for the currently active window.
setw -g window-status-current-bg magenta
### Set status line foreground colour for the currently active window.
setw -g window-status-current-fg white
### Reload tmux.conf configuration file
### Note: alternative way to reload the configuration file:
### Method 1: Run from command line: tmux source-file ~/.tmux.conf
### Method 2: In any tmux sessions: [prefix Ctrl-b] : source-file /usr/local/etc/tmux.conf
### Method 3: bind the source-file command with a key like following line, then you type: ctrl-b-r
bind r source-file /usr/local/etc/tmux.conf
### [START] vi- and vim-like bindings
### split windows like vim
### vim's definition of a horizontal/vertical split is reversed from tmux's
bind s split-window -v
bind v split-window -h
### move around panes with hjkl, as one would in vim after pressing ctrl-w
bind h select-pane -L
bind j select-pane -D
bind k select-pane -U
bind l select-pane -R
### resize panes like vim
### feel free to change the "5" to however many lines you want to resize by, only
### one at a time can be slow
bind < resize-pane -L 5
bind > resize-pane -R 5
bind - resize-pane -D 5
bind + resize-pane -U 5
### bind : to command-prompt like vim
### this is the default in tmux already
bind : command-prompt
### vi-style controls for copy mode
setw -g mode-keys vi
### [END] vi- and vim-like bindings
Add following line to your ~/.cshrc:
# vim ~/.cshrc
### Note: modify following line and set it to the terminal supported by your system (run cat /etc/termcap | egrep 'screen-256color|xterm-256color' to verify), and uncomment it.
#setenv TERM screen-256color
#setenv TERM xterm-256color
Add following lines to your ~/.vimrc:
# vim ~/.vimrc
" To enable 256 colors in vim, put this your .vimrc before setting the colorscheme.
set t_Co=256
Use following script to test verify whether your terminal supports 256 colors:
a small perl script that outputs a grid of 256 colors in your console.
It should look like this:
To see a list of TERM values supported by the system:
# cat /etc/termcap
# cat /etc/termcap | egrep 'screen-256color|xterm-256color'
Determine the terminal capability interface:
# tput Co
8
# tput colors
115
# cap_mkdb
# setenv | grep TERM
# echo $TERM
# tmux
# tmux ls
# tmux a -d
# tmux attach -d -t 1
Move window, reorder window
The 'swap-window' command is closest to what you want. "Prefix :" (that is "Ctrl-B :" by default) brings you to the tmux-command prompt. There you enter 'swap-window -s 3 -t 1' to let window number 3 and window number 1 swap their positions.
To move the current window to the top, do 'swap-window -t 0' (if base-index is 0, as it is by default).
You can bind that command to a key (T for "top" for example) by adding
bind-key T swap-window -t 0
to your ~/.tmux.conf.
Note: if you see following error messages after run the tmux command:
csh: Cannot open /etc/termcap.
csh: using dumb terminal settings.
Make sure you set following line to the terminal supported by your system (run cat /etc/termcap | egrep 'screen-256color|xterm-256color' to verify) in your /usr/local/etc/tmux.conf:
set -g default-terminal screen-256color
or
set -g default-terminal xterm-256color
Other useful tool:
tmuxinator - Manage complex tmux sessions easily
screen and tmux
A comparison of the features (or more-so just a table of notes for accessing some of those features) for GNU screen and BSD-licensed tmux.This document released for use under the PPL license available at http://code.dayid.org/ppl/ppl.txt
Want more information about tmux and screen? Check out This page also
The formatting here is simple enough to understand (I would hope). ^ means ctrl+, so ^x is ctrl+x. M- means meta (generally left-alt or escape)+, so M-x is left-alt+x | ||
| Action | tmux | screen |
| start a new session | tmux OR tmux new OR tmux new-session | screen |
| re-attach a detached session | tmux attach OR tmux attach-session | screen -r |
| re-attach an attached session (detaching it from elsewhere) | tmux attach -d OR tmux attach-session -d OR tmux a -d | screen -dr OR screen -RD |
| re-attach an attached session (keeping it attached elsewhere) | tmux attach OR tmux attach-session | screen -x |
| detach from currently attached session | ^b d OR ^b :detach | ^a ^d OR ^a :detach |
| rename-window to newname | ^b , <newname> OR ^b :rename-window <newname> | ^a A <newname> |
| list windows | ^b w | ^a w |
| list windows in chooseable menu | ^a " | |
| go to window # | ^b # | ^a # |
| go to last-active window | ^b l | ^a l |
| go to next window | ^b n | ^a n |
| go to previous window | ^b p | ^a p |
| see keybindings | ^b ? | ^a ? |
| list sessions | ^b s OR tmux ls OR tmux list-sessions | screen -ls |
| toggle visual bell | ^a ^g | |
| create another shell | ^b c | ^a c |
| exit current shell | ^d | ^d |
| split pane horizontally | ^b " | |
| split pane vertically | ^b % | |
| switch to another pane | ^b o | |
| kill the current pane | ^b x OR (logout/^D) | |
| close other panes except the current one | ^b ! | |
| swap location of panes | ^b ^o | |
| show time | ^b t | |
| show numeric values of panes | ^b q | |
Reference:
http://gala4th.blogspot.com/2011/09/install-tmux-on-freebsd-tutorial-step.html
http://www.dayid.org/os/notes/tm.html
x86 Assembly: How do Disassemblers know how to break up instructions?
How does a x86 disassembler know where to break up the instructions?
I am looking at the 8088 instruction set. For example the move instruction has 7 variations that range from 2 to 4 bytes. The instructions themselves seem to follow no particular order. Another reason for Why is x86 ugly?.
For example:
many instruction can overlap in the first byte:
The bitmasks appears to have arbitrary assignment. How does a disassembler break apart the instructions?
This question is a sub set of How to write a disassembler.
===
I am looking at the 8088 instruction set. For example the move instruction has 7 variations that range from 2 to 4 bytes. The instructions themselves seem to follow no particular order. Another reason for Why is x86 ugly?.
For example:
76543210 76543210 76543210 76543210
reg/mem to/from reg 100010dw ||regr/m
imm to reg/mem 1100011w ||000r/m dat dat w=1
imm to reg 1011wreg data dat w=1
imm to accum 1010000w addr-low addrhigh
accum to mem 1010001w addr-low addrhigh
reg/mem to seg 10001100 ||0ssr/m
seg to reg/mem 10001100 ||0ssr/m
Legend:
||=mod {NO-DISP=0,DISP-LOW,DISP-HIGH,REG}
ss=seg enum{es=0,cs,ss,ds}
reg=enum{ax=0,bx,cd,dx,bx,sp,bp,si,di (if w=1)} enum{al,bl...} (if w=0)
r/m=reg or mem (mod=3 then REG, else mem)
many instruction can overlap in the first byte:
76543210 76543210 76543210 76543210
push 11111111 ||110r/m
inc 1111111w ||000r/m
The bitmasks appears to have arbitrary assignment. How does a disassembler break apart the instructions?
This question is a sub set of How to write a disassembler.
===
Looking at my 8086/8088 Users Manual
Programmers reference (ISBN 1-55512-010-5), likely decades out of
print...Appendix A shows the instruction decoding in opcode order
0b00000000 thru 0b11111111. Does not appear to be chaotic at all. Add,
sub, and, xor, cmp, etc are all grouped in such a way that a mux can
use the opcode bits directly to route the inputs and outputs, and other
bits select the operation the alu performs on those bits.
For writing a disassembler you want to use this kind of table or an opcode chart for the top level sorting of instructions.
In your particular example, notice how whenever you see the first opcode as 0xFF there are three bits in the middle of the second byte that tell you the rest of the story as to which instruction is which. All 8 of those combinations (one is undefined) are represented and easily decoded from those 3 bits.
Yes, the x86 instruction set is crazy. Interesting and fun features, but considerably better instruction sets have been invented since. The only reason x86 has not gone the way of the 6502 for example is momentum, not quality.
You should look at this one too:
http://stackoverflow.com/questions/3917098/how-are-hex-sequence-translated-to-assembly-without-ambiguity
How to disassemble this and any other variable word length instruction set is by doing it in execution order. You will fail if you try to do it linearly in address order. Start with the vector table to get the entry addresses then follow those instructions in address order, making a note of and following all branches until you hit an unconditional branch or return or other instruction that terminates that string of instructions. Repeat this for every branch destination. That wont cover all of the instructions possible as the code may compute addresses while executing (not much you can do about disassembling that).
If any of this code was hand written intentionally or accidentally to trip up a disassembler you can expect to have collisions where the second or third byte of one opcode based on one execution path appears to be the first opcode of an instruction based on a different execution path. For example a clear a flag instruction followed by a conditional branch if flag is clear, followed by a byte of data, followed by a real instruction that is a branch destination. Yep, I have come across this. And it should be trapped by your disassembler, you need to put checks in to stop disassembling one or both of those execution paths when they collide. For complete disassembly expect to have to support some sort of user input to exclude addresses as opcodes, as well as for the user to manually add valid opcodes for you to follow the execution path from.
For fixed length instruction sets you can easily disassemble in address or execution order, your choice, address order from 0 to the end of memory is the easiest of course. Dont error out on undefined instructions, just mark them as such and keep going, some of those are data.
x86 is definitely the LAST variable length instruction set I would attempt to disassemble and I have written many disassemblers. No desire to ever attempt that project. Start with some fixed length ones like the pic and arm/thumb. Try the msp430 for variable word length, then maybe the 6502 (asteroids, asteroids deluxe, lunar lander, etc). Maybe a week or two worth of evenings to cover the above and get the feel for it, then attack the x86 if the desire remains. If you limit yourself strictly to the 8088/8086 it is not so bad, need to make sure your tools are generating those instructions and not getting into the 386 on up instructions.
If push vs inc is bothering you, definitely try something else like the msp430 for example first.
===
Thank you very much for the long descriptive answer. Things are starting to make a little more sense. The OP Code map reminds me of EBCDIC mlsite.net/8086/#tbl_oper (8086 Map). It does not appear so random any more. I was trying to envision it as a linear or set bit-mask to flag the instruction type. This site provides disassembler written in Python: mlsite.net/blog/?p=58
Reference:
http://stackoverflow.com/questions/3983735/x86-assembly-how-do-disassemblers-know-how-to-break-up-instructions?rq=1
For writing a disassembler you want to use this kind of table or an opcode chart for the top level sorting of instructions.
In your particular example, notice how whenever you see the first opcode as 0xFF there are three bits in the middle of the second byte that tell you the rest of the story as to which instruction is which. All 8 of those combinations (one is undefined) are represented and easily decoded from those 3 bits.
Yes, the x86 instruction set is crazy. Interesting and fun features, but considerably better instruction sets have been invented since. The only reason x86 has not gone the way of the 6502 for example is momentum, not quality.
You should look at this one too:
http://stackoverflow.com/questions/3917098/how-are-hex-sequence-translated-to-assembly-without-ambiguity
How to disassemble this and any other variable word length instruction set is by doing it in execution order. You will fail if you try to do it linearly in address order. Start with the vector table to get the entry addresses then follow those instructions in address order, making a note of and following all branches until you hit an unconditional branch or return or other instruction that terminates that string of instructions. Repeat this for every branch destination. That wont cover all of the instructions possible as the code may compute addresses while executing (not much you can do about disassembling that).
If any of this code was hand written intentionally or accidentally to trip up a disassembler you can expect to have collisions where the second or third byte of one opcode based on one execution path appears to be the first opcode of an instruction based on a different execution path. For example a clear a flag instruction followed by a conditional branch if flag is clear, followed by a byte of data, followed by a real instruction that is a branch destination. Yep, I have come across this. And it should be trapped by your disassembler, you need to put checks in to stop disassembling one or both of those execution paths when they collide. For complete disassembly expect to have to support some sort of user input to exclude addresses as opcodes, as well as for the user to manually add valid opcodes for you to follow the execution path from.
For fixed length instruction sets you can easily disassemble in address or execution order, your choice, address order from 0 to the end of memory is the easiest of course. Dont error out on undefined instructions, just mark them as such and keep going, some of those are data.
x86 is definitely the LAST variable length instruction set I would attempt to disassemble and I have written many disassemblers. No desire to ever attempt that project. Start with some fixed length ones like the pic and arm/thumb. Try the msp430 for variable word length, then maybe the 6502 (asteroids, asteroids deluxe, lunar lander, etc). Maybe a week or two worth of evenings to cover the above and get the feel for it, then attack the x86 if the desire remains. If you limit yourself strictly to the 8088/8086 it is not so bad, need to make sure your tools are generating those instructions and not getting into the 386 on up instructions.
If push vs inc is bothering you, definitely try something else like the msp430 for example first.
===
Thank you very much for the long descriptive answer. Things are starting to make a little more sense. The OP Code map reminds me of EBCDIC mlsite.net/8086/#tbl_oper (8086 Map). It does not appear so random any more. I was trying to envision it as a linear or set bit-mask to flag the instruction type. This site provides disassembler written in Python: mlsite.net/blog/?p=58
Reference:
http://stackoverflow.com/questions/3983735/x86-assembly-how-do-disassemblers-know-how-to-break-up-instructions?rq=1
Subscribe to:
Posts (Atom)