Improving app encryption

[m1ga]

Talking about alternatives to the current ti.cloak implementation to encrypt js files and decrypt them at runtime.

[mbender74]

Here is what I (and the AI buddy) discovered so far (iOS):

Short:

1. Remove key/IV from the binary — Derive them at runtime instead (white-box AES, keychain, device ID)
2. Obfusce string constants — Use hash-based lookups instead of plaintext filenames in initWithObjectsAndKeys
3. Remove _index_.json — No longer include it unencrypted in the application bundle
4. Obfusce data section layout — Encrypt NSRange, inject decoy data, XOR masking
5. Binary stripping & anti-analysis — Clean up symbol tables, compiler obfuscation flags
6. Runtime integrity checks — Anti-debugging, code signature verification

Plan: Hardening Titanium iOS IPA Against JS File Recovery

Note: This document is a security analysis and hardening plan. It describes theoretical attack vectors and defensive measures. No changes to the SDK are being implemented — this serves as a reference for understanding and improving the protection of JS files in production IPAs.

Current Attack Vectors

The existing decryptor (titanium_ipa_decryptor.py) successfully recovers JS files from production IPAs through these vectors:

Vector 1: Self-Contained Encryption Key

Problem: The AES-128-CBC key and IV are embedded as the last 32 bytes of the data[] array inside ApplicationRouting.m. Anyone who can read the Mach-O binary's __DATA,__data section can extract them.

Location: iphone/templates/build/ApplicationRouting.m — the <%- bytes %> template variable includes key+IV inline with the encrypted data.

Current recovery method: Scan the data section for a high-entropy 32-byte window, validate by attempting AES-CBC decryption of adjacent data.

Vector 2: Readable Data Sections (FairPlay Bypass)

Problem: Apple's FairPlay DRM encrypts the __TEXT segment (executable code) but leaves __DATA segments readable. All encryption data — the data[] array, ranges[], key, and IV — resides in __DATA,__data, which remains plaintext in App Store IPAs.

Current recovery method: Parse __DATA,__data directly; no code disassembly needed.

Vector 3: Filename Leakage via __cfstring

Problem: The initWithObjectsAndKeys: dictionary in ApplicationRouting.m stores all mangled filenames as NSString constants. These are compiled into __DATA,__cfstring and __TEXT,__cstring sections, which remain readable even in FairPlay-encrypted binaries.

Current recovery method: Parse __cfstring entries to find all mangled filenames in source-code order, matching them 1:1 to decrypted range indices.

Vector 4: _index_.json Metadata Exposure

Problem: The build generates _index_.json in the app bundle, listing every JS/JSON file with its status (1=on disk, 2=encrypted). While _app_props_.json is deleted from the index, most filenames remain exposed.

Location: iphone/cli/commands/_build.js:6799-6832 — generateRequireIndex() writes the file unencrypted.

Current recovery method: Read _index_.json directly from the app bundle to get original filenames and encryption status.

Vector 5: Entropy Transition Detection

Problem: The encrypted data has high entropy (~7+ bits/byte) while surrounding ObjC runtime data has low entropy (~1-2 bits/byte). This sharp transition makes it easy to locate the start of the encrypted data blob.

Current recovery method: Scan for the entropy transition point to find where data[] begins within __DATA,__data.

Vector 6: NSRange Array Detectability

Problem: The ranges[] array (32-bit {location, length} pairs) follows immediately after the key+IV in the data section. The entries have a characteristic pattern: monotonically increasing locations, all values within the data blob's bounds, and the array starts right after the 32-byte key+IV.

Current recovery method: Scan for aligned 8-byte pairs where both values are within the data blob size.

Vector 7: Module Assets Follow Same Pattern

Problem: Module-embedded JS files use the identical encryption pattern (*ModuleAssets classes) with their own data[], ranges[], key+IV, and map — all in readable data sections.

Location: iphone/templates/module/objc/template/ios/Classes/{{ModuleIdAsIdentifier}}ModuleAssets.m.ejs

---

Hardening Measures

Measure 1: Remove Key/IV from the Binary (Highest Impact)

Description: Instead of embedding the key and IV as the last 32 bytes of data[], derive them at runtime from device-specific or obfuscated sources.

Approaches:

