[[Category:Basic]]
== Cross-Site-Scripting (XSS) ==

Cross-Site Scripting is a class of web application vulnerabilities, which is still one of the most common security vulnerabilities in web applications. In general, XSS vulnerabilities allow an attacker to execute script code in the web browser of the victim and can be used to gain data from users, like cookies or private information. The Different Types are listed below. It's also possible to trigger actions on websites, redirect to other sites or hide advertisements. A short game with which some options can be seen easily: [https://xss-game.appspot.com/ XSS game]

== Types ==
There are two ways to classify XSS attacks. Up until 2012 the types DOM-based (Type 0), stored/persistent (Type I) and reflected/non-persistent (Type II) were used. As these three types can overlap the research community started to use the terms Server XSS and Client XSS from 2012 on.
[[File:Server-XSS_vs_Client-XSS_Chart.png|200px|thumb]]

=== Stored (Type I) ===
With Stored XSS, also referred to as persistent XSS, the application or API saves uncleaned user input on the server, such as in a database, comment field, visitor log, etc., which then is displayed at a later point in time by another user or administrator, that requested the stored information.

=== Reflected (Type II) ===
Reflected XSS is a non-persistent attack and is used to steal session cookies from a user. With Reflected XSS, the application or API includes unchecked and unmasked input from the user as part of the HTML output. If the attack was successful, the attacker could execute arbitrary HTML and a scripting language such as Javascript in the victim's browser. Typically, a user will have to click on a malicious link to do this. The attacker tries to bring this harmful link to the victim, via advertising, e-mail etc.

=== DOM Based (Type 0) ===
A DOM-based XSS vulnerability happens when dynamic content is generated with the help of the Document Object Model (DOM). The DOM is a programming interface that specifies the structure of documents. In the scenario of a DOM-Based attack, the DOM contains user inputs that are further processed without being checked. A corresponding attack takes place in the JavaScript in the user's browser.

== Prevention==

The prevention of these vulnerabilities are the task of the programmer. The programmer should be encouraged to use secure programming measures, like Context-sensitive server-side output encoding, to ensure that it is not possible to inject malicious scripts into the site through incorrect or unchecked entries. Problematic meta characters should be filtered out of the input and the permissible inputs should be fully described using regular expressions. The user, on the other hand, can protect himself from executing script commands in the browser only by deactivating scripts in the browser.

== References ==

* https://owasp.org/www-community/attacks/xss/
* https://cheatsheetseries.owasp.org/cheatsheets/DOM_based_XSS_Prevention_Cheat_Sheet.html
* https://owasp.org/www-project-top-ten/2017/A7_2017-Cross-Site_Scripting_(XSS)

Cross-Site Scripting (XSS)

2021-12-21T18:18:44Z

FVarli:

[[Category:Basic]]
== Cross-Site-Scripting (XSS) ==

Cross-Site Scripting is a class of web application vulnerabilities, which is still one of the most common security vulnerabilities in web applications. In general, XSS vulnerabilities allow an attacker to execute script code in the web browser of the victim and can be used to gain data from users, like cookies or private information. The Different Types are listed below. It's also possible to trigger actions on websites, redirect to other sites or hide advertisements. A short game with which some options can be seen easily: [https://xss-game.appspot.com/ XSS game]

== Types ==
There are two ways to classify XSS attacks. Up until 2012 the types DOM-based (Type 0), stored/persistent (Type I) and reflected/non-persistent (Type II) were used. As these three types can overlap the research community started to use the terms Server XSS and Client XSS from 2012 on.
[[File:Server-XSS_vs_Client-XSS_Chart.png|200px|thumb]]

=== Stored (Type I) ===
With Stored XSS, also referred to as persistent XSS, the application or API saves uncleaned user input on the server, such as in a database, comment field, visitor log, etc., which then is displayed at a later point in time by another user or administrator, that requested the stored information.

