tenet

README.md

@@ -33,9 +33,9 @@ The best way to try the features out is to work with the [fuzzer_hevd](src/wtf/f
 - `outputs` is the folder where the current minset files are saved into,
 - `coverage` is the folder where the `.cov` files are expected to be in,
 - `crashes` is where the crashes gets saved in,
-- `state` is where the memory dump (`mem.dmp`) as well as the CPU state (`regs.json`) and the symbol store are stored in (`symbol-store.json`). The symbol store is a simple JSON file that is used on Linux systems to know where to put breakpoints as there is no support for symbols / dbgeng on those platforms. *wtf* generates this file at runtime everytime you run your target on Windows.
+- `state` is where the memory dump (`mem.dmp`) as well as the CPU state (`regs.json`) and the symbol store are stored in (`symbol-store.json`). The symbol store is a simple JSON file that is used on Linux systems to know where to put breakpoints as there is no support for symbols / dbgeng on those platforms. **wtf** generates this file at runtime everytime you run your target on Windows.
 
-What follows assume that you downloaded the [target-hevd.7z](https://github.com/0vercl0k/wtf/releases) file attached to the latest release, and extracted it in the `targets` directory of your clone of *wtf*. You should have `wtf/targets/hevd` in which you find the `inputs` / `outputs`, etc. directories.
+What follows assume that you downloaded the [target-hevd.7z](https://github.com/0vercl0k/wtf/releases) file attached to the latest release, and extracted it in the `targets` directory of your clone of **wtf**. You should have `wtf/targets/hevd` in which you find the `inputs` / `outputs`, etc. directories.
 
 ### Starting a server node
 
@@ -47,7 +47,7 @@ This is how you might choose to launch a local server node:
 wtf.exe master --name hevd --max_len=1028 --runs=10000000
 ```
 
-The `max_len` option is used to limit the size of the generated test-case, `runs` is the number of test-cases it will generate, `address` specify where *wtf* needs to be listening on, `target` is a directory with the directory tree we described above (the user can also choose to override those directories with `--input` / `--output` / `--crashes`) and `name` specifies your fuzzing module name so that the master can invoke your generator function if you have defined one.
+The `max_len` option is used to limit the size of the generated test-case, `runs` is the number of test-cases it will generate, `address` specify where **wtf** needs to be listening on, `target` is a directory with the directory tree we described above (the user can also choose to override those directories with `--input` / `--output` / `--crashes`) and `name` specifies your fuzzing module name so that the master can invoke your generator function if you have defined one.
 
 <p align='center'>
 <img src='pics/server.webp'>
@@ -130,7 +130,7 @@ wtf.exe run --name hevd --limit 10000000 --input crashes\crash-0xfffff764b91c000
 ```
 
 <p align='center'>
-<img src='pics/tenet.gif'>
+<img src='pics/tenet.webp'>
 </p>
 
 ### Generating code-coverage traces
@@ -169,7 +169,7 @@ Also if you don't care about individual code-coverage, the master maintains a `c
 
 ## How does it work?
 
-*wtf* runs user & kernel mode through an *execution backend* and relies on the user to insert test-cases in the target. Unlike other classical fuzzer tools, *wtf* doesn't do much of the heavy lifting; the user does. The user needs to know the harnessed target very well and onboarding a target is an iterative process that will take time. It has a lot of flexibility to offer if you are ready to get hacking though :)
+**wtf** runs user & kernel mode through an *execution backend* and relies on the user to insert test-cases in the target. Unlike other classical fuzzer tools, **wtf** doesn't do much of the heavy lifting; the user does. The user needs to know the harnessed target very well and onboarding a target is an iterative process that will take time. It has a lot of flexibility to offer if you are ready to get hacking though :)
 
 The usual workflow to harness a target is as follows: