Awesome, but beside the point of writing something in bash that never needed to be in bash for any technical reason.
Meaning if it requires bash plus some specially installed compiled c code, then it might as well require c or python or anything else and there is no point in calling it "written in bash", or writing it in mostly-bash-plus-special-plugin.
I do know who I'm speaking to so please assume I say this respectfully. :)
I have no problem with a "pointless" project like that as I'll show in a second.
That said, this minecraft project itself relies on externals like xxd when it doesn't need to, so using ctypes.sh would be no worse in this case, so you are right, in this case they might as well have.
But for the record it is possible to read, store, manipulate, do math on, and output binary in pure bash without anything like dd or xxd.
The only byte that is a problem is null, and there is a way to deal with that. You can't directly store a null, but you can detect that you read one and store that info, and reconstruct it on output later, or do math on it, use it's numerical value as an array index or byte offset or whatever the byte is for.
For a minimal example, just copying a binary file:
while LANG=C IFS= read -d '' -r -n 1 x ;do printf '%c' "$x" ;done bin2
That's a bit too minimal since it doesn't show what other kinds of things you can do that are more useful than cat-without-cat.
A bit more generic and useful:
https://gist.github.com/bkw777/c1413d0e3de6c54524ddae890fe8d...
The LANG=C, IFS= , and -d'' all combine to render all bytes accessible except 0x00, and then the return value from read() tells you the difference between "we read a 0x00" and "we didn't read anything" and "input ended"
And it doesn't have to use on the overall while() comand either. You can exec 3file_or_fifo_or_tty and read -u3 / printf >&3 etc inside the loop instead.
An example reading from a serial port:
https://gist.github.com/bkw777/ddde771cc85fdd888c7ec74953193...
Used in anger: https://github.com/bkw777/pdd.sh
see tpdd_read, tpdd_write, file_to_fhex, str_to_shex
reading and writing both a serial port and local files and doing all kinds of processing on the data.
And these loops are not even subshells let alone externals. You can manipulate variables inside the loop and you are still in the same original context. I'd say parent shell but there are no childern.
Those all read a single byte at a time with read -n 1, but they don't have to.
You can read without the -n1 and each iteration of the loop will collect as much as it can between nulls instead of always one byte. That would consume less ram and less loop iterations.
But the things I'm using them for want to slice & dice the individual bytes and byte-ranges at numerical offsets anyway and the data is always small (by todays standards) so the array-of-hex-pairs is just too convenient where a[n] == byte n, and all bytes are treated the same whether printable, non-printable, or null, and aside from merely storing and regenerating the bytes with printf you can also use the numerical values directly as well by simply prepending 0x, so 0x$n or 0x${a[n]} almost anywhere you would normally have a simple integer. So you can do math on them and use them as array indexes and byte offsets etc.
Read the 2nd byte of h[] as a length of the payload to follow, and clip out that payload: ${h[@]:2:0x${h[1]}}