The Life of a Writer

Nii-kun

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.

iemhacker-how-to-switch-from-32-bit-windows-to 64bit

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!

Related word

Nii-kun

Bypassing Blockchain Authorization via Unsecured Functions

Note: Since the first part of this series I have also uploaded some further videos on remediation of reentrancy and dealing with compiler versions when working with this hacking blockchain series. Head to the console cowboys YouTube account to check those out. Haha as mentioned before I always forget to post blogs when I get excited making videos and just move on to my next project… So make sure to subscribe to the YouTube if you are waiting for any continuation of a video series.. It may show up there way before here.

Note 2: You WILL run into issues when dealing with Ethereum hacking, and you will have to google them as versions and functionality changes often... Be cognizant of versions used hopefully you will not run into to many hard to fix issues.

In the second part of this lab series we are going to take a look at privacy issues on the blockchain which can result in a vulnerably a traditional system may not face. Since typically blockchain projects are open source and also sometimes viewable within blockchain explorers but traditional application business logic is not usually available to us. With traditional applications we might not find these issues due to lack of knowledge of internal functionality or inability to read private values on a remote server side script. After we review some issues we are going to exploit an authorization issues by writing web3.js code to directly bypass vertical authorization restrictions.

Blockchain projects are usually open source projects which allow you to browse their code and see what's going on under the hood. This is fantastic for a lot of reasons but a developer can run into trouble with this if bad business logic decisions are deployed to the immutable blockchain. In the first part of this series I mentioned that all uploaded code on the blockchain is immutable. Meaning that if you find a vulnerability it cannot be patched. So let's think about things that can go wrong..

A few things that can go wrong:

Randomization functions that use values we can predict if we know the algorithm
Hard-coded values such as passwords and private variables you can't change.
Publicly called functions which offer hidden functionality
Race conditions based on how requirements are calculated

Since this will be rather technical, require some setup and a lot of moving parts we will follow this blog via the video series below posting videos for relevant sections with a brief description of each. I posted these a little bit ago but have not gotten a chance to post the blog associated with it. Also note this series is turning into a full lab based blockchain exploitation course so keep a lookout for that.

In this first video you will see how data about your project is readily available on the blockchain in multiple formats for example:

ABI data that allows you to interact with methods.
Actual application code.
Byte code and assembly code.
Contract addresses and other data.

Lab Video Part 1: Blockchain OSINT:

Once you have the data you need to interact with a contract on the blockchain via some OSINT how do you actually interface with it? That's the question we are going to answer in this second video. We will take the ABI contract array and use it to interact with methods on the blockchain via Web3.js and then show how this correlates to its usage in an HTML file

Lab Video Part 2: Connecting to a Smart Contract:

Time to Exploit an Application:

Exploit lab time, I created an vulnerable application you can use to follow along in the next video. Lab files can be downloaded from the same location as the last blog located below. Grab the AuthorizationLab.zip file:

Lab file downloads:

https://github.com/cclabsInc/BlockChainExploitation

Ok so you can see what's running on the blockchain, you can connect to it, now what? Now we need to find a vulnerability and show how to exploit it. Since we are talking about privacy in this blog and using it to bypass issues. Lets take a look at a simple authorization bypass we can exploit by viewing an authorization coding error and taking advantage of it to bypass restrictions set in the Smart Contract. You will also learn how to setup a local blockchain for testing purposes and you can download a hackable application to follow along with the exercises in the video..

Lab Video Part 3: Finding and hacking a Smart Contract Authorization Issue:

Summary:

In this part of the series you learned a lot, you learned how to transfer your OSINT skills to the blockchain. Leverage the information found to connect to that Smart Contract. You also learned how to interact with methods and search for issues that you can exploit. Finally you used your browsers developer console as a means to attack the blockchain application for privilege escalation.

Dangerous Paths: Overview

To identify attack vectors, we systematically surveyed which potentially dangerous features exist in the PDF specification. We created a comprehensive list with all PDF Actions that can be called. This list contains 18 different actions that we carefully studied.

We selected eight actions – the ones that directly or indirectly allow access to a file handle and may therefore be abused for dangerous features such as URL invocation or writing to files. Having a list of security-sensitive actions, we proceeded by investigating all objects and related events that can trigger these actions.

We identified four PDF objects which allow calling arbitrary actions (Page, Annotation, Field, and Catalog). Most objects offer multiple alternatives for this purpose. For example, the Catalog object, defines the OpenAction or additional actions (AA) events. Each event can launch any sequence of PDF actions, for example, Launch, Thread, etc. JavaScript actions can be embedded within documents. It opens a new area for attacks, for example, new annotations can be created that can have actions which once again lead to accessing file handles.

Denial of Service

The goal of the denial of service class of attacks is enforcing to process PDF applications in consuming all available resources (i.e., computing time or memory) or causes them to crash by opening a specially crafted PDF document. We identified two variants: Infinite Loop and Deflate Bomb.

Infinite Loop

This variant induces an endless loop causing the program execution to get stuck. The PDF standard allows various elements of the document structure to reference to themselves, or to other elements of the same type.

