Elvis Wiki - User contributions [en]

Heapusage

2024-01-17T15:33:11Z

LPutz: fix typo

== Summary ==

This documentation describes the usage of heapusage developed by Kristofer Berggren (d99kris) (https://github.com/d99kris/heapusage).
With practical examples it is shown how this tool can be used to find memory leaks, double free, use after free and overflows.

== Requirements ==

According to the GitHub documentation, heapusage can be used on Linux and macOS and has been tested on these operating systems:
* macOS Big Sur 11.0
* Ubuntu 20.04 LTS

During creation of this documentation it was also successfully tested on:
* Ubuntu 22.04.3 LTS

== Alternatives ==
* AddressSanitizer (https://github.com/google/sanitizers/wiki/AddressSanitizer)
* Electric Fence (https://linux.die.net/man/3/efence)
* mtrace (https://man7.org/linux/man-pages/man3/mtrace.3.html)

== Installation ==

=== Step 1 - Pre-requisites ===

To use heapusage on Ubuntu, the following pre-requisites need to be installed:
sudo apt install git cmake build-essential

To show the source filenames and line-numbers in the call stacks, another pre-requisite can be installed optionally:
sudo apt install binutils-dev

=== Step 2 - Installing heapusage ===

To install heapusage simply clone the GitHub repository and build it:
git clone https://github.com/d99kris/heapusage
cd heapusage
mkdir -p build
cd build
cmake ..
make -s

Optionally, you can install it in the system:
sudo make install
If it is installed in the system, you can simply run it using <code>heapusage</code>. More information about using heapusage can be found in the [[#Usage|Usage]] section.

== Usage ==

=== General ===
Heapusage can be used as follows:
heapusage [-d] [-m minsize] [-n] [-o path] [-t tools] PROG [ARGS..]
This parameters can be used:
* <code>-d</code> (optional) enables the debug mode.
* <code>-m <minsize></code> (optional) sets the minimum allocation size heapusage is enabled for. For example, using <code>heapusage -t leak -m 50./app</code> only shows memory leaks larger than or equal to 50 bytes.
* <code>-n</code> (optional) disables symbol lookup. This leads to a faster execution time, however less information is shown in the output. You can still see for example how many bytes are leaked, but no longer in which file/function.
* <code>-o <path></code> (optional) sets an output file to write the output to, instead of stderr.
* <code>-t <tools></code> (optional) sets which tools should be used for the analysis. If not specified, the tool <code>leak</code> is used per default. The possible tools can be found below.
* <code>PROG</code> sets the program to be analysed.
* <code>ARGS...</code> (optional) are the parameters for the analysed program (PROG).

Furthermore, heapusage can be run using
heapusage --help
heapusage --version
to show an overview of the usage or the installed version.

=== Tools ===
As mentioned above, using the <code>-t <tools></code> parameters, the tools to be used can be specified.
The following tools can be used:
* <code>leak</code> (default) detects memory allocations which are never free'd.
* <code>double-free</code> detects when an already free'd buffer is free'd again.
* <code>use-after-free</code> detects when an already free'd buffer is used afterwards.
* <code>overflow</code> detects buffer overflows, like when an address beyond the allocated memory is accessed.
* <code>all</code> enables all tools.

Multiple tools can be combined by separating them with a comma, like <code>-t leak,double-free</code>.

<code>-t all</code> is therefore the same as <code>-t leak,double-free,use-after-free,overflow</code>.

== Examples ==
In the following, a simple example for each of the tools is shown. Each of these examples is saved as <code>.c</code>-file and compiled using <code>gcc <filename>.c -o <output-filename></code>.
=== leak ===
ex1-leak.c:
#include <stdlib.h>

void* getPointer(int size) {
return malloc(size);
}

int main() {
void* p = getPointer(1337);
p = getPointer(42);
free(p);
return 0;
}

After compiling this code it is executed using heapusage: <code>heapusage -t leak ./ex1</code>
This leads to the following output:
==6367== Heapusage - https://github.com/d99kris/heapusage
==6367==
==6367== HEAP SUMMARY:
==6367== in use at exit: 1337 bytes in 1 blocks
==6367== total heap usage: 2 allocs, 79 frees, 1379 bytes allocated
==6367== peak heap usage: 1379 bytes allocated
==6367==
==6367== 1337 bytes in 1 block(s) are lost, originally allocated at:
==6367== at 0x00007fc5942aee5c: malloc (humain.cpp:175)
==6367== at 0x000055c4d3b9d185: getPointer
==6367== at 0x000055c4d3b9d19d: main
==6367== at 0x00007fc594029d90: __libc_start_call_main (libc_start_call_main.h:58)
==6367== at 0x00007fc594029e40: __libc_start_main (libc-start.c:128)
==6367== at 0x000055c4d3b9d0a5: _start
==6367==
==6367== LEAK SUMMARY:
==6367== definitely lost: 1337 bytes in 1 blocks
==6367==

It can be seen, that the second pointer initialization of 42 bytes which is free'd again is not shown here, whereas the 1337 bytes are shown as memory leak, since the are allocated and never free'd.

=== double-free ===
ex2-doubleFree.c:
#include <stdlib.h>

void* getPointer(int size) {
return malloc(size);
}

void free1(void* p) {
free(p);
}

void free2(void* p) {
free(p);
}

int main() {
void* p = getPointer(1337);
free1(p);
free2(p);
return 0;
}
The similar functions <code>free1</code> and <code>free2</code> are used for a better demonstration of the heapusage output.

<code>heapusage -t double-free ./ex2</code>:
==6438== Heapusage - https://github.com/d99kris/heapusage
==6438==
==6438== Invalid deallocation at:
==6438== at 0x00007f16a3399f4f: free (humain.cpp:188)
==6438== at 0x00005648bfc3f1c2: free2
==6438== at 0x00005648bfc3f1f7: main
==6438== at 0x00007f16a3029d90: __libc_start_call_main (libc_start_call_main.h:58)
==6438== at 0x00007f16a3029e40: __libc_start_main (libc-start.c:128)
==6438== at 0x00005648bfc3f0a5: _start
==6438== Address 0x5648c0f6a190 is a block of size 1337 free'd at:
==6438== at 0x00007f16a3399f4f: free (humain.cpp:188)
==6438== at 0x00005648bfc3f1a3: free1
==6438== at 0x00005648bfc3f1eb: main
==6438== at 0x00007f16a3029d90: __libc_start_call_main (libc_start_call_main.h:58)
==6438== at 0x00007f16a3029e40: __libc_start_main (libc-start.c:128)
==6438== at 0x00005648bfc3f0a5: _start
==6438== Block was alloc'd at:
==6438== at 0x00007f16a3399e5c: malloc (humain.cpp:175)
==6438== at 0x00005648bfc3f185: getPointer
==6438== at 0x00005648bfc3f1db: main
==6438== at 0x00007f16a3029d90: __libc_start_call_main (libc_start_call_main.h:58)
==6438== at 0x00007f16a3029e40: __libc_start_main (libc-start.c:128)
==6438== at 0x00005648bfc3f0a5: _start
==6438==
==6438== HEAP SUMMARY:
==6438== in use at exit: 0 bytes in 0 blocks
==6438== total heap usage: 1 allocs, 80 frees, 1337 bytes allocated
==6438== peak heap usage: 1337 bytes allocated
==6438==
==6438== LEAK SUMMARY:
==6438== definitely lost: 0 bytes in 0 blocks
==6438==

Here it shows an invalid deallocation in the <code>free2</code> function and the reason for that, because the block was already free'd in the <code>free1</code> function.

=== use-after-free ===
ex3-useAfterFree.c:
#include <stdlib.h>

int* getIntPointer() {
return (int*)malloc(sizeof(int));
}

void free1(int* p) {
free(p);
}

void setPointerValue(int* p, int value){
*p = value;
}

int main() {
int *p = getIntPointer();
free1(p);
setPointerValue(p, 42);
return 0;
}

<code>heapusage -t use-after-free ./ex3</code>:
==6458== Heapusage - https://github.com/d99kris/heapusage
==6458==
==6458== Invalid memory access at:
==6458== at 0x00007fe4fb042520: __restore_rt (libc_sigaction.c:0)
==6458== at 0x0000559a8cbc71b2: setPointerValue
==6458== at 0x0000559a8cbc71ee: main
==6458== at 0x00007fe4fb029d90: __libc_start_call_main (libc_start_call_main.h:58)
==6458== at 0x00007fe4fb029e40: __libc_start_main (libc-start.c:128)
==6458== at 0x0000559a8cbc70a5: _start
==6458== Address 0x559a8d19b000 is 0 bytes inside a block of size 4 free'd at:
==6458== at 0x00007fe4fb3e9f4f: free (humain.cpp:188)
==6458== at 0x0000559a8cbc7199: free1
==6458== at 0x0000559a8cbc71dd: main
==6458== at 0x00007fe4fb029d90: __libc_start_call_main (libc_start_call_main.h:58)
==6458== at 0x00007fe4fb029e40: __libc_start_main (libc-start.c:128)
==6458== at 0x0000559a8cbc70a5: _start
==6458== Block was alloc'd at:
==6458== at 0x00007fe4fb3e9e5c: malloc (humain.cpp:175)
==6458== at 0x0000559a8cbc717b: getIntPointer
==6458== at 0x0000559a8cbc71cd: main
==6458== at 0x00007fe4fb029d90: __libc_start_call_main (libc_start_call_main.h:58)
==6458== at 0x00007fe4fb029e40: __libc_start_main (libc-start.c:128)
==6458== at 0x0000559a8cbc70a5: _start
==6458==
==6458== HEAP SUMMARY:
==6458== in use at exit: 0 bytes in 0 blocks
==6458== total heap usage: 1 allocs, 79 frees, 4 bytes allocated
==6458== peak heap usage: 4 bytes allocated
==6458==
==6458== LEAK SUMMARY:
==6458== definitely lost: 0 bytes in 0 blocks
==6458==

The output looks similar to that of double-free, however in this case it now shows an invalid memory access instead of invalid deallocation. As before, it still shows where the block was free'd before and where it was allocated in the first place.

=== overflow ===
ex4-overflow.c:
#include <stdlib.h>
#include <string.h>
#include <stdio.h>

char* getCharBuf(int size) {
return (char*)malloc(size);
}

void setBufferText(char* buf, char* text) {
strcpy(buf, text);
}

int main() {
char* buf = getCharBuf(16);
setBufferText(buf, "0123456789ABCDEF0123456789");
return 0;
}

<code>heapusage -t overflow ./ex4</code>:
==6519== Heapusage - https://github.com/d99kris/heapusage
==6519==
==6519== Invalid memory access at:
==6519== at 0x00007f978f842520: __restore_rt (libc_sigaction.c:0)
==6519== at 0x00007f978f98b423: __strcpy_ssse3 (strcpy-ssse3.S:2568)
==6519== at 0x000055717f4101ae: setBufferText
==6519== at 0x000055717f4101e1: main
==6519== at 0x00007f978f829d90: __libc_start_call_main (libc_start_call_main.h:58)
==6519== at 0x00007f978f829e40: __libc_start_main (libc-start.c:128)
==6519== at 0x000055717f4100a5: _start
==6519== Address 0x55717fb4c000 is 0 bytes after a block of size 16 alloc'd at:
==6519== at 0x00007f978fb7ee5c: malloc (humain.cpp:175)
==6519== at 0x000055717f410185: getCharBuf
==6519== at 0x000055717f4101c7: main
==6519== at 0x00007f978f829d90: __libc_start_call_main (libc_start_call_main.h:58)
==6519== at 0x00007f978f829e40: __libc_start_main (libc-start.c:128)
==6519== at 0x000055717f4100a5: _start
==6519==
==6519== HEAP SUMMARY:
==6519== in use at exit: 16 bytes in 1 blocks
==6519== total heap usage: 1 allocs, 78 frees, 16 bytes allocated
==6519== peak heap usage: 16 bytes allocated
==6519==
==6519== LEAK SUMMARY:
==6519== definitely lost: 16 bytes in 1 blocks
==6519==

This output shows an invalid memory access, however, as opposed to before, this time it shows the error because <code>is 0 bytes after a block of size 16</code>. Meaning the code tries to access the memory outside of the allocated memory range.

== References ==

* https://github.com/d99kris/heapusage

[[Category:Documentation]]

Heapusage

2024-01-14T13:26:03Z

LPutz: Created page with "== Summary == This documentation describes the usage of heapusage developed by Kristofer Berggren (d99kris) (https://github.com/d99kris/heapusage). With practical examples it is shown how this tool can be used to find memory leaks, double free, use after free and overflows. == Requirements == According to the GitHub documentation, heapusage can be used on Linux and macOS and has been tested on these operating systems: * macOS Big Sur 11.0 * Ubuntu 20.04 LTS During c..."

== Summary ==

This documentation describes the usage of heapusage developed by Kristofer Berggren (d99kris) (https://github.com/d99kris/heapusage).
With practical examples it is shown how this tool can be used to find memory leaks, double free, use after free and overflows.

== Requirements ==

According to the GitHub documentation, heapusage can be used on Linux and macOS and has been tested on these operating systems:
* macOS Big Sur 11.0
* Ubuntu 20.04 LTS

During creation of this documentation it was also successfully tested on:
* Ubuntu 22.04.3 LTS

== Installation ==

=== Step 1 - Pre-requisites ===

To use heapusage on Ubuntu, the following pre-requisites need to be installed:
sudo apt install git cmake build-essential

To show the source filenames and line-numbers in the call stacks, another pre-requisite can be installed optionally:
sudo apt install binutils-dev

=== Step 2 - Installing heapusage ===

To install heapusage simply clone the GitHub repository and build it:
git clone https://github.com/d99kris/heapusage
cd heapusage
mkdir -p build
cd build
cmake ..
make -s

Optionally, you can install it in the system:
sudo make install
If it is installed in the system, you can simply run it using <code>heapusage</code>. More information about using heapusage can be found in the [[#Usage|Usage]] section.

== Usage ==

=== General ===
Heapusage can be used as follows:
heapusage [-d] [-m minsize] [-n] [-o path] [-t tools] PROG [ARGS..]
This parameters can be used:
* <code>-d</code> (optional) enables the debug mode.
* <code>-m <minsize></code> (optional) sets the minimum allocation size heapusage is enabled for. For example, using <code>heapusage -t leak -m 50./app</code> only shows memory leaks larger than or equal to 50 bytes.
* <code>-n</code> (optional) disables symbol lookup. This leads to a faster execution time, however less information is shown in the output. You can still see for example how many bytes are leaked, but no longer in which file/function.
* <code>-o <path></code> (optional) sets an output file to write the output to, instead of stderr.
* <code>-t <tools></code> (optional) sets which tools should be used for the analysis. If not specified, the tool <code>leak</code> is used per default. The possible tools can be found below.
* <code>PROG</code> sets the program to be analysed.
* <code>ARGS...</code> (optional) are the parameters for the analysed program (PROG).

Furthermore, heapusage can be run using
heapusage --help
heapusage --version
to show an overview of the usage or the installed version.

=== Tools ===
As mentioned above, using the <code>-t <tools></code> parameters, the tools to be used can be specified.
The following tools can be used:
* <code>leak</code> (default) detects memory allocations which are never free'd.
* <code>double-free</code> detects when an already free'd buffer is free'd again.
* <code>use-after-free</code> detects when an already free'd buffer is used afterwards.
* <code>overflow</code> detects buffer overflows, like when an address beyond the allocated memory is accessed.
* <code>all</code> enables all tools.

Multiple tools can be combined by separating them with a comma, like <code>-t leak,double-free</code>.

<code>-t all</code> is therefore the same as <code>-t leak,double-free,use-after-free,overflow</code>.

== Examples ==
In the following, a simple example for each of the tools is shown. Each of these examples is saved as <code>.c</code>-file and compiled using <code>gcc <filename>.c -o <output-filename></code>.
=== leak ===
ex1-leak.c:
#include <stdlib.h>

void* getPointer(int size) {
return malloc(size);
}

int main() {
void* p = getPointer(1337);
p = getPointer(42);
free(p);
return 0;
}

After compiling this code it is executed using heapusage: <code>heapusage -t leak ./ex1</code>
This leads to the following output:
==6367== Heapusage - https://github.com/d99kris/heapusage
==6367==
==6367== HEAP SUMMARY:
==6367== in use at exit: 1337 bytes in 1 blocks
==6367== total heap usage: 2 allocs, 79 frees, 1379 bytes allocated
==6367== peak heap usage: 1379 bytes allocated
==6367==
==6367== 1337 bytes in 1 block(s) are lost, originally allocated at:
==6367== at 0x00007fc5942aee5c: malloc (humain.cpp:175)
==6367== at 0x000055c4d3b9d185: getPointer
==6367== at 0x000055c4d3b9d19d: main
==6367== at 0x00007fc594029d90: __libc_start_call_main (libc_start_call_main.h:58)
==6367== at 0x00007fc594029e40: __libc_start_main (libc-start.c:128)
==6367== at 0x000055c4d3b9d0a5: _start
==6367==
==6367== LEAK SUMMARY:
==6367== definitely lost: 1337 bytes in 1 blocks
==6367==

It can be seen, that the second pointer initialization of 42 bytes which is free'd again is not shown here, whereas the 1337 bytes are shown as memory leak, since the are allocated and never free'd.

=== double-free ===
ex2-doubleFree.c:
#include <stdlib.h>

void* getPointer(int size) {
return malloc(size);
}

void free1(void* p) {
free(p);
}

void free2(void* p) {
free(p);
}

int main() {
void* p = getPointer(1337);
free1(p);
free2(p);
return 0;
}
The similar functions <code>free1</code> and <code>free2</code> are used for a better demonstration of the heapusage output.

<code>heapusage -t double-free ./ex2</code>:
==6438== Heapusage - https://github.com/d99kris/heapusage
==6438==
==6438== Invalid deallocation at:
==6438== at 0x00007f16a3399f4f: free (humain.cpp:188)
==6438== at 0x00005648bfc3f1c2: free2
==6438== at 0x00005648bfc3f1f7: main
==6438== at 0x00007f16a3029d90: __libc_start_call_main (libc_start_call_main.h:58)
==6438== at 0x00007f16a3029e40: __libc_start_main (libc-start.c:128)
==6438== at 0x00005648bfc3f0a5: _start
==6438== Address 0x5648c0f6a190 is a block of size 1337 free'd at:
==6438== at 0x00007f16a3399f4f: free (humain.cpp:188)
==6438== at 0x00005648bfc3f1a3: free1
==6438== at 0x00005648bfc3f1eb: main
==6438== at 0x00007f16a3029d90: __libc_start_call_main (libc_start_call_main.h:58)
==6438== at 0x00007f16a3029e40: __libc_start_main (libc-start.c:128)
==6438== at 0x00005648bfc3f0a5: _start
==6438== Block was alloc'd at:
==6438== at 0x00007f16a3399e5c: malloc (humain.cpp:175)
==6438== at 0x00005648bfc3f185: getPointer
==6438== at 0x00005648bfc3f1db: main
==6438== at 0x00007f16a3029d90: __libc_start_call_main (libc_start_call_main.h:58)
==6438== at 0x00007f16a3029e40: __libc_start_main (libc-start.c:128)
==6438== at 0x00005648bfc3f0a5: _start
==6438==
==6438== HEAP SUMMARY:
==6438== in use at exit: 0 bytes in 0 blocks
==6438== total heap usage: 1 allocs, 80 frees, 1337 bytes allocated
==6438== peak heap usage: 1337 bytes allocated
==6438==
==6438== LEAK SUMMARY:
==6438== definitely lost: 0 bytes in 0 blocks
==6438==

Here it shows an invalid deallocation in the <code>free2</code> function and the reason for that, because the block was already free'd in the <code>free1</code> function.

=== use-after-free ===
ex3-userAfterFree.c:
#include <stdlib.h>

int* getIntPointer() {
return (int*)malloc(sizeof(int));
}

void free1(int* p) {
free(p);
}

void setPointerValue(int* p, int value){
*p = value;
}

int main() {
int *p = getIntPointer();
free1(p);
setPointerValue(p, 42);
return 0;
}

<code>heapusage -t use-after-free ./ex3</code>:
==6458== Heapusage - https://github.com/d99kris/heapusage
==6458==
==6458== Invalid memory access at:
==6458== at 0x00007fe4fb042520: __restore_rt (libc_sigaction.c:0)
==6458== at 0x0000559a8cbc71b2: setPointerValue
==6458== at 0x0000559a8cbc71ee: main
==6458== at 0x00007fe4fb029d90: __libc_start_call_main (libc_start_call_main.h:58)
==6458== at 0x00007fe4fb029e40: __libc_start_main (libc-start.c:128)
==6458== at 0x0000559a8cbc70a5: _start
==6458== Address 0x559a8d19b000 is 0 bytes inside a block of size 4 free'd at:
==6458== at 0x00007fe4fb3e9f4f: free (humain.cpp:188)
==6458== at 0x0000559a8cbc7199: free1
==6458== at 0x0000559a8cbc71dd: main
==6458== at 0x00007fe4fb029d90: __libc_start_call_main (libc_start_call_main.h:58)
==6458== at 0x00007fe4fb029e40: __libc_start_main (libc-start.c:128)
==6458== at 0x0000559a8cbc70a5: _start
==6458== Block was alloc'd at:
==6458== at 0x00007fe4fb3e9e5c: malloc (humain.cpp:175)
==6458== at 0x0000559a8cbc717b: getIntPointer
==6458== at 0x0000559a8cbc71cd: main
==6458== at 0x00007fe4fb029d90: __libc_start_call_main (libc_start_call_main.h:58)
==6458== at 0x00007fe4fb029e40: __libc_start_main (libc-start.c:128)
==6458== at 0x0000559a8cbc70a5: _start
==6458==
==6458== HEAP SUMMARY:
==6458== in use at exit: 0 bytes in 0 blocks
==6458== total heap usage: 1 allocs, 79 frees, 4 bytes allocated
==6458== peak heap usage: 4 bytes allocated
==6458==
==6458== LEAK SUMMARY:
==6458== definitely lost: 0 bytes in 0 blocks
==6458==

The output looks similar to that of double-free, however in this case it now shows an invalid memory access instead of invalid deallocation. As before, it still shows where the block was free'd before and where it was allocated in the first place.

=== overflow ===
ex4-overflow.c:
#include <stdlib.h>
#include <string.h>
#include <stdio.h>

char* getCharBuf(int size) {
return (char*)malloc(size);
}

void setBufferText(char* buf, char* text) {
strcpy(buf, text);
}

int main() {
char* buf = getCharBuf(16);
setBufferText(buf, "0123456789ABCDEF0123456789");
return 0;
}

<code>heapusage -t overflow ./ex4</code>:
==6519== Heapusage - https://github.com/d99kris/heapusage
==6519==
==6519== Invalid memory access at:
==6519== at 0x00007f978f842520: __restore_rt (libc_sigaction.c:0)
==6519== at 0x00007f978f98b423: __strcpy_ssse3 (strcpy-ssse3.S:2568)
==6519== at 0x000055717f4101ae: setBufferText
==6519== at 0x000055717f4101e1: main
==6519== at 0x00007f978f829d90: __libc_start_call_main (libc_start_call_main.h:58)
==6519== at 0x00007f978f829e40: __libc_start_main (libc-start.c:128)
==6519== at 0x000055717f4100a5: _start
==6519== Address 0x55717fb4c000 is 0 bytes after a block of size 16 alloc'd at:
==6519== at 0x00007f978fb7ee5c: malloc (humain.cpp:175)
==6519== at 0x000055717f410185: getCharBuf
==6519== at 0x000055717f4101c7: main
==6519== at 0x00007f978f829d90: __libc_start_call_main (libc_start_call_main.h:58)
==6519== at 0x00007f978f829e40: __libc_start_main (libc-start.c:128)
==6519== at 0x000055717f4100a5: _start
==6519==
==6519== HEAP SUMMARY:
==6519== in use at exit: 16 bytes in 1 blocks
==6519== total heap usage: 1 allocs, 78 frees, 16 bytes allocated
==6519== peak heap usage: 16 bytes allocated
==6519==
==6519== LEAK SUMMARY:
==6519== definitely lost: 16 bytes in 1 blocks
==6519==

This output shows an invalid memory access, however, as opposed to before, this time it shows the error because <code>is 0 bytes after a block of size 16</code>. Meaning the code tries to access the memory outside of the allocated memory range.

== References ==

* https://github.com/d99kris/heapusage

[[Category:Documentation]]

Hak5 Plunder Bug

2023-08-17T09:04:55Z

LPutz: /* Used Hardware */

[[File:PlunderBug.jpg |thumb|right|600px||Plunder Bug]]
== Summary ==


The Plunder Bug by Hak5 is a LAN Tap device enabling interception and eavesdropping of data communicated through an Ethernet link. Its use cases are diverse, as it could be used as a diagnostic tool supporting troubleshooting in a network. If used for malicious purposes, such as sniffing attacks, it might prove itself effective because of its small form factor and therefore increasing the likelihood of being recognized. It is very easy to use and works out-of-the-box but offers only limited configurability.
== Description ==
[[File:PlunderBugTapping.jpg |thumb|right|600px||Plunder Bug Network Deployment]]
The Plunder Bug can be viewed as a simpler version of a [[Hak5 Packet Squirrel]]. It allows the user to tap network traffic and to access it for network scanning.

=== Device ===
The device offers two Ethernet ports, each for one of the devices sharing a communication link that we want to sniff the traffic. A USB-C device is used for the attacker. Traffic coming through either of the Ethernet ports will get mirrored to the attacker.

=== Deployment ===

# Connect the Ethernet port of the victim machine with one of the two Ethernet Ports of the Plunder Bug with an short Ethernet cable.
# Connect the other Ethernet port with the with the Ethernet cable which was previously plugged in the victim device.
# Power up the Plunder Bug by Connecting the USB-C female to USB-A male cable with an device which is under your control (preferably a raspberry pi with an battery shield).

==== Plunder Bug Modes ====
[[File:Plunderbug_mute_unmute_process.png |thumb|right|600px||Plunder Bug Mute/Unmute Output]]
The only configurable parameter for the Plunder Bug is to run it either in a "muted" and "unmuted" mode. The Plunder Bug mirrors all network traffic and sends it to the USB-C port when operating in the muted mode. The unmuted mode gives extra capabilities compared to the muted mode. In addition to passively listening to traffic, the USB-C port is used for sending frames out on the link, effectively making it a small portable switch. This mode would also allow one to perform network scans from the attacking device. According to specification in [https://docs.hak5.org/hc/en-us/articles/360018810834-About-Mode-Switching-on-the-Plunder-Bug], the device is set to unmuted mode by default.

To change between the Plunder Bug modes downlaod the shell script from [https://downloads.hak5.org/bug downloads.hak5.org]:

Shell script usage:
* make it executable with <code> chmod +x ./plunderbug.sh</code>
* run the script as root or superuser:

./plunderbug.sh [options]

Options:
--mute to use mute mode
--unmute to use unmuted mode

=== Sniffing Data ===
The following will describe the necessary steps that are needed to sniff data from an Ethernet link.
==== Local Access ====

If you can access the tapping device locally, open Wireshark and select the Ethernet interface from the Plunder Bug that is connected via the USB cable.

==== Remote Access ====
'''Sniffing Node'''
# Make sure that tcpdump and ssh-server is installed

'''Wireshark Machine'''
# Configure the SSH Remote capture Interface
# Server Tab:
## Enter IP
## Enter Port (usually 22)
# Server Tab:
## Enter Username & Password
# Capture Tab:
## Enter Capturing Interface into Remote Interface

==== Save TCP dumps ====
#Make sure tcpdump is installed
# Run tcpdump and log it into a file
sudo tcpdump > tcplog.pcap

=== Plunder Bug Usage Example ===
For this example, we placed the Plunder Bug in a test LAN Network as shown in the network schematic.

[[File:PlunderBugExampleTypology.jpg |700px]]

In this example, we first perform a network scan with Nmap and then Sniffing data with wire shark.

'''1. Performing an Network scan'''
sudo nmap -sP 192.168.1.0/24 -e eth1

-sP option tries to resolve the hostname

-e eth1 defines the Plunder Bug as operating Interface

Output:
Starting Nmap 7.70 ( https://nmap.org ) at 2020-06-03 11:57 CEST
Nmap scan report for 192.168.1.1
Host is up (0.0035s latency).
MAC Address: 00:18:4D:8F:53:0E (Netgear)
Nmap scan report for 192.168.1.10
Host is up (0.00022s latency).
MAC Address: DC:A6:32:7D:13:C7 (Unknown)
Nmap scan report for 192.168.1.11
Host is up (0.00028s latency).
MAC Address: DC:A6:32:7D:0C:17 (Unknown)
Nmap done: 256 IP addresses (3 hosts up) scanned in 20.53 seconds
The output shows that 3 Hosts are online:
* 192.168.1.1 The Netgear Router
* 192.168.1.10 Raspberry Pi 1
* 192.168.1.11 Raspberry Pi 2

'''2. Sniff with Wireshark'''

Wireshark gives us the following output if we sniff at the Plunder Bug Ethernet interface

[[File:PlunderBugSniffing.png |600px]]

'''3. Plunder Bug as a Switch'''

The Plunder Bug has two Ethernet ports and one USB-C port. One of the Ethernet port and the USB-C port can be used as ordinary ethernet ports, as long as the second Ethernet port has access to the Internet.

[[File:Plunderbug_Switch.png |600px||Plunder Bug as a Switch]]

The only requirement for using the Plunder Bug as a Switch is to have the device in unmuted-mode, meaning the device connected via USB-C has the possibility to send packets through the Plunder Bug.

=== Prevent Packet Sniffing ===

It is nearly impossible to prevent sending mirrored packets to the attackers, but taking the ability away to read and understand the mirrored packets may achieve a more secure environment.

[[File:Plunderbug_http_post_capture.png |600px]]

Above, an packet with HTTP got captured with the Plunder Bug. Now, the Attacker has the possibilty to read the account credentials for the "testphp.vulweb.com" website, since an insecure protocol was used: HTTP. HTTP does not encrypt the payload, but instead it sends out the Form in plain text. This can be prevented by using HTTPS, which encryptes the data, as on the picture below.

[[File:Plunderbug_https_tls_post.png |600px]]

Also, the user has the possibility to use VPN to protect itself against packet sniffing, since every sent-out packet will be encrypted, therefore taking away the attacker's ability to read and understand the captured packages.

== Plunder Bug Android App ==

As an attacker, to be more inconspicuous, it is possible to connect and sniff packets via an android mobile phone. The App "Plunder Bug - Smart LAN Tap" needs to be installed to fullfil this requirement, which can be found on the Google Play Store.

'''Prerequisites'''
# Have an Android Phone
# Android Phone needs to be rooted (since root permissions are needed)
# Install the Application "Plunder Bug"
# USB-C to USB-C Cable (since newest Android Phones have USB-C Ports)

'''Steps to sniff packets'''
# Setup the Environment

Setup the Environment for the Plunder Bug: Connect the Ethernet Port of the victim's machine with one of the Ethernet port of the Plunder Bug and use the previous plugged Ethernet cable to connect with the other Ethernet port of the Plunder Bug. Now, get the USB-C to USB-C cable and connect to the Android device.

# Start the App and record packets

The app should recognize the plugged-in Plunder Bug and should give you the opportunity to start recording packets.

[[File:Plunderbug_app_start_recording.png |200px]]

Start capturing the packets by clicking on the turquoise button below.

[[File:Plunderbug_app_recording.png |200px]]

On the screen, some statistics can be found. It displayes the numbers of packets the Plunder Bug has captured and the time ellapsed since the packet recording has started. To stop recording the packets, press on the right button below to save the recored packets in a pcap file. The saved files can be found under the register "Files"

[[File:Plunderbug_app_files_overview.png |200px]]

After clicking on the pcap file, the statistics can be found once again and the user has the opportunity to share the file. Normally, the user saves the pcap file to later view the captured packages on Wireshark (or on any other Application, which has the possibility to read pcap files).

[[File:Plunderbug_app_pcap_statistics.png |200px]]

== Used Hardware ==

[[Plunder Bug]]

== References ==

* https://docs.hak5.org/hc/en-us/categories/360001482953-Plunder-Bug
* S. Ansari, S. G. Rajeev and H. S. Chandrashekar, "Packet sniffing: a brief introduction," in IEEE Potentials, vol. 21, no. 5, pp. 17-19, Dec. 2002-Jan. 2003, doi: 10.1109/MP.2002.1166620.
[[Category:Pentesting]]

Throwing Star LAN Tap

2023-08-17T08:51:05Z

LPutz: /* Device - Editions */

== Summary ==

This description shows what the [https://greatscottgadgets.com/throwingstar/ Throwing Star LAN Tap] device is and how it can be used. Further information is given when the thorough explanation requires it.

== Requirements ==

To use this device for traffic sniffing, the following things are needed:
* Throwing Star LAN Tap Kit (assembled) or Pro edition
* Wired LAN network, where the LAN sniffing device can be installed
* Device with RJ45 Ethernet port as monitoring device
* Wireshark running on the monitoring device for capturing the traffic

== Description ==

[[File:Throwingstarlantapkit1.png|thumb|500px|frame|Throwing Star LAN Tap Kit with highlighted connectors for assembling]]

[[File:Throwingstarlantappro.jpeg|thumb|500px|frame|Throwing Star LAN Tap Pro]]

LAN Taps are integrated in the existing network and are used to monitor the network, because all traffic/packets coming into and going out of the network can be inspected using sniffing programs such as [https://www.wireshark.org/ WireShark].
The Throwing Star LAN Tap is a passive Ethernet tap that needs no power for working.

=== Device - Editions ===

There are two editions: the Kit ([[Throwing Star LAN Tap Kit]]), which you must assemble yourself and solder to work, and the Pro Edition ([[Throwing Star LAN Tap Pro]]). The device itself is the same.
* The Kit is a circuit board printed as star shaped with four RJ-45 (Ethernet) connectors and two 220pF capacitors that must be placed on the board.
* The Pro Edition is the second option, where the electrical components are already soldered and prepared for easier usage and the device fully assembled.

==== Assembly of the Throwing Star LAN Tap Kit ====

To assemble the Throwing Star LAN Tap Kit, the following steps must be taken:
* The four modular RJ-45 connectors are inserted into the circuit board at J1 - J4.
* The two capacitors are inserted into the C1 and C2 slots at the J3 and J4 monitoring ports.
* If the assembly is done permanently, the eight leads of each connector and both leads of each capacitor must be soldered carefully.
* After the assembly is done, the Throwing Star LAN Tap is connected by Ethernet cables in line with the target network at J1 and J2.
* One or both of the monitoring ports J3 and J4 are connected with Ethernet cables to one or two monitoring devices.
* To capture the network traffic, a software such as WireShark or tcptump is used on the monitoring device.

=== Step 1: Installation of the device in the LAN network ===

The following figure shows how the LAN traffic sniffing device can be implemented into the existing LAN network. From here on out, it does not matter whether the Kit or Pro edition is used - both work the same.
The sniffing device, in this example, is placed between the switch and the target computer. The traffic runs through the device (ports J1 and J2). The monitoring notebook is connected to the monitoring port J4 of the Throwing Star LAN Tap Pro.

[[File:Networkthrowingstar.png|none|100px|frame|Network, where the Throwing Star LAN Tap is installed]]

=== Step 2: Performing different tasks on the target computer ===

For capturing various packets, several different kinds of programs and usages were performed on the target computer, which are listed in the following points:
* Browser Usage with HTTP-websites
* Browser Usage with HTTPS-websites
* VPN Connection
* Checking emails with Outlook in the browser
* Watching videos in the browser (https-websites)
* Printing PDFs on the connected printer in the network
* Listening to music with Spotify

=== Step 3: Analyse results in Wireshark on the monitoring device ===

==== Introduction ====

Nowadays, every secure website uses HTTPS for communication over a computer network. It is also called HTTP over TLS, because the communication protocol is encrypted using TLS (Transport Layer Security). The packets
that are captured in Wireshark need to be inspected properly and in detail, because packet analysis is more complex since most internet traffic is encrypted and applications commonly use encryption based on TLS as well. Only if the HTTP-protocol is used, the information can be sniffed easier.
As an example, data/information that is shown in the Wireshark captures for TCP communication with HTTPS on top. These are one of the most important protocols for the mentioned use-cases described in Step 2.

* Source IP and Destination IP
* Source Port and Destination Port
* Source MAC and Destination MAC
* Round Trip Time (RTT) between client and server
* Time to live (TTL) - which indicates the hops between client and server
* TCP windows and flags
* Sessions
* Packets, Data, Payload
* Retransmissions

Getting this basic metadata, which actually provides information about other data, with the Throwing Star LAN Tap is really powerful, because today, data is everything. Algorithms and systems can be used to extract insights and knowledge from this unstructured and structured data. Implementing the sniffing device (Throwing Star LAN Tap Kit or Pro edition) in corporate networks provides powerful information about companies, their whereabouts, knowledge, views and a lot more. Extracting useful information from the data is very important for data mining, which can give companies competitive advantages through statistics and predictions on basis of the given data.

==== Example Results ====

The following figures show examples of which kind of information can be sniffed with the Throwing Star LAN Tap. The target computer has the IP-address 192.168.0.122. The screenshots are taken from the Wireshark capture of the monitoring device. The first example shows what kind of things are possible to see, if the HTTP-protocol is used. The login data can be read in cleartext, which is marked together with the host with a yellow rectangle.

[[File:throwingstarlansniff1.png|none|200px|frame|Wireshark capture using the Throwing Star LAN Tap - Login to a HTTP-Website]]

The second packet capture example of Wireshark in the following figure shows that a document was printed on the printer, which is available in the Local Area Network (LAN). The document name can be seen in cleartext in the Wireshark packet capture, highlighted with a yellow rectangle.

[[File:throwingstarlansniff2.png|none|200px|frame|Wireshark capture using the Throwing Star LAN Tap Pro - Document printed on the LAN printer]]

==== Summary of the important aspects ====

All captured packets in Wireshark provide data like the listed points given in step 2 above for TCP with HTTPS on top. It is important to mention that the most data can be seen during connection/3-way-handshake or at the beginning
of a session or transaction. After the initiation process and data starts flowing, only the payload can be seen, which does not provide more than encrypted payload packets with source and destination, length/size and the used protocol. As an example, for a network administrator it is possible to use data such as Source/Destination IP, Source/Destination MAC and the protocols to easily comprehend what the devices or users in the target network are up to and with whom they are communicating. It is important to remember that nowadays several protocols in use ensure security for the packets sent over a network. Therefore, traffic sniffing by using a device such as the Throwing Star LAN Tap becomes more difficult with Wireshark, but it is still possible to see loads of information and metadata. These can be used to inspect and learn a lot about the target network and are really powerful to a network administrator
or for illegally obtained access to the network from a hacker. With a high number of IoT devices connected to a Local Area Network via Ethernet, the Throwing Star LAN Tap can be used very successfully by installing it in the
right place in the network, for example between the switch and router. If all IoT devices are directly connected to the switch, all traffic that is sent to the router can be sniffed on the monitoring port, without any of the IoT devices knowing about this. For network administrators this can be a very powerful tool to find flaws and problems or inspect the network in detail.

== Important Take-Aways ==

* The Throwing Star LAN Tap is a device for passive LAN traffic sniffing and is a really powerful tool for network administrators.

* Nowadays, several protocols in use ensure security for the packets sent over a network. Traffic sniffing therefore becomes more difficult with Wireshark, but it is still possible to see loads of information and metadata. Stealing confidential data is not the primary goal nowadays.

* Algorithms and systems can be used to extract insights and knowledge from these unstructured and structured data. Extracting useful information from this data is very important for data mining, which can give companies competitive advantages through statistics and predictions on basis of the given data.

== Used Hardware ==

[[Throwing Star LAN Tap Kit]]

[[Throwing Star LAN Tap Pro]]

== References ==

* https://greatscottgadgets.com/throwingstar/

* https://www.wireshark.org/

* https://greatscottgadgets.com/throwingstar/throwing-star-instructions.pdf

* https://github.com/greatscottgadgets/throwing-star-lan-tap

* https://schwartzdaniel.com/5-useful-tips-for-analyzing-wireshark-packet-captures/

* https://accedian.com/blog/how-to-decrypt-an-https-exchange-with-wireshark/

* https://www.youtube.com/watch?v=3zUsJm3bwGY&ab_channel=Hak5

* Hessel Schut, Mark Scanlon, Jason Farina, and Nhien-An Le-Khac. Towards the Forensic Identification and Investigation of Cloud Hosted Servers through Non-Invasive Wiretaps. 08/2015

* V. Ribeiro, A. Rocha, R. Peixoto, F. Portela, and M. F. Santos. Importance of statistics for data mining and data science. In 2017. 5th International Conference on Future Internet of Things and Cloud Workshops (FiCloudW), pages 156-163, 2017.

[[Category:Pentesting]]

Segger J-Link: JTAG Usage

2023-04-20T12:45:14Z

LPutz:

== Summary ==

This documentation describes the steps necessary to use the [[Segger J-Link V8]] to connect to a device using JTAG. In this example, a BeagleBoard® https://www.beagleboard.org/boards/beagleboard is used.

== Requirements ==

* Target JTAG Device (e.g. BeagleBoard®)
* Compatible cable to connect the target's JTAG pins to the J-Link
** J-Link uses a standard 20-Pin connector compatible to ARM's Multi-ICE.
* Software: J-Link Software and Documentation pack https://www.segger.com/downloads/jlink/

== Description ==

=== Step 1 - Connect J-Link to PC ===

Connect the Segger J-Link to the PC using the included cable and start the J-Link Commander.
Upon successful detection of the J-Link, a message like the following is shown:

SEGGER J-Link Commander V7.86f (Compiled Mar 29 2023 16:41:57)
DLL version V7.86f, compiled Mar 29 2023 16:39:17

Connecting to J-Link via USB...O.K.
Firmware: J-Link ARM V8 compiled Nov 28 2014 13:44:46
Hardware version: V8.00
J-Link uptime (since boot): N/A (Not supported by this model)
S/N: 788529685
License(s): RDI,FlashDL,FlashBP,JFlash,GDB
VTref=3.313V

Type "connect" to establish a target connection, '?' for help
J-Link>

=== Step 2 - Connect J-Link to target device ===

Connect the J-Link to the target device's JTAG pins using an appropriate cable.

In this example, such a cable to connect to the BeagleBoard was not available. Therefore, the pins have been connected manually in the following way:

{| class="wikitable"
|- style="font-weight:bold;"
! BeagleBoard
! J-Link
|-
| 1 - TMS
| 7 - TMS
|-
| 2 - nTRST
| 3 - nTRST
|-
| 3 - TDI
| 5 - TDI
|-
| 4 - GND
| 4 - GND
|-
| 5 - VIO
| 1 - VTref
|-
| 7 - TDO
| 13 - TDO
|-
| 9 - RTCK
| 11 - RTCK
|-
| 11 - TCK
| 9 - TCK
|}

The other pins were not connected.

See https://beagleboard.org/static/BBSRM_latest.pdf (Page 112) for more information about the BeagleBoard's JTAG connector.

Information about the J-Link's pins can be found here: https://www.segger.com/products/debug-probes/j-link/technology/interface-description

=== Step 3 - Connect using J-Link Commander ===

J-Link supports many different devices/CPUs already. The BeagleBoard however requires a custom configuration script which can be found here: https://github.com/nullsub/sidplayer/blob/master/jlinkserver/Samples/JLink/Scripts/ScriptBeagleBoard_OMAP3530.JLinkScript

This script requires a little modification before it can be used. Some variables are declared as type <code>__int64</code>. This type was only available up to version 6.16 of the J-Link Software. For the usage in newer version it can be replaced with <code>U32</code>. Although the name <code>__int64</code> might suggest that it stores 64-bit values, according to https://forum.segger.com/index.php/Thread/4189-SOLVED-JLinkScript-and-int64/?postID=15018#post15018 it was internally handled as 32-bit, so these changes should have no effect on the script.

The modified script has to be saved in the installation directory as <code>Default.JLinkScript</code>.

Power the target device and connect the J-Link to the PC (if not already connected) and start the J-Link Commander. An output similar to the one shown in Step 1 should be shown again. Type <code>connect</code> and then specify the target device / core. For the BeagleBoard type <code>CORTEX-A8</code>. For the other settings keep the default values. After connecting it is possible to run commands like <code>halt</code> to halt the cpu, <code>go</code> to resume, etc. A list of commands can be found by typing <code>?</code>.

== Used Hardware ==

* [[Segger J-Link V8]]
* BeagleBoard® https://www.beagleboard.org/boards/beagleboard

== References ==
* https://beagleboard.org/static/BBSRM_latest.pdf
* https://www.segger.com/products/debug-probes/j-link/technology/interface-description/

[[Category:Documentation]]

Segger J-Link: JTAG Usage

2023-04-20T12:44:20Z

LPutz: /* Step 3 - Connect using J-Link Commander */

Segger J-Link: JTAG Usage

2023-04-20T12:28:40Z

LPutz:

== Summary ==

This documentation describes the steps necessary to use the [[Segger J-Link V8]] to connect to a device using JTAG. In this example, a BeagleBoard® https://www.beagleboard.org/boards/beagleboard is used.

== Requirements ==

* Target JTAG Device (e.g. BeagleBoard®)
* Compatible cable to connect the target's JTAG pins to the J-Link
** J-Link uses a standard 20-Pin connector compatible to ARM's Multi-ICE.
* Software: J-Link Software and Documentation pack https://www.segger.com/downloads/jlink/

== Description ==

=== Step 1 - Connect J-Link to PC ===

Connect the Segger J-Link to the PC using the included cable and start the J-Link Commander.
Upon successful detection of the J-Link, a message like the following is shown:

SEGGER J-Link Commander V7.86f (Compiled Mar 29 2023 16:41:57)
DLL version V7.86f, compiled Mar 29 2023 16:39:17

Connecting to J-Link via USB...O.K.
Firmware: J-Link ARM V8 compiled Nov 28 2014 13:44:46
Hardware version: V8.00
J-Link uptime (since boot): N/A (Not supported by this model)
S/N: 788529685
License(s): RDI,FlashDL,FlashBP,JFlash,GDB
VTref=3.313V

Type "connect" to establish a target connection, '?' for help
J-Link>

=== Step 2 - Connect J-Link to target device ===

Connect the J-Link to the target device's JTAG pins using an appropriate cable.

In this example, such a cable to connect to the BeagleBoard was not available. Therefore, the pins have been connected manually in the following way:

{| class="wikitable"
|- style="font-weight:bold;"
! BeagleBoard
! J-Link
|-
| 1 - TMS
| 7 - TMS
|-
| 2 - nTRST
| 3 - nTRST
|-
| 3 - TDI
| 5 - TDI
|-
| 4 - GND
| 4 - GND
|-
| 5 - VIO
| 1 - VTref
|-
| 7 - TDO
| 13 - TDO
|-
| 9 - RTCK
| 11 - RTCK
|-
| 11 - TCK
| 9 - TCK
|}

The other pins were not connected.

See https://beagleboard.org/static/BBSRM_latest.pdf (Page 112) for more information about the BeagleBoard's JTAG connector.

Information about the J-Link's pins can be found here: https://www.segger.com/products/debug-probes/j-link/technology/interface-description

=== Step 3 - Connect using J-Link Commander ===

J-Link supports many different devices/CPUs already. The BeagleBoard however requires a custom configuration script which can be found here: https://github.com/nullsub/sidplayer/blob/master/jlinkserver/Samples/JLink/Scripts/ScriptBeagleBoard_OMAP3530.JLinkScript

This script requires a little modification before it can be used. Some variables are declared as type __int64. This type was only available up to version 6.16 of the J-Link Software. For the usage in newer version it can be replaced with U32. Although the name __int64 might suggest that it stores 64-bit values, according to https://forum.segger.com/index.php/Thread/4189-SOLVED-JLinkScript-and-int64/?postID=15018#post15018 it was internally handled as 32-bit, so these changes should have no effect on the script.

The modified script has to be saved in the installation directory as "Default.JLinkScript".

== Used Hardware ==

* [[Segger J-Link V8]]
* BeagleBoard® https://www.beagleboard.org/boards/beagleboard

== References ==
* https://beagleboard.org/static/BBSRM_latest.pdf
* https://www.segger.com/products/debug-probes/j-link/technology/interface-description/

[[Category:Documentation]]

Segger J-Link: JTAG Usage

2023-04-20T11:56:42Z

LPutz: Created page with "== Summary == This documentation describes the steps necessary to use the Segger J-Link V8 to connect to a device using JTAG. In this example, a BeagleBoard® https://www.beagleboard.org/boards/beagleboard is used. == Requirements == * Target JTAG Device (e.g. BeagleBoard®) * Compatible cable to connect the target's JTAG pins to the J-Link ** J-Link uses a standard 20-Pin connector compatible to ARM's Multi-ICE. * Software: J-Link Software and Documentation pack..."

Attify Badge IoT Hacking Device Usage

2023-03-31T15:15:35Z

LPutz:

== Description ==
The [[Attify Badge IoT Hacking Device]] is a hardware security assessment tool created by Attify that is used to communicate between a PC and an embedded device using various hardware communication protocols. The device was initially built to aid in pentests for IoT devices, but the immense potential was soon recognized.
The Attify Badge uses an FTDI chip that can speak a wide variety of communication protocols and standards such as UART, SPI, I2C, 1-Wire and JTAG. This way one can interact with any IoT / embedded device for which one or more hardware communication ports are available. It supports both 3.3V and 5V, making it suitable for a large number of target devices. You don't need any special connection wires or cables to use the Attify Badge, but the standard Dupont jumper wires (also included in all Attify Badges). Attify Badge has a micro-USB port that allows it to be easily connected to your PC using a micro-USB cable. This is also included when you order an Attify Badge.

== Usage Attify Badge Tool https://github.com/attify/attify-badge-tool ==
=== UART ===
Connect the Pins of the Attify Badge to the UART-device:

{| class="wikitable"
|- style="font-weight:bold;"
! Attify Badge
! UART-device
|-
| D0 (TXD)
| RX
|-
| D1 (RXD)
| TX
|-
| GND
| GND
|}
Run the following commands to install and start the Attify Badge Tool (Attify Serial Console)
git clone https://github.com/attify/attify-badge-tool
cd attify-badge-tool
pip3 install -r requirements.txt
python3 serial-console.py

Set the serial port (e.g. COM6) and the baud rate and the click on connect.
After that, you are connected to the UART.

== Usage old Attify Badge Tool (deprecated) https://github.com/attify/attify-badge ==
The Attify Badge Tool consists of 5 main modules that correspond to the 5 protocols supported by the Attify Badge:
<ul>
<li>UART</li>
<li>SPI</li>
<li>JTAG</li>
<li>I2C</li>
<li>GPIO</li>
</ul>
If the target device you want to test or exploit has one of these interfaces, Attify Badge should be the tool of choice for this purpose.
=== Exploit by UART ===

Register the external USB device connected to the system and add it to the combo box at the top left of the user interface.

Select the USB port to which the device is connected and the baud rate to be used.

Once you have selected the desired baud rate, press Enter to connect to the device. the data received from the UART device will be displayed in a black console window. You can use the input fields below it to interact with the device. In the combo box at the bottom right, you can select the line termination for each line you want to send to the device.

=== Exploit by SPI ===

''Allows users to detect, read, write and erase SPI based memory of the target device connected to the Attify Badge.''

Select the desired operation from the drop-down menu.

For read/write commands, enter the path of the file where the data will be saved or read. An example of a path is ~/files/firmware.bin.

=== Exploit by JTAG ===
Select the appropriate configuration file for the target device. (Custom configuration files can be placed directly in the cfg/ directory.)

Click "Start OpenOCD Server". Then you will see the message "Initializing OpenOCD Server in the background".

Click on the "Connect to OpenOCD Server" button to connect to the OpenOCD Server. This will launch a new terminal window with a Telnet session connected to the OpenOCD Server.

''For further analysis (for example, to find and exploit firmware vulnerabilities).
''Enter the path of the sprite file in the path edit box and click "Run GDB" (you will need the appropriate elf file).
''This will start a gdb session for the tool to analyze.''

=== Exploit by I²C ===
''The I2C module can be used to find I2C devices and to read, write and erase the contents of I2C EEPROMs connected to the badge.''

To do so, simply select the action you want from the drop-down menu, enter the file path if necessary, and click the "Run" button.

=== Exploit by GPIO ===

'''Output Mode:'''
Selecting the check box next to each terminal will change the status of that terminal to "High", and unchecking the box will change the status of that terminal to "Low".

'''Input Mode'''
If you want to use the pin in input mode, change the mode of the desired pin to input mode and check the box to enable the pin.

Click on the "Start input monitoring" button to start the input monitoring control.

Click the "Start" button in the "Input monitoring" widget to start monitoring the input of the selected pin.

== What's possible ==
With the help of UART communication you can get a serial root access to the target system, you can get debugging logs, U-Boot access and boot logs. It is also possible to save firmware, API keys or other confidential information stored on the flash chip via SPI or I2C. You can also write your own firmware to the device using Flash Write or perform JTAG debugging with OpenOCD and GDB.
Attify provides several tutorials on its own website and also sells its own [https://blog.attify.com/hack-iot-devices-embedded-exploitation/ IoT Exploitation Learning Kit], which is not affordable for every hobby pentester is. They also provide a [https://github.com/attify/attify-badge GitHub Repository] with sample code.

== IoT Vulnerabilities ==
Nowadays, IoT devices are everywhere, including at home, e.g. To be able to control lamps or the heating with the mobile phone. However, many of these devices are very unsafe because for a long time no value was placed on the security of these things. Weak points are for example:
<ul>
<li>Weak, easy to guess, or hard-coded passwords. Often the standard passwords are simply used.</li>
<li>Insecure network services</li>
<li>Lack of a secure update mechanism</li>
<li>Insecure data transmission and storage</li>
<li>and many more</li>
</ul>

== References ==
https://blog.attify.com/hack-iot-devices-embedded-exploitation/

https://github.com/attify/attify-badge-tool

[[Category:Pentesting]]

Attify Badge IoT Hacking Device Usage

2023-03-31T14:32:21Z

LPutz:

== Description ==
The [[Attify Badge IoT Hacking Device]] is a hardware security assessment tool created by Attify that is used to communicate between a PC and an embedded device using various hardware communication protocols. The device was initially built to aid in pentests for IoT devices, but the immense potential was soon recognized.
The Attify Badge uses an FTDI chip that can speak a wide variety of communication protocols and standards such as UART, SPI, I2C, 1-Wire and JTAG. This way one can interact with any IoT / embedded device for which one or more hardware communication ports are available. It supports both 3.3V and 5V, making it suitable for a large number of target devices. You don't need any special connection wires or cables to use the Attify Badge, but the standard Dupont jumper wires (also included in all Attify Badges). Attify Badge has a micro-USB port that allows it to be easily connected to your PC using a micro-USB cable. This is also included when you order an Attify Badge.

== Firmware ==
Firmware is software that is embedded in electronic devices and performs basic functions there. It occupies an intermediate position between hardware (i.e. the physical components of a device) and the application software (the possibly exchangeable programs of a device). It is mostly stored in a flash memory, an EPROM, EEPROM or ROM and cannot be exchanged by the user or can only be exchanged with special means or functions. The term is derived from the fact that firmware is functionally permanently connected to the hardware, which means that one cannot be used without the other.

Firmware is both the operating software of various devices or components (e.g. mobile phone, game console, remote control, hard drive, printer) and the basic software of a computer (e.g. the BIOS anchored in a flash memory in personal computers), which is necessary to load and operate the operating system kernel of the actual operating system
== Usage ==
The Attify Badge Tool consists of 5 main modules that correspond to the 5 protocols supported by the Attify Badge:
<ul>
<li>UART</li>
<li>SPI</li>
<li>JTAG</li>
<li>I2C</li>
<li>GPIO</li>
</ul>
If the target device you want to test or exploit has one of these interfaces, Attify Badge should be the tool of choice for this purpose.
== Exploit by UART ==

Register the external USB device connected to the system and add it to the combo box at the top left of the user interface.

Select the USB port to which the device is connected and the baud rate to be used.

Once you have selected the desired baud rate, press Enter to connect to the device. the data received from the UART device will be displayed in a black console window. You can use the input fields below it to interact with the device. In the combo box at the bottom right, you can select the line termination for each line you want to send to the device.

== Exploit by SPI ==

''Allows users to detect, read, write and erase SPI based memory of the target device connected to the Attify Badge.''

Select the desired operation from the drop-down menu.

For read/write commands, enter the path of the file where the data will be saved or read. An example of a path is ~/files/firmware.bin.

== Exploit by JTAG ==
Select the appropriate configuration file for the target device. (Custom configuration files can be placed directly in the cfg/ directory.)

Click "Start OpenOCD Server". Then you will see the message "Initializing OpenOCD Server in the background".

Click on the "Connect to OpenOCD Server" button to connect to the OpenOCD Server. This will launch a new terminal window with a Telnet session connected to the OpenOCD Server.

''For further analysis (for example, to find and exploit firmware vulnerabilities).
''Enter the path of the sprite file in the path edit box and click "Run GDB" (you will need the appropriate elf file).
''This will start a gdb session for the tool to analyze.''

== Exploit by I²C ==
''The I2C module can be used to find I2C devices and to read, write and erase the contents of I2C EEPROMs connected to the badge.''

To do so, simply select the action you want from the drop-down menu, enter the file path if necessary, and click the "Run" button.

== Exploit by GPIO ==

'''Output Mode:'''
Selecting the check box next to each terminal will change the status of that terminal to "High", and unchecking the box will change the status of that terminal to "Low".

'''Input Mode'''
If you want to use the pin in input mode, change the mode of the desired pin to input mode and check the box to enable the pin.

Click on the "Start input monitoring" button to start the input monitoring control.

Click the "Start" button in the "Input monitoring" widget to start monitoring the input of the selected pin.

== What's possible ==
With the help of UART communication you can get a serial root access to the target system, you can get debugging logs, U-Boot access and boot logs. It is also possible to save firmware, API keys or other confidential information stored on the flash chip via SPI or I2C. You can also write your own firmware to the device using Flash Write or perform JTAG debugging with OpenOCD and GDB.
Attify provides several tutorials on its own website and also sells its own [https://blog.attify.com/hack-iot-devices-embedded-exploitation/ IoT Exploitation Learning Kit], which is not affordable for every hobby pentester is. They also provide a [https://github.com/attify/attify-badge GitHub Repository] with sample code.

== IoT Vulnerabilities ==
Nowadays, IoT devices are everywhere, including at home, e.g. To be able to control lamps or the heating with the mobile phone. However, many of these devices are very unsafe because for a long time no value was placed on the security of these things. Weak points are for example:
<ul>
<li>Weak, easy to guess, or hard-coded passwords. Often the standard passwords are simply used.</li>
<li>Insecure network services</li>
<li>Lack of a secure update mechanism</li>
<li>Insecure data transmission and storage</li>
<li>and many more</li>
</ul>

== References ==
https://blog.attify.com/hack-iot-devices-embedded-exploitation/

https://github.com/attify/attify-badge-tool

[[Category:Pentesting]]

Attify Badge IoT Hacking Device Description

2023-03-31T14:31:34Z

LPutz: LPutz moved page Attify Badge IoT Hacking Device Description to Attify Badge IoT Hacking Device Usage: contains more usage than description

#REDIRECT [[Attify Badge IoT Hacking Device Usage]]

Attify Badge IoT Hacking Device Usage

2023-03-31T14:31:34Z

LPutz: LPutz moved page Attify Badge IoT Hacking Device Description to Attify Badge IoT Hacking Device Usage: contains more usage than description

== Description ==
The [[Attify Badge IoT Hacking Device]] is a hardware security assessment tool created by Attify that is used to communicate between a PC and an embedded device using various hardware communication protocols. The device was initially built to aid in pentests for IoT devices, but the immense potential was soon recognized. The Attify Badge uses an FTDI chip that can speak a wide variety of communication protocols and standards such as UART, SPI, I2C, 1-Wire and JTAG. This way one can interact with any IoT / embedded device for which one or more hardware communication ports are available. It supports both 3.3V and 5V, making it suitable for a large number of target devices. You don't need any special connection wires or cables to use the Attify Badge, but the standard Dupont jumper wires (also included in all Attify Badges). Attify Badge has a micro-USB port that allows it to be easily connected to your PC using a micro-USB cable. This is also included when you order an Attify Badge.
The Attify Badge uses an FTDI chip that can speak a wide variety of communication protocols and standards such as UART, SPI, I2C, 1-Wire and JTAG. This way one can interact with any IoT / embedded device for which one or more hardware communication ports are available. It supports both 3.3V and 5V, making it suitable for a large number of target devices.
You don't need any special connection wires or cables to use the Attify Badge, but the standard Dupont jumper wires (also included in all Attify Badges). Attify Badge has a micro-USB port that allows it to be easily connected to your PC using a micro-USB cable. This is also included when you order an Attify Badge.
== Firmware ==
Firmware is software that is embedded in electronic devices and performs basic functions there. It occupies an intermediate position between hardware (i.e. the physical components of a device) and the application software (the possibly exchangeable programs of a device). It is mostly stored in a flash memory, an EPROM, EEPROM or ROM and cannot be exchanged by the user or can only be exchanged with special means or functions. The term is derived from the fact that firmware is functionally permanently connected to the hardware, which means that one cannot be used without the other.

Firmware is both the operating software of various devices or components (e.g. mobile phone, game console, remote control, hard drive, printer) and the basic software of a computer (e.g. the BIOS anchored in a flash memory in personal computers), which is necessary to load and operate the operating system kernel of the actual operating system
== Usage ==
The Attify Badge Tool consists of 5 main modules that correspond to the 5 protocols supported by the Attify Badge:
<ul>
<li>UART</li>
<li>SPI</li>
<li>JTAG</li>
<li>I2C</li>
<li>GPIO</li>
</ul>
If the target device you want to test or exploit has one of these interfaces, Attify Badge should be the tool of choice for this purpose.
== Exploit by UART ==

Register the external USB device connected to the system and add it to the combo box at the top left of the user interface.

Select the USB port to which the device is connected and the baud rate to be used.

Once you have selected the desired baud rate, press Enter to connect to the device. the data received from the UART device will be displayed in a black console window. You can use the input fields below it to interact with the device. In the combo box at the bottom right, you can select the line termination for each line you want to send to the device.

== Exploit by SPI ==

''Allows users to detect, read, write and erase SPI based memory of the target device connected to the Attify Badge.''

Select the desired operation from the drop-down menu.

For read/write commands, enter the path of the file where the data will be saved or read. An example of a path is ~/files/firmware.bin.

== Exploit by JTAG ==
Select the appropriate configuration file for the target device. (Custom configuration files can be placed directly in the cfg/ directory.)

Click "Start OpenOCD Server". Then you will see the message "Initializing OpenOCD Server in the background".

Click on the "Connect to OpenOCD Server" button to connect to the OpenOCD Server. This will launch a new terminal window with a Telnet session connected to the OpenOCD Server.

''For further analysis (for example, to find and exploit firmware vulnerabilities).
''Enter the path of the sprite file in the path edit box and click "Run GDB" (you will need the appropriate elf file).
''This will start a gdb session for the tool to analyze.''

== Exploit by I²C ==
''The I2C module can be used to find I2C devices and to read, write and erase the contents of I2C EEPROMs connected to the badge.''

To do so, simply select the action you want from the drop-down menu, enter the file path if necessary, and click the "Run" button.

== Exploit by GPIO ==

'''Output Mode:'''
Selecting the check box next to each terminal will change the status of that terminal to "High", and unchecking the box will change the status of that terminal to "Low".

'''Input Mode'''
If you want to use the pin in input mode, change the mode of the desired pin to input mode and check the box to enable the pin.

Click on the "Start input monitoring" button to start the input monitoring control.

Click the "Start" button in the "Input monitoring" widget to start monitoring the input of the selected pin.

== What's possible ==
With the help of UART communication you can get a serial root access to the target system, you can get debugging logs, U-Boot access and boot logs. It is also possible to save firmware, API keys or other confidential information stored on the flash chip via SPI or I2C. You can also write your own firmware to the device using Flash Write or perform JTAG debugging with OpenOCD and GDB.
Attify provides several tutorials on its own website and also sells its own [https://blog.attify.com/hack-iot-devices-embedded-exploitation/ IoT Exploitation Learning Kit], which is not affordable for every hobby pentester is. They also provide a [https://github.com/attify/attify-badge GitHub Repository] with sample code.

== IoT Vulnerabilities ==
Nowadays, IoT devices are everywhere, including at home, e.g. To be able to control lamps or the heating with the mobile phone. However, many of these devices are very unsafe because for a long time no value was placed on the security of these things. Weak points are for example:
<ul>
<li>Weak, easy to guess, or hard-coded passwords. Often the standard passwords are simply used.</li>
<li>Insecure network services</li>
<li>Lack of a secure update mechanism</li>
<li>Insecure data transmission and storage</li>
<li>and many more</li>
</ul>

== References ==
https://blog.attify.com/hack-iot-devices-embedded-exploitation/

https://github.com/attify/attify-badge-tool

[[Category:Pentesting]]

Bus Pirate: UART

2023-03-31T10:10:50Z

LPutz: Created page with "== Summary == This documentation describes the basic steps to connect to an UART-capable device using Bus Pirate v3.6 == Requirements == * Serial connection to the Bus Pirate (e.g. using Putty) * UART-capable device to connect to If the currently installed Firmware doesn't support UART mode, check Bus Pirate: First steps to install a different firmware. == UART Connection == === Step 1 === Connect the Pins of the Bus Pirate to the UART-device: {| class="wiki..."

== Summary ==

This documentation describes the basic steps to connect to an UART-capable device using Bus Pirate v3.6

== Requirements ==

* Serial connection to the Bus Pirate (e.g. using Putty)
* UART-capable device to connect to

If the currently installed Firmware doesn't support UART mode, check [[Bus Pirate: First steps]] to install a different firmware.

== UART Connection ==

=== Step 1 ===

Connect the Pins of the Bus Pirate to the UART-device:

{| class="wikitable"
|- style="font-weight:bold;"
! Bus Pirate
! UART-device
|-
| MOSI (TX)
| RX
|-
| MISO (RX)
| TX
|-
| GND
| GND
|}

=== Step 2 ===

Connect to the Bus Pirate using serial connection (e.g. using Putty) with baud rate 115200.

Type <code>m</code> to start the mode selection.

[[File:BusPirate_selectMode.png|500px|Bus Pirate Select Mode]]

Select the UART and enter the settings (baud rate, etc.) according to the specifications of the UART-device.

[[File:BusPirate_selectUART.png|500px|Bus Pirate Select UART]]

After setting the correct values, type <code>W</code> to enable the power supplies. Now it is possible to read values using <code>r</code>, send values like ASCII text using <code>"text"</code> and more.

[[File:BusPirate_testUART.png|500px|Bus Pirate Test UART]]

Type <code>?</code> to see a list of available commands.

[[File:BusPirate_UARThelpPage.png|500px|Bus Pirate UART help page]]

== Used Hardware ==

[[Bus Pirate v3.6 Universal serial interface]]

== References ==

* http://dangerousprototypes.com/blog/bus-pirate-manual/bus-pirate-uart-guide/

[[Category:Documentation]]

File:BusPirate UARThelpPage.png

2023-03-31T10:10:21Z

LPutz:

File:BusPirate testUART.png

2023-03-31T10:10:03Z

LPutz:

File:BusPirate selectUART.png

2023-03-31T10:09:08Z

LPutz:

File:BusPirate selectMode.png

2023-03-31T10:07:59Z

LPutz:

Bus Pirate: First Steps

2023-03-31T09:57:35Z

LPutz:

== Summary ==

Here the upgrade process for the Bus Pirate v3.6 will be showcased for [1.] Windows using the GUI application and for [2.] Linux using the console application.

This will use the tutorial provided by the [http://dangerousprototypes.com/docs/Bus_Pirate manufacture] and the [https://github.com/BusPirate/Bus_Pirate github repository]

== Description ==

The Bus Pirate is an open source hacker multi-tool that talks to electronic stuff. It's got a bunch of features an intrepid hacker might need to prototype their next project. The Bus Pirate is used through a simple terminal interface.

For [http://dangerousprototypes.com/docs/Bus_Pirate_menu_options_guide#I_Hardware.2C_firmware.2C_microcontroller_version_information all commands visit the manufactures website]

'''Protocols
* 1-Wire
* I2C
* SPI
* JTAG
* Asynchronous serial
* MIDI
* PC keyboard
* HD44780 LCD
* 2- and 3-wire libraries with bitwise pin control
* Scriptable binary bitbang, 1-Wire, I2C, SPI, and UART modes.

'''Application Support
* AVRDude AVR programmer (AVRDude v5.8+, firmware v4 (any) or v5.9+)
* OpenOCD JTAG debugger
* flashrom bios/flash programmer

== [1.] Windows ==

; Check Bus Pirate Version
: Connect via Putty (baud rate 115200) to the Bus Pirate and type <code>i</code>

HiZ>i
Bus Pirate v3b
Firmware v5.10 (r559) Bootloader v4.4
DEVID:0x0447 REVID:0x3046 (24FJ64GA002 B8)
http://dangerousprototypes.com

: Hardware v3b and v3.5 shipped with '''bootloader v4+, continue below'''
: Hardware v3a and v2go shipped with '''bootloader v2''', please see the [http://dangerousprototypes.com/docs/Bus_Pirate#Bus_Pirate_v3_bootloader_upgradesbootloader upgrade guide]

*; Enter Bus Pirate Bootloader mode (2 options)
: 1. Connect via Putty to the Bus Pirate and type <code>$</code> (! after this you have to close the application otherwise the firmware loader can not connect)
: 2. Connect the two pins: PGD and PGC (see image: [http://dangerousprototypes.com/docs/images/thumb/2/26/Bpv3-upgrade-jumper.jpg/250px-Bpv3-upgrade-jumper.jpg])
* Download: https://github.com/mikebdp2/Bus_Pirate.git
* Navigate to Bus_Pirate\BPv3-bootloader\ds30_Loader_GUI
*; Run 'ds30 Loader GUI.exe'
* Click Connect / and select the firmware image (found under Bus_Pirate\package_latest\BPv3\bpv3_fw7.0_opt2_18092016.hex)
* Click Load

== [2.] Linux ==

=== Communicate with the Bus Pirate ===

; Install minicom serial reader/writer
: <code> sudo apt install minicom</code>
; Connect BusPirate to the computer
: Check on what port the Bus Pirate connected to:
: <code>dmesg | tail</code>

j@laptop:~$ dmesg | tail
[ 760.610683] ftdi_sio 1-1.2:1.0: device disconnected
[ 765.780110] usb 1-1.2: new full-speed USB device number 7 using xhci_hcd
[ 765.887218] usb 1-1.2: New USB device found, idVendor=0403, idProduct=6001
[ 765.887224] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 765.887227] usb 1-1.2: Product: FT232R USB UART
[ 765.887230] usb 1-1.2: Manufacturer: FTDI
[ 765.887233] usb 1-1.2: SerialNumber: A907NRH0
[ 765.890644] ftdi_sio 1-1.2:1.0: FTDI USB Serial Device converter detected
[ 765.890768] usb 1-1.2: Detected FT232RL
[ 765.891161] usb 1-1.2: FTDI USB Serial Device converter now attached to ttyUSB0

; Configure minicom
: <code>minicom -s</code>
: select <code>Serial port setup</code>
: set to following parameters:

+-----------------------------------------------------------------------+
| A - Serial Device : /dev/ttyUSB0 |
| B - Lockfile Location : /var/lock |
| C - Callin Program : |
| D - Callout Program : |
| E - Bps/Par/Bits : 115200 8N1 |
| F - Hardware Flow Control : No |
| G - Software Flow Control : No |
| |
| Change which setting? |
+-----------------------------------------------------------------------+

: Then <code>Save setup as dfl</code>
; Connect to Bus Pirate
: <code>sudo minicom</code>
: Press Enter and following should be displayed:
Welcome to minicom 2.7.1
OPTIONS: I18n
Compiled on Aug 13 2017, 15:25:34.
Port /dev/ttyUSB0, 16:23:34
Press CTRL-A Z for help on special keys
HiZ>

'''If <code>Hiz/></code> is not being displayed the connection was not successful

; Get Bus Pirate version
: Enter: <code>i</code>

HiZ>i
Bus Pirate v3b
Firmware v5.10 (r559) Bootloader v4.4
DEVID:0x0447 REVID:0x3046 (24FJ64GA002 B8)
http://dangerousprototypes.com

Hardware v3b and v3.5 shipped with '''bootloader v4+, continue below'''

Hardware v3a and v2go shipped with '''bootloader v2''', please see the [http://dangerousprototypes.com/docs/Bus_Pirate#Bus_Pirate_v3_bootloader_upgradesbootloader upgrade guide]

For [http://dangerousprototypes.com/docs/Bus_Pirate_menu_options_guide#I_Hardware.2C_firmware.2C_microcontroller_version_information all commands visit the manufactures website]

== Update Firmware ==

In general there are two options. You can:
# Build the [http://dangerousprototypes.com/docs/Compile_the_Bus_Pirate_firmware source code yourself]
# Or use a precompiled binary of the firmware: ('''recommended''')

'''This tutorial is using the latest community package 7.1 for the BusPiratev3'''

'''The latest is posted in [[http://dangerousprototypes.com/forum/index.php?topic=8498.135 here]]''' (usually by the user called USBEprom)

'''IMPORTANT: In order to update to v7.1 you need to upgrade the bootloader to v4.5''' (see [http://dangerousprototypes.com/forum/index.php?topic=8498.135 forum discussion], otherwise <code>$</code> to enter the bootloader will not work)

''This tutorial is using Windows, if you have a Linux system please read "How to update with pirate-loader.rtf" in the downloaded folder''

; Download firmware v7.1 for Bus Pirate v3.6
: Latest post by USBEprom: http://dangerousprototypes.com/forum/index.php?topic=8498.120
: Or if the site is unavailable use this copy [[File:BPv3-bootloaderv4xtov45-update-vb ENG-g2.7z]] @credits to USBEprom (Note: Read the the summary!)
; Update Bootloader
* Check the bootloader version, it needs to be 4.1+, otherwise follow the description in "How to use UPGRADE_TO_BL_v4.5.bat.rft"
* Change the COM-port to the correct one in UPGRADE_TO_BL_v4.5.bat
* Save changes
* Enter Bootloader (2 options):
:: 1. connect via some serial terminal (eg. minicom) and enter <code>$</code> (! after this you have to close the application otherwise the firmware loader can not connect) '''recommended'''
:: 2. connect the two pins: PGD and PGC (see image: [http://dangerousprototypes.com/docs/images/thumb/2/26/Bpv3-upgrade-jumper.jpg/250px-Bpv3-upgrade-jumper.jpg])
* Run UPGRADE_TO_BL_v4.5.bat
* Ignore the error: Erasing page 42, a800...ERROR [50], Error updating firmware :(
* Unplug an re-plug the USB cable of the BusPirate v3
* Open the terminal and press <code>space</code> for further instructions
* Type <code>yes</code> if prompted -> This will overwrite the old bootloader
; Upgrade the firmware:
* Change COM-port to correct one in UPGRADE_FW_S_1-29092019.hex.bat
* Save changed file
* Run the file
* Ignore error: Erasing page 42, a800...ERROR [50] Error updating firmware :(
* Unplug and re-plug the BusPirate
* Done!

HiZ>i
Bus Pirate v3.5
Community Firmware v7.1 - goo.gl/gCzQnW [HiZ 1-WIRE UART I2C SPI 2WIRE 3WIRE KEYB LCD PIC DIO] Bootloader v4.5
DEVID:0x0447 REVID:0x3046 (24FJ64GA00 2 B8)
http://dangerousprototypes.com

== Used Hardware ==

[[Bus Pirate v3.6 Universal serial interface]]

== References ==

* [http://dangerousprototypes.com/docs/Bus_Pirate manufactures website]
* [https://github.com/BusPirate/Bus_Pirate github repository]

[[Category:Documentation]]

JTAGulator: Find IoT-Device's UART interface

2023-03-30T11:57:56Z

LPutz:

== Summary ==

Description of how to find the UART interface of an IoT-Device. In this example the "smart" alarm system [[Technaxx WiFi smart alarm system starter kit TX-84]] will be used.

== Requirements ==

* '''Read subsection 'Finding UART' ''' of [[JTAGulator: Introduction]] to understand the basic commands available.
* JTAGualtor
* [[Technaxx WiFi smart alarm system starter kit TX-84]] or some other device

== UART explained ==

UART stands for Universal Asynchronous Receiver/Transmitter and is a serialized asynchronous communication specification between two devices. The communication can be simplex, half-duplex or duplex.

; UART consist out of:
* '''TX''' .. Transmit
* '''RX''' .. Receive
* Vcc .. Supply Voltage (optional)
* Gnd .. Ground 0V (optional)

whereas the RX from one device is connected to the TX from the other device

http://www.circuitbasics.com/wp-content/uploads/2016/01/Introduction-to-UART-Basic-Connection-Diagram-300x147.png

The two devices should have the same ground and same Vcc

=== Data transmission ===

http://www.circuitbasics.com/wp-content/uploads/2016/01/Introduction-to-UART-Packet-Frame-and-Bits-2.png

; UART packet are defined as followed:
: - Start Bit: A connected not-sending data-line is kept at the Vcc voltage (idle, but can also be the reverse). When one party wants to send data it indicates it by pulling the data-line to ground.
: - Data Frame: The actual data section allows to send 5 to 9 bits per packet.
: - Parity: To detect transmission errors a checksum is appended to the packet. There are different modes: total of all even bits, total of all uneven bits.
: - Stop Bit: To end the packet the data-line is set to Vcc for 1 or 2 bit duration.

* The Data Frame can only send 9 bits when the Parity Bit is turned off. The Data Frame "borrows" the extra bit from the Parity Bit.
* Data is send using least significant bit first.
* The baud rate of the 2 devices should be within +-10%

[[File:UART.png|400px|border]]

Source and Images:
* https://en.wikipedia.org/wiki/Universal_asynchronous_receiver-transmitter
* http://www.circuitbasics.com/basics-uart-communication/

== Find UART interface ==

As explained in the section before the UART interface consists out of two pins: RX and TX. Usually also the pins Gnd and Vcc are laid out together. Therefore these 4 pins are usually right next to each other in a line.

We look at this mainboard we can see 4 pins next to each other.

If you can't find them it helps to look at the datasheet of the microprocessor. It is good practice to remove the UART interface of the device since this should only be accessible for testing. (exceptions exist)

== Connect to the possible pins ==

Connect the JTAGulator Gnd Channel to the Gnd of the target device. Then connect the channels (start with 0 and proceed incrementally) to the possible pins of the UART.

(Tip: you do not have to connect to the Gnd and Vcc of the target device since Gnd is already connected and Vcc has to be set in the software of the JTAGulator)

== Connect to the JTAGualtor ==

''This tutorial is based on the firmware version 1.6''

Make sure you connected the target device to power.

; Connect the JTAGulator to the computer
: and open a serial connection using the following parameters: (eg. use Putty, minicom, ...)
:: 115200 bps, 8 data bits, no parity, 1 stop bit
; Go into the UART menu
: Type <code>U</code> for the UART menu
: Type <code>H</code> for help and all possible commands
; Find UART pin configuration
: Set the voltage level of the target device
:: <code>V</code> and enter Vcc (if not known check with oscilloscope of multimeter)
: Type <code>U</code> in the UART menu to start the brute force on the pin configuration of the UART pins.
: Enter the text string you want to output on the UART interface:
:: Usually you want to keep the <code>default configuration [CR]</code> so <code>just press enter</code>
:: Usually when pressing <code>enter</code> into a UART interface it will great you with a response.
: Enter starting channel of the JTAGulator
: Enter ending channel of the JTAGulator
:: Now the JTAGulator will cycle through all pin configurations and possible baud rates and prints out the output character you specified

UART> u
UART pin naming is from the target's perspective.
Enter text string to output (prefix with \x for hex) [CR]:
Enter starting channel [0]:
Enter ending channel [4]:
Possible permutations: 20

Ignore non-printable characters? [y/N]: n
Press spacebar to begin (any other key to abort)...
JTAGulating! Press any key to abort...
----------
TXD: 2
RXD: 3
Baud: 19200
Data: ..(t0d^l.. ..... [ AF 85 28 74 30 64 5E 6C D9 0F 20 B7 E7 A5 F5 D4 ]

TXD: 2
RXD: 3
Baud: 57600
Data: ...[32;40m00:16: [ 0D 0A 1B 5B 33 32 3B 34 30 6D 30 30 3A 31 36 3A ]

TXD: 2
RXD: 3
Baud: 76800
Data: . [ 0C ]

...

TXD: 2
RXD: 4
Baud: 115200
Data: ................ [ 9E CF 0F 98 06 9E 0F 0F 98 98 E0 CF F3 98 E6 98 ]
---------
UART scan complete.

We can see that the JTAGulator received some input. Now you have to filter out the right combination by looking at the output. The UART interface will send back some ASCII characters. 0x0D / 0x0A are very good indicator signalling a carriage return / newline. So the second output (TX:2 RX:3 Baud:56700) looks very promising

; Check the found UART pin configuration
: Now we will use the UART pass-through to send terminal input directly through the JTAGulator to the specific UART pin configuration
: Type <code>P</code> in the UART menu to start the UART passthrough mode.

Restarting the target device (alarmsystem) gives us the perfect example to disable the UART as a debugging interface

-Boot 1.1.3 (May 24 2016 - 11:52:40)

Board: Dahua Tech Soc DRAM: 64 MB
relocate_code Pointer at: 83fb8000
***********************
Watchdog Reset Occurred
***********************
flash manufacture id: ef, device id 40 18
find flash: W25Q128BV
env_relocate[232] malloced ENV at 83f78010
============================================
Ralink UBoot Version: 4.3.0.0
--------------------------------------------
ASIC 7628_MP (Port5<->None)
DRAM component: 512 Mbits DDR, width 16
DRAM bus: 16 bit
Total memory: 64 MBytes
Flash component: SPI Flash
Date:May 24 2016 Time:11:52:40
============================================
icache: sets:512, ways:4, linesz:32 ,total:65536
dcache: sets:256, ways:4, linesz:32 ,total:32768

##### The CPU freq = 580 MHZ ####
estimate memory size =64 Mbytes
RESET MT7628 PHY!!!!!!

Please choose the operation:
1: Load system code to SDRAM via TFTP.
2: Load system code then write to Flash via TFTP.
3: Boot system code via Flash (default).
*: Entr boot command line interface.
5: Load img then write to Flash via TFTP.
7: Load Boot Loader code then write to Flash via Serial.
9: Load Boot Loader code then write to Flash via TFTP.
default: 3
0

3: System Boot system code via Flash.
## Booting image at bc050000 ...
Image Name: Linux Kernel Image
Image Type: MIPS Linux Kernel Image (lzma compressed)
Data Size: 2621376 Bytes = 2.5 MB
Load Address: 80000000
Entry Point: 8000c150
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
No initrd
## Transferring control to Linux (at address 8000c150) ...
## Giving linux memsize in MB, 64

Starting kernel ...

LINUX started...
Linux version 2.6.36+ (wu_zhongren@centos128) (gcc version 4.6.3 (Buildroot 2012.11.1) ) #1 Wed Nov 30 19:48:01 CST 2016

The CPU feqenuce set to 580 MHz

MIPS CPU sleep mode enabled.
prom_envp(0)=memsize=64 ace in production:

'''Ohh look it started Linux :)'''

further down in the output we can see following:

00:00:17|[NetApp-364975] debug tid:344 tid:344, P2P current config:[
{
"Address" : "www.easy4ipcloud.com",
"Enable" : true,
"Key" : "YXQ3Maxxxxxxxxx",
"Port" : 8800,
"RecvBufferSize" : 524288,
"RegisterPort" : 12366,
"RegisterServer" : "www.easy4ip.com",
"ThreadNum" : 1,
"Type" : "dhp2p",
"UUID" : "3F0073EPAN00338",
"WebVersion" : "2.211.0"
}
]

''' Oh look it also printed out some password! '''

(I replaced the last characters of the password with x)

Let's see what happens if I press enter:

user name:
password:
23:50:23|[Manager] info tid:360 CLocalClient::CLocalClient(0x0x1c28f90)>>>>>>
23:50:23|[libInfra] warn tid:360 [Src/Component/Client.cpp:67] this:0x1c28f90 tid:360, userName of client is a null string!
23:50:23|[libInfra] warn tid:360 [Sr c/Component/Client.cpp:67] this:0x1c28f90 tid:360, userName of client is a null string!
23:50:23|[Manager] info tid:360 si.l oginType=0, si.clientAddress=, si.clientType=Consol e si.authorityInfo= si.authorityType= si.passwordType=Plain
23:50:23|[Manager] error tid:360 CLo calClient::login() fa iled with:268632070!
23:50:23|[Manager] info tid:360 CLocalClient::~CLocalClie nt(0x0x1c28f90)>>>>>>
User not valid!
user name:

'''Oh look it asks for a username and password'''

Let's test admin:admin

23:50:27|[Manager] debug tid:360 CLocalClient::login() successful! username = admin

... well that was easy 😅

and the best part is: '''I am logged into root''' :)

== Used Hardware ==

[[JTAGulator]]
[[Technaxx WiFi smart alarm system starter kit TX-84]]]

[[Category:Documentation]]

WiFi Security

2023-01-08T18:26:16Z

LPutz:

== Summary ==

This documentation explains the basics of WiFi Security, specifically the protocols WPA2 and WPA3 and their respective handshakes. It also explains the possibility of frame aggregation and fragmentation, as well as some attacks on these concepts.

== Basics ==

=== WPA2 ===
[[File:4way.png|500px|thumb|right|4 Way Handshake]]

WPA2 (WiFi Protected Access 2) is specified in the IEEE 802.11i standard. It is the successor of WPA, which was based on an unfinished version of the IEEE 802.11i standard. This was done because the previously used WEP (Wired Equivalent Privacy) protocol was found to be insecure. WPA2 (and also WPA) uses the 4-Way-Handshake when a client connects to a network to create multiple keys, which are used to encrypt the communication between client (supplicant) and access point (authenticator). The handshake is based on a "Pairwise Master Key" (PMK), which is based on the Pre-Shared Key (PSK), the password you enter on a client to connect to a WiFi network. The 4-Way-Handshake consists of the following steps:

# The access point generates a random number (ANonce - Authenticator Nonce), and sends it to the client.
# The client also generates a random number (SNonce - Supplicant Nonce), and sends it to the access point, using the same value for the replay counter as the first message.
# The AP sends the group temporal key (GTK) to the client.
# The client confirms that the GTK was received.

After the 2. message, both, AP and client, have the needed information to calculate the Pairwise Transient Key (PTK), which is used to encrypt unicast messages between them. This PTK is based on the PMK, ANonce, SNonce and MAC adresses of both devices, and is therefore unique for each AP/client-combination.
The GTK is used to encrypt multicast messages and therefore the same for every client in the network. This GTK is renewed regularly by sending the messages 3 and 4 again.

After sending message 4, the client installs the PTK and GTK, meaning they are being used now. The AP also installs the PTK (the GTK was already installed).

For the encryption WPA2 allows TKIP, CCMP (counter mode with CBC-MAC protocol) and GCMP (galois counter mode protocol). The support of CCMP is mandatory in the WPA2 standard. CCMP is based on AES and is secure, if no IV (initialization vector) is repeated. The IV contains the MAC-address of the sender, a Nonce, which is increased with every message, and some other information transmitted in the WiFi frame. GCMP, also based on AES, is also considered secure, if no IV is used again. Here the IV only contains the sender-MAC-address and the nonce. In both protocols, the nonce is also used as a replay counter and initialized with 0, when the PTK gets installed.

=== WPA3 ===
[[File:Dragonfly.png|400px|thumb|right|Dragonfly Handshake (Source: https://wpa3.mathyvanhoef.com/)]]
The publication of the KRACK attacks lead to the release of WPA3. This uses the Dragonfly Handshake to provide forward secrecy and prevent dictionary attacks. It is possible to use WPA2 and WPA3 simultaneously in a network, however WPA3 clients are required to use WPA3 when it's available. If the messages, that the network supports WPA3 are manipulated and the client wants to use WPA2 instead, this is recognized during the 4-Way-Handshake, therefore preventing downgrade attacks. The Dragonfly variant used in WPA3 is also called Simultaneous Authentication of Equals (SAE). It uses elliptic curve cryptography to generate a key based on a password. This key is then used for the 4-Way-Handshake. Due to it's much higher entropy (compared to a password), it prevents dictionary attacks. Before the handshake starts, the password is converted to a group element P, by generating hashes of the password, IDs of Client and AP, and an increasing value. This is repeated until the result is a group element (in elliptic curve cryptography a point on the curve), but at least 40 times.

The dragonfly handshake consists of two phases: Commit Phase and Confirm Phase. In the Commit Phase both (Client and AP) pick two random numbers r and m in the range [2, q[ with q being the order of the used group, and calculate s = (r+m) mod q and E = -m * P (P is the previously calculated group element). The next step is to send s and E to the communcation partner (Client->AP and AP->client) and to confirm that the received values are in a valid range, aborting the handshake otherwise.
In the Confirm Phase a secret point K on the curve is calculated: K = r1 * (s2 * P + E2). r1 is the own chosen value r, while s2 and E2 are the received values s and E. The hash of this point K leads to the key k. Finally, an HMAC consisting of k, s1, E1, s2 and E2 is calculated and sent between the devices. If the value is correct, k is successfully chosen as key, which is then used for the 4-Way-Handshake.

=== Frame Aggregation and Fragmentation ===

[[File:WiFiFrameAufbau.png|500px|thumb|right|WiFi Frame Structure (Source: https://www.fragattacks.com/)]]

In WiFi the data is transmitted in so called Frames. To increase the efficiency of the transmission, it is possible to send multiple packets in one frame (aggreation), or to separate a (too) large packet into multiple frames (fragmentation). To to this, a frame contains a Frame Control Field, which specifies the type of the frame with multiple flags. The frame also contains MAC-adresses to specify the receiver and sender of the frame, as well as the source or destination. Furthermore, fields to specify the fragment- and sequence-number, and the QoS (Quality of Service) field are included. At the end, the actual transmitted data, called payload, is located. If the payload is small, multiple packets are aggregated into a large frame called A-MSDU (Aggregate MAC Service Data Units). This is marked by a flag in the QoS field, however this flag is not authenticated and can be changed by an attacker. The multiple payloads are called subframes, containing source- and destination-MAC-Address, packet-length and the actual data.
The second possibility (fragmentation) is used, when the payload is too large for a single frame, but also in noisy environments. In the latter case this leads to an increased performance, because in the case of transmission errors, only a part of the data has to be transmitted again. It is possible to use up to 16 fragments, which have an incremental fragment-number and the same sequence-number.

== Attacks ==

=== KRACK ===
Key Reinstallation Attacks are based on repeated installation of keys (see explanation of the 4-Way-Handshake), which leads to the Nonce resetting to 0, and therefore reusing an IV.

When the messages 2 and 4 of the 4-Way-Handhake are not received, the messages 1 and 3 are sent again. The IEEE 802.11i standard also states, that client should immediately install the keys after receiving message 3. In KRACK, the message 4 is intercepted, so the AP doesn't receive it. The client doesn't know about this and starts sending encrypted messages. When the access point sends the message 3 again, the client reinstalls the keys, resets the Nonce, and starts sending encrypted messages again. Since the IVs are reused now, the encryption is no longer considered secure.

=== FragAttacks ===
[[File:Fragexample.png|500px|thumb|right|Example for a Mixed Key Attack]]
Fragmentation and Aggregation Attacks affect the above mentioned possibilites of fragmenting and aggregating frames.

To attack the aggregation, the frame has to be intercepted and the A-MSDU flag modified, to make normal frames look like aggregated frames. The payload has to contain specific values, so the subframe contains the desired values. This is done by making the client perform a POST-request with specific data (e.g. on a malicious website of the attacker). If chosen correctly, the data will be interpreted as correct subframe, leading to it being forwarded like an authentic frame. With this attack it's possible to e.g. perform portscans, or to get clients to use specific (malicious) DNS servers.

The other type of FragAttacks targets the fragmentation. One variant of this is the Mixed Key Attack, which exploits flaws in the 802.11 standard, since it's not required, that multiple fragments of a frame are encrypted using the same key. This attack requires, that the keys are renewed regularly, be performing a full 4-Way-Handshake. The victim has to access data on the server of an attacker (e.g. through social engineering), which is hosted on a long URL. This leads to the frame being fragmented. The attacker intercepts these fragments and only forwards the first (with packet number n) to the access point, which encrypts it, recognizes it needs to wait for the other fragments, and stores it. At a later time, the keys are renewed and the package number is reset. When the client then sends a fragment with the packet number n+1, the attacker forwards this fragment to the AP, which then combines the previous stored fragment with the new fragment, and forwards it. This could lead to sending login data (meant for a normal website) to the server of the attacker. See the picture on the right for a simplified example.

=== Dragonblood ===
Dragonblood is a set of attacks targeting the Dragonfly Handshake of WPA3. All of them require that the attacker is in close range of the Client or the Access Point. Depending on which of these devices is attacked, the attacker has to pretend to be the other.

As mentioned above, downgrade attacks to force WPA2 instead of WPA3 are recognized during the 4-Way-Handshake. However, at this point the client has already sent enough encrypted data, to allow an attacker to perform a dictionary attack based on this data. This leads to one of the advantages of WPA3 being bypassed. To do this, a fake WPA2-network with the same SSID as the original network has to be created. Depending on the specific implementation, clients even try to connect to the fake network, although the original network doesn't support WPA2.

Another type of a Dragonblood attack targets the possibility, that Client and AP negotiate which elliptic curve is used for the handshake. The client sends the access point their desired curve. If the AP doesn't support this curve, it responds with a message stating so, leading to the client select another curve from it's list. This is repeated until a curve supported by both devices is found. The message that the AP doesn't support a curve is not verified, therefore it can be forged to force them to use a weaker curve (downgrade attack). This can also be used to perform an upgrade attack, leading to a denial of service on devices with low computational power.

== Tools ==

A description of how aircrack-ng (a popular program suite for WiFi network security) can be used to crack the Pre Shared Key after capturing the 4-Way-Handshake can be found in the article: [[WiFi Sniffing]]

== References ==

* https://www.krackattacks.com/
* https://www.fragattacks.com/
* https://wpa3.mathyvanhoef.com/

[[Category:Basic]]

WiFi Security

2023-01-08T18:07:06Z

LPutz:

== Summary ==

This documentation explains the basics of WiFi Security, specifically the protocols WPA2 and WPA3 and their respective handshakes. It also explains the possibility of frame aggregation and fragmentation, as well as some attacks on these concepts.

== Basics ==

=== WPA2 ===
WPA2 (WiFi Protected Access 2) is specified in the IEEE 802.11i standard. It is the successor of WPA, which was based on an unfinished version of the IEEE 802.11i standard. This was done because the previously used WEP (Wired Equivalent Privacy) protocol was found to be insecure. WPA2 (and also WPA) uses the 4-Way-Handshake when a client connects to a network to create multiple keys, which are used to encrypt the communication between client (supplicant) and access point (authenticator). The handshake is based on a "Pairwise Master Key" (PMK), which is based on the Pre-Shared Key (PSK), the password you enter on a client to connect to a WiFi network. The 4-Way-Handshake consists of the following steps:

[[File:4way.png|500px|4 Way Handshake]]

# The access point generates a random number (ANonce - Authenticator Nonce), and sends it to the client.
# The client also generates a random number (SNonce - Supplicant Nonce), and sends it to the access point, using the same value for the replay counter as the first message.
# The AP sends the group temporal key (GTK) to the client.
# The client confirms that the GTK was received.

After the 2. message, both, AP and client, have the needed information to calculate the Pairwise Transient Key (PTK), which is used to encrypt unicast messages between them. This PTK is based on the PMK, ANonce, SNonce and MAC adresses of both devices, and is therefore unique for each AP/client-combination.
The GTK is used to encrypt multicast messages and therefore the same for every client in the network. This GTK is renewed regularly by sending the messages 3 and 4 again.

After sending message 4, the client installs the PTK and GTK, meaning they are being used now. The AP also installs the PTK (the GTK was already installed).

For the encryption WPA2 allows TKIP, CCMP (counter mode with CBC-MAC protocol) and GCMP (galois counter mode protocol). The support of CCMP is mandatory in the WPA2 standard. CCMP is based on AES and is secure, if no IV (initialization vector) is repeated. The IV contains the MAC-address of the sender, a Nonce, which is increased with every message, and some other information transmitted in the WiFi frame. GCMP, also based on AES, is also considered secure, if no IV is used again. Here the IV only contains the sender-MAC-address and the nonce. In both protocols, the nonce is also used as a replay counter and initialized with 0, when the PTK gets installed.

=== WPA3 ===
The publication of the KRACK attacks lead to the release of WPA3. This uses the Dragonfly Handshake to provide forward secrecy and prevent dictionary attacks. It is possible to use WPA2 and WPA3 simultaneously in a network, however WPA3 clients are required to use WPA3 when it's available. If the messages, that the network supports WPA3 are manipulated and the client wants to use WPA2 instead, this is recognized during the 4-Way-Handshake, therefore preventing downgrade attacks. The Dragonfly variant used in WPA3 is also called Simultaneous Authentication of Equals (SAE). It uses elliptic curve cryptography to generate a key based on a password. This key is then used for the 4-Way-Handshake. Due to it's much higher entropy (compared to a password), it prevents dictionary attacks. Before the handshake starts, the password is converted to a group element P, by generating hashes of the password, IDs of Client and AP, and an increasing value. This is repeated until the result is a group element (in elliptic curve cryptography a point on the curve), but at least 40 times.

[[File:Dragonfly.png|500px|Dragonfly Handshake]]

The dragonfly handshake consists of two phases: Commit Phase and Confirm Phase. In the Commit Phase both (Client and AP) pick two random numbers r and m in the range [2, q[ with q being the order of the used group, and calculate s = (r+m) mod q and E = -m * P (P is the previously calculated group element). The next step is to send s and E to the communcation partner (Client->AP and AP->client) and to confirm that the received values are in a valid range, aborting the handshake otherwise.
In the Confirm Phase a secret point K on the curve is calculated: K = r1 * (s2 * P + E2). r1 is the own chosen value r, while s2 and E2 are the received values s and E. The hash of this point K leads to the key k. Finally, an HMAC consisting of k, s1, E1, s2 and E2 is calculated and sent between the devices. If the value is correct, k is successfully chosen as key, which is then used for the 4-Way-Handshake.

=== Frame Aggregation and Fragmentation ===

[[File:WiFiFrameAufbau.png|500px|WiFi Frame Structure]]

In WiFi the data is transmitted in so called Frames. To increase the efficiency of the transmission, it is possible to send multiple packets in one frame (aggreation), or to separate a (too) large packet into multiple frames (fragmentation). To to this, a frame contains a Frame Control Field, which specifies the type of the frame with multiple flags. The frame also contains MAC-adresses to specify the receiver and sender of the frame, as well as the source or destination. Furthermore, fields to specify the fragment- and sequence-number, and the QoS (Quality of Service) field are included. At the end, the actual transmitted data, called payload, is located. If the payload is small, multiple packets are aggregated into a large frame called A-MSDU (Aggregate MAC Service Data Units). This is marked by a flag in the QoS field, however this flag is not authenticated and can be changed by an attacker. The multiple payloads are called subframes, containing source- and destination-MAC-Address, packet-length and the actual data.
The second possibility (fragmentation) is used, when the payload is too large for a single frame, but also in noisy environments. In the latter case this leads to an increased performance, because in the case of transmission errors, only a part of the data has to be transmitted again. It is possible to use up to 16 fragments, which have an incremental fragment-number and the same sequence-number.

== Attacks ==

=== KRACK ===
Key Reinstallation Attacks are based on repeated installation of keys (see explanation of the 4-Way-Handshake), which leads to the Nonce resetting to 0, and therefore reusing an IV.

When the messages 2 and 4 of the 4-Way-Handhake are not received, the messages 1 and 3 are sent again. The IEEE 802.11i standard also states, that client should immediately install the keys after receiving message 3. In KRACK, the message 4 is intercepted, so the AP doesn't receive it. The client doesn't know about this and starts sending encrypted messages. When the access point sends the message 3 again, the client reinstalls the keys, resets the Nonce, and starts sending encrypted messages again. Since the IVs are reused now, the encryption is no longer considered secure.

=== FragAttacks ===
Fragmentation and Aggregation Attacks affect the above mentioned possibilites of fragmenting and aggregating frames.

To attack the aggregation, the frame has to be intercepted and the A-MSDU flag modified, to make normal frames look like aggregated frames. The payload has to contain specific values, so the subframe contains the desired values. This is done by making the client perform a POST-request with specific data (e.g. on a malicious website of the attacker). If chosen correctly, the data will be interpreted as correct subframe, leading to it being forwarded like an authentic frame. With this attack it's possible to e.g. perform portscans, or to get clients to use specific (malicious) DNS servers.

[[File:Fragexample.png|500px|Example for a Mixed Key Attack]]

The other type of FragAttacks targets the fragmentation. One variant of this is the Mixed Key Attack, which exploits flaws in the 802.11 standard, since it's not required, that multiple fragments of a frame are encrypted using the same key. This attack requires, that the keys are renewed regularly, be performing a full 4-Way-Handshake. The victim has to access data on the server of an attacker (e.g. through social engineering), which is hosted on a long URL. This leads to the frame being fragmented. The attacker intercepts these fragments and only forwards the first (with packet number n) to the access point, which encrypts it, recognizes it needs to wait for the other fragments, and stores it. At a later time, the keys are renewed and the package number is reset. When the client then sends a fragment with the packet number n+1, the attacker forwards this fragment to the AP, which then combines the previous stored fragment with the new fragment, and forwards it. This could lead to sending login data (meant for a normal website) to the server of the attacker. See the picture above for a simplified example.

=== Dragonblood ===
Dragonblood is a set of attacks targeting the Dragonfly Handshake of WPA3. All of them require that the attacker is in close range of the Client or the Access Point. Depending on which of these devices is attacked, the attacker has to pretend to be the other.

As mentioned above, downgrade attacks to force WPA2 instead of WPA3 are recognized during the 4-Way-Handshake. However, at this point the client has already sent enough encrypted data, to allow an attacker to perform a dictionary attack based on this data. This leads to one of the advantages of WPA3 being bypassed. To do this, a fake WPA2-network with the same SSID as the original network has to be created. Depending on the specific implementation, clients even try to connect to the fake network, although the original network doesn't support WPA2.

Another type of a Dragonblood attack targets the possibility, that Client and AP negotiate which elliptic curve is used for the handshake. The client sends the access point their desired curve. If the AP doesn't support this curve, it responds with a message stating so, leading to the client select another curve from it's list. This is repeated until a curve supported by both devices is found. The message that the AP doesn't support a curve is not verified, therefore it can be forged to force them to use a weaker curve (downgrade attack). This can also be used to perform an upgrade attack, leading to a denial of service on devices with low computational power.

== Tools ==

A description of how aircrack-ng (a popular program suite for WiFi network security) can be used to crack the Pre Shared Key after capturing the 4-Way-Handshake can be found in the article: [[WiFi Sniffing]]

== References ==

* https://www.krackattacks.com/
* https://www.fragattacks.com/
* https://wpa3.mathyvanhoef.com/

[[Category:Basic]]

File:WiFiFrameAufbau.png

2023-01-08T18:04:48Z

LPutz:

WiFi Security

2023-01-08T18:03:13Z

LPutz:

== Summary ==

This documentation explains the basics of WiFi Security, specifically the protocols WPA2 and WPA3 and their respective handshakes. It also explains the possibility of frame aggregation and fragmentation, as well as some attacks on these concepts.

== Basics ==

=== WPA2 ===
WPA2 (WiFi Protected Access 2) is specified in the IEEE 802.11i standard. It is the successor of WPA, which was based on an unfinished version of the IEEE 802.11i standard. This was done because the previously used WEP (Wired Equivalent Privacy) protocol was found to be insecure. WPA2 (and also WPA) uses the 4-Way-Handshake when a client connects to a network to create multiple keys, which are used to encrypt the communication between client (supplicant) and access point (authenticator). The handshake is based on a "Pairwise Master Key" (PMK), which is based on the Pre-Shared Key (PSK), the password you enter on a client to connect to a WiFi network. The 4-Way-Handshake consists of the following steps:

[[File:4way.png|500px|4 Way Handshake]]

# The access point generates a random number (ANonce - Authenticator Nonce), and sends it to the client.
# The client also generates a random number (SNonce - Supplicant Nonce), and sends it to the access point, using the same value for the replay counter as the first message.
# The AP sends the group temporal key (GTK) to the client.
# The client confirms that the GTK was received.

After the 2. message, both, AP and client, have the needed information to calculate the Pairwise Transient Key (PTK), which is used to encrypt unicast messages between them. This PTK is based on the PMK, ANonce, SNonce and MAC adresses of both devices, and is therefore unique for each AP/client-combination.
The GTK is used to encrypt multicast messages and therefore the same for every client in the network. This GTK is renewed regularly by sending the messages 3 and 4 again.

After sending message 4, the client installs the PTK and GTK, meaning they are being used now. The AP also installs the PTK (the GTK was already installed).

For the encryption WPA2 allows TKIP, CCMP (counter mode with CBC-MAC protocol) and GCMP (galois counter mode protocol). The support of CCMP is mandatory in the WPA2 standard. CCMP is based on AES and is secure, if no IV (initialization vector) is repeated. The IV contains the MAC-address of the sender, a Nonce, which is increased with every message, and some other information transmitted in the WiFi frame. GCMP, also based on AES, is also considered secure, if no IV is used again. Here the IV only contains the sender-MAC-address and the nonce. In both protocols, the nonce is also used as a replay counter and initialized with 0, when the PTK gets installed.

=== WPA3 ===
The publication of the KRACK attacks lead to the release of WPA3. This uses the Dragonfly Handshake to provide forward secrecy and prevent dictionary attacks. It is possible to use WPA2 and WPA3 simultaneously in a network, however WPA3 clients are required to use WPA3 when it's available. If the messages, that the network supports WPA3 are manipulated and the client wants to use WPA2 instead, this is recognized during the 4-Way-Handshake, therefore preventing downgrade attacks. The Dragonfly variant used in WPA3 is also called Simultaneous Authentication of Equals (SAE). It uses elliptic curve cryptography to generate a key based on a password. This key is then used for the 4-Way-Handshake. Due to it's much higher entropy (compared to a password), it prevents dictionary attacks. Before the handshake starts, the password is converted to a group element P, by generating hashes of the password, IDs of Client and AP, and an increasing value. This is repeated until the result is a group element (in elliptic curve cryptography a point on the curve), but at least 40 times.

[[File:Dragonfly.png|500px|Dragonfly Handshake]]

The dragonfly handshake consists of two phases: Commit Phase and Confirm Phase. In the Commit Phase both (Client and AP) pick two random numbers r and m in the range [2, q[ with q being the order of the used group, and calculate s = (r+m) mod q and E = -m * P (P is the previously calculated group element). The next step is to send s and E to the communcation partner (Client->AP and AP->client) and to confirm that the received values are in a valid range, aborting the handshake otherwise.
In the Confirm Phase a secret point K on the curve is calculated: K = r1 * (s2 * P + E2). r1 is the own chosen value r, while s2 and E2 are the received values s and E. The hash of this point K leads to the key k. Finally, an HMAC consisting of k, s1, E1, s2 and E2 is calculated and sent between the devices. If the value is correct, k is successfully chosen as key, which is then used for the 4-Way-Handshake.

=== Frame Aggregation and Fragmentation ===
In WiFi the data is transmitted in so called Frames. To increase the efficiency of the transmission, it is possible to send multiple packets in one frame (aggreation), or to separate a (too) large packet into multiple frames (fragmentation). To to this, a frame contains a Frame Control Field, which specifies the type of the frame with multiple flags. The frame also contains MAC-adresses to specify the receiver and sender of the frame, as well as the source or destionation. Furthermore, fields to specify the fragment- and sequence-number, and the QoS (Quality of Service) field are included. At the end, the actual transmitted data, called payload, is located. If the payload is small, multiple packets are aggregated into a large frame called A-MSDU (Aggregate MAC Service Data Units). This is marked by a flag in the QoS field, however this flag is not authenticated and can be changed by an attacker. The multiple payloads are called subframes, containing source- and destionation-MAC-Address, packet-length and the actual data.
The second possibility (fragmentation) is used, when the payload is too large for a single frame, but also in noisy environments. In the latter case this leads to an increased performance, because in the case of transmission errors, only a part of the data has to be transmitted again. It is possible to use up to 16 fragments, which have an incremental fragment-number and the same sequence-number.

== Attacks ==

=== KRACK ===
Key Reinstallation Attacks are based on repeated installation of keys (see explanation of the 4-Way-Handshake), which leads to the Nonce resetting to 0, and therefore reusing an IV.

When the messages 2 and 4 of the 4-Way-Handhake are not received, the messages 1 and 3 are sent again. The IEEE 802.11i standard also states, that client should immediately install the keys after receiving message 3. In KRACK, the message 4 is intercepted, so the AP doesn't receive it. The client doesn't know about this and starts sending encrypted messages. When the access point sends the message 3 again, the client reinstalls the keys, resets the Nonce, and starts sending encrypted messages again. Since the IVs are reused now, the encryption is no longer considered secure.

=== FragAttacks ===
Fragmentation and Aggregation Attacks affect the above mentioned possibilites of fragmenting and aggregating frames.

To attack the aggregation, the frame has to be intercepted and the A-MSDU flag modified, to make normal frames look like aggregated frames. The payload has to contain specific values, so the subframe contains the desired values. This is done by making the client perform a POST-request with specific data (e.g. on a malicious website of the attacker). If chosen correctly, the data will be interpreted as correct subframe, leading to it being forwarded like an authentic frame. With this attack it's possible to e.g. perform portscans, or to get clients to use specific (malicious) DNS servers.

[[File:Fragexample.png|500px|Example for a Mixed Key Attack]]

The other type of FragAttacks targets the fragmentation. One variant of this is the Mixed Key Attack, which exploits flaws in the 802.11 standard, since it's not required, that multiple fragments of a frame are encrypted using the same key. This attack requires, that the keys are renewed regularly, be performing a full 4-Way-Handshake. The victim has to access data on the server of an attacker (e.g. through social engineering), which is hosted on a long URL. This leads to the frame being fragmented. The attacker intercepts these fragments and only forwards the first (with packet number n) to the access point, which encrypts it, recognizes it needs to wait for the other fragments, and stores it. At a later time, the keys are renewed and the package number is reset. When the client then sends a fragment with the packet number n+1, the attacker forwards this fragment to the AP, which then combines the previous stored fragment with the new fragment, and forwards it. This could lead to sending login data (meant for a normal website) to the server of the attacker. See the picture above for a simplified example.

=== Dragonblood ===
Dragonblood is a set of attacks targeting the Dragonfly Handshake of WPA3. All of them require that the attacker is in close range of the Client or the Access Point. Depending on which of these devices is attacked, the attacker has to pretend to be the other.

As mentioned above, downgrade attacks to force WPA2 instead of WPA3 are recognized during the 4-Way-Handshake. However, at this point the client has already sent enough encrypted data, to allow an attacker to perform a dictionary attack based on this data. This leads to one of the advantages of WPA3 being bypassed. To do this, a fake WPA2-network with the same SSID as the original network has to be created. Depending on the specific implementation, clients even try to connect to the fake network, although the original network doesn't support WPA2.

Another type of a Dragonblood attack targets the possibility, that Client and AP negotiate which elliptic curve is used for the handshake. The client sends the access point their desired curve. If the AP doesn't support this curve, it responds with a message stating so, leading to the client select another curve from it's list. This is repeated until a curve supported by both devices is found. The message that the AP doesn't support a curve is not verified, therefore it can be forged to force them to use a weaker curve (downgrade attack). This can also be used to perform an upgrade attack, leading to a denial of service on devices with low computational power.

== Tools ==

A description of how aircrack-ng (a popular program suite for WiFi network security) can be used to crack the Pre Shared Key after capturing the 4-Way-Handshake can be found in the article: [[WiFi Sniffing]]

== References ==

* https://www.krackattacks.com/
* https://www.fragattacks.com/
* https://wpa3.mathyvanhoef.com/

[[Category:Basic]]

File:Dragonfly.png

2023-01-08T18:02:19Z

LPutz:

WiFi Security

2023-01-08T17:53:56Z

LPutz:

== Summary ==

This documentation explains the basics of WiFi Security, specifically the protocols WPA2 and WPA3 and their respective handshakes. It also explains the possibility of frame aggregation and fragmentation, as well as some attacks on these concepts.

== Basics ==

=== WPA2 ===
WPA2 (WiFi Protected Access 2) is specified in the IEEE 802.11i standard. It is the successor of WPA, which was based on an unfinished version of the IEEE 802.11i standard. This was done because the previously used WEP (Wired Equivalent Privacy) protocol was found to be insecure. WPA2 (and also WPA) uses the 4-Way-Handshake when a client connects to a network to create multiple keys, which are used to encrypt the communication between client (supplicant) and access point (authenticator). The handshake is based on a "Pairwise Master Key" (PMK), which is based on the Pre-Shared Key (PSK), the password you enter on a client to connect to a WiFi network. The 4-Way-Handshake consists of the following steps:

[[File:4way.png|500px|4 Way Handshake]]

# The access point generates a random number (ANonce - Authenticator Nonce), and sends it to the client.
# The client also generates a random number (SNonce - Supplicant Nonce), and sends it to the access point, using the same value for the replay counter as the first message.
# The AP sends the group temporal key (GTK) to the client.
# The client confirms that the GTK was received.

After the 2. message, both, AP and client, have the needed information to calculate the Pairwise Transient Key (PTK), which is used to encrypt unicast messages between them. This PTK is based on the PMK, ANonce, SNonce and MAC adresses of both devices, and is therefore unique for each AP/client-combination.
The GTK is used to encrypt multicast messages and therefore the same for every client in the network. This GTK is renewed regularly by sending the messages 3 and 4 again.

After sending message 4, the client installs the PTK and GTK, meaning they are being used now. The AP also installs the PTK (the GTK was already installed).

For the encryption WPA2 allows TKIP, CCMP (counter mode with CBC-MAC protocol) and GCMP (galois counter mode protocol). The support of CCMP is mandatory in the WPA2 standard. CCMP is based on AES and is secure, if no IV (initialization vector) is repeated. The IV contains the MAC-address of the sender, a Nonce, which is increased with every message, and some other information transmitted in the WiFi frame. GCMP, also based on AES, is also considered secure, if no IV is used again. Here the IV only contains the sender-MAC-address and the nonce. In both protocols, the nonce is also used as a replay counter and initialized with 0, when the PTK gets installed.

=== WPA3 ===
The publication of the KRACK attacks lead to the release of WPA3. This uses the Dragonfly Handshake to provide forward secrecy and prevent dictionary attacks. It is possible to use WPA2 and WPA3 simultaneously in a network, however WPA3 clients are required to use WPA3 when it's available. If the messages, that the network supports WPA3 are manipulated and the client wants to use WPA2 instead, this is recognized during the 4-Way-Handshake, therefore preventing downgrade attacks. The Dragonfly variant used in WPA3 is also called Simultaneous Authentication of Equals (SAE). It uses elliptic curve cryptography to generate a key based on a password. This key is then used for the 4-Way-Handshake. Due to it's much higher entropy (compared to a password), it prevents dictionary attacks. Before the handshake starts, the password is converted to a group element P, by generating hashes of the password, IDs of Client and AP, and an increasing value. This is repeated until the result is a group element (in elliptic curve cryptography a point on the curve), but at least 40 times.

The dragonfly handshake consists of two phases: Commit Phase and Confirm Phase. In the Commit Phase both (Client and AP) pick two random numbers r and m in the range [2, q[ with q being the order of the used group, and calculate s = (r+m) mod q and E = -m * P (P is the previously calculated group element). The next step is to send s and E to the communcation partner (Client->AP and AP->client) and to confirm that the received values are in a valid range, aborting the handshake otherwise.
In the Confirm Phase a secret point K on the curve is calculated: K = r1 * (s2 * P + E2). r1 is the own chosen value r, while s2 and E2 are the received values s and E. The hash of this point K leads to the key k. Finally, an HMAC consisting of k, s1, E1, s2 and E2 is calculated and sent between the devices. If the value is correct, k is successfully chosen as key, which is then used for the 4-Way-Handshake.

=== Frame Aggregation and Fragmentation ===
In WiFi the data is transmitted in so called Frames. To increase the efficiency of the transmission, it is possible to send multiple packets in one frame (aggreation), or to separate a (too) large packet into multiple frames (fragmentation). To to this, a frame contains a Frame Control Field, which specifies the type of the frame with multiple flags. The frame also contains MAC-adresses to specify the receiver and sender of the frame, as well as the source or destionation. Furthermore, fields to specify the fragment- and sequence-number, and the QoS (Quality of Service) field are included. At the end, the actual transmitted data, called payload, is located. If the payload is small, multiple packets are aggregated into a large frame called A-MSDU (Aggregate MAC Service Data Units). This is marked by a flag in the QoS field, however this flag is not authenticated and can be changed by an attacker. The multiple payloads are called subframes, containing source- and destionation-MAC-Address, packet-length and the actual data.
The second possibility (fragmentation) is used, when the payload is too large for a single frame, but also in noisy environments. In the latter case this leads to an increased performance, because in the case of transmission errors, only a part of the data has to be transmitted again. It is possible to use up to 16 fragments, which have an incremental fragment-number and the same sequence-number.

== Attacks ==

=== KRACK ===
Key Reinstallation Attacks are based on repeated installation of keys (see explanation of the 4-Way-Handshake), which leads to the Nonce resetting to 0, and therefore reusing an IV.

When the messages 2 and 4 of the 4-Way-Handhake are not received, the messages 1 and 3 are sent again. The IEEE 802.11i standard also states, that client should immediately install the keys after receiving message 3. In KRACK, the message 4 is intercepted, so the AP doesn't receive it. The client doesn't know about this and starts sending encrypted messages. When the access point sends the message 3 again, the client reinstalls the keys, resets the Nonce, and starts sending encrypted messages again. Since the IVs are reused now, the encryption is no longer considered secure.

=== FragAttacks ===
Fragmentation and Aggregation Attacks affect the above mentioned possibilites of fragmenting and aggregating frames.

To attack the aggregation, the frame has to be intercepted and the A-MSDU flag modified, to make normal frames look like aggregated frames. The payload has to contain specific values, so the subframe contains the desired values. This is done by making the client perform a POST-request with specific data (e.g. on a malicious website of the attacker). If chosen correctly, the data will be interpreted as correct subframe, leading to it being forwarded like an authentic frame. With this attack it's possible to e.g. perform portscans, or to get clients to use specific (malicious) DNS servers.

[[File:Fragexample.png|500px|Example for a Mixed Key Attack]]

The other type of FragAttacks targets the fragmentation. One variant of this is the Mixed Key Attack, which exploits flaws in the 802.11 standard, since it's not required, that multiple fragments of a frame are encrypted using the same key. This attack requires, that the keys are renewed regularly, be performing a full 4-Way-Handshake. The victim has to access data on the server of an attacker (e.g. through social engineering), which is hosted on a long URL. This leads to the frame being fragmented. The attacker intercepts these fragments and only forwards the first (with packet number n) to the access point, which encrypts it, recognizes it needs to wait for the other fragments, and stores it. At a later time, the keys are renewed and the package number is reset. When the client then sends a fragment with the packet number n+1, the attacker forwards this fragment to the AP, which then combines the previous stored fragment with the new fragment, and forwards it. This could lead to sending login data (meant for a normal website) to the server of the attacker. See the picture above for a simplified example.

=== Dragonblood ===
Dragonblood is a set of attacks targeting the Dragonfly Handshake of WPA3. All of them require that the attacker is in close range of the Client or the Access Point. Depending on which of these devices is attacked, the attacker has to pretend to be the other.

As mentioned above, downgrade attacks to force WPA2 instead of WPA3 are recognized during the 4-Way-Handshake. However, at this point the client has already sent enough encrypted data, to allow an attacker to perform a dictionary attack based on this data. This leads to one of the advantages of WPA3 being bypassed. To do this, a fake WPA2-network with the same SSID as the original network has to be created. Depending on the specific implementation, clients even try to connect to the fake network, although the original network doesn't support WPA2.

Another type of a Dragonblood attack targets the possibility, that Client and AP negotiate which elliptic curve is used for the handshake. The client sends the access point their desired curve. If the AP doesn't support this curve, it responds with a message stating so, leading to the client select another curve from it's list. This is repeated until a curve supported by both devices is found. The message that the AP doesn't support a curve is not verified, therefore it can be forged to force them to use a weaker curve (downgrade attack). This can also be used to perform an upgrade attack, leading to a denial of service on devices with low computational power.

== Tools ==

A description of how aircrack-ng (a popular program suite for WiFi network security) can be used to crack the Pre Shared Key after capturing the 4-Way-Handshake can be found in the article: [[WiFi Sniffing]]

== References ==

* https://www.krackattacks.com/
* https://www.fragattacks.com/
* https://wpa3.mathyvanhoef.com/

[[Category:Basic]]

File:Fragexample.png

2023-01-08T17:51:03Z

LPutz:

File:4way.png

2023-01-08T17:47:35Z

LPutz:

WiFi Security

2023-01-08T17:46:31Z

LPutz:

== Summary ==

This documentation explains the basics of WiFi Security, specifically the protocols WPA2 and WPA3 and their respective handshakes. It also explains the possibility of frame aggregation and fragmentation, as well as some attacks on these concepts.

== Basics ==

=== WPA2 ===
WPA2 (WiFi Protected Access 2) is specified in the IEEE 802.11i standard. It is the successor of WPA, which was based on an unfinished version of the IEEE 802.11i standard. This was done because the previously used WEP (Wired Equivalent Privacy) protocol was found to be insecure. WPA2 (and also WPA) uses the 4-Way-Handshake when a client connects to a network to create multiple keys, which are used to encrypt the communication between client (supplicant) and access point (authenticator). The handshake is based on a "Pairwise Master Key" (PMK), which is based on the Pre-Shared Key (PSK), the password you enter on a client to connect to a WiFi network. The 4-Way-Handshake consists of the following steps:

# The access point generates a random number (ANonce - Authenticator Nonce), and sends it to the client.
# The client also generates a random number (SNonce - Supplicant Nonce), and sends it to the access point, using the same value for the replay counter as the first message.
# The AP sends the group temporal key (GTK) to the client.
# The client confirms that the GTK was received.

After the 2. message, both, AP and client, have the needed information to calculate the Pairwise Transient Key (PTK), which is used to encrypt unicast messages between them. This PTK is based on the PMK, ANonce, SNonce and MAC adresses of both devices, and is therefore unique for each AP/client-combination.
The GTK is used to encrypt multicast messages and therefore the same for every client in the network. This GTK is renewed regularly by sending the messages 3 and 4 again.

After sending message 4, the client installs the PTK and GTK, meaning they are being used now. The AP also installs the PTK (the GTK was already installed).

For the encryption WPA2 allows TKIP, CCMP (counter mode with CBC-MAC protocol) and GCMP (galois counter mode protocol). The support of CCMP is mandatory in the WPA2 standard. CCMP is based on AES and is secure, if no IV (initialization vector) is repeated. The IV contains the MAC-address of the sender, a Nonce, which is increased with every message, and some other information transmitted in the WiFi frame. GCMP, also based on AES, is also considered secure, if no IV is used again. Here the IV only contains the sender-MAC-address and the nonce. In both protocols, the nonce is also used as a replay counter and initialized with 0, when the PTK gets installed.

=== WPA3 ===
The publication of the KRACK attacks lead to the release of WPA3. This uses the Dragonfly Handshake to provide forward secrecy and prevent dictionary attacks. It is possible to use WPA2 and WPA3 simultaneously in a network, however WPA3 clients are required to use WPA3 when it's available. If the messages, that the network supports WPA3 are manipulated and the client wants to use WPA2 instead, this is recognized during the 4-Way-Handshake, therefore preventing downgrade attacks. The Dragonfly variant used in WPA3 is also called Simultaneous Authentication of Equals (SAE). It uses elliptic curve cryptography to generate a key based on a password. This key is then used for the 4-Way-Handshake. Due to it's much higher entropy (compared to a password), it prevents dictionary attacks. Before the handshake starts, the password is converted to a group element P, by generating hashes of the password, IDs of Client and AP, and an increasing value. This is repeated until the result is a group element (in elliptic curve cryptography a point on the curve), but at least 40 times.

The dragonfly handshake consists of two phases: Commit Phase and Confirm Phase. In the Commit Phase both (Client and AP) pick two random numbers r and m in the range [2, q[ with q being the order of the used group, and calculate s = (r+m) mod q and E = -m * P (P is the previously calculated group element). The next step is to send s and E to the communcation partner (Client->AP and AP->client) and to confirm that the received values are in a valid range, aborting the handshake otherwise.
In the Confirm Phase a secret point K on the curve is calculated: K = r1 * (s2 * P + E2). r1 is the own chosen value r, while s2 and E2 are the received values s and E. The hash of this point K leads to the key k. Finally, an HMAC consisting of k, s1, E1, s2 and E2 is calculated and sent between the devices. If the value is correct, k is successfully chosen as key, which is then used for the 4-Way-Handshake.

=== Frame Aggregation and Fragmentation ===
In WiFi the data is transmitted in so called Frames. To increase the efficiency of the transmission, it is possible to send multiple packets in one frame (aggreation), or to separate a (too) large packet into multiple frames (fragmentation). To to this, a frame contains a Frame Control Field, which specifies the type of the frame with multiple flags. The frame also contains MAC-adresses to specify the receiver and sender of the frame, as well as the source or destionation. Furthermore, fields to specify the fragment- and sequence-number, and the QoS (Quality of Service) field are included. At the end, the actual transmitted data, called payload, is located. If the payload is small, multiple packets are aggregated into a large frame called A-MSDU (Aggregate MAC Service Data Units). This is marked by a flag in the QoS field, however this flag is not authenticated and can be changed by an attacker. The multiple payloads are called subframes, containing source- and destionation-MAC-Address, packet-length and the actual data.
The second possibility (fragmentation) is used, when the payload is too large for a single frame, but also in noisy environments. In the latter case this leads to an increased performance, because in the case of transmission errors, only a part of the data has to be transmitted again. It is possible to use up to 16 fragments, which have an incremental fragment-number and the same sequence-number.

== Attacks ==

=== KRACK ===
Key Reinstallation Attacks are based on repeated installation of keys (see explanation of the 4-Way-Handshake), which leads to the Nonce resetting to 0, and therefore reusing an IV.

When the messages 2 and 4 of the 4-Way-Handhake are not received, the messages 1 and 3 are sent again. The IEEE 802.11i standard also states, that client should immediately install the keys after receiving message 3. In KRACK, the message 4 is intercepted, so the AP doesn't receive it. The client doesn't know about this and starts sending encrypted messages. When the access point sends the message 3 again, the client reinstalls the keys, resets the Nonce, and starts sending encrypted messages again. Since the IVs are reused now, the encryption is no longer considered secure.

=== FragAttacks ===
Fragmentation and Aggregation Attacks affect the above mentioned possibilites of fragmenting and aggregating frames.

To attack the aggregation, the frame has to be intercepted and the A-MSDU flag modified, to make normal frames look like aggregated frames. The payload has to contain specific values, so the subframe contains the desired values. This is done by making the client perform a POST-request with specific data (e.g. on a malicious website of the attacker). If chosen correctly, the data will be interpreted as correct subframe, leading to it being forwarded like an authentic frame. With this attack it's possible to e.g. perform portscans, or to get clients to use specific (malicious) DNS servers.

The other type of FragAttacks targets the fragmentation. One variant of this is the Mixed Key Attack, which exploits flaws in the 802.11 standard, since it's not required, that multiple fragments of a frame are encrypted using the same key. This attack requires, that the keys are renewed regularly, be performing a full 4-Way-Handshake. The victim has to access data on the server of an attacker (e.g. through social engineering), which is hosted on a long URL. This leads to the frame being fragmented. The attacker intercepts these fragments and only forwards the first (with packet number n) to the access point, which encrypts it, recognizes it needs to wait for the other fragments, and stores it. At a later time, the keys are renewed and the package number is reset. When the client then sends a fragment with the packet number n+1, the attacker forwards this fragment to the AP, which then combines the previous stored fragment with the new fragment, and forwards it. This could lead to sending login data (meant for a normal website) to the server of the attacker.

=== Dragonblood ===
Dragonblood is a set of attacks targeting the Dragonfly Handshake of WPA3. All of them require that the attacker is in close range of the Client or the Access Point. Depending on which of these devices is attacked, the attacker has to pretend to be the other.

As mentioned above, downgrade attacks to force WPA2 instead of WPA3 are recognized during the 4-Way-Handshake. However, at this point the client has already sent enough encrypted data, to allow an attacker to perform a dictionary attack based on this data. This leads to one of the advantages of WPA3 being bypassed. To do this, a fake WPA2-network with the same SSID as the original network has to be created. Depending on the specific implementation, clients even try to connect to the fake network, although the original network doesn't support WPA2.

Another type of a Dragonblood attack targets the possibility, that Client and AP negotiate which elliptic curve is used for the handshake. The client sends the access point their desired curve. If the AP doesn't support this curve, it responds with a message stating so, leading to the client select another curve from it's list. This is repeated until a curve supported by both devices is found. The message that the AP doesn't support a curve is not verified, therefore it can be forged to force them to use a weaker curve (downgrade attack). This can also be used to perform an upgrade attack, leading to a denial of service on devices with low computational power.

== Tools ==

A description of how aircrack-ng (a popular program suite for WiFi network security) can be used to crack the Pre Shared Key after capturing the 4-Way-Handshake can be found in the article: [[WiFi Sniffing]]

== References ==

* https://www.krackattacks.com/
* https://www.fragattacks.com/
* https://wpa3.mathyvanhoef.com/

[[Category:Basic]]

WiFi Security

2023-01-08T17:45:58Z

LPutz: Created page with "== Summary == This documentation explains the basics of WiFi Security, specifically the protocols WPA2 and WPA3 and their respective handshakes. It also explains the possibility of frame aggregation and fragmentation, as well as some attacks on these concepts. == Basics == === WPA2 === WPA2 (WiFi Protected Access 2) is specified in the IEEE 802.11i standard. It is the successor of WPA, which was based on an unfinished version of the IEEE 802.11i standard. This was do..."

== Summary ==

This documentation explains the basics of WiFi Security, specifically the protocols WPA2 and WPA3 and their respective handshakes. It also explains the possibility of frame aggregation and fragmentation, as well as some attacks on these concepts.

== Basics ==

=== WPA2 ===
WPA2 (WiFi Protected Access 2) is specified in the IEEE 802.11i standard. It is the successor of WPA, which was based on an unfinished version of the IEEE 802.11i standard. This was done because the previously used WEP (Wired Equivalent Privacy) protocol was found to be insecure. WPA2 (and also WPA) uses the 4-Way-Handshake when a client connects to a network to create multiple keys, which are used to encrypt the communication between client (supplicant) and access point (authenticator). The handshake is based on a "Pairwise Master Key" (PMK), which is based on the Pre-Shared Key (PSK), the password you enter on a client to connect to a WiFi network. The 4-Way-Handshake consists of the following steps:

# The access point generates a random number (ANonce - Authenticator Nonce), and sends it to the client.
# The client also generates a random number (SNonce - Supplicant Nonce), and sends it to the access point, using the same value for the replay counter as the first message.
# The AP sends the group temporal key (GTK) to the client.
# The client confirms that the GTK was received.

After the 2. message, both, AP and client, have the needed information to calculate the Pairwise Transient Key (PTK), which is used to encrypt unicast messages between them. This PTK is based on the PMK, ANonce, SNonce and MAC adresses of both devices, and is therefore unique for each AP/client-combination.
The GTK is used to encrypt multicast messages and therefore the same for every client in the network. This GTK is renewed regularly by sending the messages 3 and 4 again.

After sending message 4, the client installs the PTK and GTK, meaning they are being used now. The AP also installs the PTK (the GTK was already installed).

For the encryption WPA2 allows TKIP, CCMP (counter mode with CBC-MAC protocol) and GCMP (galois counter mode protocol). The support of CCMP is mandatory in the WPA2 standard. CCMP is based on AES and is secure, if no IV (initialization vector) is repeated. The IV contains the MAC-address of the sender, a Nonce, which is increased with every message, and some other information transmitted in the WiFi frame. GCMP, also based on AES, is also considered secure, if no IV is used again. Here the IV only contains the sender-MAC-address and the nonce. In both protocols, the nonce is also used as a replay counter and initialized with 0, when the PTK gets installed.

=== WPA3 ===
The publication of the KRACK attacks lead to the release of WPA3. This uses the Dragonfly Handshake to provide forward secrecy and prevent dictionary attacks. It is possible to use WPA2 and WPA3 simultaneously in a network, however WPA3 clients are required to use WPA3 when it's available. If the messages, that the network supports WPA3 are manipulated and the client wants to use WPA2 instead, this is recognized during the 4-Way-Handshake, therefore preventing downgrade attacks. The Dragonfly variant used in WPA3 is also called Simultaneous Authentication of Equals (SAE). It uses elliptic curve cryptography to generate a key based on a password. This key is then used for the 4-Way-Handshake. Due to it's much higher entropy (compared to a password), it prevents dictionary attacks. Before the handshake starts, the password is converted to a group element P, by generating hashes of the password, IDs of Client and AP, and an increasing value. This is repeated until the result is a group element (in elliptic curve cryptography a point on the curve), but at least 40 times.

The dragonfly handshake consists of two phases: Commit Phase and Confirm Phase. In the Commit Phase both (Client and AP) pick two random numbers r and m in the range [2, q[ with q being the order of the used group, and calculate s = (r+m) mod q and E = -m * P (P is the previously calculated group element). The next step is to send s and E to the communcation partner (Client->AP and AP->client) and to confirm that the received values are in a valid range, aborting the handshake otherwise.
In the Confirm Phase a secret point K on the curve is calculated: K = r1 * (s2 * P + E2). r1 is the own chosen value r, while s2 and E2 are the received values s and E. The hash of this point K leads to the key k. Finally, an HMAC consisting of k, s1, E1, s2 and E2 is calculated and sent between the devices. If the value is correct, k is successfully chosen as key, which is then used for the 4-Way-Handshake.

=== Frame Aggregation and Fragmentation ===
In WiFi the data is transmitted in so called Frames. To increase the efficiency of the transmission, it is possible to send multiple packets in one frame (aggreation), or to separate a (too) large packet into multiple frames (fragmentation). To to this, a frame contains a Frame Control Field, which specifies the type of the frame with multiple flags. The frame also contains MAC-adresses to specify the receiver and sender of the frame, as well as the source or destionation. Furthermore, fields to specify the fragment- and sequence-number, and the QoS (Quality of Service) field are included. At the end, the actual transmitted data, called payload, is located. If the payload is small, multiple packets are aggregated into a large frame called A-MSDU (Aggregate MAC Service Data Units). This is marked by a flag in the QoS field, however this flag is not authenticated and can be changed by an attacker. The multiple payloads are called subframes, containing source- and destionation-MAC-Address, packet-length and the actual data.
The second possibility (fragmentation) is used, when the payload is too large for a single frame, but also in noisy environments. In the latter case this leads to an increased performance, because in the case of transmission errors, only a part of the data has to be transmitted again. It is possible to use up to 16 fragments, which have an incremental fragment-number and the same sequence-number.

== Attacks ==

=== KRACK ===
Key Reinstallation Attacks are based on repeated installation of keys (see explanation of the 4-Way-Handshake), which leads to the Nonce resetting to 0, and therefore reusing an IV.

When the messages 2 and 4 of the 4-Way-Handhake are not received, the messages 1 and 3 are sent again. The IEEE 802.11i standard also states, that client should immediately install the keys after receiving message 3. In KRACK, the message 4 is intercepted, so the AP doesn't receive it. The client doesn't know about this and starts sending encrypted messages. When the access point sends the message 3 again, the client reinstalls the keys, resets the Nonce, and starts sending encrypted messages again. Since the IVs are reused now, the encryption is no longer considered secure.

=== FragAttacks ===
Fragmentation and Aggregation Attacks affect the above mentioned possibilites of fragmenting and aggregating frames.

To attack the aggregation, the frame has to be intercepted and the A-MSDU flag modified, to make normal frames look like aggregated frames. The payload has to contain specific values, so the subframe contains the desired values. This is done by making the client perform a POST-request with specific data (e.g. on a malicious website of the attacker). If chosen correctly, the data will be interpreted as correct subframe, leading to it being forwarded like an authentic frame. With this attack it's possible to e.g. perform portscans, or to get clients to use specific (malicious) DNS servers.

The other type of FragAttacks targets the fragmentation. One variant of this is the Mixed Key Attack, which exploits flaws in the 802.11 standard, since it's not required, that multiple fragments of a frame are encrypted using the same key. This attack requires, that the keys are renewed regularly, be performing a full 4-Way-Handshake. The victim has to access data on the server of an attacker (e.g. through social engineering), which is hosted on a long URL. This leads to the frame being fragmented. The attacker intercepts these fragments and only forwards the first (with packet number n) to the access point, which encrypts it, recognizes it needs to wait for the other fragments, and stores it. At a later time, the keys are renewed and the package number is reset. When the client then sends a fragment with the packet number n+1, the attacker forwards this fragment to the AP, which then combines the previous stored fragment with the new fragment, and forwards it. This could lead to sending login data (meant for a normal website) to the server of the attacker.

=== Dragonblood ===
Dragonblood is a set of attacks targeting the Dragonfly Handshake of WPA3. All of them require that the attacker is in close range of the Client or the Access Point. Depending on which of these devices is attacked, the attacker has to pretend to be the other.

As mentioned above, downgrade attacks to force WPA2 instead of WPA3 are recognized during the 4-Way-Handshake. However, at this point the client has already sent enough encrypted data, to allow an attacker to perform a dictionary attack based on this data. This leads to one of the advantages of WPA3 being bypassed. To do this, a fake WPA2-network with the same SSID as the original network has to be created. Depending on the specific implementation, clients even try to connect to the fake network, although the original network doesn't support WPA2.

Another type of a Dragonblood attack targets the possibility, that Client and AP negotiate which elliptic curve is used for the handshake. The client sends the access point their desired curve. If the AP doesn't support this curve, it responds with a message stating so, leading to the client select another curve from it's list. This is repeated until a curve supported by both devices is found. The message that the AP doesn't support a curve is not verified, therefore it can be forged to force them to use a weaker curve (downgrade attack). This can also be used to perform an upgrade attack, leading to a denial of service on devices with low computational power.

== Tools ==

A description of how aircrack-ng (a popular program suite for WiFi network security) can be used to crack the Pre Shared Key after capturing the 4-Way-Handshake can be found in the article: [[WiFi Sniffing]]

== References ==

* https://www.krackattacks.com/
* https://www.fragattacks.com/
* https://wpa3.mathyvanhoef.com/

[[Category:Basics]]

Hak5 Signal Owl

2022-12-12T12:33:30Z

LPutz: /* References */

== Summary ==

The [https://docs.hak5.org/hc/en-us/categories/360002117953-Signal-Owl Signal Owl] is a hardware product developed by the company Hak5.
It is a simple payload-based signals intelligence platform with a unique design for discreet planting or mobile operations on any engagement. The most popular application cases include classic network mapping and basic penetration tests for various wireless technologies.

== Description ==

[[File:SignalOwlDiagram.png|thumb|500px|frame|Components of the Signal Owl [Eigene Darstellung]]]

The Signal Owl is designed to be rapidly deployed in all kinds of environments, allowing it to be an entry point for network analysis and basic wireless attacks in a variety of locations. With a power consumption of 100-200 mAh and the thermally optimized architecture, mobile operations as well as long term deployments, are enabled.

=== Components ===

This device features several components of which some may not be visible to the human eye at first sight.

==== USB Power / Passthrough Plug ====

The USB power or passthrough plug is used to power the device. It can be powered from any reliable USB source.

==== USB 2.0 Passthrough Port ====

The USB 2.0 passthrough port is the port closest to the pigtail. Data and power pass through to that port, allowing for implant operations. With devices like keyboards plugged plugged inline between this passthrough port and the power plug connected to the target computer, the Signal Owl will remain undetected from the operating system. Only the keyboard will be visible.

==== USB 2.0 Host Port ====

The USB 2.0 host port is the port farthest away from the pigtail. It is connected to the Linux socket of the Signal Owl and supports USB flash drives formatted with FAT32 and EXT4 file systems as well as many Wi-Fi, Bluetooth and other RF transceivers.

==== Button ====

The button on the bottom of the device is used to enter Arming Mode and to interact with payloads. It is not pressable without special tools like paperclips.

==== Status LED ====

The status LED indicates the current status of the Signal Owl. When turned off, it is not visible.

=== Implant / mobile operations ===

'''Implant operations
'''

During long term wireless engagements, the Signal Owl may be planted inline between any typical 5V USB power source. This may be useful in situations where ports are occupied, or to deter the unit from being unplugged.

'''Mobile operations
'''

The Signal Owl features a low power consumption profile, with a typical power draw averaging 100-200 mAh. Additionally, it is thermally optimized for long term deployments in many indoor environments. One can expect a large 20,000 mAh USB battery bank to operate the unit for up to 4 days.

=== Default Settings ===

Default settings that are used in order to access the device via SSH are pictured in the table below.

{| class="wikitable"
!colspan="2"|Default Settings
|-
|Username
|root
|-
|Password
|hak5owl
|-
|SSID
|Owl_xxxx
|-
|IP Address
|172.16.56.1
|-
|SSH command
|ssh root@172.16.56.1
|}

The SSID during Arming Mode is Owl_xxxx in which xxxx indicates the last two octets of the devices MAC address.

=== LED Status Indications ===

The Signal Owl features a red LED with the following default status indications:

{| class="wikitable"
!|LED
!|Status
|-
|Blinking
|Booting
|-
|Solid
|Mounting external storage / Running upgrade
|-
|Single blinking
|Attack Mode
|-
|Double blinking
|Arming Mode
|-
|Slow blinking
|Error running payload
|}

=== Modes of Operation ===

The Signal Owl comes with two modes of operation, Attack Mode and Arming Mode. By default, the device will boot into Attack Mode. In order to access Arming Mode, the button on the bottom of the device has to be pressed while in Attack Mode. It is not recommended to press the button during the boot sequence as this can possibly brick the device and render it useless. The arming mode is used for firmware updates and shell access, while the attack mode is used to load and execute the payload.

==== Attack Mode ====

Attack Mode is the default mode, the Signal Owl boots into. It provides two basic functions, being the payload loading function and the payload execution function. The payload loading function checks for any USB flash drives plugged into the host port of the device and copies payloads and extensions to the root of the Signal Owl. The payload execution function is responsible for executing the payload that is currently stored on the root of the Signal Owl. In case no payload is found, the device will blink slowly, indicating the FAIL status.

==== Arming Mode ====

The Arming Mode provides two basic functions, being the firmware update function and the shell access function. The firmware update function checks for any USB flash drives plugged into the host port of the device and copies firmware upgrade files into the internal storage of the device and flashes it. The shell access function starts an open access point with the SSID Owl_xxxx in which xxxx indicates the last two octets of the devices MAC address. Additionally, a SSH server providing access to the shell of the Signal Owl is enabled.

=== Initial Setup ===

When first unboxing the Signal Owl, the device runs a stager firmware that is designed to flash the latest firmware from a USB flash drive. In order to update the Signal Owl, the [https://downloads.hak5.org/owl latest firmware] has to be downloaded. Then, the downloaded file must be copied to the root of an EXT4 or FAT32 formatted USB flash drive. It is important not to modify this file. The next step is to plug the USB flash drive into the powered off Signal Owl. Afterwards, the device has to be powered on by a reliable USB source. The upgrade itself takes approximately five to ten minutes and is indicated by a solid red LED light. When finished, the device will reboot, enter Attack Mode and blink slowly, indicating an error running the payload because no payload has been found.

=== Payload Development ===

Payloads for the Signal Owl are written in bash with [https://github.com/hak5darren/USB-Rubber-Ducky/wiki/Duckyscript Ducky Script] and can be created with any standard text editor. All payloads should begin with an interpreter directive, like the shebang #!/bin/bash for bash payloads and payloads must be named either payload.txt or payload.sh. In order to create effective payloads, the Signal Owl comes with several preinstalled penetration testing tools. These are as follows: [https://nmap.org/ Nmap], [https://www.aircrack-ng.org/ Aircrack-ng], [https://github.com/aircrack-ng/mdk4 MDK4] and [https://www.kismetwireless.net/ Kismet].

'''Tools'''

• Kismet - detector for wireless networks and devices.

• MDK4 - Wi-Fi testing tool.

• Aircrack-ng Suite - a complete suite of tools for WiFi network security assessment.

• Nmap - open source utility for network discovery and security auditing.

=== Adding Payloads and Extensions ===

Payloads can be stored on the internal storage of the Signal Owl as well as on a USB flash drive. When booting, payloads on USB flash drives are given priority and will override payloads stored on the Signal Owl. If no payload is found on the external storage and a payload is present on the internal storage, the internally stored payload will be executed. In case no payload is found on both internal and external storage, the Signal Owl will blink slowly. To successfully copy a payload to the Signal Owl and execute it, the payload must be named payload.txt or payload.sh and it has to be placed in the root directory of the flash drive. Similarly, payload extensions should be stored in a /extensions directory on the flash drive.

After plugging the Signal Owl into a USB source, it will boot and then copy the payloads and payload extensions to the /root/payload and /root/payload/extensions directory respectively. Then, the device will enter Attack Mode and execute the payload.

== Fake Beacon Flooding Attack ==

The fake beacon flooding attack is one possible use case for the Signal Owl. With that attack, fake beacon frames are broadcasted to nearby devices. Beacon Frames include various parameters like the SSID, the type of encryption used and timestamps. This results in the creation of multiple fake Wi-Fi networks. Devices with Wi-Fi browsers are then flooded with these fake networks, causing potential network scanner and driver crashes. Furthermore, the attack may prevent legitimate users from finding their networks and lead to denial of service.
To execute the attack with the Signal Owl, the preinstalled tools Aircrack-ng and MDK4 are used. The following bash script is saved as payload.sh and placed on the root of an USB flash drive. Then the USB flash drive is plugged into the Signal Owl. After powering on the device, multiple fake networks with random SSIDs are generated and broadcasted to all nearby devices.

<pre>
#!/bin/bash

LED SETUP
#creates monitor mode interface on wirelss card of the Signal Owl
airmon-ng start wlan0

LED ATTACK
#floods nearby devices with random SSIDs
mdk4 wlan0mon b -w a -m -s 1000
</pre>

The results as seen from a victim running a Windows 10 system are pictured in the figure below.

[[File:FakeBeaconFloodingSignalOwl.png|none|Random SSIDs as seen from a victim windows 10 client |]][Eigene Darstellung]

== Open AP Nmap Scanner ==

Description: First access points are scanned, then a connection is established to the open access points, after connecting, the nmap scan runs and analyses the AP,
the results are saved in the loot folder.

Settings

NMAP_OPTIONS="-sP"

LOOT_DIR=/root/loot/open_ap_nmap_scan

MAX_CIDR=20

DEBUG=1

Step-by-step guide

1) download the payload [https://github.com/hak5/signalowl-payloads/blob/master/payloads/library/wifi/Open-AP-Nmap-Scanner/payload.txt payload]
2) store the payload in a usb stick and plug the stick into the signal owl
3) after connecting the signal owl, the payload is loaded on the root folder and the scan starts.
4) once successfully executed, you can start the signal owl in arming mode and see the results in the loot folder.
example loot Directory
[[File:ArmingmodeSSHloot.png [Eigene Darstellung]]]

== Arming Mode connection ==

Step-by-step guide for accessing the arming mode
1) click on the button located on the bottom of the signal owl while it is in attack mode. After pressing the button, the signal owl enters the arming
mode and provides an open access point with the name Owl xxxx (where xxxx stands for the last two digits of the MAC address of the device).
2) Connect to the access point.
[[File:Armingmode.png]][Eigene Darstellung]
3) Now you can connect via ssh by using the username and password (default: Username: root, Password: hak5owl, IP Address: 172.16.56.1)
4) after successful connection you will end up in root@Owl directory
[[File:ArmingmodeSSH.png]][Eigene Darstellung]
5) Now you can enter the directories loot and payload to either view the results or to make further settings

example Directory structure
[[File:ArmingmodeSSHdirectories.png]][Eigene Darstellung]

== Use Cases ==

The Signal Owl has a variety of different use cases. Among the most popular ones are classical network mapping and wardriving as well as basic penetration tests for different wireless technologies.

== Used Hardware ==

[[Signal Owl]]

== References ==

* https://docs.hak5.org/signal-owl/
*https://github.com/hak5/signalowl-payloads

[[Category:Pentesting]]

Jetson AGX Xavier Development Kit: Setup

2022-07-25T19:30:47Z

LPutz:

== Summary ==

This is a guide to set up the [[Jetson AGX Xavier Development Kit]]. After this guide the user will be able to connect with SSH and VNC.
This guide will also show the installation process of TensorFlow and Keras for AI-Research purposes.

== Requirements ==

* Operating system: Ubuntu 18*
* Software: Nvidia SDK Manager https://developer.nvidia.com/nvidia-sdk-manager

*Depending on the desired JetPack version different Ubuntu versions are required.

::JetPack 4.x requires Ubuntu 18

::JetPack 5.0 requires Ubuntu 20

In order to complete these steps, you must install the required Software before.

== Description ==

=== Step 1 - Connecting the Jetson AGX ===

*To start setting up the Jetson AGX Xavier Development Kit, you need to connect it to your host computer using the included USB-C to USB-A cable. This cable has to be connected to the USB-C port on the front side of the Jetson AGX.
[[File:JetsonFrontSide.jpg|500px|Jetson AGX Front Side]]

*Next, connect it to your local network using the Ethernet port on the back side. On this side also connect a monitor using HDMI and keyboard/mouse using USB-A. If you need a second USB-A port, an USB-C to USB-A adapter is included which can be plugged in to the USB-C port on this side.
[[File:JetsonBackSide.jpg|500px|Jetson AGX Back Side]]

*Finally, connect the Jetson to the power supply.

=== Step 2 - Installing the JetPack ===

*To install the JetPack, you need to bring the Jetson AGX into force recovery mode. To do this, press and hold the force-recovery button (middle button). Then press the power button (left button) and release both buttons.
[[File:JetsonButtons.jpg|500px|Jetson AGX Buttons]]

*Start the Nvidia SDK Manager on your host computer, make sure that the Jetson AGX is detected and choose your desired JetPack version.
[[File:JetsonSetup1.png|500px|Nvidia SDK Manager Choose JetPack Version]]

*On the next page you can choose if the SDK Components should be installed, which is the default. Make sure you have enough disk space available on your device and click continue.
[[File:JetsonSetup2.png|500px|Nvidia SDK Manager Choose SDK Components]]

*When the SDK manager is about to flash the OS to the Jetson AGX, choose Manual Setup to put the device into force recovery mode (as it should already be) and choose the storage device it should be installed to.
[[File:JetsonSetup3.png|500px|Nvidia SDK Manager Flash Settings]]

*During the installation, you need to complete the Ubuntu configuration on the Jetson AGX using the connected monitor and keyboard/mouse.

*Afterwards, enter the chosen username and password in the SDK Manager to allow it to complete the installation.
[[File:JetsonSetup4.png|500px|Nvidia SDK Manager Enter user credentials]]

*After the installation is completed, you can connect to the Jetson AGX using SSH.
[[File:JetsonSetup5.png|500px|Nvidia SDK Manager Setup Complete]]

=== Step 3 - Enabling VNC ===

To enable VNC, run the following commands as provided by Nvidia:

*Enable the VNC server to start each time you log in
mkdir -p ~/.config/autostart
cp /usr/share/applications/vino-server.desktop ~/.config/autostart

*Configure the VNC server
gsettings set org.gnome.Vino prompt-enabled false
gsettings set org.gnome.Vino require-encryption false

*Change the desktop resolution
If no monitor is connected to the Jetson AGX, the default resolution (for VNC) is 640x480
To change this, append the following lines to <code>/etc/X11/xorg.conf</code>
Section "Screen"
Identifier "Default Screen"
Monitor "Configured Monitor"
Device "Tegra0"
SubSection "Display"
Depth 24
Virtual 1280 800 # Modify the resolution by editing these values
EndSubSection
EndSection

*Reboot the system
sudo reboot

Note: You can only connect to the VNC server after logging in to the Jetson locally. To be able to always use VNC enable automatic login in the Ubuntu system settings on the Jetson AGX.

=== Step 4 - Installing TensorFlow and Keras ===
Nvidia provides a custom TensorFlow package, which requires the installation of some dependencies first (https://docs.nvidia.com/deeplearning/frameworks/install-tf-jetson-platform/index.html#prereqs).

*Install required system packages
sudo apt-get update
sudo apt-get install libhdf5-serial-dev hdf5-tools libhdf5-dev zlib1g-dev zip libjpeg8-dev liblapack-dev libblas-dev gfortran

*Install/Upgrade pip3
sudo apt-get install python3-pip
sudo pip3 install -U pip testresources setuptools==49.6.0

*Install python packages
sudo pip3 install -U --no-deps numpy==1.19.4 future==0.18.2 mock==3.0.5 keras_preprocessing==1.1.2 keras_applications==1.0.8 gast==0.4.0 protobuf pybind11 cython pkgconfig packaging
sudo env H5PY_SETUP_REQUIRES=0 pip3 install -U h5py==3.1.0

*Install TensorFlow
sudo pip3 install --pre --extra-index-url https://developer.download.nvidia.com/compute/redist/jp/v46 tensorflow
Note: This command installs the latest available TensorFlow version for the specified JetPack version. If you installed a different version, you need to change the URL: e.g. /v46 for JetPack 4.6, /v461 for JetPack 4.6.1, /v50 for JetPack 5.0

*Install Keras
sudo pip3 install keras==2.5.0rc0
Note: Depending on your installed JetPack and TensorFlow versions you might need a different version of keras.

== Used Hardware ==

* [[Jetson AGX Xavier Development Kit]]

== References ==
* Jetson AGX Xavier Development Kit User Guide https://developer.download.nvidia.com/embedded/L4T/r32-3-1_Release_v1.0/jetson_agx_xavier_developer_kit_user_guide.pdf
* NVIDIA SDK Manager Installation Guide https://docs.nvidia.com/sdk-manager/download-run-sdkm/index.html
* Tensorflow Installation Guide https://docs.nvidia.com/deeplearning/frameworks/install-tf-jetson-platform/index.html#prereqs

[[Category:Documentation]]

AI: Anomaly Detection in logfiles

2022-07-13T14:48:09Z

LPutz: /* Step 4 - Plot the results */

<div style="border: 1px solid #8a6d3b; background-color: #fcf8e3; color: #8a6d3b; padding: 5px 10px; margin-bottom: 5px; text-align: justify">
&emsp;➤ IMPORTANT: This page is still under construction.</div>
== Summary ==

This guide will create a basic AI model to perform binary classification in order to detect anomalies in logfiles.
This AI model is also suitable for the [[Jetson AGX Xavier Development Kit]]

== Requirements ==

* Packages: TensorFlow, Keras, Pandas, sklearn, numpy, seaborn, matplotlib
* Software: Pycharm or any other python editor

== Description ==

=== Step 0 - Import the needed packages/libraries ===

from keras.callbacks import EarlyStopping, ModelCheckpoint # for training
from keras.models import Sequential, load_model # for model
from keras.layers import Dense, Activation # layers and activation function
import pandas as pd # read/prep dataset
pd.options.mode.chained_assignment = None # removes warning
import numpy as np # read/prep dataset
import sklearn.model_selection as sk # dataset splitting
import tensorflow as tf # for model
import seaborn as sns # plotting
from sklearn.metrics import confusion_matrix # confusion matrix
from matplotlib import pyplot as plt # plotting

=== Step 1 - Read the dataset ===

First we need to read the data, for that we can use the predefined function from pandas 'read_csv'
logfile_features = pd.read_csv(path)
Afterwards we replace the infinite values with nans and drop them all together
logfile_features.replace([np.inf, -np.inf], np.nan, inplace=True)
logfile_features.dropna(inplace=True)
Our dataset has labels which define if its an attack or not, so we replace them with numericals (0 and 1)
logfile_features["Label"].replace({"Benign": 0, "DoS attacks-Slowloris": 1, "DoS attacks-GoldenEye": 1}, inplace=True)
Next we shuffle our dataset
logfile_features = logfile_features.sample(frac=1)

Now we need to split our data into 3 parts: Training data (60%), Test data (20%) and Validation data (20%).
To do that we use the following methods
train_dataset, temp_test_dataset = sk.train_test_split(logfile_features, test_size=0.4)
test_dataset, valid_dataset = sk.train_test_split(temp_test_dataset, test_size=0.5)

Next we extract the labels from the actual dataset, we need them extra for our training
train_labels = train_dataset.pop('Label')
test_labels = test_dataset.pop('Label')
valid_labels = valid_dataset.pop('Label')

To norm our data correctly we need to get the stats of our training data (mean and standard deviation)
train_stats = train_dataset.describe()
train_stats = train_stats.transpose()

For norming we use a following method
def norm(x, stats):
return (x - stats['mean']) / stats['std']
This method can then be used the following way
normed_train_data = norm(train_dataset, train_stats)
normed_test_data = norm(test_dataset, train_stats)
normed_valid_dataset = norm(valid_dataset, train_stats)

=== Step 2 - Create a model ===

First we need to create a sequential model, which can be trained later
model = Sequential()

The next step is to create an input layer with exactly as many nodes as features in our training data
model.add(Dense(normed_train_data.shape[1],input_shape=(normed_train_data.shape[1],))

Next a hidden layer consisting of 128 nodes with the ReLU (Rectified Linear Unit) activation function
model.add(Dense(128, Activation('relu')))

And finally the output layer consisting of 1 node which represents 'attack' or 'no attack'
model.add(Dense(1))

Now we could change the learning rate to a specific value, but we just leave it at the default 0.001
learning_rate = 0.001
For the optimizer we just use the Adam Optimizer with the pre-defined learning rate
optimizer = tf.optimizers.Adam(learning_rate)

Lastly we need to compile the model, for the loss function we use BinaryCrossentropy, our optimizer and the metric should be the accuarcy of the model
model.compile(loss=tf.keras.losses.BinaryCrossentropy(from_logits=True),
optimizer=optimizer,
metrics=['accuracy'])

=== Step 3 - Train the model ===

First we set our epochs, a complete pass of the normed training data through the model, and our batch size, after how many datapoints the model gets updated
EPOCHS = 5000
batch_size = 1024

To not have to wait for 5000 training epochs to finish and to prevent overfitting we can set an early stop
es = EarlyStopping(monitor='val_loss', mode='min', verbose=1, patience=2)

Finally the training, model fitting, can start
with tf.device('/CPU:0'):
# with tf.device('/GPU:0'): # wenn man mit der Grafikkarte trainieren will
history = model.fit(
normed_train_data,
train_labels,
batch_size=batch_size,
epochs=EPOCHS,
verbose=1,
shuffle=True,
steps_per_epoch=int(normed_train_data.shape[0] / batch_size),
validation_data=(normed_valid_dataset, valid_labels), callbacks=[es],
)

=== Step 4 - Plot the results ===
After the training has been completed you can easily plot the accuarcy and validation accuracy during the training using
plt.plot(history.history['accuracy'])
plt.plot(history.history['val_accuracy'])
plt.title('model accuracy')
plt.ylabel('accuracy')
plt.xlabel('epoch')
plt.legend(['Train', 'Cross-Validation'], loc='upper left')
plt.show()

To show the accuarcy when tested against the test data, meaning data the model didn't train with, we can use a confusion matrix the following
ax = plt.subplot()
predict_results = model.predict(normed_test_data)
predict_results = (predict_results > 0.5)
cm = confusion_matrix(test_labels, predict_results)
ax.set_xlabel('Predicted labels')
ax.set_ylabel('True labels')
ax.set_title('Confusion Matrix')
ax.xaxis.set_ticklabels(['No Attack', 'Attack'])
ax.yaxis.set_ticklabels(['No Attack', 'Attack'])
plt.show()

[[File:AI_model_accuracy.png|500px|Model Accuracy]]
[[File:AI_confusion_matrix.png|500px|Confusion Matrix]]

== Used Hardware ==

* [[Jetson AGX Xavier Development Kit]]

[[Category:Documentation]]

File:AI confusion matrix.png

2022-07-13T14:47:06Z

LPutz:

File:AI model accuracy.png

2022-07-13T14:46:58Z

LPutz:

Jetson AGX Xavier Development Kit: Setup

2022-07-10T15:34:18Z

LPutz: Added setup instructions

File:JetsonSetup5.png

2022-07-10T15:09:32Z

LPutz:

File:JetsonSetup4.png

2022-07-10T15:09:24Z

LPutz:

File:JetsonSetup3.png

2022-07-10T15:09:18Z

LPutz:

File:JetsonSetup2.png

2022-07-10T15:09:12Z

LPutz:

File:JetsonSetup1.png

2022-07-10T15:09:03Z

LPutz:

File:JetsonButtons.jpg

2022-07-10T15:08:48Z

LPutz:

File:JetsonBackSide.jpg

2022-07-10T15:07:57Z

LPutz:

File:JetsonFrontSide.jpg

2022-07-10T15:06:09Z

LPutz: