Skip to content

Conversation

@rmelotte
Copy link

@rmelotte rmelotte commented Jun 2, 2025

Fixes #45 .

rmelotte added 2 commits June 2, 2025 14:08
frida dropped support for enumerateRangesSync, which leads to the
following error at runtime:
---
Starting Memory dump...
/home/rme/builds/fridump/./fridump.py:119: DeprecationWarning: Script.exports will become asynchronous in the future, use the explicit Script.exports_sync instead
  agent = script.exports
Traceback (most recent call last):
  File "/home/rme/builds/fridump/./fridump.py", line 120, in <module>
    ranges = agent.enumerate_ranges(PERMS)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/rme/builds/frida-tools/venv/lib/python3.11/site-packages/frida/core.py", line 180, in method
    return script._rpc_request(request, data, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/rme/builds/frida-tools/venv/lib/python3.11/site-packages/frida/core.py", line 86, in wrapper
    return f(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^
  File "/home/rme/builds/frida-tools/venv/lib/python3.11/site-packages/frida/core.py", line 497, in _rpc_request
    raise result.error
frida.core.RPCException: TypeError: not a function
    at enumerateRanges (/script1.js:5)
    at call (native)
    at handleRpcMessage (/frida/runtime/message-dispatcher.js:39)
    at handleMessage (/frida/runtime/message-dispatcher.js:25)
---

Instead, frida now uses 'Process.enumerateRanges()'. See [1] for the
current API.

It's not clear which exact commit in frida contains this change, but
the related internal frida javascript code has been updated in commit
09c8ba45de064c43fb4e20c91b2d4d0dc58edccc ("Modernize internal
JavaScript code") which is part of frida-core 16.2.1 onwards.

To fix it, switch to enumerateRanges() in fridump.

While at it, add a missing newline at the end of the file (done
automatically by text editor).

[1]: https://frida.re/docs/javascript-api/#process

Signed-off-by: Raphaël Mélotte <[email protected]>
Recent frida versions changed the way memory is read.

As a result, trying to dump memory using the verbose option with a
recent frida version leads to the following error:
---
DEBUG:Base Address: 0x2000000
DEBUG:
DEBUG:Size: 402653184
DEBUG:Too big, splitting the dump into chunks
DEBUG:Number of chunks:19.2
DEBUG:Save bytes: 33554432 till 54525952
DEBUG:[!]TypeError: not a function
    at readMemory (/script1.js:8)
    at call (native)
    at handleRpcMessage (/frida/runtime/message-dispatcher.js:39)
    at handleMessage (/frida/runtime/message-dispatcher.js:25)
Oops, memory access violation!
---

Instead of 'Memory.readByteArray()', frida now has
'NativePointer.readByteArray()'. See [1] for the corresponding API.

It's not clear which exact commit introduced this change in frida, but
the corresponding tests in frida-core have been update in commit
6f8b242eae0a79f4ebb3556cf092fd0ea58017d7 ("Eliminate use of deprecated
APIs in tests") which is part of frida-core 16.2.1 onwards.

To fix it, switch to using NativePointer.readByteArray in fridump as
well.

Fixes: Nightbringer21#45

[1]: https://frida.re/docs/javascript-api/#nativepointer

Signed-off-by: Raphaël Mélotte <[email protected]>
Copy link

@5archoufa 5archoufa left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Works like a charm

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

TypeError: not a function with Frida 17.0.7

2 participants