#StackBounty: #debian #linux-kernel #osx #console #qemu Generate a QEMU bootable kernel from an existing installation

Bounty: 100

I have been trying to setup QEMU to provide console output only. So far I have succeeded with the following parameters: qemu-system -curses -hda debian.img, where debian.img is a working Debian installation. No other boot related parameters are used. (N)Curses seems to be terribly buggy and slow for this purpose however, at least under a macOS host.

I found out that a better way to achieve console, non-gui output to the terminal that qemu is launched in by using -serial stdio -append "console=ttyAMA0" instead of -curses. This option requires you to specify a kernel with the -kernel parameter however. Is there a way I can extract a bootable kernel from my existing Debian installation that I can provide to qemu? I already tried copying vmlinux from /boot, and also followed this guide to extract the kernel from the OS, but they won’t boot under QEMU with my existing debian.img file. I believe I possibly have to supply the initrd.img from my OS to qemu as well.

Now, is it possible to keep using my exisiting debian.img file with a fully working OS on it, while also passing an (extracted) kernel from that image (or elsewhere if needed) to qemu using the -kernel parameter? (and the same question for the initrd.img file)
My guest OS on the debian.img file is Debian Jessy.


Get this bounty!!!

#StackBounty: #process #linux-kernel #malware how does fileless malware work on linux?

Bounty: 200

I understand the definition of fileless malware:

Malicious code that is not file based but exists in memory only… More
particularly, fileless malicious code … appends itself to an active
process in memory…

Can somebody please explain how this appending itself to an active process in memory works ?

Also, what (kernel) protection/hardening is available against such attacks ?


Get this bounty!!!

#StackBounty: #linux-kernel #ip #routing Understand when in the day of a life of an ICMP "echo reply" message "ip rule&q…

Bounty: 100

I have a PC with two interfaces: eth0(IP address 192.168.1.16) and eth2(IP address 10.10.10.73). In addition, I have a host route in this PC in main table which says that if destination address is 172.16.1.1, then use eth0 interface.

Now when I send ICMP “echo request” from 172.16.1.1 to 10.10.10.73(eth2 interface), then ICMP “echo reply” is sent out from eth0(I have RPF disabled) using 192.168.1.16 as a source IP. This all is as expected because of this host route.

However, when I add an ip rule with selector from 10.10.10.73 and action lookup test right after rule number 0 and table test contains simply a default route using eth2 interface, then ICMP “echo reply” is sent out from eth2 interface.

I’m confused how can this from 10.10.10.73 selector match. When in the day of a life of an ICMP “echo reply” message the source IP was 10.10.10.73 so that match occurred?


Get this bounty!!!

#StackBounty: #linux-kernel #ip #routing Understand when in the day of a life of an ICMP "echo reply" message "ip rule&q…

Bounty: 100

I have a PC with two interfaces: eth0(IP address 192.168.1.16) and eth2(IP address 10.10.10.73). In addition, I have a host route in this PC in main table which says that if destination address is 172.16.1.1, then use eth0 interface.

Now when I send ICMP “echo request” from 172.16.1.1 to 10.10.10.73(eth2 interface), then ICMP “echo reply” is sent out from eth0(I have RPF disabled) using 192.168.1.16 as a source IP. This all is as expected because of this host route.

However, when I add an ip rule with selector from 10.10.10.73 and action lookup test right after rule number 0 and table test contains simply a default route using eth2 interface, then ICMP “echo reply” is sent out from eth2 interface.

I’m confused how can this from 10.10.10.73 selector match. When in the day of a life of an ICMP “echo reply” message the source IP was 10.10.10.73 so that match occurred?


Get this bounty!!!

#StackBounty: #linux-kernel #ip #routing Understand when in the day of a life of an ICMP "echo reply" message "ip rule&q…

Bounty: 100

I have a PC with two interfaces: eth0(IP address 192.168.1.16) and eth2(IP address 10.10.10.73). In addition, I have a host route in this PC in main table which says that if destination address is 172.16.1.1, then use eth0 interface.

Now when I send ICMP “echo request” from 172.16.1.1 to 10.10.10.73(eth2 interface), then ICMP “echo reply” is sent out from eth0(I have RPF disabled) using 192.168.1.16 as a source IP. This all is as expected because of this host route.

However, when I add an ip rule with selector from 10.10.10.73 and action lookup test right after rule number 0 and table test contains simply a default route using eth2 interface, then ICMP “echo reply” is sent out from eth2 interface.

I’m confused how can this from 10.10.10.73 selector match. When in the day of a life of an ICMP “echo reply” message the source IP was 10.10.10.73 so that match occurred?


Get this bounty!!!

#StackBounty: #linux-kernel #ip #routing Understand when in the day of a life of an ICMP "echo reply" message "ip rule&q…

Bounty: 100

