Re: Automatic Poke

[Jose E. Marchesi]

> Thank you Mohammad-Rez and Jose for the pointers, I am looking into them.
>
> If we focus on the libPoke side, I have some questions:
> 1-My tool will need to open many ios that may not be backed directly by
> files. They could be backed by a file, a hexdump, a base64 snippet, etc...
> I started with the libPoke API, but I cannot find the API to populate the
> ios content with my bytes (from my C side). How should I go about that? I
> could set each byte with a Poke statement like: byte@0x00#B=0x34 but it
> looks wrong.

You can use the alien IOS interface in libpoke.h.  See the GDB
integration or the r2 integration for examples.

> 2-The search space might get very big quickly. Is there any chance libPoke
> can work in a multithreaded program?

We still have some global state in the library, that we are working on
removing.  This means you cannot have more than one incremental
compiler.  But you can always use a mutex to guard the calls to libpoke.

> If I understand your email correctly, you recommend using the Poke language
> directly to implement the permutations? I will look into that option, but I
> rely on other analysis libraries. I am also considering using poked instead
> of libPoke. I was thinking of using the Poke language only to describe the
> known structures, and the placeholders where the search/permutations should
> occur. I like your idea of using the constraints to detect problems.

Yeah, I was suggesting that you can permute by creating different
buffers with Poke definitions.

Note that if you use poked instead of libpoke, you won't be able to use
the foreign IOS interface.

On the other hand, what you suggest may be the best approach.

> - The data structures I am working with vary in length from a few bytes to
> a few megabytes. I need to manage from 10 to 100 different blobs that are
> mapped into Poke ios.
> - The content usually follows a combination of list, struct and primitives.
> - The primitives I work a lot with are ieee754 decimals. They are a
> good source of information because in most applications, they will
> represent a value with few decimals. (Think Latitudes/Longitudes) or even
> whole numbers. When you have a list of floats, most of them will have the
> same precision.
> - You can also have various integer encodings. Big/Little endian, variable
> length, fixed length, indexed, ...
> - Various fixed decimal encodings
> - Endianness sometimes varies within the blob (!)
> - They may contain embedded files that I will identify with magic headers
> (think jpeg or png files). These embedded files can remain opaque for my
> purpose.
> - Rarely do I encounter blobs that are not byte aligned, but it happens.
> (canbus messages)

Sounds like fun :)
Got an example?