I am using bash. I have switched off ASLR in Ubuntu 11.04 using
#sysctl -w kernel.randomize_va_space=0
And I have exported a variable from the shell using
$ export MYSHELL=/bin/sh
I wrote a C program to get the address of the MYSHELL:
void main(){
char* shell = getenv("MYSHELL");
if (shell)
printf("0x%x\n", (unsigned int)shell);
}
It spat out 0xbffffe82.
When I used it as a part of my attack for ret-to-libc, the address changes (although by a very small offset).
Why does this happen?
Also when I change the filename of the binary and use the previously successful address, it won't work, and it has been relocated to a different address. Why? In other words, What is the relation of binary names and environment variable addresses? Is this a protection feature by bash? How do I switch this off?
Note: this is not homework.
Stack layout at program startup is documented here. It should be obvious why changing the name of the program (length really) changes the layout.
Related
Following Situation I need to setup the DISPLAY Variable for my WSL2 to transmit goutput to the Xserver running on my Host-System.
In general I would do this by using my .bashrc:
export DISPLAY=$(ip route list default | awk '{print $3}'):0
So I started by setting the DISPLAY Variable with
set -Ux DISPLAY $(ip route list default | awk '{print $3}'):0
which worked in the first place.
The Issue: The Variable is now set inside .config/fish/fish_variables as SETUVAR --export DISPLAY:<MY-IP>:0
Seems fine for the moment but since my Homenet uses DHCP it might happen that my IP is changing. How do I set the variable by calling the top used command?
Your mistake was using set -U. That creates a "universal" variable. Instead, simply do set -x in your ~/.config/fish/config.fish so the var is created every time you start a fish shell. See also https://fishshell.com/docs/current/faq.html#why-doesn-t-set-ux-exported-universal-variables-seem-to-work. Universal variables shouldn't be used for values that can change each time you start a fish shell or that might be different for concurrently running shells.
Kurtis's answer would normally be correct, but this is WSL2, and there's (IMHO) a better solution on WSL2 that can use fish universal variables.
set -Ux DISPLAY (hostname).local:0
As long as the hostname matches the Windows Computer Name (which it should and does by default), then that will always use mDNS to return the correct address, even if the IP has changed.
Note that you'll need to remove the global variable definition from ~/.config/fish/config.fish or else the universal will be shadowed by the global.
Explanation:
You might think that it is the dynamically assigned DHCP address changing that is causing the problem, but that's not actually it. The IP address that you get back from ip route list default | awk '{print $3}' is not the one that is assigned to Windows by DHCP on your home network.
It's actually the address of a virtual switch provided by WSL2 that allows WSL2 to communicate with the Windows host (and beyond).
When the Windows IP address changes, it doesn't matter to this virtual switch. Side note: I just confirmed this to make sure on WSL2 by changing my Windows IP manually.
The problem here is actually that the switch address changes each time the computer (or WSL2) restarts. This is why most instructions for setting your DISPLAY on WSL2 tell you to map it to this address, rather than hardcoding it.
As Kurtis said, however, this type of assignment would (typically) be a problem if you were using a fish universal variable, since the virtual switch IP does change each reboot.
But WSL2 provides a convenient mDNS lookup for the address, in the form of <computername>.local. By hardcoding that into the universal variable, DISPLAY should always resolve correctly, even after the IP address itself changes.
In PowerShell, is there a way to preserve the ANSI control codes used to convey color information to the console when assigning a program's output to a variable?
For instance, I use Test Kitchen which provides colored output unique to each suite of tests to run. When I run kitchen create INSTANCE, I get output in several colors. However, if I assign the output to a variable, or pipe it to another cmdlet such as Tee-Object, that color information is lost. It seems that PowerShell strips this information out when the result is sent down the pipeline or assigned to a variable:
kitchen create INSTANCE # Colored output
$output = kitchen create INSTANCE
Write-Host $output # Color information is lost
Curiously though, I can implement control codes in my own strings and PowerShell is able to honor them when Virtual Terminal is enabled. These survive variable assignment, unlike command output:
$output = "`u{001b}[31mHello"
Write-Host $output # Results in colored output
So it seems that the color information is being stripped out only from a program's output, and only if the value is assigned or sent down the pipeline. Is there a way to preserve these control codes from external commands?
To add to your own answer:
On Windows I'm not aware of any simple solutions, though perhaps there is a programmatic way to do what the script utility does on Unix-like platforms (see below).
On Unix-like platforms, you can use the script utility to make external programs believe they are connected to a terminal and thus make them produce colored output they would otherwise suppress:
script is not a POSIX-mandated utility, but it ships with at least some Linux distros, notably Ubuntu, as well as with macOS.
Notably, the macOS and Linux implementations use different syntax, as shown below.
Example:
Note:
ls --color=auto is used as a readily available test command, because it exhibits the conditional coloring behavior.
ls --color=always would exhibit unconditional coloring behavior, and would therefore obviate the need for script - as such, ls is an example of a utility that does allow you to request unconditional coloring; ls --color=auto merely serves as a stand-in for utilities that do not.
The variable assignment below ($out = ...) is enclosed in (...) in order to pass the value being assigned through, so you'll see right away that the coloring is preserved.
Linux
($out = script -qc 'ls --color=auto')
macOS:
($out = script -q /dev/stdout ls --color=auto)
As mentioned by #IMSoP and #mklement0 in the question comments, the problem does not lie within PowerShell. To quote #mklement0:
PowerShell is not to blame here. Most utilities (external programs) that are capable of colored output via ANSI escape sequences at least by default apply coloring selectively, namely only when stdout is connected to a terminal (i.e. when printing to the display). Such utilities may offer opt-in mechanisms to apply coloring unconditionally, via command-line options and/or environment variables.
I'm doing some work using Linux server, after I log on to the server,the tutorial says:
If you need to run any program which will open a window, like xterm, from these servers, you need to set display first.
To do that, I need to execute setenv DISPLAY name:portnum.What does this command really do?If I don't execute this command,what will happen?And what is xterm?
setenv is specific and peculiar to csh and derivatives. The modern portable syntax is
DISPLAY=:0.0
though if your shell is csh or tcsh, this will not work, and you do need setenv after all.
Depending on the use case, you may need to export DISPLAY as well.
Environment variables are a simple way to pass configuration information between programs. The DISPLAY variable indicates to graphical programs on which screen or graphical terminal to display their GUI.
For X Window System, it is a server/client architecture, usually, server side is called display, the tutorials means you should launch server side and specify launch parameter for server side.
read here for more details.
Xterm is just a terminal. And setenv, is used to set Environment variables, which are basically variables used to define the behavior of the terminal. For example, you have the variable PATH, which is used by the terminal to find the path where to execute binaries. Because if you type the command "ls", your terminal has to go into the "env", look for the variable "PATH", and use the value stored in this variable "PATH" to find the path of the ls binary. But I don't know if it's necessary in your situation, could you give more details about the context?
I have opened an executable in IDA Pro, and found the location I want to break at, 0x3390 from the beginning of the file.
How do I set a breakpoint in lldb at the memory address, start of program + 0x3390.
I tried b s -a 0x3390 but it doesn't work, I presume because I need the actual address, not the offset.
The image list command will show the load address of the __TEXT.__text section of all the executables loaded in the program. If you need more information, image dump sections will dump the addresses of all the sections. From this you should be able to figure out what to offset your address with. Note that the program may not load at its pre-run address, so you may have to figure out the base address after you've started up.
Then you should be able to say:
(lldb) br set -a <FileAddress>+<Address>
Note, b is an alias for some fancy regular-expression based command that tries to emulate the gdb breakpoint expression parser, so you either need to disable that alias or use br to get the full breakpoint command.
I have a script that on startup of an application is looking for the host. I am declaring a variable at the beginning of the script VAR=$(uname -n) and calling that variable as needed throughout the script. Is there any advantage/disadvantage to just using $(uname -n) throughout the script instead of just calling the variable each time?
If you use a variable it is slightly more efficient, as it will spawn the program only once. You are also sure that the value does not change (which is not typically the case). You also need to handle execution errors only once, so I would say: go for it.
(And you should use the full path to uname or be sure to sanitize the PATH before using relative commands).
BTW: if you call the variable UNAME instead of VAR, then it is also less confusing :)
BTW2: the uts_name you get from this method might not always be the right hostname. Hard to say without knowing for what you use it.