• A) Key Derivation from Device Identifier: Use identifierForVendor or keychain-stored identifier as input to PBKDF2/HKDF to derive the AES key at runtime. The IPA would no longer contain the key.

  • Trade-off: App must phone home on first launch or embed an obfuscated seed value
  • Recovery difficulty: Attacker must extract the seed from obfuscated runtime code (hard but not impossible)

• B) Separate Key in Keychain: Store the key in the iOS Keychain with kSecAttrAccessible: kSecAttrAccessibleWhenUnlockedThisDeviceOnly. The IPA alone is insufficient; the device is needed.

  • Trade-off: Requires key provisioning step; app won't work on first launch without network
  • Recovery difficulty: Requires access to the device + jailbreak

• C) White-Box Cryptography: Use a white-box AES implementation where the key is embedded in precomputed lookup tables, making static extraction infeasible.

  • Trade-off: ~2-10x performance overhead; significantly larger binary; not foolproof (DFA attacks exist)
  • Recovery difficulty: Requires dynamic analysis or side-channel attacks

Impact: Eliminates Vectors 1, 5, and 6 (key extraction, entropy detection, and range-finding all become moot without the key).

SDK files requiring changes:

File	Lines	Current behavior	Required change
iphone/templates/build/ApplicationRouting.m	13-24	<%- bytes %> embeds data[] with key+IV as last 32 bytes, ranges[] as plaintext, initWithObjectsAndKeys: dictionary with string keys	Remove key+IV from data array; add key derivation/lookup call before filterDataInRange; replace initWithObjectsAndKeys: with hash-based lookup (see Measure 2)
iphone/lib/tiverify.xcframework/	—	Prebuilt static library containing filterDataInRange(NSData* thedata, NSRange range) which performs AES-128-CBC decryption using key+IV extracted from the end of thedata	Must be rebuilt to accept key+IV as separate parameters, or to perform key derivation internally. No source code is available — this would need to be reverse-engineered and rewritten, or replaced with a new implementation
support/iphone/titanium_prep	—	Prebuilt binary that generates the data[] array, ranges[], key+IV, and initWithObjectsAndKeys: dictionary at build time. Reads /dev/urandom for key generation	Must be modified to either omit key+IV from output (for derived-key approach) or embed key in white-box tables. No source code is available — would need to be reverse-engineered and rewritten
iphone/cli/commands/_build.js	6667-6797	encryptJSFiles() spawns titanium_prep, reads its initWithObjectsAndKeys: output, renders ApplicationRouting.m via EJS template	Must be updated to handle new key provisioning logic (e.g., passing derived key seed, or omitting key from generated code)
iphone/cli/commands/_buildModule.js	546-707	compileJS() spawns titanium_prep for module encryption, renders {{ModuleIdAsIdentifier}}ModuleAssets.m.ejs	Same changes as _build.js — must handle new key provisioning for module assets
iphone/TitaniumKit/TitaniumKit/Sources/API/TiUtils.m	1625-1637	loadAppResource: calls [AppRouter performSelector:@selector(resolveAppAsset:) withObject:appurlstr]	No change needed if resolveAppAsset: internally handles key derivation; if key is passed separately, this call site must provide it
iphone/TitaniumKit/TitaniumKit/Sources/API/TiModule.m	205-218	loadModuleAsset: calls [moduleAssets performSelector:@selector(resolveModuleAsset:) withObject:fromPath] with mangling fallback	Same as TiUtils — must adapt if module key provisioning changes

Critical dependency: tiverify.xcframework and titanium_prep are prebuilt binaries with no available source code. Any measure that changes how keys are handled requires either:

1. Reverse-engineering and rewriting these binaries, or
2. Replacing filterDataInRange with a new implementation (e.g., CommonCrypto calls directly in ApplicationRouting.m)

---

Measure 2: Obfuscate String Constants (High Impact)

Description: The NSString constants in initWithObjectsAndKeys: leak all filenames. Obfuscate or remove them.

Approaches:

• A) Runtime String Construction: Build mangled filenames at runtime from character arrays or simple encoding rather than using @"stringLiteral" constants. This removes them from __cfstring/__cstring.

  // Instead of: [NSNumber numberWithInteger:0], @"app_js",
  char appJs[] = {0x61,0x70,0x70,0x5F,0x6A,0x73, 0x00}; // "app_js"
  [NSNumber numberWithInteger:0], [NSString stringWithUTF8String:appJs],

  • Trade-off: Minor runtime overhead; filenames still recoverable via dynamic analysis
  • Recovery difficulty: Requires runtime hooking or dynamic analysis

