Proposal

GuardScript — Code Protector Platform

Project Proposal

Team Members:

1. Executive Summary

GuardScript is a script distribution platform with loader-based access control. Instead of distributing source code directly, the system serves script content through controlled endpoints with signature checks, timestamp/nonce validation, license enforcement, HWID binding, and workspace access policies.

The solution uses a serverless AWS architecture to reduce operational overhead, support scale, and satisfy cloud workshop objectives.

2. Problem Statement

Current Problems

The team identified three key issues in script delivery workflows:

1. Source code can be easily leaked or copied when shared manually
2. Lack of fine-grained access control for users or teams
3. Difficulty in tracking versions, access, and usage history
4. Absence of centralized management leading to fragmented data
5. Limited auditing, monitoring, and protection mechanisms
6. Deployment and security systems are often complex and costly

Solution

The proposed system addresses these issues through:

1. Loader-based script retrieval instead of direct source distribution.
2. Dual transfer protocols: v2 (XOR + response verification) and v3 (X25519 ECDH + AES-GCM).
3. License/HWID controls with access list policies.
4. Cloud-native observability using CloudWatch and application logs.

Benefits and ROI

1. Stronger control over script usage and distribution.
2. Better protection against API abuse via signed requests and rate limits.
3. Cost-efficient operation for student/demo workloads with pay-per-use services.

3. Solution Architecture

The architecture follows a serverless model with edge delivery for frontend and Lambda-based API processing.

Typical request flow:

Client (browser / loader)
  → CloudFront Distribution (SSL termination, cache layer)
    → Static assets: S3 bucket (frontend)
    → API /api/*, /files/*: Lambda Function URL origin
      → DynamoDB (users, workspaces, projects, licenses, logs, rate_limits, ...)
      → S3 (script/content objects)
  → API Gateway WebSocket (real-time updates)
  → CloudWatch Logs / Alarms / Dashboard

AWS Services Used

Component Design

1. Client Layer: web dashboard and loader clients (Python/Node/Lua).
2. Edge Layer: CloudFront routing and caching.
3. Compute Layer: Lambda handlers for auth, workspace, project, license, and loader protocols.
4. Data Layer: DynamoDB + S3.
5. Observability Layer: CloudWatch metrics/alarms/dashboard and application logs.

Monitoring & Observability

1. CloudWatch alarms are configured for Errors, Throttles, and p95 Duration.
2. A CloudWatch dashboard is provisioned for runtime visibility.
3. Application-level logs are stored by workspace for auditability.
4. Validation checklist includes auth, protocol, access-list, and alarm tests.

4. Technical Implementation

4.1. Technical Requirements

Functional Requirements:

1. User registration, login, and session-based authentication.
2. Workspace creation and management with role-based access control (owner, admin, member).
3. Script project management: CRUD for projects, files, and bundled content.
4. Script distribution via controlled loader endpoints (Protocol v2 and v3).
5. License key management with HWID binding, expiration, and usage tracking.
6. IP access control per workspace (blacklist and whitelist policies).
7. Team collaboration via workspace invitations and membership management.
8. Audit logging for all critical user and admin actions.
9. Real-time event broadcasting via WebSocket API.
10. Admin console for platform-level oversight and user management.

Non-Functional Requirements:

Technical Stack:

4.2. Implementation Phases

The project follows Agile Scrum methodology with 6 sprints (1 week each):

Sprint 1 — Analysis & Architecture Design

• Define system requirements
• Design AWS architecture
• Design database schema and APIs

Sprint 2 — Backend Foundation

• Set up Lambda project structure
• Implement Auth, User, Workspace APIs
• Integrate DynamoDB

Sprint 3 — Script & File Management

• CRUD for project, file, and content resources
• S3 integration for upload/download
• File tree structure and bundling

Sprint 4 — Security & Access Control

• Implement access control and licensing
• Integrate script protection loader (Protocol v2/v3)
• Build audit logging

Sprint 5 — Frontend & Realtime

• Develop dashboard UI
• Integrate APIs
• Configure WebSocket for real-time updates

Sprint 6 — CI/CD & Deployment

• Configure GitHub Actions pipeline
• Deploy via AWS SAM/CloudFormation
• Set up CloudWatch monitoring and alarms

5. Roadmap & Milestones

6. Cost Estimation

Typical monthly infrastructure cost (Free Tier / Small Scale): ~$4.32/month

Lambda and DynamoDB are mostly covered by the free tier at low usage levels.

7. Risk Assessment

Contingency Plan:

• If primary endpoint behavior fails → fallback to Lambda Function URL.
• If S3 is unavailable → retry with exponential backoff, log to CloudWatch.
• Use SAM/CloudFormation stacks for quick infrastructure recovery.

8. Expected Outcomes

Technical Outcomes:

• End-to-end AWS serverless deployment with validated API and loader flow.
• Dual loader protocol support with security controls (signature, HWID, rate-limit).
• Baseline observability for runtime health and performance.
• Reproducible deployment process aligned with workshop requirements.

Long-term Value:

• Extendable architecture for additional loaders and governance features.
• Reusable cloud-native reference for future FCJ workshop projects.

9. Future Improvements

1. Add production-ready SES email workflow for invitations.
2. Add AWS WAF managed rules for edge protection.
3. Upgrade S3 encryption controls from SSE-S3 to SSE-KMS CMK where needed.
4. Add AWS Budgets and Cost Anomaly Detection.
5. Increase automated test coverage (unit/integration/security checks).