AssessArc: System Architecture and Methodology of a Mobile Workbench for Authorized Security Assessment

Abstract

WepresentAssessArc,anAndroidapplicationstruc-tured as a modular workbench for authorized security as-sessment, oriented toward analysts who lack a conventional workstation:thephonebecomestheprimaryreconnaissanceand manual-testing surface for discovering and documenting vul-nerabilities in scope. The system integrates rules-of-engagement (RoE) recording, vulnerability-assessment (VA) reconnaissance, manual penetration-testing (PT) aids, offline utilities, and on-device review of saved scan artifacts. Its architecture is delib-erately operator-driven: functional areas share governance con-cepts (gated network activity for the highest-risk emitters, local textual evidence with optional cryptographic fingerprints, and manualhand off betweentools )insteadofamonolithicautomated pipeline that could obscure intent or exceed scope silently. We articulate (i) the RoE lifecycle and its selective enforcement model,(ii)methodologicalpatternsofthefourVAmodules and twelve PT capabilities, (iii) offline utilities and the report repository including deduplication semantics, (iv) cross-cutting workflowsandpersistencetrade-offs,and(v)limitationsrelevant to research reproducibility, security properties of on-device stor-age, and responsible use. The contribution is architectural and methodological: a coherent field-oriented decomposition aligned with mainstream PT/VA frameworks, suitable for adaptation, extension, or formal verification in future work.

Introduction

AssessArc is a mobile-first penetration testing and vulnerability assessment workbench designed for authorized security professionals who need to perform security assessments without relying on laptops or cloud-based platforms. The application emphasizes local-first operation, governance, and evidence management, making it suitable for fieldwork while maintaining accountability.

Key Design Principles

• Human-in-the-loop control: All scans and network operations require explicit user actions, preventing unintended traffic generation.
• Governance through Rules of Engagement (RoE): High-risk network activities, such as vulnerability scans and HTTP testing, require a recorded Rules of Engagement before execution.
• Separation of evidence: Formal scan reports, encrypted engagement records, and informal workflow notes are stored separately to preserve evidentiary integrity.
• Traceability: Optional engagement metadata is attached to reports to improve provenance, although it does not replace formal legal authorization.

Rules of Engagement (RoE)

Before performing network reconnaissance, users must record engagement details including:

• Organization and authorized scope
• Ticket/reference number
• Approver and assessor names
• Validity period

These records are securely stored using encrypted application preferences and automatically expire to prevent unauthorized reuse.

Application Components

The application consists of five major modules:

• Rules of Engagement management
• Utilities (offline encoding, hashing, JSON formatting)
• Vulnerability Assessment (VA)
• Penetration Testing (PT) tools
• Saved Reports

Vulnerability Assessment Features

The VA module provides:

• SSL Check: Examines HTTPS configuration, certificates, security headers, cookies, and assigns a risk score.
• Subdomain Scanner: Discovers active subdomains using DNS and HTTP probing.
• Directory Scanner: Identifies accessible directories and files from wordlists.
• Virtual Host Scanner: Detects hidden virtual hosts on shared infrastructure.

Reports are generated only when useful findings exist, reducing unnecessary files.

Penetration Testing Tools

The PT module includes:

• HTTP Request Laboratory
• Encoder/Decoder
• JWT Inspector
• Response Analyzer
• Authentication Header Tester
• CORS Tester
• Wordlist Mutator
• SSRF URL Helper
• Open Redirect Tester
• Workflow notes and security checklists

Only the HTTP Request Laboratory is gated by the Rules of Engagement because it actively sends requests to target systems.

Utilities

Offline tools provide:

• Encoding and decoding
• Hash generation
• JSON validation and formatting

These functions do not require an active engagement since they do not generate network traffic.

Report Management

Assessment reports are stored locally as plaintext files and include:

• Search and filtering
• Sharing through standard Android mechanisms
• Duplicate detection using SHA-256 fingerprints
• Optional engagement metadata for improved traceability

Workflow notes remain separate from formal assessment evidence.

Workflow

A typical assessment involves:

1. Registering or renewing the Rules of Engagement.
2. Running vulnerability scans.
3. Saving and reviewing reports.
4. Conducting manual penetration testing.
5. Using offline utilities for analysis.
6. Exporting or deleting reports as needed.

Limitations

The paper notes several limitations:

• Engagement information is self-declared and not verified with enterprise systems.
• Scan results rely on heuristics and require expert validation.
• Reports are stored locally without cloud synchronization or role-based access control.
• The tool supports only one active engagement at a time.
• It must only be used on systems where explicit authorization has been granted.

Conclusion

We described AssessArc as a mobile, modular workbench coupling RoE recording, VA reconnaissance, pentest aids, utilities, and local report review, with deep methodological patterns for each surface. The architecture emphasizes selec-tive gating, heterogeneous persistence, deduplicated textual evidence,andmanualcompositionbetweentools.Futurework may explore external ticket integration, stronger evidence packaging(e.g.,signedexports),formalmodelsofengagement state, and broader automation that stays within policy.

References

[1] Penetration Testing Execution Standard (PTES) Technical Guidelines.http://www.pentest-standard.org (accessed 2026). [2] OWASPFoundation,“OWASPWebSecurityTestingGuide,”stablereleasedocumentation.https://owasp.org/www-project-web-security-testing-guide/ (accessed 2026). [3] NIST, “Technical Guide to Information Security Testing and Assess-ment,” SP 800-115 Rev. 1, 2020. [4] Google, “Android Security Overview,” Android Open Source Projectdocumentation (app sandbox, storage model). [5] M. Jones, J. Bradley, and N. Sakimura, “JSON Web Token (JWT),”IETF RFC 7519, May 2015.

Copyright

Copyright © 2026 Prof. Rushikesh S. Bhalerao, Vishal Satle, Satyam Katkade, Tanvi Sangale, Tanishq Medhane. This is an open access article distributed under the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.