How maxamin/craxsrat-v6.7-source-code works
1. What this repository is
- This is a single Visual Studio solution for a Windows desktop C# application built with WinForms on .NET Framework.
- Based on the README and the file names, it functions as the builder/control panel for an Android RAT, not as the Android payload itself.
2. Top-level structure
- The repo is dominated by one project: CraxsRat/.
- Most features are implemented as form-based screens with paired .cs, .Designer.cs, and .resources files, which indicates a highly UI-driven operator console.
- obj/ and .vs/ are build/IDE artifacts and not part of the runtime architecture.
3. Operator console as the center of the system
- The application appears to present a central control interface for managing infected devices.
- Feature-specific windows include device, file, app, call, SMS, camera, microphone, location, clipboard, keylogger, shell, and screen modules.
- This suggests a command-and-control dashboard pattern, where the user of the tool issues actions and views exfiltrated data.
4. Remote device management subsystems
- Many forms map directly to device capabilities:
- ContactsManager, CallsManager, Calls_Records, SMSManager, TextMessage
- FileManager, Download, Upload
- CameraManager, Microphone, LocationManager
- ScreenShoter, ScreenReader, ScreenReaderV2, ScreenLoger
- Keylogger, KeyboardManager, ClipboardManager
- Applications, AppsProperties, WebViewMonitor, Win_Users
- These likely represent the commanding, viewing, and extraction side of the malware.
5. Payload builder and packaging path
- Files like Build, Jector, Faker, CypherRat, requestapk, SelfRemove, and PermissionsManager point to a payload generation pipeline.
- The README explicitly mentions obfuscation, anti-removal, accessibility abuse, and Play Protect bypass, so this app likely builds a customized APK with embedded configuration and evasion features.
6. Configuration and connection management
- EditConnections, EditSocket, Ports, Settings, CraxsSettings, AccountManager, and LanguageSelector indicate a dedicated configuration layer for how the panel and payload communicate.
- The architecture likely stores operator preferences, connection parameters, and per-build options in local settings/resources rather than in a separate service.
7. Communication/runtime core
- The generic classes (Module0–Module13, GClass*, GModule*, NativeMethods*, GWebClient0, GProgressBar0, GRichTextBox0, GUserControl0) suggest a shared runtime library used across the forms.
- This layer likely contains the common networking, UI plumbing, marshaling, and platform interop used by the feature screens.
8. Data flow
- The likely flow is:
- operator configures a build or connection,
- the builder produces an Android payload,
- the payload connects back to the operator console,
- feature modules exchange commands and results,
- collected artifacts are displayed in the relevant forms or logs.
- The forms Report, craxscallslog, craxsnotification, and information look like aggregation points for incoming device data.
9. Persistence, evasion, and abuse features
- The README calls out accessibility exploitation, anti-removal, and Google Play Protect bypass.
- In the UI, this is reflected by modules like PermissionsManager, SelfRemove, DialogPloice, nonetform, and Faker, which likely support stealth, permission prompts, and persistence-related workflows.
- These are not separate services; they appear embedded into the same desktop control application.
10. UI and resource architecture
- The project is resource-heavy: most forms have paired .resources files and designer-generated layouts.
- This indicates a large modal UI surface rather than a small command-line or service-based backend.
- Custom controls such as GControl0, GProgressBar0, GRichTextBox0, and GUserControl0 suggest a reusable theming/UI toolkit inside the project.
11. Boundary between desktop panel and Android target
- The repository shown here is the Windows-side control and builder application.
- The Android target is implied by the README and the payload-building forms, but its source is not present as a separate project in this tree.
- For an architecture diagram, it is useful to draw two major boundaries: operator workstation app and infected Android device/payload.
12. Key takeaway for a diagram
- The architecture is best represented as a single desktop WinForms control suite with:
- a configuration/build subsystem,
- a communication layer,
- many feature-specific device-control screens,
- and shared runtime/helper classes underneath.
- There is no evidence here of microservices or separate backend APIs; the control plane logic appears concentrated inside this one C# application.
Main entry points: Module0.cs Runtime · Build.cs Build · Report.cs Report · Applications.cs Apps
Components 22
Desktop Panel
WinForms operator console and its feature screens.
- Report · Central view for incoming device data and operator status.
CraxsRat/Report.cs - Connections · Configures how the panel and payload communicate.
CraxsRat/EditConnections.cs - Settings · Stores operator and application options.
CraxsRat/CraxsSettings.cs - Files · Browse, download, and upload remote files.
CraxsRat/FileManager.cs - SMS · Views and manages device text messages.
CraxsRat/SMSManager.cs - Media · Captures camera and microphone streams.
CraxsRat/CameraManager.cs - Screen · Screenshots, screen reading, and log capture tools.
CraxsRat/ScreenShoter.cs - Input · Captures keystrokes, keyboard state, and clipboard data.
CraxsRat/Keylogger.cs - Shell · Interactive command terminal for the remote device.
CraxsRat/ShellTerminal.cs - Apps · Lists installed applications and their properties.
CraxsRat/Applications.cs - Identity · Contacts, call history, and related phone records.
CraxsRat/ContactsManager.cs - Data Views · Consolidated reports, notifications, and activity views.
CraxsRat/craxsnotification.cs
Build Pipeline
Payload generation, packaging, and evasion-related configuration.
- Build · Assembles a customized Android payload from operator choices.
CraxsRat/Build.cs - APK Request · Initiates or prepares the APK generation flow.
CraxsRat/requestapk.cs - Hardening · Permissions, anti-removal, and persistence-related build options.
CraxsRat/PermissionsManager.cs - Cleanup · Supports stealth and removal-related behavior after deployment.
CraxsRat/SelfRemove.cs - Branding · Faker, dialogs, and social-engineering themed build controls.
CraxsRat/Faker.cs
Shared Runtime
Common UI, networking, and helper classes reused across forms.
- Runtime · Common code for forms, networking, and interop.
CraxsRat/Module0.cs - Network · Shared client used for communication and requests.
CraxsRat/GWebClient0.cs - UI Kit · Reusable themed controls used across the WinForms surface.
CraxsRat/GControl0.cs - Interop · Platform invoke and low-level Windows support code.
CraxsRat/NativeMethods.cs
Android Payload
Conceptual target-side implant built and controlled by this application.
- Payload · Conceptual Android side that receives the build output and connects back.
Connections 33
- Report → Data Views: surfaces · Operator dashboard displays aggregated logs and notifications.
- Report → Identity: opens · Dashboard links into phone identity, contacts, and call views.
- Report → Apps: opens · Dashboard links into application inventory.
- Connections → Build: feeds · Connection settings are used by the builder and payload configuration.
- Settings → Build: configures · Local preferences influence build and operator behavior.
- Build → APK Request: starts · Build flow requests or prepares the APK artifact.
- Build → Hardening: applies · Build pipeline includes permission and evasion options.
- Build → Cleanup: embeds · Build pipeline can include self-removal and stealth behavior.
- Build → Branding: packages · Build pipeline can disguise the payload and craft prompts.
- APK Request → Payload: emits · Builder produces the Android-side artifact.
- Hardening → Payload: shapes · Permissions and anti-removal settings affect the payload.
- Cleanup → Payload: modifies · Cleanup/self-removal logic is embedded into the payload.
- Branding → Payload: disguises · Social-engineering and fake UI elements are packaged into the payload.
- Network → Payload: communicates · Shared client underpins panel-to-payload traffic.
- Runtime → Network: uses · Core runtime depends on common communication helpers.
- Runtime → UI Kit: uses · Core runtime is rendered through custom controls.
- Runtime → Interop: uses · Core runtime relies on native Windows interop.
- Runtime → Files: powers · Shared core backs feature forms for remote file control.
- Runtime → SMS: powers · Shared core backs messaging features.
- Runtime → Media: powers · Shared core backs camera and microphone features.
- Runtime → Screen: powers · Shared core backs screen capture and screen log modules.
- Runtime → Input: powers · Shared core backs input-capture modules.
- Runtime → Shell: powers · Shared core backs the remote shell interface.
- Runtime → Apps: powers · Shared core backs app inspection screens.
- Runtime → Identity: powers · Shared core backs contacts and calls modules.
- Payload → Files: serves · Remote file operations act on the connected device.
- Payload → SMS: serves · Messaging data is retrieved from the connected device.
- Payload → Media: serves · Camera and microphone data come from the connected device.
- Payload → Screen: serves · Screen capture features operate on the connected device.
- Payload → Input: serves · Keystrokes and clipboard data are collected from the connected device.
- Payload → Shell: serves · Shell commands are executed on the connected device.
- Payload → Apps: serves · Application inventory is pulled from the connected device.
- Payload → Identity: serves · Contacts and call records are exposed by the connected device.