• B) Hash-Based Lookup: Replace initWithObjectsAndKeys: string keys with integer hashes. Instead of @"app_js" → index 0, use hash("app_js") → index 0. The hash values are opaque integers in the binary.

  // Instead of: @{@"app_js": @0, @"lib/Badge_js": @1, ...}
  // Use: @{@(0x3a7f2c1d): @0, @(0x8b4e5a92): @1, ...}

  • Trade-off: Runtime must compute hashes from incoming path strings; requires modifying resolveAppAsset: to hash the input path
  • Recovery difficulty: Attacker must brute-force hash→filename mapping or trace runtime calls

• C) Remove initWithObjectsAndKeys: Entirely: Replace the dictionary with a binary search over sorted (hash, range) pairs or a minimal perfect hash function. No string constants in the binary at all.

  • Trade-off: More complex code generation; lookup is O(log n) instead of O(1)
  • Recovery difficulty: Very high — filenames must be recovered purely from runtime tracing

Impact: Eliminates Vector 3 (filename leakage via __cfstring).

SDK files requiring changes:

File	Lines	Current behavior	Required change
support/iphone/titanium_prep	—	Generates initWithObjectsAndKeys: dictionary output with string keys (e.g., @"app_js", @0, @"lib/Badge_js", @1, ...)	Must be modified to output hash-based keys instead of string keys. No source code available — this is the primary blocker for approach B/C
iphone/templates/build/ApplicationRouting.m	21	[map objectForKey:path] — looks up the mangled filename in the dictionary generated by titanium_prep	For approach B: add hash computation on path before lookup (e.g., uint32_t h = hash(path); [map objectForKey:@(h)]). For approach A: no change needed (strings are just constructed differently). For approach C: replace dictionary with sorted array + binary search
iphone/TitaniumKit/TitaniumKit/Sources/API/TiUtils.m	1630	stringByReplacingOccurrencesOfString:@"." withString:@"_" — performs dot→underscore mangling before calling resolveAppAsset:	For approach B: mangled string must be hashed before lookup. Add: NSString *mangled = [appurlstr stringByReplacingOccurrencesOfString:@"." withString:@"_"]; uint32_t h = hash_fn(mangled); and pass @(h) to resolve
iphone/TitaniumKit/TitaniumKit/Sources/API/TiModule.m	216	stringByReplacingOccurrencesOfString:@"." withString:@"_" — same mangling for module assets fallback	Same change as TiUtils.m if using hash-based lookup for modules
iphone/templates/module/objc/template/ios/Classes/{{ModuleIdAsIdentifier}}ModuleAssets.m.ejs	17-22	resolveModuleAsset: uses initWithObjectsAndKeys: dictionary with string keys (generated by titanium_prep)	Same changes as ApplicationRouting.m — must use hash keys or runtime-constructed strings
iphone/cli/commands/_build.js	6750	Checks out.indexOf('initWithObjectsAndKeys') to validate titanium_prep output	Must be updated to check for new output format (hash keys, runtime strings, etc.)
iphone/cli/commands/_buildModule.js	604	Same check: out.indexOf('initWithObjectsAndKeys') !== -1	Same change as _build.js
cli/lib/tasks/process-js-task.js	269	file = file.replace(/\./g, '_') — performs dot→underscore mangling for encrypted filenames	For approach B: must also compute hash of mangled name and pass it to titanium_prep. For approaches A/C: no change needed

Critical dependency: titanium_prep generates the initWithObjectsAndKeys: output. Approaches B and C require modifying this binary, which has no available source code. Approach A (runtime string construction) could be implemented as a post-processing step on the generated code without modifying titanium_prep.

---

Measure 3: Remove _index_.json from the App Bundle (High Impact, Easy)

Description: Don't include _index_.json in the IPA at all. Currently it's written unencrypted to the app bundle.

Implementation: In generateRequireIndex(), skip writing the file for production builds, or encrypt it using the same key and include it in the data[] array.

Impact: Eliminates Vector 4 (_index_.json metadata exposure).

SDK files requiring changes:

