diff --git a/Adding-a-new-operation.md b/Adding-a-new-operation.md
index bb93eb8..6a74536 100644
--- a/Adding-a-new-operation.md
+++ b/Adding-a-new-operation.md
@@ -1,113 +1,31 @@
## How to add an operation
- 1. Create a new file in the `src/core/operations` directory and name it using CamelCase. e.g. `MyOperation.js`
- 2. In this file, create a namespace with the same name and populate it with a single function looking like this (all function and variable names should be written in camelCase):
-
- ```javascript
- const MyOperation = {
- runMyOperation: function (input, args) {
- return input;
- }
- };
-
- export default MyOperation;
- ```
-
- - `input` will be the input data passed on from the previous operation (or the data entered by the user if yours is the first operation). Its data type is specified in the next step by `inputType`.
- - `args` will be an array of the arguments for your operation. They are specified in the next step by `args`.
- - Make sure that you return the output data in the format specified in the next step by `outputType`.
-
- 3. Choose which module to add it to. This decision should be based on how much extra code your operation will add to the app, including any dependencies it imports. If it doesn't require any dependencies, add it to the 'Default' module in `src/core/config/modules/Default.js`. Import it at the top of the file:
-
- ```javascript
- import MyOperation from "../../operations/MyOperation.js";
- ```
-
- and then add it to the operation list like so:
-
- ```javascript
- "My Operation": MyOperation.runMyOperation, // a reference to the function that runs your operation
- ```
-
- If it imports the same dependencies as other operations, add it to the relevant existing module. If it imports entirely new dependencies that are not related to other operations in any way, create a new module using an existing module as a template and then import this new module into the `src/core/config/modules/OpModules.js` file.
- 4. In `src/core/config/OperationConfig.js`, import your operation at the top of the file:
-
- ```javascript
- import MyOperation from "../operations/MyOperation.js";
- ```
-
- Then create a new entry:
-
- ```javascript
- "My Operation": {
- module: "Module name",
- description: "A short description if necessary, optionally containing HTML code (e.g. lists and paragraphs)",
- inputType: "byteArray", // the input type for your operation, see the next section for valid types
- outputType: "byteArray", // the output type for your operation, see the next section for valid types
- highlight: true, // [optional] true if the operation does not change the position of bytes in the output (so that highlighting can be calculated)
- highlightReverse: true, // [optional] same as above but for the reverse of the operation (output to input highlighting)
- manualBake: false, // [optional] true if auto-bake should be disabled when this operation is added to the recipe
- args: [ // A list of the arguments that the user will be presented with
- {
- name: "Argument name",
- type: "string", // the argument data type, see the next section for valid types
- value: MyOperation.DEFAULT_VALUE // the default value of the argument
- }
- ]
- }
- ```
+The easiest way to create a new operation is to use the provided quickstart script. This can be run using the command `npm run newop`. This script will walk you through the configuration process and create your operation file in the `src/core/operations` directory.
- For example:
-
- ```javascript
- "XOR": {
- module: "Default",
- description: "XOR the input with the given key, provided as either a hex or ASCII string.
e.g. fe023da5
Options
Null preserving: If the current byte is 0x00 or the same as the key, skip it.
Differential: Set the key to the value of the previously decoded byte.",
- inputType: "byteArray",
- outputType: "byteArray",
- args: [
- {
- name: "Key",
- type: "binaryString",
- value: ""
- },
- {
- name: "Key format",
- type: "option",
- value: BitwiseOp.KEY_FORMAT
- },
- {
- name: "Null preserving",
- type: "boolean",
- value: BitwiseOp.XOR_PRESERVE_NULLS
- },
- {
- name: "Differential",
- type: "boolean",
- value: BitwiseOp.XOR_DIFFERENTIAL
- }
- ]
- }
- ```
+Once this file has been created, add your operation to the [`src/core/config/Categories.json`](https://github.com/gchq/CyberChef/blob/master/src/core/config/Categories.json) file. This determines which menu it will appear in. You can add it to multiple menus if you feel it is appropriate.
- 5. In `src/core/config/Categories.js`, add your operation name to an appropriate list. This determines which menu it will appear in. You can add it to multiple menus if you feel it is appropriate.
- 6. Finally, run `grunt dev` if you haven't already. If it's already running, it should automatically build a development version when you save the files.
- 7. You should now be able to view your operation on the site by browsing to [`localhost:8080`](http://localhost:8080).
- 8. You can write whatever code you like as long as it is encapsulated within the namespace you created (`MyOperation`). Take a look at `src/core/operations/Entropy.js` for a good example.
- 9. You may find it useful to use some helper functions which have been written in `src/core/Utils.js`. These are available in the `Utils` object (e.g. `Utils.strToByteArray("Hello")` returns `[72,101,108,108,111]`).
+Finally, run `grunt dev` if you haven't already. If it's already running, it should automatically build a development version when you save the files. You should now be able to view your operation on the site by browsing to [`localhost:8080`](http://localhost:8080).
+
+You can write whatever code you like as long as it is encapsulated within the object you created. Take a look at [`src/core/operations/Entropy.mjs`](https://github.com/gchq/CyberChef/blob/master/src/core/operations/Entropy.mjs) for a good example.
+
+You may find it useful to use some helper functions which have been written in [`src/core/Utils.mjs`](https://github.com/gchq/CyberChef/blob/master/src/core/Utils.mjs) (e.g. `Utils.strToByteArray("Hello")` returns `[72,101,108,108,111]`).
## Data types
**Input and Output**
-Five data types are supported for the input and output of operations:
+Nine data types are supported for the input and output of operations:
1. `string` - e.g. `"hello"`
2. `byteArray` - e.g. `[104,101,108,108,111]`
3. `number` - e.g. `562` or `3.14159265`
4. `html` - e.g. `"hello
"`
5. [`ArrayBuffer`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/ArrayBuffer) - e.g. `new Uint8Array([104,101,108,108,111]).buffer`
+ 6. `BigNumber` - e.g. `12345678901234567890`
+ 7. `JSON` - e.g. `[{"a":1,"b":2}]`
+ 8. [`File`](https://developer.mozilla.org/en-US/docs/Web/API/File) - e.g. `new File()`
+ 9. `List` - e.g. `[new File(), new File()]`
Each operation can define any of these data types as their input or output. The data will be automatically converted to the specified type before running the operation.
@@ -132,14 +50,27 @@ Operation arguments (ingredients) can be set to any of the following types:
- User is presented with a checkbox, operation receives `true` or `false`.
7. `option`
- Given an array of strings, the user is presented with a dropdown selection box with each of those strings as an option. The selected string is sent to the operation.
+ - You can use the `defaultIndex` property to define which index should be selected by default, if required.
7. `populateOption`
- Given an array of `{name: "", value: ""}` objects, the user is presented with a dropdown selection box with the names as options. The corresponding value will be assigned to whichever argument index the `target` parameter is set to.
- See the *Regular expression* configuration in `src/core/config/OperationConfig.js` for an example of how this works.
- 8. `editableOption`
+ 8. `editableOption` or `editableOptionShort`
- Given an array of `{name: "", value: ""}` objects, the user is presented with an editable dropdown menu. The items in the dropdown are labelled with `name` and set the argument to `value` when selected.
+ - You can use the `defaultIndex` property to define which index should be selected by default, if required.
9. `toggleString`
- User is presented with a string input box with a toggleable dropdown attached.
- Populate the dropdown using the `toggleValues` property.
- Operation receives an object with two properties: `option` containing the user's dropdown selection, and `string` containing the input box contents.
- Particularly useful for arguments that can be specified in various different formats.
- See the *XOR* configuration in `src/core/config/OperationConfig.js` for an example of how this works.
+
+
+## Presenting complex data
+
+The output of your operation will be passed on to the next operation in the recipe, or to the Output field if it is the final operation. If your operation has a complex output, it should be presented to the user in a friendly format, perhaps using HTML markup, however this format should not be sent to follow-on operations, as it would make onward processing unnecessarily complex.
+
+In these situations, the `present` function should be used. This function is called if your operation is the final operation in the recipe. It is passed the output of your `run` function which you can then manipulate into a suitable format for displaying to the user. This allows you to return a sensible format which can be easily processed from your `run` function.
+
+The data type for your present function should be specified in the operation constructor using `this.presentType`.
+
+A good example of this can be found in [`src/core/operations/Unzip.mjs`](https://github.com/gchq/CyberChef/blob/master/src/core/operations/Unzip.mjs).
\ No newline at end of file
diff --git a/Automatic-detection-of-encoded-data-using-CyberChef-Magic.md b/Automatic-detection-of-encoded-data-using-CyberChef-Magic.md
new file mode 100644
index 0000000..c6f0d52
--- /dev/null
+++ b/Automatic-detection-of-encoded-data-using-CyberChef-Magic.md
@@ -0,0 +1,71 @@
+CyberChef v8 introduces the ['Magic'](https://gchq.github.io/CyberChef/#recipe=Magic()) operation, designed to automatically detect how your data is encoded and which operations can be used to decode it. A number of methods are used to achieve this.
+
+### Pattern matching
+
+Many common data encoding schemes, such as Base64, Hexadecimal and Gzip, have predictable structures that can be detected using pattern matching techniques. Regular expressions have been written for all operations where this is the case. They are each run over the data and any matches are recorded. In some cases, multiple regular expressions are written for the same operation where different arguments can be applied, for example Base64 using a non-standard alphabet.
+
+Example regular expression for Base64 data using the standard alphabet:
+```regex
+/^(?:[A-Z\\d+/]{4})+(?:[A-Z\\d+/]{2}==|[A-Z\\d+/]{3}=)?$/i
+```
+
+Example regular expression for Base64 data using the y64 alphabet:
+```regex
+/^(?:[A-Z\\d._]{4}){5,}(?:[A-Z\\d._]{2}--|[A-Z\\d._]{3}-)?$/i
+```
+
+### Speculative execution
+
+For every pattern that matches, the corresponding operation is speculatively executed to determine what the output looks like. Various metrics are collected for each of these possible branches to determine whether they look like valid data or not. Each branch is also checked for further pattern matches, meaning that data under multiple levels of encoding can be unwrapped recursively. The maximum number of levels of recursion is controlled by the 'Depth' argument.
+
+The methods used to detect how "valid" the data looks are as follows, ranging from simple to more complex techniques:
+
+#### Magic byte detection
+
+In many file formats, a [magic number](https://en.wikipedia.org/wiki/List_of_file_signatures) is included to allow trivial detection of the file type. If a magic byte sequence is found in a branch, it increases the likelihood that the correct decoding sequence has been found.
+
+
+
+#### UTF-8 detection
+
+UTF-8 data has a well-defined structure which can be easily tested for. The presence of valid UTF-8 data may suggest that a valid decoding sequence has been found.
+
+#### Entropy measurement
+
+[Shannon Entropy](https://en.wikipedia.org/wiki/Entropy_(information_theory)), in the context of information theory, is a measure of the rate at which information is produced by a source of data. It can be used, in a broad sense, to detect whether data is likely to be structured or unstructured. If a branch results in data with high entropy, it is possible that it has simply output unstructured, random garbage. Branches resulting in lower entropy data are ranked higher as they are more likely to contain repeating structures.
+
+#### Byte frequency analysis
+
+On average, the English language contains more "e"s than any other letter. In fact, given a long enough sample, the relative frequency of each character is very predictable, to the extent that we can consider any text not roughly matching these frequencies as unlikely to be English.
+
+
+
+This set of frequencies can be expanded to include all possible bytes, incorporating punctuation, numbers, symbols and other formatting characters. To generate a set of accurate "truth data", the [English language Wikipedia dump](https://dumps.wikimedia.org/enwiki/) was downloaded, wiki syntax was stripped out, then the byte frequencies were calculated. The resulting values assume a character encoding of UTF-8.
+
+For every branch created by the Magic operation, the byte frequencies for the output are calculated and then compared to this truth data using [Pearson's chi-squared goodness of fit test](https://en.wikipedia.org/wiki/Pearson%27s_chi-squared_test). This process tells us how closely the branch's output matches the English language and therefore hopefully gives us an idea of how likely it is that we have found correctly decoded data, if that data includes a reasonably high proportion of English text.
+
+Truth data was also generated for all other languages supported by Wikipedia. By default, only the top 38 languages are checked (based on the most popular languages used on the Internet, as listed on [W3 Techs](https://w3techs.com/technologies/overview/content_language/all)), however if 'Extensive language support' is selected, all 245 languages are supported.
+
+
+
+### Intensive mode
+
+The above methods have been optimised to run reasonably quickly over most types of input, however there are some methods which take considerably longer to run due to their high branching factor. These can be turned on by enabling the 'Intensive mode' argument.
+
+#### Character encoding brute forcing
+
+For each branch, the data is converted into a number of different character encodings. If this conversion results in different data, a new branch is created and metrics are calculated as described above. This can help to detect the correct character encodings for [mojibake](https://en.wikipedia.org/wiki/Mojibake) (garbled data represented in the wrong encoding). Over 40 character encodings are currently supported.
+
+
+
+#### Arithmetic logic brute forcing
+
+Single byte XORs are carried out over every branch, creating 255 further branches to analyse. Bit rotates are also calculated, resulting in another 7 branches.
+
+
+
+### Automated background magic
+
+As well as being available as a standalone operation, CyberChef runs the 'Magic' operation automatically in a background thread whenever the Output is changed. If it manages to find an operation or set of operations that can help decode the data, the magic icon will be displayed in the Output pane. Hovering over this icon shows which operations are most likely to help and a snippet of what they will produce. Clicking the icon will append those operations to your recipe.
+
+
diff --git a/Contributing.md b/Contributing.md
index 384d2f0..f29a2f8 100644
--- a/Contributing.md
+++ b/Contributing.md
@@ -26,7 +26,7 @@ Before your contributions can be accepted, you must:
4. Use Vanilla JS if at all possible to reduce the number of libraries required and relied upon. Frameworks like jQuery, although included, should not be used unless absolutely necessary.
-With these principals in mind, any changes or additions to CyberChef should keep it:
+With these principles in mind, any changes or additions to CyberChef should keep it:
- Standalone
- Efficient
diff --git a/Enigma,-the-Bombe,-and-Typex.md b/Enigma,-the-Bombe,-and-Typex.md
new file mode 100644
index 0000000..dded9d1
--- /dev/null
+++ b/Enigma,-the-Bombe,-and-Typex.md
@@ -0,0 +1,350 @@
+## How to guides
+
+### How to encrypt/decrypt with Enigma
+
+We'll start with a step-by-step guide to decrypting a known message. You can see the result of
+these steps in CyberChef
+[here](https://gchq.github.io/CyberChef/#recipe=Enigma('3-rotor','','','','BDFHJLCPRTXVZNYEIWGAKMUSQO
+
+
+In this case, if we extend our crib by a single character to `HELLO CYBER CHEFU`, we get a loop in
+the menu (that `U` maps to a `Y` in the ciphertext, the `Y` in the second cipher block maps to
+`A`, the `A` in the third ciphertext block maps to `E`, and the `E` in the second crib block maps
+back to `U`). We immediately get a manageable number of results. You can see this
+[here](https://gchq.github.io/CyberChef/#recipe=Bombe('3-rotor','LEYJVCNIXWPBQMDRTAKZGFUHOS','BDFHJLCPRTXVZNYEIWGAKMUSQOletter conversions to produce ciphertext from plaintext. It
+is symmetric, such that the same series of operations on the ciphertext recovers the original
+plaintext.
+
+The bulk of the conversions are implemented in "rotors", which are just an arbitrary mapping from
+the letters A-Z to the same letters in a different order. Additionally, to enforce the symmetry, a
+reflector is used, which is a symmetric paired mapping of letters (that is, if a given reflector
+maps X to Y, the converse is also true). These are combined such that a letter is mapped through
+three different rotors, the reflector, and then back through the same three rotors in reverse.
+
+To avoid Enigma being a simple [Caesar cipher](https://wikipedia.org/wiki/Caesar_cipher), the
+rotors rotate (or "step") between enciphering letters, changing the effective mappings. The right
+rotor steps on every letter, and additionally defines a letter (or
+later, letters) at which the adjacent (middle) rotor will be stepped. Likewise, the middle rotor
+defines a point at which the left rotor steps. (A mechanical issue known as the
+double-stepping anomaly means that the middle rotor actually steps twice when the left hand rotor
+steps.)
+
+The German military Enigma adds a plugboard, which is a configurable pair mapping of letters
+(similar to the reflector, but not requiring that every letter is exchanged) applied before the
+first rotor (and thus also after passing through all the rotors and the reflector).
+
+It also adds a ring setting, which allows the stepping point to be adjusted.
+
+Later in the war, the Naval Enigma added a fourth rotor. This rotor does not step during
+operation. (The fourth rotor is thinner than the others, and fits alongside a thin reflector,
+meaning this rotor is not interchangeable with the others on a real Enigma.)
+
+There were a number of other variants and additions to Enigma which are not currently supported
+here, as well as different Enigma networks using the same basic hardware but different rotors
+(which are supported by supplying your own rotor configurations).
+
+### How Typex works
+
+Typex is a clone of Enigma, with a few changes implemented to improve security. It uses five rotors
+rather than three, and the _rightmost_ two are static. Each rotor has more stepping points.
+Additionally, the rotor design is slightly different: the wiring for each rotor is in a removable
+core, which sits in a rotor housing that has the ring setting and stepping notches. This means each
+rotor has the same stepping points, and the rotor cores can be inserted backwards, effectively
+doubling the number of rotor choices.
+
+Later models (from the Mark 22, which is the variant we simulate here) added two plugboards: an
+input plugboard, which allowed arbitrary letter mappings
+(rather than just pair switches) and thus functioned similarly to a configurable extra static
+rotor, and a reflector plugboard, which allowed rewiring the reflector.
+
+### How the Bombe works
+
+The Bombe is a mechanism for efficiently testing and discarding possible rotor positions, given
+some ciphertext and known plaintext. It exploits the symmetry of Enigma and the reciprocal
+(pairwise) nature of the plugboard to do this regardless of the plugboard settings. Effectively,
+the machine makes a series of guesses about the rotor positions and plugboard settings and for
+each guess it checks to see if there are any contradictions (e.g. if it finds that, with its
+guessed settings, the letter `A` would need to be connected to both `B` and `C` on the plugboard,
+that's impossible, and these settings cannot be right). This is implemented via careful connection
+of electrical wires through a group of simulated Enigma machines.
+
+A full explanation of the Bombe's operation is beyond the scope of this document - you can read
+the source code, and the authors also recommend Graham Ellsbury's
+[Bombe explanation](http://www.ellsbury.com/bombe1.htm), which is very clearly diagrammed.
+
+## Implementation in CyberChef
+
+### Enigma/Typex
+
+Enigma and Typex were implemented from documentation of their functionality.
+
+Enigma rotor and reflector settings are from GCHQ's documentation of known Enigma wirings. We
+currently simulate all basic versions of the German Service Enigma; most other versions should be
+possible by manually entering the rotor wirings. There are a few models of Enigma, or attachments
+for the Service Enigma, which we don't currently simulate. The operation was tested against some
+of GCHQ's working examples of Enigma machines. Output should be letter-for-letter identical to a
+real German Service Enigma. Note that some Enigma models used numbered rather than lettered
+rotors - we've chosen to stick with the easier-to-use lettered rotors.
+
+There were a number of different Typex versions over the years. We implement the Mark 22, which is
+backwards compatible with some (but not completely with all, as some early variants supported case
+sensitivity) older Typex models. GCHQ also has a partially working Mark 22 Typex. This was used to
+test the plugboards and mechanics of the machine. Typex rotor settings were changed regularly, and
+none have ever been published, so a test against real rotors was not possible. An example set of
+rotors have been randomly generated for use in the Typex operation. Some additional information on
+the internal functionality was provided by the Bombe Rebuild Project.
+
+### The Bombe
+
+The Bombe was likewise implemented on the basis of documentation of the attack and the machine. The
+Bombe Rebuild Project at the National Museum of Computing answered a number of technical questions
+about the machine and its operating procedures, and helped test our results against their working
+hardware Bombe, for which the authors would like to extend our thanks.
+
+Constructing menus from cribs in a manner that most efficiently used the Bombe hardware was another
+difficult step of operating the real Bombes. We have chosen to generate the menu automatically from
+the provided crib, ignore some hardware constraints of the real Bombe (e.g. making best use of the
+number of available Enigmas in the Bombe hardware; we simply simulate as many as are necessary),
+and accept that occasionally the menu selected automatically may not always be the optimal choice.
+This should be rare, and we felt that manual menu creation would be hard to build an interface for,
+and would add extra barriers to users experimenting with the Bombe.
+
+The output of the real Bombe is optimised for manual verification using the checking machine, and
+additionally has some quirks (the rotor wirings are rotated by, depending on the rotor, between one
+and three steps compared to the Enigma rotors). Therefore, the output given is the _ring position_,
+and a correction depending on the rotor needs to be applied to the _initial value_, setting it to
+`W` for rotor V, `X` for rotor IV, and `Y` for all other rotors. We felt that this would require
+too much explanation in CyberChef, so the output of CyberChef's Bombe operation is the initial
+value for each rotor, with the ring positions set to `A`, required to decrypt the ciphertext starting
+at the beginning of the crib. The actual stops are the same. This would not have caused problems at
+Bletchley Park, as operators working with the Bombe would never have dealt with a real or simulated
+Enigma, and vice versa.
+
+By default the checking machine is run automatically and stops which fail silently discarded. This
+can be disabled in the operation configuration, which will cause it to output all stops from the
+actual Bombe hardware instead. (In this case you only get one stecker pair, rather than the set
+identified by the checking machine.)
+
+#### Optimisation
+
+A three-rotor Bombe run (which tests 17,576 rotor positions and takes about 15-20 minutes on
+original Turing Bombe hardware) completes in about a fifth of a second in our tests. A four-rotor
+Bombe run takes about 5 seconds to try all 456,976 states. This also took about 20 minutes on the
+four-rotor US Navy Bombe (which rotates about 30 times faster than the Turing Bombe!). CyberChef
+operations run single-threaded in browser JavaScript.
+
+We have tried to remain fairly faithful to the implementation of the real Bombe, rather than
+a from-scratch implementation of the underlying attack. There is one small deviation from "correct"
+behaviour: the real Bombe spins the slow rotor on a real Enigma fastest. We instead spin the fast
+rotor on an Enigma fastest. This means that all the other rotors in the entire Bombe are in the
+same state for the 26 steps of the fast rotor and then step forward: this means we can compute
+the 13 possible routes through the lower two/three rotors and reflector (symmetry means there are
+only 13 routes) once every 26 ticks and then save them. This does not affect where the machine stops,
+but it does affect the order in which those stops are generated.
+
+The fast rotors repeat each others' states: in the 26 steps of the fast rotor between steps of the
+middle rotor, each of the scramblers in the complete Bombe will occupy each state once. This means
+we can once again store each state when we hit them and reuse them when the other scramblers rotate
+through the same states.
+
+Note also that it is not necessary to complete the energisation of all wires: as soon as 26 wires
+in the test register are lit, the state is invalid and processing can be aborted.
+
+The above simplifications reduce the runtime of the simulation by an order of magnitude.
+
+If you have a large attack to run on a multiprocessor system - for example, the complete M4 Naval
+Enigma, which features 1344 possible choices of rotor and reflector configuration, each of which
+takes about 5 seconds - you can open multiple CyberChef tabs and have each run a subset of the
+work. For example, on a system with four or more processors, open four tabs with identical Multiple
+Bombe recipes, and set each tab to a different combination of 4th rotor and reflector (as there are
+two options for each). Leave the full set of eight primary rotors in each tab. This should complete
+the entire run in about half an hour on a sufficiently powerful system.
\ No newline at end of file
diff --git a/Getting-started.md b/Getting-started.md
index 2659803..1d63736 100644
--- a/Getting-started.md
+++ b/Getting-started.md
@@ -11,18 +11,19 @@ CyberChef uses the Grunt build system, so it's very easy to install. You'll need
npm will then install all the dependencies needed by Grunt.
+_Consider adding `export NODE_OPTIONS=--max_old_space_size=2048` to your `~/.bashrc` file. If you attempt to build a production version of CyberChef, you may get a "JavaScript heap out of memory" error if you do not set this environment variable._
+
## Compiling
Grunt has been configured with several tasks to aid in the development process:
+
```
grunt dev
```
> Use this when developing new functionality. It will launch a web server on port 8080 hosting an uncompressed, development version of CyberChef, accessible by browsing to [`localhost:8080`](http://localhost:8080). Whenever a source file is modified, the development version will be rebuilt automatically.
-> Note: This task will initially result in an error relating to the `MetaConfig.js` file but will quickly rebuild and should complete successfully. This is due to the `MetaConfig.js` file being built at the same time as the rest of the app and therefore not being available for compilation immediately.
-
```
grunt prod
@@ -69,9 +70,11 @@ grunt docs
- `src/`
- `core/` - Core CyberChef files that make up the heart of the application
- `config/` - Files specifying the operation configurations
- - `modules/` - Modules containing the run functions for each operation
- - `lib/` - Libraries that we can't currently import through npm
+ - `modules/` - Automatically generated module references
+ - `lib/` - Libraries containing shared code for multiple operations
+ - `errors/` - Custom error types
- `operations/` - Operation objects
+ - `vendor/` - Libraries that cannot currently be imported through npm
- `node/` - Wrappers for the NodeJS version of CyberChef
- `web/` - The code which makes up the CyberChef web app
- `css/`
@@ -85,10 +88,11 @@ grunt docs
- `test/`
- `tests/` - Configuration for tests on operations and recipes
- `.babelrc` - Babel transpilation configuration
- - `.travid.yml` - Travis CI build process configuration
+ - `.editorconfig` - Text editor conventions stored in a cross-compatible format
+ - `.travis.yml` - Travis CI build process configuration
- `Gruntfile.js` - Grunt build process configuration
- `webpack.config.js` - Webpack configuration
- `postcss.config.js` - PostCSS configuration
- `LICENSE` - The Apache 2.0 licence information
- `package.json` - npm configuration and a list of all the dependencies
- - `README.md` - An introduction to CyberChef
+ - `README.md` - An introduction to CyberChef
\ No newline at end of file
diff --git a/Home.md b/Home.md
index 38762e8..eacff42 100644
--- a/Home.md
+++ b/Home.md
@@ -7,7 +7,7 @@ Welcome to the CyberChef wiki pages. Here you can find guides for installing and
- [[Repository structure|Getting-started#repository-structure]]
2. [[Contributing]]
- [[Coding conventions|Contributing#coding-conventions]]
- - [[Design principals|Contributing#design-principals]]
+ - [[Design principles|Contributing#design-principles]]
3. [[Adding a new operation]]
- [[How to add an operation|Adding-a-new-operation#how-to-add-an-operation]]
- [[Data types|Adding-a-new-operation#data-types]]
diff --git a/Troubleshooting.md b/Troubleshooting.md
new file mode 100644
index 0000000..addbfc8
--- /dev/null
+++ b/Troubleshooting.md
@@ -0,0 +1,9 @@
+## Script error when running `cyberchef.htm` from a local file in Safari
+
+Sometimes Safari throws a scriptError or syntaxError when you run `cyberchef.htm` from a file. The workaround for this is to run an instance of [`http-server`](https://www.npmjs.com/package/http-server) with compression enabled. You can do this with the following commands:
+
+```
+cd
+npm install -g http-server
+http-server -g .
+```
\ No newline at end of file