Microsoft offers Windows 10 as a free upgrade for computers running a genuine copy of Windows 7 or Windows 8.1. Also, similar to previous releases, the operating system is available on different editions and two versions: 32-bit and 64-bit.While upgrading from Windows 10 Home to Windows 10 Pro is not free, what many people are unfamiliar with is that Microsoft won't ask for more money to upgrade from a 32-bit to a 64-bit version.
However, the upgrade path only allows moving from a qualifying version to its equivalent edition on the same architecture. This limit means that if your PC is running a 32-bit version of Windows 8.1, after the upgrade you'll be stuck with the 32-bit version of Windows 10 — even if your computer's processor can handle the 64-bit version. The only solution is to make a clean installation of the operating system and reconfigure all your apps and settings.
In this Windows 10 guide, we'll walk you through the steps to verify whether your computer in fact includes support for a 64-bit version and we'll guide you through the upgrade process to Windows 10 (x64).
Make sure Windows 10 64-bit is compatible with your PC
A 64-bit version of Windows can only be installed on computers with capable hardware. As such, the first thing you need to do is to determine whether your computer has a 64-bit processor.
You can easily get this information from the Settings app.
Use the Windows key + I keyboard shortcut to open the Settings app.
Click System.
Click About.
Under System type, you will see two pieces of information: if it says 32-bit operating system, x64-based processor, then it means that your PC is running a 32-bit version of Windows 10 on a 64-bit processor. If it says 32-bit operating system, x86-based processor, then your computer doesn't support Windows 10 (64-bit).
Make Sure Your Processor is 64-bit Capable
First thing's first. Before even thinking of upgrading to 64-bit Windows, you'll need to confirm that the CPU in your computer is 64-bit capable. To do so, head to Settings > System > About. On the right-hand side of the window, look for the "System type" entry.
You'll see one of three things here:
64-bit operating system, x64-based processor. Your CPU does support 64-bit and you already have the 64-bit version of Windows installed.
32-bit operating system, x86-based processor. Your CPU does not support 64-bit and you have the 32-bit version of Windows installed.
32-bit operating system, x64-based processor. Your CPU supports 64-bit, but you have the 32-bit version of Windows installed.
If you see the first entry on your system, you don't really need this article. If you see the second entry, you won't be able to install the 64-bit version of Windows on your system at all. But if you see the last entry on your system—"32-bit operating system, x64-based processor"—then you're in luck. This means you're using a 32-bit version of Windows 10 but your CPU can run a 64-bit version, so if you see it, it's time to move on to the next section. Make Sure Your PC's Hardware Has 64-bit Drivers Available
Even if your processor is 64-bit compatible, you might want to consider whether your computer's hardware will work properly with a 64-bit version of Windows. 64-bit versions of Windows require 64-bit hardware drivers, and the 32-bit versions you're using on your current Windows 10 system won't work.
Modern hardware should certainly offer 64-bit drivers, but very old hardware may no longer be supported and the manufacturer may have never offered 64-bit drivers. To check for this, you can visit the manufacturer's driver download web pages for your hardware and see if 64-bit drivers are available. You shouldn't necessarily need to download these from the manufacturer's website, though. They are likely included with Windows 10 or automatically will be downloaded from Windows Update. But old hardware—for example, a particularly ancient printer—simply may not offer 64-bit drivers.
Upgrade by Performing a Clean Install
You'll need to perform a clean install to get to the 64-bit version of Windows 10 from the 32-bit one. Unfortunately, there's no direct upgrade path.
Warning: Back up your important files before continuing and also make sure you have what you need to reinstall your programs. This process will wipe your whole hard disk, including Windows, installed programs, and personal files.
First, if you haven't upgraded to Windows 10 yet, you'll need to use the upgrade tool to upgrade. You'll get the 32-bit version of Windows 10 if you were previously using a 32-bit version of Windows 7 or 8.1. But the upgrade process will give your PC a Windows 10 license. After upgrading, be sure to check that your current 32-bit version of Windows 10 is activated under Settings > Update & security > Activation.
Once you're using an activated version of the 32-bit Windows 10, download the Windows 10 media creation tool from Microsoft. If you're using the 32-bit version of Windows 10 at the moment, you'll have to download and run the 32-bit tool.
When you run the tool, select "Create installation media for another PC" and use the tool to create a USB drive or burn a disc with Windows 10. As you click through the wizard, you'll be asked whether you want to create 32-bit or 64-bit installation media. Select the "64-bit (x64)" architecture.
Next, restart your computer (you did back everything up, right?) and boot from the installation media. Install the 64-bit Windows 10, selecting "Custom install" and overwriting your current version of Windows. When you're asked to insert a product key, skip the process and continue. You'll have to skip two of these prompts in total. After you reach the desktop, Windows 10 will automatically check in with Microsoft and activate itself. You'll now be running the 64-bit edition of Windows on your PC.
If you want to go back to the 32-bit version of Windows, you'll need to download the media creation tool—the 64-bit version, if you're running the 64-bit version of Windows 10—and use it to create 32-bit installation media. Boot from that installation media and do another clean install—this time installing the 32-bit version over the 64-bit version.
Final Words :
Finally, you are aware of the way through which you could be able to switch from the 32-bit windows to 64-bit windows really easily. There will be no difference in the functions or the working of the windows yet the only change that you will get is the more advanced architecture that is compatible with numerous high-end apps. If you are thinking to switch your windows to the 64-bit version then make sure you first check for your hardware compatibility. Hopefully, you would have liked the information of this post, please share this post with others if you really liked it. Provide us your valuable views regarding this post through using the comments section below. At last nevertheless thanks for reading this post!
you are just interested in hacker conference badge hacking.
or maybe all of the above. Whatever the reasons, this guide should be helpful for those who never had any real-life experience with these little gadgets.
But first things first, here is a list what you need for hacking the badge:
a computer with USB port and macOS, Linux or Windows. You can use other OS as well, but this guide covers these
USB mini cable to connect the badge to the computer
the Hacktivity badge from 2018
By default, this is how your badge looks like.
Let's get started
Luckily, you don't need any soldering skills for the first steps. Just connect the USB mini port to the bottom left connector on the badge, connect the other part of the USB cable to your computer, and within some seconds you will be able to see that the lights on your badge are blinking. So far so good.
Now, depending on which OS you use, you should choose your destiny here.
Linux
The best source of information about a new device being connected is
# dmesg
The tail of the output should look like
[267300.206966] usb 2-2.2: new full-speed USB device number 14 using uhci_hcd [267300.326484] usb 2-2.2: New USB device found, idVendor=0403, idProduct=6001 [267300.326486] usb 2-2.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [267300.326487] usb 2-2.2: Product: FT232R USB UART [267300.326488] usb 2-2.2: Manufacturer: FTDI [267300.326489] usb 2-2.2: SerialNumber: AC01U4XN [267300.558684] usbcore: registered new interface driver usbserial_generic [267300.558692] usbserial: USB Serial support registered for generic [267300.639673] usbcore: registered new interface driver ftdi_sio [267300.639684] usbserial: USB Serial support registered for FTDI USB Serial Device [267300.639713] ftdi_sio 2-2.2:1.0: FTDI USB Serial Device converter detected [267300.639741] usb 2-2.2: Detected FT232RL [267300.643235] usb 2-2.2: FTDI USB Serial Device converter now attached to ttyUSB0
Dmesg is pretty kind to us, as it even notifies us that the device is now attached to ttyUSB0.
From now on, connecting to the device is exactly the same as it is in the macOS section, so please find the "Linux users, read it from here" section below.
macOS
There are multiple commands you can type into Terminal to get an idea about what you are looking at. One command is:
# ioreg -p IOUSB -w0 -l
With this command, you should get output similar to this:
The most important information you get is the USB serial number - AC01U4XN in my case. Another way to get this information is
# system_profiler SPUSBDataType
which will give back something similar to:
FT232R USB UART:
Product ID: 0x6001 Vendor ID: 0x0403 (Future Technology Devices International Limited) Version: 6.00 Serial Number: AC01U4XN Speed: Up to 12 Mb/sec Manufacturer: FTDI Location ID: 0x14100000 / 2 Current Available (mA): 500 Current Required (mA): 90 Extra Operating Current (mA): 0
The serial number you got is the same.
What you are trying to achieve here is to connect to the device, but in order to connect to it, you have to know where the device in the /dev folder is mapped to. A quick and dirty solution is to list all devices under /dev when the device is disconnected, once when it is connected, and diff the outputs. For example, the following should do the job:
ls -lha /dev/tty* > plugged.txt ls -lha /dev/tty* > np.txt vimdiff plugged.txt np.txt
The result should be obvious, /dev/tty.usbserial-AC01U4XN is the new device in case macOS. In the case of Linux, it was /dev/ttyUSB0.
Linux users, read it from here. macOS users, please continue reading
Now you can use either the built-in screen command or minicom to get data out from the badge. Usually, you need three information in order to communicate with a badge. Path on /dev (you already got that), speed in baud, and the async config parameters. Either you can guess the speed or you can Google that for the specific device. Standard baud rates include 110, 300, 600, 1200, 2400, 4800, 9600, 14400, 19200, 38400, 57600, 115200, 128000 and 256000 bits per second. I usually found 1200, 9600 and 115200 a common choice, but that is just me. Regarding the async config parameters, the default is that 8 bits are used, there is no parity bit, and 1 stop bit is used. The short abbreviation for this is 8n1. In the next example, you will use the screen command. By default, it uses 8n1, but it is called cs8 to confuse the beginners.
If you type: # screen /dev/tty.usbserial-AC01U4XN 9600 or # screen /dev/ttyUSB0 9600 and wait for minutes and nothing happens, it is because the badge already tried to communicate via the USB port, but no-one was listening there. Disconnect the badge from the computer, connect again, and type the screen command above to connect. If you are quick enough you can see that the amber LED will stop blinking and your screen command is greeted with some interesting information. By quick enough I mean ˜90 seconds, as it takes the device 1.5 minutes to boot the OS and the CTF app.
Windows
When you connect the device to Windows, you will be greeted with a pop-up.
Just click on the popup and you will see the COM port number the device is connected to:
In this case, it is connected to COM3. So let's fire up our favorite putty.exe, select Serial, choose COM3, add speed 9600, and you are ready to go!
You might check the end of the macOS section in case you can't see anything. Timing is everything.
The CTF
Welcome to the Hacktivity 2018 badge challenge!
This challenge consists of several tasks with one or more levels of difficulty. They are all connected in some way or another to HW RE and there's no competition, the whole purpose is to learn things.
Note: we recommend turning on local echo in your terminal! Also, feel free to ask for hints at the Hackcenter!
I will not spoil any fun in giving out the challenge solutions here. It is still your task to find solutions for these.
But here is a catch. You can get a root shell on the device. And it is pretty straightforward. Just carefully remove the Omega shield from the badge. Now you see two jumpers; by default, these are connected together as UART1. As seen below.
But what happens if you move these jumpers to UART0? Guess what, you can get a root shell! This is what I call privilege escalation on the HW level :) But first, let's connect the Omega shield back. Also, for added fun, this new interface speaks on 115200 baud, so you should change your screen parameters to 115200. Also, the new interface has a different ID under /dev, but I am sure you can figure this out from now on.
If you connect to the device during boot time, you can see a lot of exciting debug information about the device. And after it boots, you just get a root prompt. Woohoo!
But what can you do with this root access? Well, for starters, how about running
# strings hello | less
From now on, you are on your own to hack this badge. Happy hacking.
PS: In case you want to use the radio functionality of the badge, see below how you should solder the parts to it. By default, you can process slow speed radio frequency signals on GPIO19. But for higher transfer speeds, you should wire the RF module DATA OUT pin with the RX1 free together.
Saw that a lot of people were looking for a pcap with WannaCry spreading Using EthernalBlue.
I have put together a little "petri dish" test environment and started looking for a sample that has the exploit. Some samples out there simply do not have the exploit code, and even tough they will encrypt the files locally, sometimes the mounted shares too, they would not spread.
Once I got the sample from the VxStream Sandbox site, dropped it in the test environment, and monitored it with Security Onion. I was super happy to see it spreading, despite the fact that for the first run my Windows 7 x64 VM went to BSOD as the EthernalBlue exploit failed.
A step by step lab based mini course on analyzing your car network
I wanted to learn about hacking cars. As usual I searched around the internet and didn't find any comprehensive resources on how to do this, just bits and pieces of the same info over and over which is frustrating. I am not a car hacking expert, I just like to hack stuff. This mini course will run in a fully simulated lab environment available from open garages, which means in 5 minutes from now you can follow along and hack cars without ever bricking your girlfriends car. Since you obviously wouldn't attack your own Lambo, totally use your girlfriends Prius.
Below are the topics covered in this blogseries so you can decide if you want to read further:
Whats covered in this car hacking mini course:
Setting up Virtual Environments for testing
Sniffing CAN Traffic
Parsing CAN Traffic
Reverse Engineering CAN IDs
Denial of service attacks
Replaying/Injecting Traffic
Coding your own CAN Socket Tools in python
Targeted attacks against your cars components
Transitioning this to attacking a real car with hardware
The first thing we are going to do before we get into any car hacking specifics such as "WTF is CAN?", is get your lab up and running. We are going to run a simple simulated CAN Bus network which controls various features of your simulated car. Its better to learn by doing then sit here and recite a bunch of car network lingo at you and hope you remember it.
I also don't want you to buy a bunch of hardware and jack into your real car right away. Instead there are options that can get you started hacking cars RIGHT NOW by following along with this tutorial. This will also serve to take away the fear of hacking your actual car by understanding what your doing first.
Video Playlist:
Setting up your Lab:
First things first, set yourself up with an Ubuntu VMware install, and load it up. Optionally you could use a Kali Iinux VM, however, that thing drives me nuts with copy paste issues and I think Kayak was giving me install problems. So support is on you if you would like to use Kali. However, I do know Kali will work fine with OpenGarages virtual car.. So feel free to use it for that if you have it handy and want to get started right away.
Install PreReq Libraries:
Once you load this up you are going to want to install CAN utilities and pre-requisite libraries. This is really easy to do with the following Apt-get commands:
Once this is done we can startup the simulator by changing directories to the downloaded repo and running the following 2 commands, which will setup a virtual CAN interface and a simulator GUI Cluster:
Run the setup Script to get the vcan0 interface up:
root@kali:~/ICSim# ./setup_vcan.sh
root@kali:~/ICSim# ./icsim vcan0
On a new terminal tab we will open up our simulators controller with the following command,
root@kali:~/ICSim#./controls vcan0
Note: that the controller must be the in-focus GUI screen to send keyboard commands to the simulator.
How to Use the Simulator:
The simulator has a speedometer with Right and Left turn signals, doors etc. Below are the list of commands to control the simulator when the Control panel is in focus. Give them each a try and note the changes to the simulator.
Up and Down keys control the gauges clusters speedometer
Left and Right keys Control the Blinkers
Right Shift + X, A or B open doors
Left Shift + X, A or be Close doors
Try a few of the above commands for example Right Shift +X and you will see the interface change like so, notice the open door graphic:
Awesome, thanks to OpenGarages you now you have your very own car to hack
Notice in the setup commands above we used a VCan0 interface. Run Ifconfig and you will now see that you indeed have a new network interface that speaks to the CAN network over VCan0.
ficti0n@ubuntu:~/Desktop/ICSim$ ifconfig vcan0
vcan0 Link encap:UNSPECHWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
Car networks run on a variety of protocols most prevalent being CAN. You can think of a CAN Bus like an old school networking hub where everyone can see everyone elses traffic. This is true to some extent although you may not see all of the cars traffic if its not connected to that particular bus your plugged into. You can think of CAN traffic kind of like UDP in that its send and forget, the main difference being parts of the CAN bus network don't actually have addresses and everything runs off arbitration IDs and priorities. Thats enough background to get you doing rather then reading.
With a little knowledge out of the way lets check if we can see our CAN traffic from our virtual car via the CanDump utility, which you installed as part of CanUtils package above. Using the following command on the vcan0 interface our simulator uses you can view a stream of traffic:
ficti0n@ubuntu:~/Desktop/ICSim$ candump vcan0
Above we can see a bunch of CAN frames, and if we perform actions on the vehicle we will see changes to data values in the CanDump output.However this may happen very fast, and we may not be able to see if for example we unlocked our simulators door. This is because things are changing constantly in the cars IDLE state. One single value changing may not stand out enough for us to take notice or may scroll so fast we cant see it.
Capture and Replay CAN Actions:
One option would be to perform an action and replay it, we should see the actions happen again in the replay if the traffic for the action we recorded is on the same bus network our device is plugged into. There are loads of networks within a car and its not guaranteed our network tap for example an OBD2 port plugin is connected to the same network as door we opened.Or the door may not be connected to the network at all depending on your car and its age or how its configured.
Replaying dumps with CanPlayer:
Another useful tool included with CanUtils package is CanPlayer for replaying traffic. If the functionality we are trying to capture is on the same Bus as the adaptor plugged into the car, or in this case our Virtual CAN interface, we can use CanDump to save traffic to a file. We then use CanPlayer to replay the traffic on the network. For example lets run CanDump and open a door and then replay the functionality with CanPlayer.
Lab 1 Steps:
Run CanDump
Right Shift + X to open a door
Cancel CanDump (ctrl+c)
Left Shift + X to close the door
Run can player with the saved dump and it will replay the traffic and open the door
Recording the door opening:(-l for logging)
ficti0n@ubuntu:~/Desktop/ICSim$ candump -l vcan0
Replaying the CanDump file:(use the file your can dump created)
Nice, so if all went well you should see that your door is now open again. If this did not happen when attacking a real car, just try to replay it again. CAN networks are not like TCP/IP, they are more like UDP in that you send out your request and its not expecting a response. So if it gets lost then it gets lost and you have to resend. Perhaps something with higher priority on the network was sending at the time of your replay and your traffic was overshadowed by it.
Interacting with the Can Bus and Reversing Traffic:
So thats cool, but what about actually understanding what is going on with this traffic, CanDump is not very useful for this, is scrolls by to quickly for us to learn much from.Instead we can use CanSniffer with colorized output to show us the bytes within packets that change. Below is an example of CanSniffer Traffic:
You will see 3 fields, Time, IDand Data. Its pretty easy to figure out what these are based on thier name. The most important part for our usage in this blog are the ID and the Data fields.
The ID field is the frame ID which is loosely associated with the device on the network which is effected by the frame being sent. The ID to also determines the priority of the frame on the network.The lower the number of the CAN-ID the higher priority it has on the network and more likely it will be handled first.The data field is the data being sent to change some parameter like unlocking a door or updating output. You will notice that some of the bytes are highlighted RED. The values in red are the values that are changing during the idle state you are currently in.
Determine which ID and Byte controls the throttle:
So with the terminal sniffing window open put the simulator and the controller into the foreground, with the controller being the window you have clicked and selected.Pay attention to the CanSniffer output while hitting the UP ARROW and look for a value that was white but is now Red and increasing in value as the throttle goes up.This might take you a few minutes of paying attention to whats going on to see.
The following 2 pictures show ID 244 in the IDLE state followed by pressing the up button to increase the speed. You will notice a byte has turned red and is increasing in value through a range of HEX values 0-F. It will continue to enumerate through values till it reaches its max speed.
The byte in ID 244 which is changing is the value while the throttle is engaged, so 244 associated in some way with the increasing speed. The throttle speed is a good value to start with as it keeps increasing its value when pressed making it easier to spot while viewing the CanSniffer output.
Singling out Values with Filters:
If you would like to single out the throttle value then click the terminal window and press -000000 followed by the Enter key which will clear out all of the values scrolling. Then press +244 followed by the Enter key which will add back the throttle ID. You can now click the controller again and increase the speed with your Up arrow button without all the noise clouding your view.You will instead as shown below only have ID 244 in your output:
To get back all of the IDs again click the terminal window and input +000000 followed by the Enter key. Now you should see all of the output as before.Essentially 000000 means include everything. But when you put a minus in front of it then it negates everything and clears your terminal window filtering out all values.
Determine Blinker ID:
Now lets figure out another ID for the blinkers. If you hit the left or right arrow with the controls window selected you will notice a whole new ID appears in the list, ID 188 shown in the picture below which is associated with the blinker.
This ID was not listed before as it was not in use within the data output until you pressed the blinker control.Lets single this value out by pressing -000000 followed by +188. Just like in the throttle example your terminal should only show ID 188, initially it will show with 00 byte values.
As you press the left and the right blinker you will see the first Byte change from 00 to 01 or 02. If neither is pressed as in the screenshot above it will be 00. Its kind of hard to have the controller in focus and get a screenshot at the same time but the ID will remain visible as 00 until it times out and disappears from the list when not active. However with it filtered out as above you can get a better view of things and it wont disappear.
Time for YOU to do some Protocol Reversing:
This lab will give you a good idea how to reverse all of the functionality of the car and associate each action with the proper ID and BYTE. This way you can create a map of intended functionality changes you wish to make.Above we have done a few walk throughs with you on how to determine which byte and ID is associated with an action. Now its time to map everything out yourself with all the remaining functionality before moving on to attacking individual components.
Lab Work Suggestion:
Take out a piece of paper and a pencil
Try unlocking and locking doors and write down the ID which controls this action (remember your filters)
Try unlocking each door and write down the BYTES needed for each door to open
Try locking each doors and what Bytes change and what are their values, write them down
Do the same thing for the blinkers left and right (Might be different then what I did above)
What ID is the speedometer using?What byte changes the speed?
Attacking Functionality Directly:
With all of the functionality mapped out we can now try to target various devices in the network directly without interacting with the controllers GUI. Maybe we broke into the car via cellular OnStar connectionor the center console units BLE connection which was connected to the CAN network in some way. After an exploit we have direct access to the CAN network and we would like to perform actions. Or maybe you have installed a wireless device into an OBD2 port under the dashboard you have remote access to the automobile.
Using the data from the CAN network reversing lab above we can call these actions directly with the proper CAN-ID and Byte.Since we are remote to the target we can't just reach over and grab the steering wheel or hit the throttle we will instead send your CAN frame to make the change.
One way we can do this is via the CanSend utility. Lets take our information from our lab above and make the left turn signal flash with the following ID 188 for the turn signal by changing the first byte to 01 indicating the left signal is pressed. CanSend uses the format ID#Data. You will see this below when sending the turn signal via CanSend.
You should have noticed that the left signal flashed. If not pay more attention and give it another try or make sure you used the correct ID and changed the correct byte.So lets do the same thing with the throttle and try to set the speed to something with ID 244 that we determined was the throttle.
My guess is that nothing happened because its so fast the needle is not going to jump to that value. So instead lets try repeating this over and over again with a bash loop which simply says that while True keep sending the throttle value of 11 which equates to about 30mph:
ficti0n@ubuntu:~/Desktop/ICSim$ while true; do cansend vcan0 244#00000011F6;done
Yes thats much better, you may notice the needle jumping back and forth a bit. The reason the needle is bouncing back and forth is because the normal CAN traffic is sent telling the car its actually set to 00 in between your frames saying its 30mph.But it worked and you have now changed the speed the car sees and you have flashed the blinker without using the cars normal blinker controls. Pretty cool right?
Monitor the CAN Bus and react to it:
Another way to handle this issue is to monitor the CAN network and when it sees an ID sent it will automatically send the corresponding ID with a different value.. Lets give that a try to modify our speed output by monitoring for changes. Below we are simply running CanDump and parsing for ID 244 in the log output which is the throttle value that tells the car the speed. When a device in the car reports ID 244 and its value we will immediately resend our own value saying the speed is 30mph with the value 11.See below command and try this out.
ficti0n@ubuntu:~/Desktop/ICSim$ candump vcan0 | grep " 244 " | while read line; do cansend vcan0 244#00000011F6; done
With this running after a few seconds you will see the speed adjust to around 30MPH once it captures a legitimate CAN-ID 244 from the network traffic and sends its own value right after.
Ok cool, so now while the above command is still running click the controller window and start holding down the Up arrow with the controller in focus.. After a few seconds or so when the speed gets above 30MPH you will see the needle fighting for the real higher value and adjusting back to 30MPH as your command keeps sending its on value as a replacement to the real speed.
So thats one way of monitoring the network and reacting to what you see in a very crude manner.Maybe someone stole your car and you want to monitor for an open door and if they try to open the door it immediately locks them in.
Conclusion and whats next:
I am not an expert car hacker but I hope you enjoyed this. Thats about as far as I want to go into this subject today, in the next blog we will get into how to code python to perform actions on the CAN network to manipulate things in a similar way.With your own code you are not limited to the functionality of the tools you are provided and can do whatever you want. This is much more powerful then just using the CanUtils pre defined tools. Later on I will also get into the hardware side of things if you would like to try this on a real car where things are more complicated and things can go wrong.
Printers belong arguably to the most common devices we use. They are available in every household, office, company, governmental, medical, or education institution.
From a security point of view, these machines are quite interesting since they are located in internal networks and have direct access to sensitive information like confidential reports, contracts or patient recipes.
TL;DR: In this blog post we give an overview of attack scenarios based on network printers, and show the possibilities of an attacker who has access to a vulnerable printer. We present our evaluation of 20 different printer models and show that each of these is vulnerable to multiple attacks. We release an open-source tool that supported our analysis: PRinter Exploitation Toolkit (PRET) https://github.com/RUB-NDS/PRET
Full results are available in the master thesis of Jens Müller and our paper.
Furthermore, we have set up a wiki (http://hacking-printers.net/) to share knowledge on printer (in)security. The highlights of the entire survey will be presented by Jens Müller for the first time at RuhrSec in Bochum.
Background
There are many cool protocols and languages you can use to control your printer or your print jobs. We assume you have never heard of at least half of them. An overview is depicted in the following figure and described below.
Device control
This set of languages is used to control the printer device. With a device control language it is possible to retrieve the printer name or status. One of the most common languages is the Simple Network Management Protocol (SNMP). SNMP is a UDP based protocol designed to manage various network components beyond printers as well, e.g. routers and servers.
Printing channel
The most common network printing protocols supported by printer devices are the Internet Printing Protocol (IPP), Line Printer Daemon (LPD), Server Message Block (SMB), and raw port 9100 printing. Each protocol has specific features like print job queue management or accounting. In our work, we used these protocols to transport malicious documents to the printers.
Job control language
This is where it gets very interesting (for our attacks). A job control language manages printer settings like output trays or paper size. A de-facto standard for print job control is PJL. From a security perspective it is very useful that PJL is not limited to the current print job as some settings can be made permanent. It can further be used to change the printer's display or read/write files on the device.
Page description language
A page description language specifies the appearance of the actual document. One of the most common 'standard' page description languages is PostScript. While PostScript has lost popularity in desktop publishing and as a document exchange format (we use PDF now), it is still the preferred page description language for laser printers. PostScript is a stack-based, Turing-complete programming language consisting of about 400 instructions/operators. As a security aware researcher you probable know that some of them could be useful. Technically spoken, access to a PostScript interpreter can already be classified as code execution.
Attacks
Even though printers are an important attack target, security threats and scenarios for printers are discussed in very few research papers or technical reports. Our first step was therefore to perform a comprehensive analysis of all reported and published attacks in CVEs and security blogs. We then used this summary to systematize the known issues, to develop new attacks and to find a generic approach to apply them to different printers. We estimated that the best targets are the PostScript and PJL interpreters processing the actual print jobs since they can be exploited by a remote attacker with only the ability to 'print' documents, independent of the printing channel supported by the device.
We put the printer attacks into four categories.
Denial-of-service (DoS)
Executing a DoS attack is as simple as sending these two lines of PostScript code to the printer which lead to the execution of an infinite loop:
Other attacks include:
Offline mode. The PJL standard defines the OPMSG command which 'prompts the printer to display a specified message and go offline'.
Physical damage. By continuously setting the long-term values for PJL variables, it is possible to physically destroy the printer's NVRAM which only survives a limited number of write cycles.
Showpage redefinition. The PostScript 'showpage' operator is used in every document to print the page. An attacker can simply redefine this operator to do nothing.
Protection Bypass
Resetting a printer device to factory defaults is the best method to bypass protection mechanisms. This task is trivial for an attacker with local access to the printer, since all tested devices have documented procedures to perform a cold reset by pressing certain key combinations. However, a factory reset can be performed also by a remote attacker, for example using SNMP if the device complies with RFC1759 (Printer MIB):
Other languages like HP's PML, Kyocera's PRESCRIBE or even PostScript offer similar functionalities.
Furthermore, our work shows techniques to bypass print job accounting on popular print servers like CUPS or LPRng.
Print Job Manipulation
Some page description languages allow permanent modifications of themselves which leads to interesting attacks, like manipulating other users' print jobs. For example, it is possible to overlay arbitrary graphics on all further documents to be printed or even to replace text in them by redefining the 'showpage' and 'show' PostScript operators.
Information Disclosure
Printing over port 9100 provides a bidirectional channel, which can be used to leak sensitive information. For example, Brother based printers have a documented feature to read from or write to a certain NVRAM address using PJL:
Our prototype implementation simply increments this value to dump the whole NVRAM, which contains passwords for the printer itself but also for user-defined POP3/SMTP as well as for FTP and Active Directory profiles. This way an attacker can escalate her way into a network, using the printer device as a starting point. Other attacks include:
File system access. Both, the standards for PostScript and PJL specify functionality to access the printers file system. As it seems, some manufacturers have not limited this feature to a certain directory, which leads to the disclosure of sensitive information like passwords.
Print job capture. If PostScript is used as a printer driver, printed documents can be captured. This is made possible by two interesting features of the PostScript language: First, permanently redefining operators allows an attacker to 'hook' into other users' print jobs and secondly, PostScript's capability to read its own code as data allows to easily store documents instead of executing them.
Credential disclosure. PJL passwords, if set, can easily retrieved through brute-force attacks due to their limited key space (1..65535). PostScript passwords, on the other hand, can be cracked extremely fast (up to 100,000 password verifications per second) thanks to the performant PostScript interpreters.
PRET
To automate the introduced attacks, we wrote a prototype software entitled PRET. The main idea of PRET is to facilitate the communication between the end-user and the printer. Thus, by entering a UNIX-like command PRET translates it to PostScript or PJL, sends it to the printer, and evaluates the result. For example, PRET converts a UNIX command ls to the following PJL request:
It then collects the printer output and translates it to a user friendly output.
PRET implements the following list of commands for file system access on a printer device:
Evaluation
As a highly motivated security researcher with a deep understanding of systematic analysis, you would probably obtain a list of about 20 - 30 well-used printers from the most important manufacturers, and perform an extensive security analysis using these printers. However, this was not our case. To overcome the financial obstacles, we collected printers from various university chairs and facilities. While our actual goal was to assemble a pool of printers containing at least one model for each of the top ten manufacturers, we practically took what we could get. The result is depicted in the following figure:
The assembled devices were not brand-new anymore and some of them were not even completely functional. Three printers had physically broken printing functionality so it was not possible to evaluate all the presented attacks. Nevertheless, these devices represent a good mix of printers used in a typical university or office environment.
Before performing the attacks, we of course installed the newest firmware on each of the devices. The results of our evaluation show that we could find multiple attacks against each printer. For example, simple DoS attacks with malicious PostScript files containing infinite loops are applicable to each printer. Only the HP LaserJet M2727nf had a watchdog mechanism and restarted itself after about ten minutes. Physical damage could be caused to about half of the tested device within 24 hours of NVRAM stressing. For a majority of devices, print jobs could be manipulated or captured.
PostScript, PJL and PML based attacks can even be exploited by a web attacker using advanced cross-site printing techniques. In the scope of our research, we discovered a novel approach – 'CORS spoofing' – to leak information like captured print jobs from a printer device given only a victim's browser as carrier. A proof-of-concept implementation demonstrating that advanced cross-site printing attacks are practical and a real-world threat to companies and institutions is available at http://hacking-printers.net/xsp/.
Our next post will be on adapting PostScript based attacks to websites.
Most people who know me will know that I wear my heart on my sleeve. I do not hide emotions, I don't know how to any more. I say "any more" because either I used to be very good at it, or maybe I just had none. A lot has changed over the years.