File	Lines	Current behavior	Required change
iphone/cli/commands/_build.js	6799-6832	generateRequireIndex() writes _index_.json unencrypted to the app bundle. Lists all JS/JSON files with status codes (1=on disk, 2=encrypted). Deletes _app_props_.json entry but exposes all other filenames	Option A (remove entirely): Skip writing _index_.json for production builds (this.encryptJS === true). Option B (encrypt): Add _index_.json to jsFilesToEncrypt so it gets encrypted into the data[] array alongside other files
iphone/TitaniumKit/TitaniumKit/Sources/API/AssetsModule.m	99-123	fileStatus: reads _index_.json via loadIndexJSON to determine whether a file exists on disk (1), is encrypted (2), or doesn't exist	Option A: Remove fileStatus: logic; always attempt resolveAppAsset: first, fall back to disk check. Change the switch in loadURL: (lines 69-87) to try encrypted path first, then disk. Option B (encrypt): loadIndexJSON already tries loadAppResource: first (line 151), which would find the encrypted copy — no runtime change needed
iphone/TitaniumKit/TitaniumKit/Sources/API/AssetsModule.m	143-175	loadIndexJSON loads _index_.json — first tries encrypted path via loadAppResource:, then falls back to NSData dataWithContentsOfFile:	Option A: Remove this method entirely or return empty dict. Option B: No change — the existing fallback chain already handles encrypted _index_.json
iphone/cli/commands/_build.js	6828	delete index['Resources/_app_props_.json'] — removes _app_props_.json from the index	Option B (encrypt): Also add _app_props_.json to the encrypted files list instead of just deleting it from the index
iphone/cli/commands/_build.js	6829	index['Resources/_index_.json'] = 1 — marks _index_.json itself as "on disk"	Option B (encrypt): Change to = 2 (encrypted) since _index_.json would now be in the encrypted data array

Option A (remove entirely) is simpler but requires runtime changes. Option B (encrypt) requires minimal runtime changes — loadIndexJSON already tries encrypted loading first — but means _index_.json must be included in jsFilesToEncrypt during the build.

---

Measure 4: Obfuscate the Data Section Layout (Medium Impact)

Description: Make the data[], ranges[], and key+IV harder to locate through structural obfuscation.

Approaches:

• A) Interleave with Decoy Data: Insert random-length blocks of random bytes between encrypted files and between the data and the key. This breaks the contiguous structure and makes entropy detection less reliable.

  • Trade-off: Slightly larger binary; decryption code must skip decoys
  • Recovery difficulty: Attacker must distinguish real encrypted blocks from decoys

• B) Encrypt the NSRange Array: Store ranges[] in encrypted form (using a derived key), not as plaintext structs. The runtime decrypts it before use.

  • Trade-off: Minor performance overhead on each resolveAppAsset: call
  • Recovery difficulty: Attacker must find the range decryption key or trace runtime

• C) XOR-Mask the Data Blob: Apply a simple XOR mask with a derived key before storing in the binary. The runtime unmasks before AES decryption.

  • Trade-off: Negligible performance impact
  • Recovery difficulty: Defeats entropy-based detection; attacker must find the mask key

Impact: Makes Vectors 5 and 6 (entropy detection, NSRange detection) significantly harder.

SDK files requiring changes:

File	Lines	Current behavior	Required change
support/iphone/titanium_prep	—	Generates data[] (contiguous encrypted bytes), ranges[] (plaintext {location, length} pairs), and key+IV (last 32 bytes of data array)	Approach A: Must interleave decoy random bytes between encrypted file segments and update ranges accordingly. Approach B: Must encrypt the ranges array separately (with its own key or a derived key). Approach C: Must XOR-mask the entire data blob before outputting. No source code available
iphone/templates/build/ApplicationRouting.m	13-24	<%- bytes %> places raw data[], ranges[], and dictionary inline. resolveAppAsset: calls filterDataInRange directly on the data array	Approach A: Add decoy-skipping logic before passing data to filterDataInRange. Approach B: Add range array decryption before lookup. Approach C: Add XOR-unmasking before AES decryption call
iphone/lib/tiverify.xcframework/	—	filterDataInRange(NSData* thedata, NSRange range) — performs AES-128-CBC decryption on a range of data, extracting key+IV from the end of the data blob	Approach C: Would need to accept a mask key parameter or have unmasking done before the call. Approach B: No change needed if ranges are decrypted before calling filterDataInRange. No source code available
iphone/templates/module/objc/template/ios/Classes/{{ModuleIdAsIdentifier}}ModuleAssets.m.ejs	10-22	Same structure as ApplicationRouting.m for module assets	Same changes as ApplicationRouting.m

