Add memory functionality

[mrexodia]

The difficulty is designing an API that will be useful. Just returning bytes seems prone to hallucinations, but there are definitely valid use cases (analyzing vtables #47). Here is some code from #46:

@jsonrpc
@idaread
def data_read_byte(
    address: Annotated[str, "Address to get 1 byte value from"],
) -> int:
    """Get 1 byte value at the specified address"""
    ea = parse_address(address)
    return ida_bytes.get_wide_byte(ea)

@jsonrpc
@idaread
def data_read_word(
    address: Annotated[str, "Address to get 2 bytes value from"],
) -> int:
    """Get 2 bytes value at the specified address"""
    ea = parse_address(address)
    return ida_bytes.get_wide_word(ea)

@jsonrpc
@idaread
def data_read_dword(
    address: Annotated[str, "Address to get 4 bytes value from"],
) -> int:
    """Get 4 bytes value at the specified address"""
    ea = parse_address(address)
    return ida_bytes.get_wide_dword(ea)

@jsonrpc
@idaread
def data_read_qword(address: Annotated[str, "Address to get 8 bytes value from"]) -> int:
    """Get 8 bytes value at the specified address"""
    ea = parse_address(address)
    return ida_bytes.get_qword(ea)

@jsonrpc
@idaread
def data_read_string(address: Annotated[str, "Address to get string from"]):
    """Get string at the specified address"""
    try:
        return idaapi.get_strlit_contents(parse_address(address),-1,0).decode("utf-8")
    except Exception as e:
        return "Error:" + str(e)

@jsonrpc
@idaread
def get_memory_bytes(
    address: Annotated[str, "Address to get memory bytes from"],
    size: Annotated[int, "Number of bytes to read"]
) -> list[int]:
    """Get memory bytes (hex) at the given address"""
    address = parse_address(address)
    data = idc.get_bytes(address, size)
    if not data:
        raise IDAError(f"Failed to read memory at {hex(address)}")
    return list(data)

I lean towards data_read_uint8, data_read_uint16, data_read_uint32, data_read_uint64 that return hex(value) and discuss convert_number in their descriptions. Reading a string is also fine, but get_memory_bytes seems rather pointless (unless the bytes need to be extracted into a script or something).

[withzombies]

I missed this issue before working on my PR #82. I went with slightly different route, which is to implement it as two functions:

• an equivalent get_memory_bytes function which takes an address and size (but returns it as a string of hex formatted bytes)
• get_global_variable_value which takes the global variable name and attempts to resolve its width through its type and then returns the value as appropriate for the type.

I agree that get_memory_bytes is probably pointless if you provide accessors for each width already.

[mrexodia]

I agree that get_memory_bytes is probably pointless if you provide accessors for each width already.

I think a combination will likely be the best approach. If the user asks 'extract the code into an emulation script with unicorn' then a get_memory_bytes function will be useful, but for reading vtables and global variables it's probably better to have a get_global_variable_value function and accessors for different widths.

The main thing I want to avoid is that the LLM starts randomly calling memory read functions to try and disassemble in its head or do other things that will not perform well.

[williballenthin]

(For discussion...)

In a past agent, I provided a `read_bytes(address)‘ that always returned 8 bytes (and was clearly documented as such). My intuition was that providing more choices to the LLM (1, 2, 4, ... bytes) would be more likely to confuse it. And since the LLM certainly knows how to interpret little and big endian data, 8 bytes covers a vast majority of (non string) cases. This seemed to work fine.

But without a robust way to test these systems, it's hard to make a data driven decision. So I won't say my solution was better or worse. Just an option.

[williballenthin]

That being said, it might be worth providing different accessors for different data types, to encourage the LLM to ask for the format it wants.

If you provide "read bytes" then the LLM might feel free to interpret those bytes, and perhaps hallucinate the interpretation. If you provide "read pointer" (that possibly also symbolizes valid pointers) then you might discourage rogue hallucinated disassembly.

[withzombies]

My branch provides data type accessors based on the IDA type info and will fall back to the named items size. I think this is likely the way to go.

Notably, I also have a get bytes function and Claude preferred to use that. From what I've seen, I agree that a get bytes function not a robust approach for LLMs. In my case it did an ntohs calculation (and got it right) but did it with math functions not binary operations.

Would it be useful to either:

1. include prompt guidance in the doc string (like, use this function only if get_global_value failed), or
2. provide a get_bytes that's initially disabled (does the MCP configuration allow this?)