Hacker News: mras0

New comment by mras0 in "The virtual AmigaOS runtime (a.k.a. Wine for Amiga:)"

mras0 — Thu, 08 Jan 2026 16:53:48 +0000

There already exist cross-compilers (e.g. http://sun.hasenbraten.de/vbcc/ and various amiga-gcc versions). vAmos is more for the case where you want to use an Amiga-native compiler (say SAS/C http://pjhutchison.org/tutorial/sas_c.html) but work on Linux/Windows.

New comment by mras0 in "The virtual AmigaOS runtime (a.k.a. Wine for Amiga:)"

mras0 — Thu, 08 Jan 2026 16:49:30 +0000

Amiga Forever is a distribution of software (Amiga ROMs and OS disks) and a full system emulator: CPU, custom chips (graphics/sound/..) etc. It allows you to emulate various Amiga systems completely.

vAmos is just CPU and an embedded ROM/OS replacement that does just enough to run (some) AmigaOS command line programs. The primary use case is for cross-development (running Amiga compilers/tools, testing simple stuff, etc.) without having to boot a full system emulator for each command and better integration with e.g. host-side Makefiles.

With the vAmos=WINE analogy, Amiga Forever=VirtualBox/VMWare.

New comment by mras0 in "x86 architecture 1 byte opcodes"

mras0 — Fri, 31 Oct 2025 21:02:21 +0000

Size optimizing assembly code finds use in a variety of places. Demoscene for size constrained things is one of them, but also "hacking"/exploits and of course "whitehat" stuff (patches / compiler optimization etc).

New comment by mras0 in "x86 architecture 1 byte opcodes"

mras0 — Fri, 31 Oct 2025 20:50:28 +0000

I understand what you're getting at, but in this case even I (who know what most things on that page means) struggle to understand why it was submitted. Are we looking for the 0E opcode? New optimization opportunities?

Genuinely asking, for this post did you click on the link and say "yeah, I got the point" or did you involve an LLM? If you did, what did you ask it? I'm asking because I want to get better at LLM use (Another example post (and prompt) where you've used this, that's also fine)!

New comment by mras0 in "x86 architecture 1 byte opcodes"

mras0 — Fri, 31 Oct 2025 20:23:00 +0000

The link is to an opcode map with strange abbreviations with no apparent explanation. Asking "What am I looking at?" without doing any research (with a LLM or otherwise) is entirely reasonable.

New comment by mras0 in "x86 architecture 1 byte opcodes"

mras0 — Fri, 31 Oct 2025 19:30:17 +0000

Not sure why you're being downvoted. You need a to know quite a bit of esoteric knowledge to parse this beyond knowing x86 opcodes (even x86 assembly).

It's more or less the same information you get from the intel manuals (specifically appendix 2A of https://www.intel.com/content/www/us/en/developer/articles/t...). There you can also see what e.g. "Jb" means (a byte sized immediate following the instruction that specifies a sign-extended relative offset to the instruction).

One-byte opcodes here differs from 2 byte opcodes (386+ IIRC) prefixed by a 0F byte and even more convoluted stuff added later.

New comment by mras0 in "Cursed Knowledge"

mras0 — Fri, 08 Aug 2025 14:55:14 +0000

No, it's due to the construction of bcrypt - it ends up using the password more or less directly as the key for blowfish (the underlying cipher) which is why the limit is there. Check wikipedia for details.

New comment by mras0 in "Cursed Knowledge"

mras0 — Fri, 08 Aug 2025 14:40:53 +0000

bcrypt is based on the blowfish cipher which "only" support keys up to 576 bits (72 bytes) in length (actually only 448 bits as spec'ed). Wikipedia has all the details.

New comment by mras0 in "Why I no longer have an old-school cert on my HTTPS site"

mras0 — Sat, 24 May 2025 12:51:52 +0000

> moduli generated by OpenSSL will always have the high bit set

Correct for 1024, but...

    openssl genrsa 1023 | openssl rsa -text -noout

Also just noticed that openssl rsa actually has a -modulus switch so you can make do with "cut -b9-"

New comment by mras0 in "Why I no longer have an old-school cert on my HTTPS site"

mras0 — Sat, 24 May 2025 08:42:04 +0000

The standard format for RSA private keys is ASN.1 (https://www.rfc-editor.org/rfc/rfc8017#appendix-C) with the components encoded as INTEGERs. An INTEGER is always signed in ASN.1, so you need the leading 0 byte if the MSB of your positive number is set.

OpenSSL is just dumping the raw bytes comprising the value. Tools that don't show a leading zero in this case are doing a bit more interpretation (or just treating it as an unsigned value) to show you the number you expect.

New comment by mras0 in "How a 20 year old bug in GTA San Andreas surfaced in Windows 11 24H2"

mras0 — Wed, 23 Apr 2025 18:30:44 +0000

Not really the ethos of C(++), though of course this particular bug would be easily caught by running a debug build (even 20 years ago). However, this being a game "true" debug builds were probably too slow to be usable. That was at least my experience doing gamedev in that timeframe. Then again code holding up for 20 years in that line of biz is more than sufficient anyway :)

New comment by mras0 in "An invalid 68030 instruction accidentally allowed the Mac Classic II to boot"

mras0 — Mon, 27 Jan 2025 15:09:20 +0000

Good luck! As the sibling comment mentions, Asm-Pro is IMO a good choice these though it requires KSv2+ (so you can't use it on an stock A500). I mostly use vasm for "larger" stuff though (http://sun.hasenbraten.de/vasm/) and cross-compile (though it can run on Amiga as well) / test in an emulator.

For a quick test/code loop nothing beats the Asm-* family - remember to save often and make backups though :)

New comment by mras0 in "An invalid 68030 instruction accidentally allowed the Mac Classic II to boot"

mras0 — Mon, 27 Jan 2025 15:03:56 +0000

Update: a1=-1 is a bad choice of test value (0 is much better), as it won't show the issue if present! However, it doesn't change the outcome of the test on 060, but I would have noticed that 020 is affected as well (as also mentioned in the comments to the article).

New comment by mras0 in "An invalid 68030 instruction accidentally allowed the Mac Classic II to boot"

mras0 — Sun, 26 Jan 2025 01:00:58 +0000

Rev5 "full" 060 (not EC/LC). Quick capture of crappy methodology: https://imgur.com/a/XwQ1Tnp (PCR with revision number is in d0)

New comment by mras0 in "An invalid 68030 instruction accidentally allowed the Mac Classic II to boot"

mras0 — Sat, 25 Jan 2025 23:48:40 +0000

Have an Amiga w/ 060, and that instruction doesn't seem to modify any A registers. (Only did a very quick test of those exact instruction words)

New comment by mras0 in "Benchmarking RSA Key Generation"

mras0 — Sat, 04 Jan 2025 19:36:34 +0000

Thanks, understand what you mean. I probably botched the 1/4 probability thing, was thinking 4^-60 gives 2^-120 bit assurance (roughly, security margin in my mind), and an extra round would quadruple it, but doesn't work that way I realize.

New comment by mras0 in "Benchmarking RSA Key Generation"

mras0 — Sat, 04 Jan 2025 19:25:48 +0000

Thanks for the reply (and it definitely answers my original question). For both short-lived keys, and where production time matters it makes perfect sense. I was mostly thinking about the scenario where you're generating a key for e.g. a long-lived certificate (maybe even a CA) or high-stakes PGP stuff. Just seems like you'd want spend a few more seconds in that case.

New comment by mras0 in "Benchmarking RSA Key Generation"

mras0 — Fri, 03 Jan 2025 22:03:33 +0000

I don't pretend to understand all the involved math, but what I'm trying to say is that as far as I understand T rounds gives 4^-T probability that we've chosen a "bad" prime (really composite) per normal Miller-Rabin in the worst case. Doing ~5 rounds has been shown to be enough to choose a good prime candidate, under most (very probable!) conditions when we get it a random, and thus the argument is that that ~5 rounds is fine. We agree so far?

I'm just asking, why not run the conservative 60 round test, rather than ~5 when you're doing a very rare, one time, key generation? I understand that it's very unlikely to reject any numbers, but at least BSI thinks it's worth it for important keys.

If I understand the recommendation right, you wouldn't do 60 for a 2048 bit key and then 120 for 4096, rather 61 rounds would be enough for 4096 if 120 is alright for 2048.

New comment by mras0 in "Benchmarking RSA Key Generation"

mras0 — Fri, 03 Jan 2025 20:35:10 +0000

The BSI recommendation I linked says 60 times here (considering the worst case and the security level they're targeting). Just wondering why we'd want to do less for a (presumably rare) one-time operation.

New comment by mras0 in "Benchmarking RSA Key Generation"

mras0 — Fri, 03 Jan 2025 19:29:26 +0000

I happened to look at this recently, and while I understand the argument (but not the math) of having to do fewer Miller-Rabain rounds, why would you do so in PRACTICAL settings? Unlike ECC you're likely only generating long term keys, so shorter key generation time seems like a bad tradeoff. Composite candidates are going to be rejected early, so you're (with high probability) not doing expensive calculations for most candidates. My reading of [BSI B.5.2](https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publicat...) confirms this.

Of course random bit flips could interfere, but other measures should thwart this in high-stakes environments (at least to some degree).