The Obsidian Deck note .md file
tag, concept, meta_tag, meta_keyword are the # tags added by the AI parser. Instead of manually tagging 600 files
the script uses a local installed LLM to give useful tags to the large amount of files.
It creates quite a set of tags and some connected tags are combined in meta_tags enabling different views in the
Obsidian software and better clustering of the notes for further analysis.
The LLM models are quite good in finding good tags and meta tags. DeepSeek considered the Cyberdeck to be a Game
Simulation rather then an actual thing of real use and therefore was in its thought process quite close to the Cyberpunk games.
Even so possible and most likely more powerful than a Unix Server is that Beowulf Long Chain Ollama models project not
intended to crack any systems, but based on the actual Original Hacker idea of Understanding and Knowledge
Acquisition.
Never the less was that the start and thereby here a sample from the Vault:
---
title: Shadowrun-Cyberdeck-Project
converted_from: Shadowrun-Cyberdeck-Project.md
conversion_date: 2025-10-23
---
---
title: deepseek-chat-2025-06-22T03-38-47-626Z
date: 2025-06-22
tags:
- knowledge-management
- obsidian
- shadowrun
- cyberdeck
concepts:
- Shadowrun
- Cyberdeck
- Matrix
- Hacking
- Intrusion
- Defense
- ICE
- CLI
- GUI
- Turn-based_combat
- Resource_management
meta_tags:
- [[Technical Writing]]
- [[Cybersecurity]]
- [[Game Development]]
- [[Shadowrun]]
meta_keyword: [[Cybersecurity]]
---
## Summary
This content is a white paper for a Shadowrun Cyberdeck
project, outlining the project's goals, system architecture,
hardware and software requirements, functional specifications,
non-functional specifications, data structures, algorithms,
user interface specifications, error handling, testing plan,
and security considerations.
---
## Content
Hi. I am working on a Shadowrun Cyberdeck with you and keep
exceeding the chat limit, due to constant errors in the scripts.
That's why I need to first create a proper white paper with
you so you can provide the python scripts as close to ready to
work as possible. What you need in which structure, please?
Thought for 67 seconds
We are going to create a white paper for a Shadowrun Cyberdeck
project. The goal is to have a structured document that will help
in generating Python scripts with minimal errors.
The white paper should include:
1\. **Project Overview**: A brief description of the project,
its goals, and the intended functionality of the cyberdeck.
2\. **System Architecture**: A high-level diagram or description
of how the components interact.
3\. **Hardware Requirements**: List of hardware components and
their specifications (if we are simulating hardware, we can skip
this or note that it's simulated).
4\. **Software Requirements**: Operating system, libraries,
dependencies, etc.
5\. **Functional Specifications**: Detailed descriptions of each
function the cyberdeck should perform.
6\. **Non-Functional Specifications**: Performance, security,
usability, etc.
7\. **Data Structures**: Definitions of key data structures
to be used.
8\. **Algorithms**: Description of core algorithms.
9\. **User Interface Specifications**: If there is a UI, describe
its components and behavior.
10\. **Error Handling**: How errors should be handled throughout
the system.
11\. **Testing Plan**: How the system will be tested.
12\. **Security Considerations**: Any security measures to be taken.
Since we are focusing on the software part (Python scripts), we can
skip hardware if it's simulated. However, for the sake of
completeness, we can note that.
Let's structure the white paper accordingly.
\---
**Project: Shadowrun Cyberdeck Simulator**
**1. Project Overview**
\- The cyberdeck simulator is a software representation of a cyberdeck
from the Shadowrun universe. It allows the user to perform matrix
actions such as hacking, data theft, and system intrusion in a
simulated environment.
\- The core functionality will include:
\- Scanning for networks and devices.
\- Connecting to a target.
\- Running hacking programs (scripts) against the target.
\- Stealing data, transferring funds, planting backdoors, etc.
\- Defending against intrusion countermeasures (ICE).
**2. System Architecture**
\- The system will be composed of:
\- **User Interface (CLI or GUI)**: For user interaction.
\- **Cyberdeck Core**: Main module that coordinates actions.
\- **Programs Module**: Contains the various hacking programs
(e.g., Exploit, Stealth, BruteForce, etc.).
\- **Network Simulator**: Simulates the network environment,
including hosts, firewalls, ICE, etc.
\- **Database**: For storing data about the state of the network,
the cyberdeck, and user progress.
\- The architecture is modular to allow for easy expansion.
**3. Hardware Requirements (Simulated)**
\- This is a software simulation. No specific hardware is required
beyond a standard computer.
**4. Software Requirements**
\- Python 3.8+
\- Libraries:
\- `argparse` for CLI (if using CLI)
\- `sqlite3` for database (or `json` for simpler storage)
\- `random` for generating random events
\- `time` for delays and timing
\- (Optional) `curses` for a TUI or `tkinter` for a GUI
**5. Functional Specifications**
\- **5.1. Scanning**
\- The user can scan for available networks and devices
in the vicinity.
\- Output: List of networks/devices with their security ratings
and other attributes.
\- **5.2. Connection**
\- The user can attempt to connect to a target device/network.
\- Success depends on the deck's attack rating vs. the target's defense.
\- **5.3. Running Programs**
\- Once connected, the user can run hacking programs.
\- Programs have different purposes and success probabilities.
\- Example programs:
\- `BruteForce`: Attempt to crack a password.
\- `Stealth`: Reduce the chance of detection.
\- `Exploit`: Exploit a vulnerability to gain higher access.
\- `DataScan`: Search for valuable data.
\- `Backdoor`: Plant a backdoor for easier future access.
\- **5.4. Data Transfer**
\- Transfer data (e.g., files, credentials) from the target to
the deck.
\- **5.5. Transfer Funds**
\- If the target is a financial system, transfer nuyen (currency)
to a designated account.
\- **5.6. ICE Evasion/Combat**
\- If detected, the system may deploy ICE (Intrusion Countermeasures
Electronics). The user can attempt to evade or fight the ICE.
\- **5.7. Logging Out**
\- Cleanly disconnect to avoid leaving traces.
**6. Non-Functional Specifications**
\- **Performance**: Actions should have realistic delays (simulated
with time.sleep) but not be too slow.
\- **Usability**: The interface should be clear and provide feedback
for every action.
\- **Modularity**: Easy to add new programs or network entities.
**7. Data Structures**
\- **Cyberdeck**:
\- Attributes: name, attack_rating, sleaze_rating, firewall_rating,
programs_installed, etc.
\- **TargetDevice**:
\- Attributes: name, defense_rating, alert_level, data_stored,
has_funds, access_level, etc.
\- **Program**:
\- Attributes: name, type (attack, stealth, utility), strength,
cost (in resources or time)
\- **Network**:
\- A collection of devices and their connections.
**8. Algorithms**
\- **Connection Algorithm**:
\- success = cyberdeck.attack_rating + dice_roll() > target.defense_rating
\- If successful, connection established. Otherwise, alert may be raised.
\- **Program Execution**:
\- For an attack program: success = program.strength + dice_roll()
> target.defense_rating
\- Adjust target's alert level based on the type of program and success.
\- **ICE Combat**:
\- Modeled as turn-based combat between the cyberdeck's programs and the ICE.
**9. User Interface Specifications**
\- We'll start with a CLI (Command Line Interface). The user is presented
with a menu of actions at each step.
Example flow:
> scan
Scanning... Found:
1\. Corporate Network (Security: Medium)
2\. Public Terminal (Security: Low)
> connect 1
Attempting to connect to Corporate Network... Success!
> run BruteForce
Running BruteForce... Success! Access level increased.
> run DataScan
Found: Secret plans.txt
> transfer Secret plans.txt
Transferring... Done.
> logout
Disconnected.
**10. Error Handling**
\- Use try-except blocks for critical operations
(like file I/O, network operations if any).
\- Validate user input to avoid crashes.
\- If an action fails, provide a reason (e.g., "Insufficient access",
"Connection lost", "Program not found").
**11. Testing Plan**
\- Unit tests for each module (using `unittest` or `pytest`).
\- Integration tests for the main workflow.
\- Simulate various hacking scenarios and edge cases.
**12. Security Considerations**
\- Since this is a simulation, real-world security is not a primary
concern. However, if we later add networking features,
we must consider security.
\---
Now, with this white paper, we can start writing the code in a structured way,
module by module.
Let me know if you want to adjust any part of this white paper, or if you are
ready to proceed with the code.
Below is a structured white paper outline tailored for your Shadowrun
Cyberdeck project. This will ensure we have precise requirements before coding,
minimizing errors and iterations. I'll include placeholders for your inputs.
* * *
**Shadowrun Cyberdeck Project White Paper Structure**
**1\. Project Overview**
* **Objective** : Simulate a Shadowrun cyberdeck with Matrix actions (hacking, intrusion, defense).
* **Scope** :
* CLI-based interface (expandable to GUI)
* Turn-based combat vs. ICE (Intrusion Countermeasures)
* Resource management (Memory, Programs, Deck Attributes)
* **Non-Goals** : Real networking, hardware integration.
**2\. Core Mechanics**
* **Deck Attributes** (Your input needed):
* `Attack Rating`, `Sleaze`, `Data Processing`, `Firewall`
* Example: `{"attack": 5, "sleaze": 3, "data_processing": 4, "firewall": 6}`
* **Programs** :
* List programs (e.g., `BruteForce`, `Stealth`, `Decrypt`). Specify:
* `Type` (Attack/Defense/Utility)
* `Memory Cost`
* `Success Probability Formula` (e.g., `Attack Rating + 2d6 > Target Rating`)
* **ICE Mechanics** :
* Define ICE types (e.g., `Patrol`, `Black`, `Raven`):
* `Detection Logic`, `Attack Damage`, `Counter-Hack Rules`
**3\. Data Structures (Critical for Script Accuracy)**
python
Copy
Download
EXAMPLE STRUCTURES - ADAPT AS NEEDED
class Cyberdeck:
def __init__(self, name, attributes, memory_max):
self.name = name
self.attributes = attributes # Dict of {attack, sleaze, ...}
self.memory_max = memory_max
self.loaded_programs = [] # List of active Program objects
class Program:
def __init__(self, name, program_type, memory_cost, effect):
self.name = name
self.type = program_type # "Attack", "Stealth", etc.
self.memory_cost = memory_cost
self.effect = effect # Function or success formula
class ICE:
def __init__(self, name, detection_threshold, damage):
self.name = name
self.detection_threshold = detection
This response is AI-generated, for reference only.
Continue
New chat
DeepThink (R1)
Search
AI-generated, for reference only
#knowledge-management #obsidian #shadowrun #cyberdeck #Shadowrun
#Cyberdeck #Matrix #Hacking #Intrusion #Defense #ICE #CLI #GUI
#Turn-based_combat #Resource_management
[[Technical Writing]] [[Cybersecurity]] [[Game Development]]
[[Shadowrun]] [[Cybersecurity]]