justfoxing / jfx_bridge Goto Github PK

I discovered this issue in the context of the Ghidra bridge, however I suppose it's rooted in this infrastructure.

Functions such as ghidra.program.database.data.ProgramDataTypeManager.findDataTypes, which return their value through a list argument, don't seem to work over the bridge.

Using Ghidra's built in Python interpreter:

>>> candidates = []
>>> currentProgram.getDataTypeManager().findDataTypes("int", candidates)
>>> candidates
[int, typedef int dword]

Using the bridge:

>>> import ghidra_bridge
>>> b = ghidra_bridge.GhidraBridge(namespace=globals(), hook_import=True)
>>> candidates = []
>>> currentProgram.getDataTypeManager().findDataTypes("int", candidates)
>>> candidates
[]

Follow up from the ghidra_bridge comment:

jfx-bridge is now throwing a TypeError:

WARNING:jfx_bridge.bridge:Handling connection from ('127.0.0.1', 50000)
Traceback (most recent call last):
  File "C:\Users\student\Downloads\ghidra_10.0.4_PUBLIC_20210928\ghidra_10.0.4_PUBLIC\Ghidra\Features\Python\ghidra_scripts\jfx_bridge\bridge.py", line 974, in local_get
    print(name)
AttributeError: 'javapackage' object has no attribute '__all__'
Traceback (most recent call last):
  File "C:\Users\student\Downloads\ghidra_10.0.4_PUBLIC_20210928\ghidra_10.0.4_PUBLIC\Ghidra\Features\Python\ghidra_scripts\jfx_bridge\bridge.py", line 974, in local_get
    print(name)
AttributeError: 'javapackage' object has no attribute '__all__'
Traceback (most recent call last):
  File "C:\Users\student\Downloads\ghidra_10.0.4_PUBLIC_20210928\ghidra_10.0.4_PUBLIC\Ghidra\Features\Python\ghidra_scripts\jfx_bridge\bridge.py", line 974, in local_get
    print(name)
AttributeError: 'javapackage' object has no attribute '__all__'
Traceback (most recent call last):
  File "C:\Users\student\Downloads\ghidra_10.0.4_PUBLIC_20210928\ghidra_10.0.4_PUBLIC\Ghidra\Features\Python\ghidra_scripts\jfx_bridge\bridge.py", line 974, in local_get
    print(name)
AttributeError: 'javapackage' object has no attribute '__all__'
Traceback (most recent call last):
  File "C:\Users\student\Downloads\ghidra_10.0.4_PUBLIC_20210928\ghidra_10.0.4_PUBLIC\Ghidra\Features\Python\ghidra_scripts\jfx_bridge\bridge.py", line 1083, in local_call
    )
TypeError: array.array indices must be integers
WARNING:jfx_bridge.bridge:Closing connection from ('127.0.0.1', 50000)

I threw in some prints, but I'm not finding them useful, hopefully it makes more sense to you

    @stats_hit
    def local_get(self, args_dict):
        handle = args_dict[HANDLE]
        name = args_dict[NAME]
        self.logger.debug("local_get: {}.{}".format(handle, name))

        target = self.get_object_by_handle(handle)
        print("target: ", target)
        print("name: ", name)

@stats_hit
    def local_call(self, args_dict):
        print("HANDLE: ", HANDLE)
        print(args_dict)

Output seems to print from local_get, but not local_call:

target:  <class 'slice'>
name:  __str__
target:  <class 'slice'>
name:  __hash__
target:  <class 'slice'>
name:  __eq__
target:  <class 'slice'>
name:  __ge__
target:  <class 'slice'>
name:  __gt__
target:  <class 'slice'>
name:  __le__
target:  <class 'slice'>
name:  __lt__
target:  <class 'slice'>
name:  __ne__
target:  <class 'slice'>
name:  __subclasshook__

Hello,

I want to remotify a function 'my_function' and return a very large object from my_function.
When I do this, I get the following output:

2022-02-17 12:04:47,842 [ERROR bridge.py:522 run()] 'utf-8' codec can't decode byte 0xaa in position 196607: invalid start byte
Traceback (most recent call last):
  File "/usr/local/lib/python3.8/dist-packages/jfx_bridge/bridge.py", line 504, in run
    msg_dict = json.loads(data.decode("utf-8"))
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xaa in position 196607: invalid start byte

In the bridge.py file in function read_size_and_data_from_socket, I think the size of 'data' is stored in 32 bits. Maybe there is a problem if 'my_function' returns an object that is larger than 2**32 bytes (~4 Gigabytes)?

Let me know if you need more info.

if I use bytes(getBytes(xxx)), there will be an error:
File "xxx/bridge.py", line 1114, in get
raise AttributeError()

I am working on some new things for ipyghidra , specifically reading out documentation and type info from a -stubs package generated with VDOO-Connected-Trust/ghidra-pyi-generator

So far I was mostly patching some properties into the BridgedObject class, but this isn't always working with IPython. For example IPython will access some property on the class, which will return a property, which then fails. I could start patching IPython for this, but I don't think this is the right approach.

I think some standardized interface for some other python package to control the values of certain attributes what be the best way.
As a rough idea:

import jfx_bridge

jfx_bridge.register_overrides(
{
'__module__': lambda obj: ...,
'__annotations__': lambda obj: ...,
'__doc__', lambda obj: ...
})

Either

or

could then check the dict of all registered overrides if the requested attribute is handled there and then return the result of the function called on the object. This would allow dynamically generating those fields, which is probably to expensive to do for every object initialization, without having to resort to monkey patching.

If this would allow overriding something that is actually defined on the server side is something I am not sure about yet. It might be useful for things that are often queried by IPython but are expected to stay the same anyway, and shouldn't waste bridge traversals, which introduce a lot of latency during auto completion.

This might also be something that should be exposed in the ghidra_bridge package itself, because any mapping of overrrides will most likely be specific to some environment like Ghidra, IDA, binja etc. Maybe as an optional argument to the bridge constructor itself.

I think I will implement a PR with this later today, but I expect any feedback or input you have on this. I think this will greatly reduce any meddling or PRs for simple additions like not bridging 'module` from my side...