# 2020/08/01

## Organization

- Business Plan:
- **Name** (and logo). This will affect project/repo structure, company registration, and a lot of other things.
- Combination of words?
- One word?
- When?
- Who?
- Contents:
- How to convince customers to use our product.
- How to prove the security? Pentests? Bug Bounty?
- What's new/innovative? Hypervisor? Extensions?
- Market analysis: BE, EAC, Vanguard, ...
- Marketing/Promotion: Indie Developers (maybe even some who post Devblogs on YT like ThinMatrix). Reach out to companies that have games on Steam (easily checkable via Steam Charts)
- Support: Certain predefined times per timezone? E.g. 6PM-8PM UTC
- Live support: Paid
- Tickets: Free
- Setup & Consulting: requires manual communication, maybe included
- Where to host our (non)-technical documentation? Confluence? Github Wiki?
- Gitbook
- [Nuxtjs](https://content.nuxtjs.org/)
- MkDocs
- How can we prevent a shitstorm for having a kernel driver?
- Writeup prepared beforehand similar to Secret Club's thing?
- Try to be transparent. For example show statistics that prove a point.
- Example: BE saying 90% of KVM users are cheating
- Get the driver audited by some security firms? This could be expensive.
- Make it technical: Explain how UM AC can be bypassed
- Chart / Panel to show statistics -> as backup to somewhat prove it

## Technical

- Third party libraries/tools selection:
- Crypto
- OpenSSL
- **LibTomCrypt** (I (Codefuser) am leaning to this, it is lightweight and has everything we'd ever need. Needs to port to kernel-compat version though, which is relatively simple to do, mainly getting rid of usermode important and so on)
- **Crypto++**
- mbedcrypto
- LibreSSL
- Disasm
- Capstone
- **Zydis** (personally also leaning to this, it can run in the kernel out of the box)
- XED
- udis
- libdisasm
- bddisasm
- **How should we handle ban appeals?**
- Store logs in db and assign the user id with it -> Lots of effort to check them
- Maybe generate a ban document that has all the different factors (only for internal use).
- "We'll look into it"
- Don't expose too much.
- Extension system:
- We allow game publisher to store certain encrypted data on our server
- Adds security to whatever that encrypted data is, makes emulation more difficult.
- We allow the game publisher to read from the game process.
1. GP (game publisher) sets a certain address/marker on the web dashboard which will get stored on the server.
2. Server will send a memory read request to the client.
3. Client reads the memory and sends it to the server.
4. GP specified a certain routine that will check the memory that has been read.
- Example:
- Recoil/Spread
- It should never be 0.0 when playing a normal match.
- If the GP adds a marker to the code so that we can find the value in memory, we can run the check and detect if the player is cheating.
- Only allow to read from the game process to prevent abuse.
- Separate detection modules
- Banned/Detected: Don't stream it
- Not all users get the same modules -> use user groups
- Randomly do it, not all modules at the same time
- Offensive Detection:
- P2C processes have some unique characteristics:
- Network connection to their server (probably also with heartbeat)
- Randomized window titles: I (Matthias) don't know any legit process that does that. I (Codefuser) think we can use an algorithm similar to Mark Baggett's freq.py (https://github.com/sans-blue-team/freq.py) to detect "abnormal" windows title.
- Scan for encrypted strings.
- Check if virtualized (like DIE). Can validate this based on section header, which will either have strange sections or be wiped altogether.
- Does the process have anti-debug checks?
- We can also try to analyze the process further and check for the driver communication method:
- Analyse the stack to see what functions get called a lot -> Hook
- Check for opened handles -> IRP Hook
- Check for shared memory / named pipes / sockets
- Signed / Not signed
- Query on VT
- Trust-factor for each process: All these factors combined
- High: Ignore
- Medium: Dump certain stuff
- Low: Dump and send to server, Hash and see if many users run it
- Scan for abnormal values:
- Detect ESP by scanning for positions
- An external cheat almost always reads the positions from the game memory and then draws the esp. We can scan the memory to try to find those positions and act upon it.
- Position = Vector3 = 3 floats in the range of -1000.0 to 1000.0
- If we find an abnormal amount of these positions (non-duplicates!!) we can be certain that they have been read from the game process.
- This could even be combined with the extension system.
- Intercept driver communication:
- We can also flag based on certain values. For example if the base address of the game process will be transferred a lot. Or if Vectors will be read.
- Maybe even flag if the driver gets called a lot -> Might be the indication of an esp or something similar that requires at least 60 times per second
- Internal Detection:
- Check if hooks are still there.
- Hook free: Scan / Hash
- Hook malloc / VirtualAlloc / HeapAlloc ...
- Hook CRT functions and check stack
- Hook math stuff (needs to be performant)
- Obfuscate it:
- Hook and unhook
- Load after the game has already started
- Needs to be decided for each hook: CRT only effective in the beginning
- Logging:
- Splunk/ELK stack
- Backend Organization:
- Monolith?
- Microservices?
- Stability, Scalability
- Language selection: Develop our custom benchmarks? Web-Server, Database, ...
- https://www.techempower.com/benchmarks/
- https://medium.com/sean3z/rest-api-node-vs-rust-c75aa8c96343
- https://medium.com/@maxsparr0w/performance-of-node-js-compared-to-actix-web-37f20810fb1a

# Next up

- Business Plan
- Start on the backend documentation / research
-