=== Reflected (Type II) ===
Reflected XSS is a non-persistent attack and is used to steal session cookies from a user. With Reflected XSS, the application or API includes unchecked and unmasked input from the user as part of the HTML output. If the attack was successful, the attacker could execute arbitrary HTML and a scripting language such as Javascript in the victim's browser. Typically, a user will have to click on a malicious link to do this. The attacker tries to bring this harmful link to the victim, via advertising, e-mail etc.

=== DOM Based (Type 0) ===
A DOM-based XSS vulnerability happens when dynamic content is generated with the help of the Document Object Model (DOM). The DOM is a programming interface that specifies the structure of documents. In the scenario of a DOM-Based attack, the DOM contains user inputs that are further processed without being checked. A corresponding attack takes place in the JavaScript in the user's browser.

== Prevention==

In the case of reflected and stored XSS, the of prevention of both vulnerabilities are the task of the programmer. The programmer should be encouraged to use secure programming measures, like Context-sensitive server-side output encoding, to ensure that it is not possible to inject malicious scripts into the site through incorrect or unchecked entries. Problematic meta characters should be filtered out of the input and the permissible inputs should be fully described using regular expressions. The user, on the other hand, can protect himself from executing script commands in the browser only by deactivating scripts in the browser.

== References ==

* https://owasp.org/www-community/attacks/xss/
* https://cheatsheetseries.owasp.org/cheatsheets/DOM_based_XSS_Prevention_Cheat_Sheet.html
* https://owasp.org/www-project-top-ten/2017/A7_2017-Cross-Site_Scripting_(XSS)

Cross-Site Request Forgery (CSRF)

2021-12-21T17:48:21Z

FVarli:

[[Category:Basic]]
== Cross-Site-Request Forgery (CSRF) ==

Cross-Site Request Forgery, also known as CSRF or XSRF, is an attack where a malicious website, email message, web application, or blog causes an unwanted web browser action on a trusted site where a user is currently authenticated. The consequences of a CSRF attack depend on the extent to which the vulnerable application is hit. In the simplest case, attackers use CSRF attacks to cause a target system to perform available and malicious functions through the target's browser without the target user's knowledge. This function is usually not known to the victim until after it occurs.

A CSRF vulnerability allows an attacker to force an authenticated, logged-in user to perform an important action without the user's consent or knowledge. This way leaves no trace of the attacker from the web application's point of view. The reason for this is, the fake request contains all the victim's information and comes from the same IP address as a real request from the victim. As a consequence, any application that allows a user to send or update data is a potential target for an attacker.

The important thing to remember about CSRF is that these attacks only work if the victim is logged into the target website. This may be a complication for attackers, but many websites allow users to click something like "Stay logged in," which makes the attacker's job easier.

== Prevention ==

To detect this vulnerability, one checks that each link and form is protected with an unpredictable "secret" token. Alternatively, one can have the user reconfirm the request, e.g., by re-authenticating or entering CAPTCHA. Here, one can focus on links and forms that actually trigger a state-changing function, as these are the most important targets for CSRF. Multi-step transactions should also be examined, as they can be equally vulnerable. An attacker can easily trigger a sequence of fake requests by using multiple tags or even JavaScript.

To prevent CSRF, each input page should contain a token. The token should be unpredictable, secret and unique for each session, or better for each form, and
checked by the server. CSRF tokens should be generated on the server-side. Generally, per-request tokens are more secure than per-session tokens as the time range for an attacker to exploit the stolen tokens is minimal.

* The preferred method to embed the token is a hidden input field. This way the token value is transferred in the body of the request and not in the URL, which otherwise facilitates spying.

* Such a token can also be written directly into the URL or passed as a URL parameter. However, by doing that we fix one security flaw by creating a new one. This approach carries the risk that the URL falls into the hands of the attacker and thus the secret token is compromised.

* Active reconfirmation from the user, in the form of re-authentication, CAPTCHA input, etc. can also protect against CSRF.