Critical dependency: All three approaches require modifying titanium_prep output format, which has no source code. Approach C (XOR masking) is the least invasive — the unmasking could be done in the generated ObjC code before calling filterDataInRange, without modifying the tiverify library.

---

Measure 5: Binary Stripping and Anti-Analysis (Medium Impact)

Description: Reduce the amount of structural information available in the binary.

Approaches:

• A) Strip Symbol Tables: Already done for App Store builds, but ensure __objc_classname doesn't leak ApplicationRouting or *ModuleAssets.

  • Trade-off: None for production builds
  • Recovery difficulty: Attacker must use heuristic detection instead of class name search

• B) Compiler Obfuscation Flags: Use -mllvm -fla (control flow flattening) and -mllvm -sub (instruction substitution) via the Xcode build settings to make static analysis harder.

  • Trade-off: 10-30% performance overhead; larger binary
  • Recovery difficulty: Significantly increases reverse engineering effort

• C) Remove Debug Info: Ensure __objc_methname, __objc_classname, and other metadata sections are stripped. Already partially done for release builds.

  • Trade-off: None for production
  • Recovery difficulty: Removes easy class/method discovery

Impact: Increases the effort required for all vectors but doesn't eliminate them.

SDK files requiring changes:

File	Lines	Current behavior	Required change
iphone/templates/build/ApplicationRouting.m	15-17	Class name ApplicationRouting is explicit in @implementation ApplicationRouting and + (NSData*) resolveAppAsset:(NSString*)path;	Approach A: Rename to an opaque name (e.g., _T5Routing) that doesn't reveal its purpose. Add an __attribute__((objc_root_class)) or use a #define for the class name
iphone/TitaniumKit/TitaniumKit/Sources/API/TiUtils.m	1625-1627	NSClassFromString(@"ApplicationRouting") — looks up the class by its string name	Approach A: Must use the same opaque name as ApplicationRouting.m. Change to NSClassFromString(@"_T5Routing") or use a shared constant
iphone/TitaniumKit/TitaniumKit/Sources/API/TiModule.m	186-188	NSString *moduleAsset = [NSString stringWithFormat:@"%@Assets", moduleName_] and NSClassFromString(moduleAsset) — constructs *ModuleAssets class names dynamically	Approach A: Change the naming convention. Instead of ModuleNameAssets, use an obfuscated pattern. Must coordinate with _buildModule.js which generates the class name
iphone/cli/commands/_buildModule.js	677-678	Generates ModuleAssets.m with @implementation <%- moduleIdAsIdentifier %>ModuleAssets — the class name includes the module ID	Approach A: Use an obfuscated class name pattern. Must coordinate with the runtime lookup in TiModule.m
Xcode build settings	—	Current strip settings may leave __objc_classname and __objc_methname sections	Approach C: Add STRIP_SWIFT_SYMBOLS=YES, COPY_PHASE_STRIP=YES, and additional OTHER_LDFLAGS=-w flags. Add a build phase to strip __objc_classname and __objc_methname sections from the binary using strip or ld flags

Note on Approach B (compiler obfuscation): LLVM obfuscation flags (-mllvm -fla, -mllvm -sub) are not available in stock Xcode/LLVM. They require building with a modified LLVM toolchain (e.g., the OLLVM project). This would require significant build infrastructure changes and is likely impractical for most Titanium developers.

---

Measure 6: Runtime Integrity Checks (Low Impact, Defensive)

Description: Add runtime checks that detect when the app is being analyzed or the binary has been modified.

Approaches:

• A) Anti-Debugging: Check for debugger attachment using sysctl and refuse to decrypt files if detected.

  • Trade-off: Can be bypassed by patching the check
  • Recovery difficulty: Requires additional bypass step

• B) Code Signature Verification: At runtime, verify the binary's code signature before decrypting. If the binary has been modified (e.g., to extract data), refuse to decrypt.

  • Trade-off: Adds startup latency; can be bypassed by patching
  • Recovery difficulty: Requires patching the verification code

• C) Certificate Pinning: Only decrypt if the app's signing certificate matches the expected one. Prevents re-signing attacks.

  • Trade-off: Requires certificate management
  • Recovery difficulty: Requires bypassing the certificate check

