OSCAR

A Modular Payload Generation Framework
_{From a Windows prototype to a more extensible security research project.}

“There's chaos in you.”

Oscar is a Windows-focused payload generation project that uses a Python command-line interface to coordinate native components written in C, C++, and Assembly.

The project started in 2022 as an experiment in simplifying the process of configuring and building native Windows executables. Rather than treating every implementation as a separate tool, Oscar explores how a common interface can organize components and provide a consistent workflow.

The original prototype focuses on a Windows keylogging component with local logging and Telegram reporting. The repository also contains C and Assembly implementations at different stages of completeness.

Oscar is now intended to evolve beyond its original prototype toward a better-organized, modular architecture.

The current codebase contains the following elements:

• Command-line interface: A Python menu for navigating the available options.
• Native components: Windows-focused implementations in C, C++, and Assembly.
• Build orchestration: An early Python Builder intended to prepare source files and invoke a native compiler.
• Component organization: Source files grouped by operating system, component type, and programming language.
• Planned modularity: A direction for separating configuration, build logic, and individual implementations.

The current Builder has path and build-validation issues, so the presence of a component in the repository does not guarantee that its complete workflow works out of the box.

Oscar's original design can be understood as three layers:

The long-term objective is to make these layers independent, so that a change to one component does not require rewriting the entire application.

Oscar is a prototype under active development, not a production-ready framework.

Important: These statuses describe the source code currently available in the repository. They should not be interpreted as claims that every component compiles or works reliably.

Oscar/
├── Oscar.py
├── Payloads/
│   └── windows/
│       └── keylogger/
│           ├── C/
│           │   └── keylog.c
│           ├── C++/
│           │   └── keylog.cpp
│           └── Assembly/
│               └── keylog.asm
├── modules/
│   ├── banner.py
│   └── gnt.py
├── icon/
├── requirements.txt
├── log.log
└── README.md

This layout reflects the files currently identified in the repository. The Builder still contains references to an older CPP-Payload/ directory, which needs to be reconciled with the current Payloads/ layout.

• Python 3.8 or later
• Git
• colorama for the Python command-line interface
• A compatible native compiler and required libraries for native components

git clone https://github.com/Arash-abraham/Oscar.git
cd Oscar

python -m pip install colorama

The current requirements.txt includes dependencies that should be reviewed. In particular, ctypes is part of Python's standard library and normally does not need to be installed through pip.

python Oscar.py

The interface presents a menu for the available options. However, the Windows Builder currently references source paths that do not match the repository layout, so successful payload generation should not be assumed until that issue is resolved.

The current prototype has several limitations that are relevant to anyone studying or contributing to the code:

• Path consistency: The Builder references an outdated source directory.
• Build verification: Compiler exit status and output-file existence are not reliably checked.
• Input validation: Some menu and build inputs need stricter validation.
• Network security: The C and C++ implementations disable TLS certificate verification.
• Assembly completeness: The Assembly source contains placeholder sections and requires independent verification.
• Dependency management: The Python dependency list needs to be aligned with actual imports and build requirements.

These are known areas for improvement, not features that should be considered complete.

• Reconcile source paths across the Builder and payload directories.
• Correct menu input handling.
• Validate build inputs and handle failures explicitly.
• Replace fixed delays with actual process-result checks.
• Review dependency declarations.

• Separate interface, configuration, and build responsibilities.
• Define a consistent interface for individual components.
• Add a configuration format and component registry.
• Improve platform-specific path handling.
• Document the status and requirements of each component.

• Add automated tests for non-destructive functionality.
• Verify compiler compatibility and build reproducibility.
• Restore proper TLS certificate verification.
• Document component behavior, data handling, and network communication.
• Test in isolated, explicitly authorized environments.

• Explore a modular extension system.
• Evaluate additional operating-system support.
• Add clearer diagnostics and developer documentation.

Future items are goals, not promises of existing functionality.

Contributions are welcome, particularly in the areas of code quality, documentation, testing, dependency management, and architecture.

When submitting a bug report, include:

• Your operating system and Python version
• The affected file or component
• The steps required to reproduce the issue
• Relevant error output
• Expected behavior versus actual behavior

Please avoid including real credentials, bot tokens, private logs, or other sensitive information in public issues.

Oscar is intended for educational experimentation, controlled malware analysis, and authorized security research.

Some existing components can capture keyboard input, collect system information, and transmit data to a configured Telegram destination. These behaviors are sensitive and must be clearly understood before any testing.

Only assess systems for which you have explicit authorization. Do not use the project for covert monitoring, unauthorized data collection, or access to systems belonging to others.

Oscar was inspired by Oscar Isaac and the period when development began in 2022. The name stayed with the project as it evolved.

_{Built for learning, experimentation, and responsible security research.}