I think that we should also support regex-based conditional recv functions too. I expect that some users (cough cough maybe Chino? cough cough) might expect match_[...] to work with regex-like patterns.

I'm also not sure about the names, if I need to call recvuntil with multiple patterns, I think that recvuntil_something is easier to find than something_recvuntil.

Maybe recvuntil_regex and recvuntil_pattern?

I think that we should also support regex-based conditional recv functions too. I expect that some users (cough cough maybe Chino? cough cough) might expect match_[...] to work with regex-like patterns.

I'm also not sure about the names, if I need to call recvuntil with multiple patterns, I think that recvuntil_something is easier to find than something_recvuntil.

Maybe recvuntil_regex and recvuntil_pattern?

I did consider the regex matching recv as an alternative, but matching it on a stream like in the case of the multiple patterns would require adding additional dependencies such as Google's RE2 (reimplementing a regex engine is probably outside the scope of libdebug). As an alternative, I can implement a naive approach that just reruns the regex matcher from the builtin python package on the overall buffer as input is accumulated, which would probably be slow. Still, it there's demand for it, we can consider both options.

As for renaming the function, we can do a poll with different options.

I did consider the regex matching recv as an alternative, but matching it on a stream like in the case of the multiple patterns would require adding additional dependencies such as Google's RE2 (reimplementing a regex engine is probably outside the scope of libdebug). As an alternative, I can implement a naive approach that just reruns the regex matcher from the builtin python package on the overall buffer as input is accumulated, which would probably be slow. Still, it there's demand for it, we can consider both options.

I think doing it like pwntools does would be fine for now.

Did you try to benchmark the efficiency of Aho–Corasick with respect to other approaches? I am thinking about the really dumb approach of repeatedly calling bytes.find(pattern) for each pattern, or similar ones. I know what you’re thinking: the theoretical complexity of Aho–Corasick is very low. However, that complexity really manifests in cases of (i) large buffers and (ii) a high number of patterns.

On the other hand, I expect only a few patterns (2 or 3?) and buffers smaller than a single read (4096 bytes) in most cases (and at worst only a few times larger than a single read). Since the implementation allocates a non-negligible number of Python objects, while other “dumb” solutions are C-backed, there might be some surprises, as we have seen in the past with other pattern-searching code in libdebug, where the dumb solution was more efficient than the state-of-the-art algorithm for similar reasons.

I don’t really know the answer. I’m just suggesting that it might be worth running a few tests to ensure that the most common cases are prioritized.

Also, remember we are in 2026… the copyright 😉

PS. really cool stuff, btw

Yes, the naive approach appears to be faster on the test binary. I guess we could either stick to the base approach or set a threshold on the number of patterns / flag to enable/disable it. I don't have large use cases in mind right now that I can readily benchmark.

This would be really handy for CTF exploitation where the binary output changes depending on state or randomization. match_recvuntil with a list of patterns is much cleaner than wrapping everything in try/except blocks or layering timeouts. +1 on this, looking forward to seeing it land.