Using Kali Linux (And other systems) natively on Windows 10 without VM.

[Insider]

Using Kali Linux (And other systems) natively on Windows 10 without VM.

Not exactly something new but thought I'd share this cool trick there. Especially useful if you want to get access to Kali commandline tools like SET, metasploit and more without firing up a VM taking up a lot of system resources.

Note: This only applies for the linux commandline. So you probably wont be able to fire up GUI tools. But rather mostly for commandline tools such as Nikto etc. Bash for Windows doesn't seem to support GUI applications.

How to:

1. Enable WSL (Windows Subsystem for Linux).

Control Panel > Programs > Programs and Features > Turn Windows features on or off:



"Bottom"
Check: Windows Subsystem for Linux.

2. Reboot.

3. Sign into microsoft store, download Linux Subsystem of your choice: "Search for linux".



4. Fire up your commandline.

For kali, type "kali" into commandline to launch Linux subsystem:



Boom!

[dropzone]

While WSL is absolutely a god-send, and makes Windows much more bearable to use. When it comes to use it there are some gotchas to be aware of.

1. Windows and as such WSL doesn't support RAW (AF_PACKET) sockets. This means tools that use that either for listening or crafting complete packets won't work under WSL: Tcpdump, Wireshark, Scapy library, some nmap scan types. You won't be able to use a WiFi device in promiscuous mode so many WiFi tools are out also.

Of course there are Windows options you can install that generally use Winpcap to get this functionality.

2. Limited support for inotify. This is a family of functions for monitoring the filesystem, essentially getting notified when a file changes or something like that. While the functionality does work, the implementation has been buggy when getting events about files modified from a Windows application. Think like running a script in the Linux env and modifying a file from a text editor installed on Windows. This isn't a deal breaker but you're bound to eventually come across it and be wondering why its not detecting something filesystem related, it was a source of frustration for me.

3. 64Bit only, for most tools this isn't a problem but where I've run into it is when trying to use certain old Python packages that do some obscure task and were written forever ago.

4. No core dumps, it'll say it wrote them but it doesn't, you can enable them but WSL just doesn't do it. So if you want to analyze a crash hopefully you have a debugger attached before it happens.

On a whole WSL has made my Windows experience significantly better than when I was using Cygwin so by all means use it, but a VM is still the best option.

[enmafia2]

I am not sure if this was fixed, but when this came out there were vulns caused by this.
One of them is bashware. I saw this on 2017, so I hope this was fixed, but I can't find any news about this.
If someone can tell please do.

For people who don't know what Bashware is:

"WSL enables Linux system calls to be directed into the Windows kernel."

"Bashware does not leverage any logic or implementation flaws in WSL’s design. In fact, WSL seems to be well designed. What allows Bashware to operate the way it does is the lack of awareness by various security vendors, due to the fact that this technology is relatively new and expands the known borders of the Windows operating system."

Read more:
https://research.checkpoint.com/beware-b...solutions/