[Bug] Cardwriter does not write the given bytearray to the card correctly

[Mabeeck]

Describe the bug
I noticed, that when writing some bytes larger than 127 to a card with the card writer, those bytes may get substituted with other bytes for no clear reason.
I checked the data on the rfid/magnetic card with nbtexplorer and a binary explorer of my own creation to find that this is as expected not a problem with the reader.
Here some examples of bytes and what they got substituted with:

• 128 -> 239
• 129 -> 191
• 130 -> 189
• 131 -> 239
• 132 -> 191
• 133 -> 189
• 134 -> 239
• 135 -> 191

and so on all the way through to 255.

In which environment did the Bug appear?
This bug appeared on a Windoes dedicated server, though I did not try to replicate it on a singleplayer world.
Mods:

• OpenComputers-MC1.12.2-1.8.9a+8ca336f
• OpenSecurity-1.12.2-1.0-93
• Several other non OpenComputers related mods

To Reproduce
Steps to reproduce the behavior:

1. Write one of the example bytes to a rfid card
2. Take your freshly written rfid card out of the writer
3. Read the card via a RFID Reader
4. Compare the scan result with the original data

Expected behavior
I expected the card writer to write the exact bytes that I supplied to the cards.

Screenshots / Code Snippet

component=require("component")
io=require("io")
b=""
-- Expects a rfid card to already be inserted
for i=128,128+63 do b=b..string.char(i) end
component.os_cardwriter.write(b)
-- Take card into inventory and press ENTER
io.read()
d=component.os_rfidreader.scan(4)[1].data
print(b:byte(1))
print(d:byte(1))
print(b:byte(2))
print(d:byte(2))
print(b:byte(3))
print(d:byte(3))

Wierdly this causes OpenOS to throw an error at me and reload the shell after the program finishes:

/bin/sh.lua:14: attempt to index a nil value (field 'stdin')
stack traceback:
     init:18: in function <init:17:>
    [C]: in function 'xpcall'
    machine:823: in upvalue 'errorCapture'
    machine:827: in metamethod '__index'
    bin/sh.lua:14: in main chunk
    [C]: in function 'xpcall'
    machine:823: in upvalue 'errorCapture'
    machine:833: in global 'xpcall'
    init:17: in main chunk
    (...tail calls...)
Press any key to continue.

Sometimes the error message is shown twice.

Minecraft:

• Mod Version (e.g. OpenSecurity-1.12.2-1.0-93)
• Minecraft Version (e.g. Minecraft 1.12.2)
• Forge Version (e.g. Forge 14.23.5.2859)

Additional context
I think I already mentioned everything, but if there is something I forgot, please kindly point it out for me so that I can inform you.

[ben-mkiv]

i guess this comes from how the method handles the input. It's interpreted as UTF-8 string
https://github.com/PC-Logix/OpenSecurity/blob/4ff9b314851d2edae5fa29c1740a773b4103aa11/src/main/java/pcl/opensecurity/common/tileentity/TileEntityCardWriter.java#L87C8-L87C78

i don't have a build environment set up for minecraft stuff, so i won't be able to fix it, if you manage to fix it on your end you can make a PR and it can be merged, ideally with a new method to handle raw byte data, to not break existing programs/setups.

[Mabeeck]

As far as I am aware the funcion you refrenced is used only for eeproms, wich I did not test for in this case.
For rfid and mag cards the write function is used instead. This one seems to not have anything with explicit encodings in it, so I suppose it might have something to do with how the argumants class or java in general handles strings. That or it is something that happened before the function was called.

I don't think I have the neccisary expertise to fix this yet.