Generally, it is recommended to use built-in or existing CSRF implementations for CSRF Protection. OWASP also advises to research if the framework used in your project has an option to achieve CSRF Protection, since many Frameworks have built-in implementations for these types of attacks.

== References ==

* https://owasp.org/www-community/attacks/csrf
* https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html
* https://owasp.org/www-community/Anti_CRSF_Tokens_ASP-NET

Cross-Site Request Forgery (CSRF)

2021-12-21T17:48:08Z

FVarli:

== Cross-Site-Request Forgery (CSRF) ==

Cross-Site Request Forgery, also known as CSRF or XSRF, is an attack where a malicious website, email message, web application, or blog causes an unwanted web browser action on a trusted site where a user is currently authenticated. The consequences of a CSRF attack depend on the extent to which the vulnerable application is hit. In the simplest case, attackers use CSRF attacks to cause a target system to perform available and malicious functions through the target's browser without the target user's knowledge. This function is usually not known to the victim until after it occurs.

A CSRF vulnerability allows an attacker to force an authenticated, logged-in user to perform an important action without the user's consent or knowledge. This way leaves no trace of the attacker from the web application's point of view. The reason for this is, the fake request contains all the victim's information and comes from the same IP address as a real request from the victim. As a consequence, any application that allows a user to send or update data is a potential target for an attacker.

The important thing to remember about CSRF is that these attacks only work if the victim is logged into the target website. This may be a complication for attackers, but many websites allow users to click something like "Stay logged in," which makes the attacker's job easier.

== Prevention ==

To detect this vulnerability, one checks that each link and form is protected with an unpredictable "secret" token. Alternatively, one can have the user reconfirm the request, e.g., by re-authenticating or entering CAPTCHA. Here, one can focus on links and forms that actually trigger a state-changing function, as these are the most important targets for CSRF. Multi-step transactions should also be examined, as they can be equally vulnerable. An attacker can easily trigger a sequence of fake requests by using multiple tags or even JavaScript.

To prevent CSRF, each input page should contain a token. The token should be unpredictable, secret and unique for each session, or better for each form, and
checked by the server. CSRF tokens should be generated on the server-side. Generally, per-request tokens are more secure than per-session tokens as the time range for an attacker to exploit the stolen tokens is minimal.

* The preferred method to embed the token is a hidden input field. This way the token value is transferred in the body of the request and not in the URL, which otherwise facilitates spying.

* Such a token can also be written directly into the URL or passed as a URL parameter. However, by doing that we fix one security flaw by creating a new one. This approach carries the risk that the URL falls into the hands of the attacker and thus the secret token is compromised.

* Active reconfirmation from the user, in the form of re-authentication, CAPTCHA input, etc. can also protect against CSRF.

Generally, it is recommended to use built-in or existing CSRF implementations for CSRF Protection. OWASP also advises to research if the framework used in your project has an option to achieve CSRF Protection, since many Frameworks have built-in implementations for these types of attacks.

== References ==

* https://owasp.org/www-community/attacks/csrf
* https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html
* https://owasp.org/www-community/Anti_CRSF_Tokens_ASP-NET

[[Category:Basic]]

2021-11-21T15:48:08Z

2021-11-21T15:38:33Z

FVarli: Created page with "== Summary == A practical guide using burp suite and Firefox browser: how to generate a proof-of-concept reflected XSS exploit. A Reflected XSS vulnerability is when a passi..."

== Summary ==

