Implement load_buffer/check_buffer in RBinPlugins

[ret2libc]

Some of the bin plugins in #13349

[ret2libc]

Note that check_buffer is still not used, but it will be soon IMO, since we use load_buffer there's no reason to keep check_bytes.

[radare]

cool

[ret2libc]

I'd say let's start by reviewing/merging this if travis is green. I'll do the rest of the plugins soon.

[radare]

sgtm

…

On 12 Mar 2019, at 11:15, Riccardo Schirone ***@***.***> wrote: I'd say let's start by reviewing/merging this if travis is green. I'll do the rest of the plugins soon. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#13353 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA3-lljR2EtdXcHqgtolw2uTHRDi7_nQks5vV34ugaJpZM4bpkWR>.

[ret2libc]

Also, I'm rewriting the plugins to just call r_buf_ref on the buffer passed to load_buffer. Does that sound like a problem to you? This way, we don't even create a new RBuffer, but we just use the one passed to load_buffer. The alternative may be to use a r_buf_new_with_bufref, which creates a new buffer structure but reuses the same data as the original buffer. What do you think?

Using r_buf_ref:

• pros:
  • no additional memory used, at all
• cons:
  • one single "buffer state", so if something changes the buffer state outside of the binplugin, it may affect the bin plugin as well, because the state is the same

Using r_buf_new_with_bufref:

• pros:
  • no additional memory for the data
  • separate buffer state for the bin plugin (e.g. seek, etc.)
• cons:
  • a little (very little, i'd say) of extra memory for the separate buffer state

[radare]

yes, that was expected to happen too. copying buffers is not necessary

…

On 12 Mar 2019, at 11:21, Riccardo Schirone ***@***.***> wrote: Also, I'm rewriting the plugins to just call r_buf_ref on the buffer passed to load_buffer. Does that sound like a problem to you? This way, we don't even create a new RBuffer, but we just use the one passed to load_buffer. The alternative may be to use a r_buf_new_with_bufref, which creates a new buffer structure but reuses the same data as the original buffer. What do you think? Using r_buf_ref: pros: no additional memory used, at all cons: one single "buffer state", so if something changes the buffer state outside of the binplugin, it may affect the bin plugin as well, because the state is the same Using r_buf_new_with_bufref: pros: no additional memory for the data separate buffer state for the bin plugin (e.g. seek, etc.) cons: a little (very little, i'd say) of extra memory for the separate buffer state — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#13353 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA3-luHHgF0Mbr8B95QXrwUThUT0n-ziks5vV3-UgaJpZM4bpkWR>.

[radare]

what about != 16

[radare]

well != sizeof(tmp).

[ret2libc]

I'm trying to keep the original semantic. And originally the check was length > 0, it wasn't really a requirement that 16 bytes were read.

[codecov-io]

Codecov Report

Merging #13353 into master will increase coverage by <.01%.
The diff coverage is 79.11%.

@@            Coverage Diff             @@
##           master   #13353      +/-   ##
==========================================
+ Coverage   36.88%   36.89%   +<.01%     
==========================================
  Files         931      931              
  Lines      299060   299089      +29     
==========================================
+ Hits       110321   110358      +37     
+ Misses     188739   188731       -8

Impacted Files	Coverage Δ
libr/util/buf.c	67.45% <100%> (+0.15%)	⬆️
libr/bin/format/mach0/mach0.c	61.56% <100%> (+0.03%)	⬆️
libr/bin/p/bin_art.c	5.67% <33.33%> (+4.15%)	⬆️
libr/bin/format/bflt/bflt.c	68.33% <50%> (+2.7%)	⬆️
libr/bin/p/bin_avr.c	64.94% <77.35%> (-0.57%)	⬇️
libr/bin/p/bin_bflt.c	41.83% <90%> (+0.95%)	⬆️
libr/bin/p/bin_bios.c	87.35% <90%> (+3.57%)	⬆️
libr/bin/p/bin_any.c	92.85% <93.75%> (+4.48%)	⬆️
libr/bin/p/bin_bf.c	91.54% <95.23%> (+1.99%)	⬆️
libr/core/project.c	57.51% <0%> (+0.34%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 975505f...7ef1752. Read the comment docs.

[radare]

.

[ret2libc]

Ok let's wait for Travis. I think if green it can be merged.