Action loop: PDF actions allow to specify a Next action to be performed, thereby resulting in "action cycles".

ObjStm loop: Object streams may extend other object streams allows the crafting of a document with cycles.

Outline loop: PDF documents may contain an outline. Its entries, however, can refer to themselves or each other.

Calculations: PDF defines "Type 4" calculator functions, for example, to transform colors. Processing hard-to-solve mathematical formulas may lead to high demands of CPU.

JavaScript: Finally, in case the PDF application processes scripts within documents, infinite loops can be induced.

Deflate Bomb

Data amplification attacks based on malicious zip archives are well-known. The first publicly documented DoS attack using a "zip bomb" was conducted in 1996 against a Fidonet BBS administrator. However, not only zip files but also stream objects within PDF documents can be compressed using various algorithms such as Deflate to reduce the overall file size.

Information Disclosure

The goal of this class of attacks is to track the usage of a document by silently invoking a connection to the attacker's server once the file is opened, or to leak PDF document form data, local files, or NTLM credentials to the attacker.

URL Invocation

PDF documents that silently "phone home" should be considered as privacy-invasive. They can be used, for example, to deanonymize reviewers, journalists, or activists behind a shared mailbox. The attack's goal is to open a backchannel to an attacker-controlled server once the PDF file is opened by the victim.

The possibility of malicious URI resolving in PDF documents has been introduced by Hamon [1] who gave an evaluation for URI and SubmitForm actions in Acrobat Reader. We extend their analysis to all standard PDF features that allow opening a URL, such as ImportData, Launch, GoToR, and JavaScript.

Form Data Leakage

Documents can contain forms to be filled out by the user – a feature introduced with PDF version 1.2 in 1996 and used on a daily basis for routine offices tasks, such as travel authorization or vacation requests. The idea of this attack is as follows: The victim downloads a form – a PDF document which contains form fields – from an attacker controlled source and fills it out on the screen, for example, in order to print it. The form is manipulated by the attacker in such a way that it silently send input data to the attacker's server.

Local File Leakage

The PDF standard defines various methods to embed external files into a document or otherwise access files on the host's file system, as documented below.

External streams: Documents can contain stream objects (e.g., images) to be included from external files on disk.
Reference XObjects: This feature allows a document to import content from another (external) PDF document.
Open Prepress Interface: Before printing a document, local files can be defined as low-resolution placeholders.
Forms Data Format (FDF): Interactive form data can be stored in, and auto-imported from, external FDF files.
JavaScript functions: The Adobe JavaScript reference enables documents to read data from or import local files.

If a malicious document managed to firstly read files from the victim's disk and secondly, send them back to the attacker, such behavior would arguably be critical.

Credential Theft

In 1997, Aaron Spangler posted a vulnerability in Windows NT on the Bugtraq mailing list [2]: Any client program can trigger a connection to a rogue SMB server. If the server requests authentication, Windows will automatically try to log in with a hash of the user's credentials. Such captured NTLM hashes allow for efficient offline cracking and can be re-used by applying pass-the-hash or relay attacks to authenticate under the user's identity. In April 2018, Check Point Research [3] showed that similar attacks can be performed with malicious PDF files. They found that the target of GoToR and GoToE actions can be set to \\attacker.com\dummyfile, thereby leaking credentials in the form of NTLM hashes.

Data Manipulation

This attack class deals with the capabilities of malicious documents to silently modify form data, to write to local files on the host's file system, or to show a different content based on the application that is used to open the document.

Form Modification

The idea of this attack is as follows: Similar to Form Data Leakage attacks, the victim obtains a harmlessly looking PDF document from an attacker controlled source, for example, a remittance slip or a tax form. The goal of the attacker is to dynamically, and without knowledge of the victim, manipulate form field data.

File Write Access

The PDF standard enables documents to submit form data to external webservers. Technically the webserver's URL is defined using a PDF File Specification. This ambiguity in the standard may be interpreted by implementations in such a way that they enable documents to submit PDF form data to a local file, thereby writing to this file.

Content Masking

The goal of this attack is to craft a document that renders differently, depending on the applied PDF interpreter. This can be used, for example, to show different content to different reviewers, to trick content filters (AI-based machines as well as human content moderators), plagiarism detection software, or search engines, which index a different text than the one shown to users when opening the document.

Stream confusion: It is unclear how content streams are parsed if their Length value does not match the offset of the endstream marker, or if syntax errors are introduced.
Object confusion: An object can overlay another object. The second object may not be processed if it has a duplicate object number, if it is not listed in the XRef table, or if other structural syntax errors are introduced.
Document confusion: A PDF file can contain yet another document (e.g., as embedded file), multiple XRef tables, etc., which results in ambiguities on the structural level.
PDF confusion: Objects before the PDF header or after an EOF marker may be processed by implementations, introducing ambiguities in the outer document structure.

Code Execution

The goal of this attack is to execute attacker-controlled code. This can be achieved by silently launching an executable file, embedded within the document, to infect the host with malware. The PDF specification defines the Launch action, which allows documents to launch arbitrary applications. The file to be launched can either be specified by a local path, a network share, a URL, or a file embedded within the PDF document itself.