Impact: Doesn't prevent static analysis of the IPA but prevents dynamic extraction on a running device.

SDK files requiring changes:

File	Lines	Current behavior	Required change
iphone/templates/build/ApplicationRouting.m	17-24	resolveAppAsset: directly calls filterDataInRange with no checks	Approach A: Add if (is_debugger_attached()) return nil; before decryption. Approach B: Add if (!verify_code_signature()) return nil; before decryption. Approach C: Add if (!verify_signing_certificate()) return nil; before decryption
iphone/TitaniumKit/TitaniumKit/Sources/API/TiUtils.m	1637	performSelector:@selector(resolveAppAsset:) withObject:appurlstr — no validation before calling	Add integrity check before the performSelector call. Could check debugger status, code signature, or signing certificate
iphone/TitaniumKit/TitaniumKit/Sources/API/AssetsModule.m	73-74	case FileStatusExistsEncrypted: return [TiUtils loadAppResource:url] — no checks	Add integrity checks in loadURL: before dispatching to encrypted file loading

Note: Runtime integrity checks are easily bypassed by an attacker with a jailbroken device and are primarily useful as a deterrent. They do not protect against static analysis of the IPA file itself.

---

Prebuilt Binary Dependencies

Two critical components in the encryption pipeline are prebuilt binaries with no available source code. This is the single biggest blocker for implementing most hardening measures:

Binary	Location	Purpose	Source available?
titanium_prep	support/iphone/titanium_prep	Build-time tool that generates data[], ranges[], key+IV, and initWithObjectsAndKeys: dictionary. Reads /dev/urandom for key generation.	No
tiverify.xcframework	iphone/lib/tiverify.xcframework/	Runtime library providing filterDataInRange(NSData* thedata, NSRange range) — performs AES-128-CBC decryption extracting key+IV from end of data	No

Implications:

• Measure 1 (key removal) requires rewriting titanium_prep to change key output format, and rebuilding tiverify.xcframework to accept derived keys or implement key derivation internally.
• Measure 2 (string obfuscation) approaches B/C require rewriting titanium_prep to output hash keys instead of string keys.
• Measure 4 (data obfuscation) requires modifying titanium_prep output format and potentially tiverify.xcframework.
• Measure 5 (stripping) and Measure 6 (runtime checks) can be implemented without touching these binaries.

Recommendation: Before implementing Measures 1, 2, or 4, the titanium_prep and tiverify binaries must be reverse-engineered and reimplemented with available source, or replaced entirely with new implementations whose source is available for modification.

---

Recommended Priority

Priority	Measure	Impact	Effort	Blocker
1	Remove key/IV from binary (1C: White-box AES)	Critical	High	Requires tiverify + titanium_prep rewrite
2	Obfuscate string constants (2B: Hash-based lookup)	High	Medium	Requires titanium_prep rewrite
3	Remove _index_.json (Measure 3)	High	Low	No blocker — pure JS/ObjC changes
4	Encrypt NSRange array (4B)	Medium	Medium	Requires titanium_prep rewrite
5	XOR-mask data blob (4C)	Medium	Low	Requires titanium_prep rewrite
6	Strip metadata sections (5A, 5C)	Medium	Low	No blocker — build config changes
7	Runtime integrity checks (6A, 6B)	Low	Low	No blocker — ObjC code changes

Quick Wins (No prebuilt binary dependency)

These measures can be implemented immediately without modifying titanium_prep or tiverify:

1. Remove _index_.json (Measure 3, Option A): Skip writing the file in production builds. Modify generateRequireIndex() in _build.js:6799 and update AssetsModule.m fileStatus: and loadURL: to fall back to resolveAppAsset: directly.

2. Strip ObjC metadata sections (Measure 5A/5C): Add Xcode build phase to strip __objc_classname, __objc_methname sections from the final binary. Rename ApplicationRouting class to an opaque name in the template and update TiUtils.m:1627 accordingly.

3. Runtime string construction (Measure 2A): Post-process the titanium_prep output to replace @"stringLiteral" dictionary keys with runtime-constructed strings from character arrays. This can be done in _build.js:6752 after the EJS template rendering without modifying titanium_prep.

4. Anti-debugging check (Measure 6A): Add a sysctl debugger check in ApplicationRouting.m template before the filterDataInRange call. Simple, no dependency on prebuilt binaries.

