Merge pull request #6 from JudahZF/Docs

Create and Update Documentation

4 files changed, 96 insertions, 0 deletions

diff --git a/docs/dev/Captures.md b/docs/dev/Captures.md
new file mode 100644
index 0000000..757660c
--- /dev/null
+++ b/docs/dev/Captures.md
@@ -0,0 +1,19 @@
+# Captures
+
+[Back to developer documentation main page](README.md)
+
+[Captures can now be decryped here](https://vaniseghemthomas.github.io/OpenCortex/File-decryption/webapp/)
+
+Infomation about how Captures on the QCs works.
+
+## How it works (Needs updating)
+
+Captures are encrypted protobufs, with local encryption use the serial number, global does not.
+
+After cracking the encryption to the Neural Captures, and writing some code to decode the captures to JSON format. I was shocked to see that there is very little "Neural" about it. Recently it was discovered that the training process involves some kind of genetic algorithm and until now we haven't found a conrete reference to any neural network training. Looking at one of the captures you can see that the network consists of a 13 parameter network.
+
+## Links
+
+- [Capture Demo](http://research.spa.aalto.fi/publications/papers/smc19-black-box/)
+- [Patent](https://patentimages.storage.googleapis.com/0e/b9/35/293f5bf8c3340a/EP3828878A1.pdf)
+- [Capture Article](https://www.smc2019.uma.es/articles/S5/S5_02_SMC2019_paper.pdf)
diff --git a/docs/dev/README.md b/docs/dev/README.md
new file mode 100644
index 0000000..40190c1
--- /dev/null
+++ b/docs/dev/README.md
@@ -0,0 +1,9 @@
+# Documentation of all the discoveries about Quad Cortex
+
+## Table of Contents
+
+[Back to Main README](../../README.md)
+
+- [Decrypt Captures](Captures.md)
+- [Custom DSP](DSP.md)
+- [Live Update Patchers](Updates.md)
diff --git a/docs/dev/Updates.md b/docs/dev/Updates.md
new file mode 100644
index 0000000..96430d9
--- /dev/null
+++ b/docs/dev/Updates.md
@@ -0,0 +1,20 @@
+# Updates
+
+[Back to developer documentaion main page](README.md)
+
+Infomation about the QCs update process, and how we can use it should be placed here.
+
+## How it works
+
+the update process first talks to an API to see if there's anything available and then downloads the update archive right
+
+## Patching the update file for persistent access
+
+(Coming soon)
+
+## Man In The Middle updates
+
+SSL checks are disabled for the updater (see `cloud_updater.py`)... this means that on paper, we could have command execution on the unit without even opening it.
+In the middle, we can literally patch (from any device on the same network) the update archive as it arrives, using a transparent http proxy that gives you a scripting engine to modify buffers on the fly.
+
+we could do something simple ... download the original update file, apply our changes to it, [bindiff](https://www.daemonology.net/bsdiff/) the two archives and just apply the binpatch on the https buffers
diff --git a/docs/dev/dsp.md b/docs/dev/dsp.md
new file mode 100644
index 0000000..ef0d230
--- /dev/null
+++ b/docs/dev/dsp.md
@@ -0,0 +1,48 @@
+# DSP
+
+[Back to developer documentaion main page](README.md)
+
+Infomation about how the dsp on the QCs works, and how we can develop code for it.
+
+## How it works
+
+### LDR Files & DSP Loading
+
+A LDR is basically a sequence of 4 unsigned longs blocks where each is:
+
+```c
+printf("block code: 0x%08x\n", bh[block_code_idx]);
+printf("target address: 0x%08x\n", bh[target_address_idx]);
+printf("byte count: 0x%08x\n", bh[byte_count_idx]);
+printf("argument: 0x%08x\n", bh[argument_idx]);
+```
+
+It's not an executable format, but it tells the DSP to literally "load this code at this address"
+The original code should be recoverable from these files
+
+the dsp loading process works via /dev/mem
+
+[Sharc Runtime Loader](https://github.com/analogdevicesinc/runtime-sharc-loaderGitHubGitHub)
+[U-Boot LDR Files](https://www.analog.com/media/en/technical-documentation/application-notes/EE407v01.pdf)
+
+### Architecture
+
+A single binary is splitted into different chunks and each is executed by a specific core
+core0 gets the actual arm code and the models are handled (maybe passed from the code in core0 to core1) by core1 and core2
+
+#### MEMORY LAYOUT
+
+```c
+0x001609a8 DATA | <0 bytes>
+0x001609a8 CODE | 0xab9c8000
+0x001609a8 CODE | 0xab9c8000
+0x00161320 CODE | 0xab9c8000
+```
+
+all the opcodes are the same (addeq sb, r0, fp, lsr #25)
+they just increment the pointer to the data, meaning, the actual logic is in the data section
+All the data sections are sized as a multiple of 4, this would suggest these are arm instructions as well
+
+## Links
+
+- [SDK Examples](https://github.com/analogdevicesinc/runtime-sharc-loader/blob/master/SharcLoader/loader.c#L228GitHubruntime-sharc-loader/loader.c)