Repository navigation
Conversation
The DTX methods processIdentifierForBundleIdentifier:, isPidDebuggable:, and launchSuspendedProcessWithDevicePath:... previously insisted on an NSNumber reply and raised a generic PROTOCOL error on anything else. iOS 16 has been observed returning NSDictionary wrappers and error payloads that this strict cast rejected, aborting the whole flow with no useful diagnostic. Route those calls through parse_uint_response / parse_bool_response helpers that accept NSNumber, parse numeric strings, or look up conventional result keys inside an NSDictionary, and surface NSError / dictionary-wrapped error payloads via try_extract_error_response_details with the originating method name. Stash the pending method name on DTXChannel so ERROR frames can report which invocation failed and format the NSError through the shared format_nserror helper, and fall back to describe_response for any unexpected shape so future breakage is actionable.
oleavr
requested changes
Apr 17, 2026
Member
There was a problem hiding this comment.
Thanks! 🙌 Some further refinement is needed:
| "Result", | ||
| "value", | ||
| "Value", | ||
| }; |
Member
There was a problem hiding this comment.
(Here and elsewhere:) This is a little too fuzzy/defensive for my taste. Can we make this more explicit? Each specific caller should know what shapes exist for the specific call, and use helper functions to avoid duplication.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to t
3214
he code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Addressing frida/frida#3719
Problem
Three DTX methods —
processIdentifierForBundleIdentifier:,isPidDebuggable:, andlaunchSuspendedProcessWithDevicePath:bundleIdentifier:environment:arguments:options:— previously cast the reply directly to
NSNumberand threwError.PROTOCOL ("Malformed response")on anything else.On iOS 16 the remote service has been observed returning richer shapes
(e.g.
NSDictionarywrappers with conventional result keys, or errorpayloads such as
NSError/ dicts carryingNSLocalizedDescription),which the strict cast rejected. The result was an opaque
Malformed responsefailure with no indication of which invocationfailed or why — impossible to debug from a bug report.
Fix
parse_uint_response/parse_bool_responsehelpers thataccept
NSNumber, parse numeric strings, or look up conventionalresult keys (
pid,processIdentifier,result,value, …)inside an
NSDictionary.try_extract_error_response_details,which recognises
NSError, string replies, and dict-wrapped errors(
NSError,NSLocalizedDescription,message, …), and surfacethem as
Error.NOT_SUPPORTEDcarrying the originating method name.describe_responsestringifies the payloadtype and a truncated representation so future breakage is
actionable instead of opaque.
DTXChannelwith aPendingResponserecord that stashes theoriginating method name alongside each pending promise, so ERROR
frames can report which invocation failed. The error-path
formatting is consolidated through the new shared
format_nserrorhelper.
No behaviour change for the existing happy path: an
NSNumberreplystill resolves to the same value.
Testing
MACOS_CERTID=- makein thetop-level frida tree (full frida-gum + frida-core Vala + C pipeline).
ninja src/libfrida-core.aexplicitly rebuilds the Vala compilepass over every frida-core
.valafile, including the patcheddtx.vala, which confirms the new helpers andPendingResponseinner class typecheck against the existing DTX code.
reproducer on a physical device; this change is a strict superset
of the prior cast behaviour so it is safe to merge even without
such a reproducer in CI.