I have a PC with two interfaces: eth0(IP address 192.168.1.16) and eth2(IP address 10.10.10.73). In addition, I have a host route in this PC in main table which says that if destination address is 172.16.1.1, then use eth0 interface.

Now when I send ICMP “echo request” from 172.16.1.1 to 10.10.10.73(eth2 interface), then ICMP “echo reply” is sent out from eth0(I have RPF disabled) using 192.168.1.16 as a source IP. This all is as expected because of this host route.

However, when I add an ip rule with selector from 10.10.10.73 and action lookup test right after rule number 0 and table test contains simply a default route using eth2 interface, then ICMP “echo reply” is sent out from eth2 interface.

I’m confused how can this from 10.10.10.73 selector match. When in the day of a life of an ICMP “echo reply” message the source IP was 10.10.10.73 so that match occurred?


Get this bounty!!!

#StackBounty: #linux-kernel #ip #routing Understand when in the day of a life of an ICMP "echo reply" message "ip rule&q…

Bounty: 100

I have a PC with two interfaces: eth0(IP address 192.168.1.16) and eth2(IP address 10.10.10.73). In addition, I have a host route in this PC in main table which says that if destination address is 172.16.1.1, then use eth0 interface.

Now when I send ICMP “echo request” from 172.16.1.1 to 10.10.10.73(eth2 interface), then ICMP “echo reply” is sent out from eth0(I have RPF disabled) using 192.168.1.16 as a source IP. This all is as expected because of this host route.

However, when I add an ip rule with selector from 10.10.10.73 and action lookup test right after rule number 0 and table test contains simply a default route using eth2 interface, then ICMP “echo reply” is sent out from eth2 interface.

I’m confused how can this from 10.10.10.73 selector match. When in the day of a life of an ICMP “echo reply” message the source IP was 10.10.10.73 so that match occurred?


Get this bounty!!!

#StackBounty: #linux-kernel #ip #routing Understand when in the day of a life of an ICMP "echo reply" message "ip rule&q…

Bounty: 100

I have a PC with two interfaces: eth0(IP address 192.168.1.16) and eth2(IP address 10.10.10.73). In addition, I have a host route in this PC in main table which says that if destination address is 172.16.1.1, then use eth0 interface.

Now when I send ICMP “echo request” from 172.16.1.1 to 10.10.10.73(eth2 interface), then ICMP “echo reply” is sent out from eth0(I have RPF disabled) using 192.168.1.16 as a source IP. This all is as expected because of this host route.

However, when I add an ip rule with selector from 10.10.10.73 and action lookup test right after rule number 0 and table test contains simply a default route using eth2 interface, then ICMP “echo reply” is sent out from eth2 interface.

I’m confused how can this from 10.10.10.73 selector match. When in the day of a life of an ICMP “echo reply” message the source IP was 10.10.10.73 so that match occurred?


Get this bounty!!!

#StackBounty: #linux-kernel #ip #routing Understand when in the day of a life of an ICMP "echo reply" message "ip rule&q…

Bounty: 100

I have a PC with two interfaces: eth0(IP address 192.168.1.16) and eth2(IP address 10.10.10.73). In addition, I have a host route in this PC in main table which says that if destination address is 172.16.1.1, then use eth0 interface.

Now when I send ICMP “echo request” from 172.16.1.1 to 10.10.10.73(eth2 interface), then ICMP “echo reply” is sent out from eth0(I have RPF disabled) using 192.168.1.16 as a source IP. This all is as expected because of this host route.

However, when I add an ip rule with selector from 10.10.10.73 and action lookup test right after rule number 0 and table test contains simply a default route using eth2 interface, then ICMP “echo reply” is sent out from eth2 interface.

I’m confused how can this from 10.10.10.73 selector match. When in the day of a life of an ICMP “echo reply” message the source IP was 10.10.10.73 so that match occurred?


Get this bounty!!!

#StackBounty: #linux-kernel #ip #routing Understand when in the day of a life of an ICMP "echo reply" message "ip rule&q…

Bounty: 100

I have a PC with two interfaces: eth0(IP address 192.168.1.16) and eth2(IP address 10.10.10.73). In addition, I have a host route in this PC in main table which says that if destination address is 172.16.1.1, then use eth0 interface.

Now when I send ICMP “echo request” from 172.16.1.1 to 10.10.10.73(eth2 interface), then ICMP “echo reply” is sent out from eth0(I have RPF disabled) using 192.168.1.16 as a source IP. This all is as expected because of this host route.

However, when I add an ip rule with selector from 10.10.10.73 and action lookup test right after rule number 0 and table test contains simply a default route using eth2 interface, then ICMP “echo reply” is sent out from eth2 interface.

I’m confused how can this from 10.10.10.73 selector match. When in the day of a life of an ICMP “echo reply” message the source IP was 10.10.10.73 so that match occurred?


Get this bounty!!!