@lanodan I've got a few things working with csharpexec-test. I could get a build pretty close the shipped one with Mono 2.6.7 (running in Wine because I couldn't build a native version, oops). It has functions in the wrong order and some field values have minor differences but it's probably the closest I could get to a complete match. Also, C# assemblies have a random build ID so a 100% would never be possible. This project took way too much time, the findings are impractical, but it was "fun"
@lanodan I've managed to get a 100% match for javaversion.class.
Unfortunately, the provided source is not correct. The binary class file contains debug symbols, in particular line numbers. At some point the source was modified and had its line numbers shifted which caused a mismatch when I recompiled it. I "fixed" it by deleting 3 comment lines from the header to compensate for the shift.
@lanodan The javaversion.java file has a command to build it (not sure if it counts as a "recipe").
With some tweaking I managed to build the binary with openjdk-jdk8u which is the oldest version I could get on Alpine (javac -d . -target 1.1 -source 1.2 javaversion.java) but it still has a 3 byte difference from the original. Not sure what's up with that.
As for C#, well, there are no instructions or compiler versions anywhere. Using standard csc from the latest mono gives tons of differences.
@lanodan All those files have source equivalents now*. It's definitely very strange that binaries were put there instead of just compiling during the build. Both csharptest and javaversion are tiny but compiled with ancient toolchains which means it's very annoying to reproduce them exactly. Auditing is quite easy: `javap -p -c` and `ikdasm` (from mono) can show the very few instructions making up those files – there's nothing funny going on there.
@lanodan From my understanding, most RISC-V specifications (including SBI) don't expect any kind of input devices or special shortcuts.
So any kind of SysRQ-magic is just using the default input driver from the kernel. This is what Linux does at least.
It's possible that a device has an interrupt source for this use-case - check the device tree. Though I'm not very familiar with RV hardware, no idea if there exists a board with such a feature.
Had some nightmares doing bit manipulation in Python. That was fun, for some definition of fun.
I accidentally read two bytes as signed instead of unsigned, then bitshifted them to get a relative offset for RLE decoding. This meant that the result was the correct length but completely wrong contents.
Also, for some reason it seemed to gravitate towards the octet 0xBA, filling lots of places with it for no apparent reason.
That was the entire morning of staring at the code and vbindiff.
Not sure what "export control regulations" is this referring to. As far as I understand those only cover physical goods or encryption tech (in some jurisdictions). This is neither of those!
In fact, serving that error message would have probably been a violation of those regulations. Sending an error page is no different from sending the plugin (which is probably just a .jar with metadata).
In fact, Oracle had a similar geoblock a while ago but they quickly reverted it, for some reason
@lanodan I think Rust's stdlib only uses POSIX APIs and not general C things like stdio.h, so this doesn't really apply here. Hare also does the same thing on OpenBSD
@lanodan Even without libc, the language itself has a lot of really nasty footguns especially relating to integer promotion and the infamous signed overflow
When not tired and/or lazy, I write software that's used by at most 2 people. Mainly interested in programming language design, compilers and operating systems.#nobot