Effectiveness Assessment

Current state: An attacker with only the IPA file (no device access) can recover 100% of JS source files in under 30 seconds using titanium_ipa_decryptor.py.

After quick wins (Measures 2A, 3, 5A/5C, 6A): Static analysis is significantly harder. Filenames are no longer in __cfstring as plain strings (must trace runtime), _index_.json is gone, and class names are obfuscated. An attacker would need to use entropy analysis and dynamic tracing, raising effort from minutes to hours.

After Measures 1-3 (full implementation): Static analysis of the IPA alone is no longer sufficient. An attacker needs dynamic analysis (runtime tracing on a jailbroken device) or significant reverse engineering effort (weeks, not minutes).

After Measures 1-5 (full implementation): Even dynamic analysis becomes challenging. Recovering filenames requires tracing every resolveAppAsset: call or brute-forcing hash mappings. Combined with anti-debugging, the effort approaches the cost of rewriting the app from scratch.

Practical recommendation: Implement the quick wins first (Measures 2A, 3, 5A/5C). They eliminate the most exploitable vectors with minimal effort and no dependency on prebuilt binary modifications. Then tackle the prebuilt binary dependency by open-sourcing or reimplementing titanium_prep and tiverify, which unlocks the higher-impact measures (1C, 2B/C, 4).

[mbender74]

@cb1kenobi you can drop me an email (ask @m1ga ) won´t publish it here, for the two tools for testing

[cb1kenobi]

Instead of embedding the obfuscated the key, maybe we could convert the key to actual native code. Use the machine code as the DSL. Kinda looking at ASM.js for inspiration where took something (native code) and compiled it into JavaScript (the DSL).

Also, I'm wondering if we can ship byte code instead of source code? It would provide a level of obfuscation with the benefit of speeding up initial load time since it doesn't need to parse the code.

[cb1kenobi]

I have another idea. We could do some sort of hybrid thing where we bundle the app unencrypted, then bundle select assets (JavaScript code, JSON files, etc) in an encrypted archive, something with a directory (maybe tar?). The Titanium build would write the app guid, the assets sha, and the decryption key to a file that is not bundled with the app.

The app would run as usual, then at the developer's descretion, they would download the decryption key on first launch, or when the user logs into their app, by making a GET call to an endpoint with the app guid plus a sha of the assets so that the server can validate the app. I think this is way easier than my DSL idea (which I still like a lot).

[mbender74]

I´m not happy that that app would not work when, the app can´t go online after installing. I do also got concerns about the problem, that a secret is downloaded, this is a "phone home" function and needs to be declared in Europe, because it could identify (perhaps) a person (GDPR)... maybe I do think too far...

BTW: who is maintaining "tiverify" ?

[m1ga]

is ti.verify the iOS version of ti.cloak? Guess then it's the same that there is no code for it.

I'm also not a big fan of the online key. But I like to have different options from high security (with online key) -> only obfuscation/normal flow. And the machine code idea sounds very interesting too.

[cb1kenobi]

Good point on phoning home. I didn't think of that.

BTW: who is maintaining "tiverify" ?

Nobody. Axway never handed over the code for tiverify, appcverify, titanium_prep, or ti.cloak. Word is they downloaded an archive of the repos, tossed it on a file server, and deleted the repos.

[mbender74]

ok, time for for change then.... I will see what I can do. I will push later a first test of the modified SDK in my fork in a "hardening" branch with some of the proposed changes for iOS (at least it does not throw errors and compiles) Testing is in progress

[m1ga]

btw: why don't we add something like https://github.com/javascript-obfuscator/javascript-obfuscator ?

looks a bit harder (and it runs just fine) to understand then it is currently:

even your decompiler will only show the obfuscated code at the end @mbender74

[cb1kenobi]

Um, that feels like a step backwards. I'm all for using Vite/rollup in our build process to minify, but that obfuscator seems to inflate the code.

[m1ga]

the differences are:

13.2.0.GA: build folder size: 7.8MB | apk: 62.9MB | aab: 97.6MB
with obfuscation: build folder size: 15.7MB | apk: 62.7mb | aab: 97.4mb

and it takes a lot longer in a big project to build the apk. I guess it will also break error reporting

[mbender74]

https://github.com/mbender74/titanium_mobile/tree/security/js-encryption-hardening
feel free to test...
the other steps need tiverify .... I'm on it....