Status: ✅ IN PROGRESS
Date: 2026-02-01
Focus: String constant extraction and pattern identification
- ✅ phase4_extractor.rs (150 lines) - Simplified string extraction
- Scans entire binary for printable ASCII strings
- Categorizes by pattern (URLs, headers, servers)
- Completed in ~2 seconds
- Total strings found: 81 (first 1000 scanned)
- URLs/Endpoints: 26 identified
- HTTP Headers: 47 identified
- Server Addresses: 10 identified
gpu_api
https
Internal-Skinning.compute
api_name
arcore_unity_api
http:\\
$func.commandbuffer
http://
http:
https://
[... 16 more]
Observations:
- HTTP/HTTPS protocol variants detected
- API naming patterns found
- Compute shader references (not typical game)
- Mixed protocol indicators (both http:// and http:\)
Content-Disposition: %s%s%s%s%s%s%s
User-Agent
Content-Length
Proxy-Authorization: Basic
Content-Length:
getContentResolver
setContentView
CompleteContent
[... 39 more]
Observations:
- Standard HTTP headers present
- Format string patterns with % markers
- Android-specific APIs (getContentResolver, setContentView)
- Content negotiation headers
Can't complete SOCKS4 connection to %d.%d.%d.%d:%d...
User was rejected by the SOCKS5 server...
HTTP server doesn't seem to support byte ranges...
A HTTP server error occurred...
server hello, session id len.: %zu
server hello, compress alg.: 0x%02X
Undocumented SOCKS5 mode attempted...
ARCore Unity Plugin...
physx/source/lowlevel...
Observations:
- Error messages rather than actual server addresses
- SOCKS protocol handling code
- TLS/SSL handshake messages
- ARCore and PhysX framework references
The extracted strings show:
- HTTP/HTTPS protocol stacks
- SOCKS proxy protocol support
- TLS handshake handling
- Complex networking infrastructure
This indicates the binary contains a complete networking library rather than just game API calls.
- PhysX physics engine
- ARCore AR support
- Unity engine base classes
- Networking frameworks (libcurl-like)
The Phase 3 ADRP addresses may point to:
- Dynamically computed addresses
- Encrypted constant pools
- Obfuscated data structures
This explains why direct string extraction didn't find actual server IPs or API endpoints.
Given the initial results, we need to:
Use the 127 function calls identified in Phase 3 to trace:
- Which functions are called from 0xf4d340 (server loader)
- Which functions are called from 0xf98ff8 (HTTP builder)
- Which functions are called from 0xe7f6c0 (token handler)
Instead of static string extraction:
- Trace register values through function calls
- Identify where constants are loaded/computed
- Find actual server addresses in runtime data
Map the complete flow:
0xf4d340 calls → 0x10e7bda8, 0x10e7c4bc, 0x1088638
0xc3a2b8 calls → [multiple orchestration calls]
0xf98ff8 calls → [HTTP protocol functions]
0xe7f6c0 calls → [signature/crypto functions]
- Build call graph from Phase 3 function calls data
- Trace data flow through identified helper functions
- Identify obfuscation/encryption patterns
- Reverse engineer constant pool access
- Dynamic analysis using frida/debugger
- Traffic capture during actual API calls
- Signature verification algorithm
- Token validation logic
manual_analysis/phase4_extraction/PHASE4_EXTRACTION.txt- Initial string scan results
Phase 4 initial analysis reveals the binary uses sophisticated networking infrastructure with likely obfuscation. Direct string extraction insufficient. Next phase requires deeper call graph analysis and runtime behavior analysis.
Readiness: Ready to proceed with call graph extraction (Phase 4 part 2)