TMV-ORCA: TLS & Lyman-α Tomography

• TMV-ORCA is a dual-domain framework that automates TLS vulnerability analysis in Android via dynamic instrumentation and LLM-based classification, while also optimizing 3D Lyman-α reconstructions using constrained multiscale annealing.
• For TLS, the system deploys ART-TI with live MitM probes to capture detailed calling contexts, achieving classification precision of up to 0.97 for vulnerability taxonomy assignment.
• For cosmology, the ORCA algorithm minimizes voxel RMS error by 10–20% compared to Wiener filters, ensuring physical constraints on absorption and enhanced computational efficiency with GPU-based solvers.

TMV-ORCA denotes a class of methods and frameworks in two distinct domains: (1) attribution and root-cause analysis of Transport Layer Security Man-in-the-Middle vulnerabilities in Android applications, and (2) the Optimized Reconstruction with Constraints on Absorption (ORCA) algorithm for Lyman-α forest tomography when the pipeline incorporates a Transfer-Matrix Variance (TMV) approach. This article provides a technical overview of both uses, their algorithms, evaluation metrics, taxonomy, and applications, as documented in recent peer-reviewed literature (Yang et al., 30 Jan 2026, Li et al., 2021).

1. TMV-ORCA for TLS Man-in-the-Middle Vulnerabilities in Android

TMV-ORCA is the attribution and analysis component within the Okara framework, developed to automate the localization, categorization, and attribution of TLS Man-in-the-Middle (MitM) vulnerabilities in Android applications. The methodology integrates dynamic instrumentation with a LLM-based code classifier to systematically analyze discovered TLS validation pathways and identify their root causes (Yang et al., 30 Jan 2026).

1.1 Architectural Modules

TMV-ORCA consists of two synergistic modules:

• Dynamic Instrumentation & Trace Collection: Utilizes the Android Runtime Tooling Interface (ART-TI) to monitor Java class load events, immediately hooking TLS validation entry points such as X509TrustManager.checkServerTrusted, HostnameVerifier.verify, and WebViewClient.onReceivedSslError. It records full calling contexts for each observed TLS flow, including certificate chains, hostnames or URLs, stack traces, and outcome status. Live MitM probes further disambiguate execution paths.
• Vulnerable Code Classification: Extracts the hooked method's code snippet and interface type, forwarding them to an LLM-based classifier. The classifier assigns fine-grained labels from a bespoke taxonomy and outputs a structured mapping associating discovered issues to apps, FQDNs, code snippets, and taxonomy categories.

Both modules together automate the previously manual process of code localization and vulnerability taxonomy assignment at scale.

2. LLM-Based Vulnerable Code Classification

2.1 Input Representation and Prediction

Let $S = \{s_1, ..., s_N\}$ be the set of extracted code snippets and $Y$ the set of taxonomy labels ($|Y| \approx 20$). For snippet $s_i$, the input is $$x_i = \langle \text{code} = s_i, \text{interface} = I_i \rangle$$. The LLM parameterizes the conditional distribution $P(y \mid x_i; \theta)$, and predicted labels are $$\hat{y}_i = \operatorname{argmax}_{y \in Y} P(y \mid x_i; \theta)$$. Few-shot in-context learning using examples of the form $(x^{(j)}, y^{(j)})$ is used in practice.

An implicit feature extractor $\phi: s_i \mapsto \mathbb{R}^d$ projects code to an embedding vector; a linear classification head with softmax produces $$P(y \mid x_i) = \operatorname{softmax}(W \cdot \phi(x_i) + b)_y$$. Prompt engineering includes templates with an “Unknown” category to accommodate obfuscated or indeterminate code.

2.2 Taxonomy of TLS Validation Vulnerabilities

TMV-ORCA defines a hierarchical, interface-partitioned taxonomy, including:

• TrustManager ($Y$0)
  • T0: Secure TrustManager
  • T1: Empty TrustManager
  • T2: Non-empty but insecure TrustManager, with subcategories (e.g., T2-A: checks only certificate validity, T2-C: checks only subject fields, etc.)
  • TU: Unknown TrustManager
• WebViewClient ($Y$1)
  • W0: Secure handling (e.g., handler.cancel())
  • W1: Unconditional ignore (handler.proceed())
  • W2: Conditional ignore (with subtypes: user dialogs, error-specific, state-dependent)
  • WU: Unknown WebViewClient
• HostnameVerifier
  • H0: Secure verify()
  • H1: Always returns true
  • H2: Flawed logic (H2-A: compares input hostname, H2-B: partial match)
  • HU: Unknown HostnameVerifier

Snippet-to-label mapping is direct: $Y$2.

3. Attribution Methodology and Pipeline

3.1 Trace-to-Vulnerability Correlation

For each execution trace tuple $Y$3 and set $Y$4 of vulnerable FQDNs from TMV-Hunter:

• Hostname correlation: $Y$5 receives a hostname $Y$6 and $Y$7
• Certificate correlation: Match Common Name and SANs in $Y$8 to $Y$9, accommodating wildcards
• Live MitM probe: When multiple domains share a certificate, only code paths accepting invalid certs under MitM are considered vulnerable

3.2 Third-Party Library Attribution

The procedure identifies the responsible party for each snippet via package prefix aggregation:

1. Extract package prefix $|Y| \approx 20$0 from $|Y| \approx 20$1
2. Cross-reference $|Y| \approx 20$2 against known app-local prefixes
3. Prefixes present in $|Y| \approx 20$3 apps are library candidates
4. Manual mapping via SDK index or code search assigns a library name
5. Assign $|Y| \approx 20$4

Pseudocode:

$P(y \mid x_i; \theta)$0

4. Evaluation and Empirical Results

4.1 Locator Coverage Metrics

Key metrics for code localization coverage include:

Metric	Definition	Observed Value
$|Y| \approx 20$5	Fraction of vulnerable FQDNs with located root cause code snippets: $|Y| \approx 20$6	$|Y| \approx 20$7
$|Y| \approx 20$8	Fraction of vulnerable TLS flows with code localization: $|Y| \approx 20$9	$s_i$0
App-All	Fraction of apps where all vulnerabilities are explained by code localization	$s_i$1
App-One	Fraction with at least one explained issue	$s_i$2

4.2 Classifier Accuracy

On a held-out set of 365 manually labeled snippets:

Category	Precision	Recall	$s_i$3 Score
All	0.97	0.97	0.97
T2 Subcategories	0.92	0.90	0.90
W2 Subcategories	0.96	0.95	0.95
H2 Subcategories	1.00	0.88	0.94

4.3 Real-World Attributions

• Total vulnerable apps detected: 8,374
• Code snippets located: 8,065 (3,904 unique classes)
• Third-party origin: $s_i$4 of snippets, affecting 48.98% of vulnerable apps and 28.9% of vulnerable FQDNs
• Most prevalent third-party libraries include JPush (Aurora SDK), UMeng+, Baidu Map SDK, and Bugly (Tencent)
• Example T2-A snippet: $P(y \mid x_i; \theta)$1

5. Limitations and Prospective Enhancements

5.1 Known Limitations

• Java-only coverage: No visibility into native (C/C++, e.g. libcurl) TLS logic
• Dynamic-only analysis: Paths unexercised by GUI agent are not analyzed
• App anti-instrumentation defense may hinder analysis
• Manual effort required for novel library/prefix mapping

5.2 Future Directions

• Incorporate eBPF or low-overhead native hooks for native TLS logic
• Symbolic/concolic execution to increase code path exploration
• Semi-automated library mapping by code similarity search
• LLM fine-tuning for improved taxonomy assignment
• iOS extension to Objective-C and related API categories

6. TMV-ORCA: Optimized Reconstruction with Constraints on Absorption

In cosmological large-scale structure tomography, TMV-ORCA denotes a variant of ORCA employing a Transfer-Matrix Variance scheme in multiscale annealing pipelines (Li et al., 2021). ORCA optimizes the voxelized 3D Lyman-α flux field reconstruction given absorption constraints, outperforming Wiener filter baselines.

6.1 Mathematical Formulation

• Let $s_i$5: observed, continuum-normalized Lyman-α transmitted flux along all sight lines ($s_i$6)
• Let $s_i$7: binned 3D flux contrast (voxelized field)
• Linear model: $s_i$8 ($s_i$9: skewer-selector, $$x_i = \langle \text{code} = s_i, \text{interface} = I_i \rangle$$0)
• ORCA finds $$x_i = \langle \text{code} = s_i, \text{interface} = I_i \rangle$$1 minimizing:

$$x_i = \langle \text{code} = s_i, \text{interface} = I_i \rangle$$2

• $$x_i = \langle \text{code} = s_i, \text{interface} = I_i \rangle$$3
• Absorption constraint penalty:

$$x_i = \langle \text{code} = s_i, \text{interface} = I_i \rangle$$4

• Regularization parameters $$x_i = \langle \text{code} = s_i, \text{interface} = I_i \rangle$$5 selected empirically.

6.2 Algorithmic Implementation

• Composite multiscale loss:

$$x_i = \langle \text{code} = s_i, \text{interface} = I_i \rangle$$6

• Gaussian smoothing $$x_i = \langle \text{code} = s_i, \text{interface} = I_i \rangle$$7, with “annealing” (start with large scale, decrease to fine).
• Solver: L-BFGS (quasi-Newton), gradient by automatic differentiation.

6.3 Performance Metrics and Empirical Results

Metric	WF Baseline	ORCA
Voxel RMS error	Reference	Reduced by 10–20%
Void overlap fraction	55.9%	58.0%
Equivalent ∆sight-lines	—	+30–40%

On CLAMATO survey data, ORCA identified voids with 70.5% overlap to WF catalog and matched mock redshift-space void fractions.

6.4 Physical Impact and Limitations

• By enforcing $$x_i = \langle \text{code} = s_i, \text{interface} = I_i \rangle$$8, ORCA eliminates non-physical “overshoots,” yielding improved reconstructions in under- and over-dense regions.
• Computational efficiency: GPU L-BFGS is 10–100× faster than PCG Wiener methods for the same voxel grid.
• Limitation: Constraints are less effective as sight-line density decreases ($$x_i = \langle \text{code} = s_i, \text{interface} = I_i \rangle$$9), with behavior reverting to WF-like.

7. Summary

TMV-ORCA encompasses advanced methods for vulnerability attribution in Android TLS logic and for regularized 3D reconstruction in cosmological Lyman-α tomography. Both domains leverage algorithmic innovations—LLMs and quasi-Newton optimizers respectively—to outperform traditional baselines, automate complex root-cause analyses, and facilitate large-scale, systematic research and remediation (Yang et al., 30 Jan 2026, Li et al., 2021).