A practical guide using burp suite and Firefox browser: how to generate a proof-of-concept reflected XSS exploit.
A Reflected XSS vulnerability is when a passing parameter in an HTTP request of a web application is re-integrated unfiltered into the response HTML page. If an attacker were to insert HTML or JavaScript code, for example, into the transfer parameter, this would be included in the response page and executed.
A more detailed explaination can be found [https://wiki.elvis.science/index.php?title=Cross-Site-Scripting_(XSS) here].

== Requirements ==

* [https://portswigger.net/burp/communitydownload Burp Suite]
* In this example Firefox is used as web browser, but any browser that is compatible with Burp Suite can be used
* [https://sourceforge.net/projects/owaspbwa/ﬁles/ OWASP Broken Web Application Project]

== Description ==

=== Setup ===

First the user needs to download Burp Suite.

Next, the user needs to download OWASP’s Broken Web Application Project to follow this tutorial. The example uses a version of "Mutillidae II" taken from OWASP's Broken Web Application Project. As this Web Application has a lot of vulnerabilities, it should only be started using VMNets with "host only” due to security reasons.

To run and configure Burp Suite, the author recommends to follow Burp Suites Browser Configuration Tutorial, since its very precise and easy to follow. It is also advised to install and import Burp Suites Certificate, since the user won’t be able to use Websites that use HTTPs as Protocol. The tutorial can be found [https://portswigger.net/burp/documentation/desktop/external-browser-config here].

=== Tutorial ===

Steps:
* Visit the page of the website you want to test for reflected XSS vulnerability. In this example we used the “DNS lookup” page.
* Return to Burp and switch the turn “Intercept is off” to “Intercept is on”
* Enter some appropriate input in to the web app and submit the request
* You should see that the web page is “stuck”. This is because we turned on the interception In Burp suite. The HTTP request is now captured by Burp, which can be viewed in the Proxy “Intercept” tab. Right click on the request and click “Send to Repeater”.
* Go to the “Repeater” tab. Here you can input various XSS payloads in the input field. We edit the “value” of the parameter. In this example we use a payload, that tries to perform a pop up in our browser.
* Click "Go"
* The user can assess whether the attack payload appears unmodified in the response. In our case it is, which means the application is almost certainly vulnerable to XSS.
* Right click on the response and click “Show response in browser” to copy the URL.
* In the window, that popped up, click “Copy” and paste it into your browser's address bar.
* You are now able to produce a proof of concept for this vulnerability.

== References ==

* https://portswigger.net/burp/communitydownload
* https://sourceforge.net/projects/owaspbwa/
* https://portswigger.net/burp/documentation/desktop/external-browser-config
* https://portswigger.net/support/using-burp-to-manually-test-for-reflected-xss

[[Category:Documentation]]

GSM Pentesting

2021-07-08T16:45:09Z

FVarli:

== Summary ==

This article describes two possible attack vectors in the GSM protocol. It is actually possible to do these attacks with open-source solutions. The only problem is the legal and technical situation, whether there is a way to keep the output power so low that only our devices connect to the base station, otherwise legal consequences follow if other devices and Signals are involved.

== Description ==

=== Fake Basesstation & IMSI-Catcher ===

The problem with GSM is the lack of authentication between the base station (BTS) and the end device. This enables a “man in the middle” attack to be carried out with a “rogue base station”/IMSI catcher. To do this, the system must be placed near the person to be spied on. By increasing the transmission power, the ME located in the vicinity are made to connect to this station of the attacker If the IMSI number of the person to be intercepted is not yet known, it must first be identified from the multitude of telephone calls made in the area. Professional devices such as the GA-901 from “Rohde & Schwarz” can therefore record several channels at the same time. This means that uninvolved people can also be eavesdropped. With this method, only outgoing phone calls can be eavesdropped. The outgoing call is forwarded to a "real" BTS. The so-called "MITM impersonation" uses the "Dynamic SIM cloning" method to position oneself in the uplink and also in the downlink channel between the communication partners. An "IMSI request" prompts the Mobile Equipment to disclose this unique number, which rarely occurs in normal operation. This allows movement profiles to be created, although this is to be prevented by the TMSI.

IMSI catchers are mainly used by law enforcement agencies and intelligence services to determine the locations and to create a movement profile of certain people.

=== Encryption ===

The encryption algorithm A5 is used on the air interface between the ME and the BTS. When A5 / 1 and A5 / 2 were developed in the late 1980s, the decision was made to use "Security By Obscurity", which means that the security of the process depends on the algorithm being kept secret. By 1999, both stream cipher methods were investigated by Marc Briceno and other scientists using reverse engineering and finally published.

An attack on A5 / 1 was carried out by A. Biryukov, A. Shamir, and D. Wagner in 2000. The complexity of the original 2^64 has been reduced to 2^38 and 2^48 respectively. In the meantime, “Rainbow Tables” are used to decrypt the A5 / 1. This technology shortens the computational effort in order to calculate back the correct session key, with which it is then possible to passively listen in on phone calls in real time. A modified cell phone of an older design is completely sufficient for this. A5 / 1 is used in Europe and the USA. The much weaker A5 / 2 was developed for countries where strong encryption is prohibited. According to the standardization committee, this algorithm has not been allowed to be used since 2007.

With UMTS, only A5 / 3 is used to encrypt the radio connection. Also known as KASUMI, the procedure was published in 2002. However, more security is only created by the increased complexity of the block cipher procedure. In the GSM network sections between BTS, BSC and MSC, the data is not encrypted and is transmitted via radio link if required, which means that passive eavesdropping or the interception of the session key is possible at these points.
An up-to-date overview of the security level of those cellular networks in use:

''Link: https://gsmmap.org''

The website shows Osmocom-compatible mobile phones and laptops, which are visualized on a map.

== References ==

* https://de.wikipedia.org/wiki/A5_(Algorithmus)
* https://it-forensik.fiw.hs-wismar.de/index.php/IMSI-Catcher
* https://www.tarife.at/wissen/imsi-catcher
* https://www.heise.de/newsticker/meldung/26C3-GSM-Hacken-leicht-gemacht-892911.html
* https://www.webcitation.org/5rgp2JlUf
* https://gsmmap.org

[[Category:Documentation]]

GSM Pentesting

2021-07-08T16:44:58Z

FVarli:

GSM Pentesting

2021-07-08T16:43:05Z

FVarli:

== Summary ==

This article describes two possible attack vectors in the GSM protocol. It is actually possible to do these attacks with open-source solutions. The only problem is the legal and technical situation, whether there is a way to keep the output power so low that only our devices connect to the base station, otherwise legal consequences follow if other devices and Signals are involved.

== Description ==

=== Fake Basesstation & IMSI-Catcher ===

The problem with GSM is the lack of authentication between the base station (BTS) and the end device. This enables a “man in the middle” attack to be carried out with a “rogue base station”/IMSI catcher. To do this, the system must be placed near the person to be spied on. By increasing the transmission power, the ME located in the vicinity are made to connect to this station of the attacker If the IMSI number of the person to be intercepted is not yet known, it must first be identified from the multitude of telephone calls made in the area. Professional devices such as the GA-901 from “Rohde & Schwarz” can therefore record several channels at the same time. This means that uninvolved people can also be eavesdropped. With this method, only outgoing phone calls can be eavesdropped. The outgoing call is forwarded to a "real" BTS. The so-called "MITM impersonation" uses the "Dynamic SIM cloning" method to position oneself in the uplink and also in the downlink channel between the communication partners. An "IMSI request" prompts the handset to disclose this unique number, which rarely occurs in normal operation. This allows movement profiles to be created, although this is to be prevented by the TMSI.

IMSI catchers are mainly used by law enforcement agencies and intelligence services to determine the locations and to create a movement profile of certain people.

=== Encryption ===

The encryption algorithm A5 is used on the air interface between the ME and the BTS. When A5 / 1 and A5 / 2 were developed in the late 1980s, the decision was made to use "Security By Obscurity", which means that the security of the process depends on the algorithm being kept secret. By 1999, both stream cipher methods were investigated by Marc Briceno and other scientists using reverse engineering and finally published.

An attack on A5 / 1 was carried out by A. Biryukov, A. Shamir, and D. Wagner in 2000. The complexity of the original 2^64 has been reduced to 2^38 and 2^48 respectively. In the meantime, “Rainbow Tables” are used to decrypt the A5 / 1. This technology shortens the computational effort in order to calculate back the correct session key, with which it is then possible to passively listen in on phone calls in real time. A modified cell phone of an older design is completely sufficient for this. A5 / 1 is used in Europe and the USA. The much weaker A5 / 2 was developed for countries where strong encryption is prohibited. According to the standardization committee, this algorithm has not been allowed to be used since 2007.

With UMTS, only A5 / 3 is used to encrypt the radio connection. Also known as KASUMI, the procedure was published in 2002. However, more security is only created by the increased complexity of the block cipher procedure. In the GSM network sections between BTS, BSC and MSC, the data is not encrypted and is transmitted via radio link if required, which means that passive eavesdropping or the interception of the session key is possible at these points.
An up-to-date overview of the security level of those cellular networks in use:

''Link: https://gsmmap.org''

The website shows Osmocom-compatible mobile phones and laptops, which are visualized on a map.

== References ==

* https://de.wikipedia.org/wiki/A5_(Algorithmus)
* https://it-forensik.fiw.hs-wismar.de/index.php/IMSI-Catcher
* https://www.tarife.at/wissen/imsi-catcher
* https://www.heise.de/newsticker/meldung/26C3-GSM-Hacken-leicht-gemacht-892911.html
* https://www.webcitation.org/5rgp2JlUf
* https://gsmmap.org

[[Category:Documentation]]

GSM Pentesting

2021-07-08T16:35:16Z

FVarli: Created page with "== Summary == This article describes two possible attack vectors in the GSM protocol. It is actually possible to do this with open-source solutions. The only problem is the..."

== Summary ==

This article describes two possible attack vectors in the GSM protocol. It is actually possible to do this with open-source solutions. The only problem is the legal and technical situation, whether there is a way to keep the output power so low that only our devices connect to the base station, otherwise legal consequences follow if other devices and Signals are involved.

== Description ==

=== Fake Basesstation & IMSI-Catcher ===

The problem with GSM is the lack of authentication between the base station (BTS) and the end device. This enables a “man in the middle” attack to be carried out with a “bogus base station” or an IMSI catcher. To do this, the system must be placed near the person to be spied on. By increasing the transmission power, those in the vicinity are
Brought ME to connect to this attacker's station. If the IMSI number of the person to be intercepted is not yet known, it must first be identified from the multitude of telephone calls made in the area. Professional devices such as the GA-901 from “Rohde & Schwarz” can therefore record several channels at the same time. This means that uninvolved people can also be eavesdropped. With this method, only outgoing phone calls can be eavesdropped. The outgoing call is forwarded to a "real" BTS. The so-called "MITM impersonation" uses the "Dynamic SIM cloning" method to position oneself in the uplink and also in the downlink channel between the communication partners. An "IMSI request" prompts the handset to disclose this unique number, which rarely occurs in normal operation. This allows movement profiles to be created, although this is to be prevented by the TMSI.

IMSI catchers are mainly used by law enforcement agencies and intelligence services to determine the locations and to create a movement profile of certain people.

=== Encryption ===

The encryption algorithm A5 is used on the air interface between the ME and the BTS. When A5 / 1 and A5 / 2 were developed in the late 1980s, the decision was made to use "Security By Obscurity", which is to say that the security of the process depends on the algorithm being kept secret. By 1999, both stream cipher methods were investigated by Marc Briceno and other scientists using reverse engineering and finally published.
An attack on A5 / 1 was carried out by A. Biryukov, A. Shamir, and D. Wagner in 2000. The complexity of the original 264 has been reduced to 238 and 248 respectively. In the meantime, “Rainbow Tables” 15, 16 are used to decrypt the A5 / 1. This technology shortens the computational effort in order to calculate back the correct session key, with which it is then possible to passively listen in on phone calls in real time. A modified cell phone of an older design is completely sufficient for this. A5 / 1 is used in Europe and the USA. The much weaker A5 / 2 was developed for countries where strong encryption is prohibited. According to the standardization committee, this algorithm has not been allowed to be used since 2007.
With UMTS, only A5 / 3 is used to encrypt the radio connection. Also known as KASUMI, the procedure was published in 2002. However, more security is only created by the increased complexity of the block cipher procedure. In the GSM network sections between BTS, BSC and MSC, the data is not encrypted and is transmitted via radio link if required, which means that passive eavesdropping or the interception of the session key is possible at these points.
An up-to-date overview of the security level of those in use: The GSM-MAP project is intended to enable cellular networks. The website shows Osmocom-compatible mobile phones and laptops, which are visualized on a map.
Link: https://gsmmap.org

== References ==

* https://de.wikipedia.org/wiki/A5_(Algorithmus)
* https://it-forensik.fiw.hs-wismar.de/index.php/IMSI-Catcher
* https://www.tarife.at/wissen/imsi-catcher
* https://www.heise.de/newsticker/meldung/26C3-GSM-Hacken-leicht-gemacht-892911.html
* https://www.webcitation.org/5rgp2JlUf
* https://gsmmap.org

[[Category:Documentation]]

HackRF One: Setup

2021-06-24T22:44:40Z

FVarli:

== Summary ==

We want to get started with the HackRF One Software Defined Radio. At the end of the setup, the HackRF One will be ready to use and we will be able to see the first incoming radio signals.

== Requirements ==

* Operating system: Any Linux Distribution but preferably Kali or Pentoo

== Description ==

=== Installation of Packages ===

The following commands are for Debian/Ubuntu based Linux Distributions.
First, update your machine:

''sudo apt-get update''
''sudo apt upgrade''

Then install the hackrf tool and libraries:

''sudo apt install hackrf libhackrf-dev libhackrf0''

Now install GQRX:

''sudo apt install gqrx-sdr''

If that does not work use:

''sudo aptitude install gqrx-sdr''

We also must download the newest firmware from this Git repository:

https://github.com/mossmann/hackrf/releases

Download the newest firmware .tar, e.g.:

hackrf-2021.01.1.tar.xz

=== Check HackRF One ===

Now, that we have installed the necessary software we can finally connect the HackRF One to our computer. IMPORTANT: Before you connect it to the computer, make sure you have attached the antenna. If you do not do this the HackRF One might get broken.

[[File:Hackrf.PNG]]

Now we must activate the USB port in the virtual machine. In Oracle Virtual Box you can do that by right-clicking the VM -> select options -> click USB -> add USB drive -> choose the HackRF One -> Restart the machine.

Now we can check if the HackRF one is recognized by the machine:

''hackrf_info''

When everything is correct you should see an output like this:

[[File:Output.PNG]]

Here you can see the HackRF One was found and some more things. Important now is the firmware version. If it is not the newest, we have to do the following:
Unpack the folder we downloaded before from https://github.com/mossmann/hackrf/releases and navigate into the firmware-bin subdirectory. Then use this command to update the firmware:

''hackrf_spiflash -w hackrf_one_usb.bin''

Now navigate into the firmware subdirectory and use this command to update CPLD:

''hackrf_cpldjtag -x ./cpld/sgpio_if/default.xsvf''

Now restart the HackRF One by simply unplugging and plugging back in. You can now check if the version was updated.

=== Receiving Radio Waves ===

To validate that the HackRF One is properly working we want to test it by simply listening to Radio. To do that, we must start the previous downloaded program GQRX. You will be prompted a configuration window which you should edit like that:

[[File:Iqinput.PNG]]

Now the program window will open. We must do some configuration here though:

[[File:Gqrx.PNG]]

* Change the Mode to ‘WFM(stereo)’
* Increase the Gain (otherwise you will not hear anything)
* Click the ‘Start DSP processing’ button
* Change the Frequency (you can google for radio channel frequencies in your area or try to move the red bar inside one of the white curves)

If you can listen to the radio channel now your HackRF One is set up properly and you can move on to do other, more interesting things with it.

== Used Hardware ==

* HackRF One
* Antenna (Antratek ANT500)

== Courses ==

* Wahlfach Projekt 1 (2021)

== References ==

* https://miloserdov.org/?p=4370
* https://github.com/mossmann/hackrf/wiki/Getting-Started-with-HackRF-and-GNU-Radio

[[Category:Documentation]]

HackRF One: Setup

2021-06-24T22:44:17Z

FVarli:

HackRF One: Setup

2021-06-24T22:43:04Z

FVarli:

== Summary ==

We want to get started with the HackRF One Software Defined Radio. At the end of the setup, the HackRF One will be ready to use and we will be able to see the first incoming radio signals.

== Requirements ==

* Operating system: Any Linux Distribution but preferably Kali or Pentoo

== Description ==

=== Installation of Packages ===

The following commands are for Debian/Ubuntu based Linux Distributions.
First, update your machine:

''sudo apt-get update
sudo apt upgrade''

Then install the hackrf tool and libraries:

sudo apt install hackrf libhackrf-dev libhackrf0

Now install GQRX:

sudo apt install gqrx-sdr

If that does not work use:

sudo aptitude install gqrx-sdr

We also must download the newest firmware from this Git repository:

https://github.com/mossmann/hackrf/releases

Download the newest firmware .tar, e.g.:

hackrf-2021.01.1.tar.xz

=== Check HackRF One ===

Now, that we have installed the necessary software we can finally connect the HackRF One to our computer. IMPORTANT: Before you connect it to the computer, make sure you have attached the antenna. If you do not do this the HackRF One might get broken.

[[File:Hackrf.PNG]]

Now we must activate the USB port in the virtual machine. In Oracle Virtual Box you can do that by right-clicking the VM -> select options -> click USB -> add USB drive -> choose the HackRF One -> Restart the machine.

Now we can check if the HackRF one is recognized by the machine:

hackrf_info

When everything is correct you should see an output like this:

[[File:Output.PNG]]

Here you can see the HackRF One was found and some more things. Important now is the firmware version. If it is not the newest, we have to do the following:
Unpack the folder we downloaded before from https://github.com/mossmann/hackrf/releases and navigate into the firmware-bin subdirectory. Then use this command to update the firmware:

hackrf_spiflash -w hackrf_one_usb.bin

Now navigate into the firmware subdirectory and use this command to update CPLD:

hackrf_cpldjtag -x ./cpld/sgpio_if/default.xsvf

Now restart the HackRF One by simply unplugging and plugging back in. You can now check if the version was updated.

=== Receiving Radio Waves ===

To validate that the HackRF One is properly working we want to test it by simply listening to Radio. To do that, we must start the previous downloaded program GQRX. You will be prompted a configuration window which you should edit like that:

[[File:Iqinput.PNG]]

Now the program window will open. We must do some configuration here though:

[[File:Gqrx.PNG]]

* Change the Mode to ‘WFM(stereo)’
* Increase the Gain (otherwise you will not hear anything)
* Click the ‘Start DSP processing’ button
* Change the Frequency (you can google for radio channel frequencies in your area or try to move the red bar inside one of the white curves)

If you can listen to the radio channel now your HackRF One is set up properly and you can move on to do other, more interesting things with it.

== Used Hardware ==

* HackRF One
* Antenna (Antratek ANT500)

== Courses ==

* Wahlfach Projekt 1 (2021)

== References ==

* https://miloserdov.org/?p=4370
* https://github.com/mossmann/hackrf/wiki/Getting-Started-with-HackRF-and-GNU-Radio

[[Category:Documentation]]