I need a seasoned Android reverse engineer to dig into my own application and show, step by step, how its drm_id, x-cit, x-sig, the full Client Attestation string, and any related request signatures are created on the device. Because I already hold full legal rights to the app, you can work freely with both static and dynamic approaches. I will provide the APK and any additional material you require. Primary working tools: Frida for live instrumentation and APKTool for unpacking and smali review. You are welcome to pull in JADX, Objection, or Ghidra if it speeds things up, but Frida and APKTool must anchor the workflow. The initial spotlight is on cryptographic operations. I strongly suspect an HMAC/SHA chain somewhere in the call flow, yet you may uncover RSA, AES, or custom native code as well. Please trace where each identifier is produced, note whether the code lives in Java, smali, JNI, or external libraries, and flag any use of Android Keystore, Keymaster, SafetyNet, or Play Integrity if present. Deliverables: • A concise report mapping the execution path that leads to every identifier and signature, including method names, class paths, and offsets when native code is involved. • Clarification of the exact crypto primitives (e.g., HMAC-SHA256, RSA-2048, etc.) and any keys, salts, or nonces referenced. • Frida or other hooking scripts you craft, plus reproduction steps so I can see the values generating in real time. Acceptance criteria: I can run python script to view these generated keys using the inputs, or if they are dynamic, dynamically generated ids. If this fits your expertise, let’s get started right away—I’m eager to see what’s really happening under the hood.