Nomad still has a tangible learning curve, which (in my very biased opinion) is almost non-existent with Uncloud assuming the user has already heard about Docker and Compose.
They had quite a few release in the last year so it's not dead that's for sure, but unclear how many new customers they are able to sign up. And with IBM in charge, it's also unclear at what moment they will loose interest.
As a former cheat developer, I think it is impossible since it is digging into some specific stuff of Windows. For example, some anti-cheat uses PsSetCreateThreadNotifyRoutine and PsSetCreateThreadNotifyRoutine to strip process handle permission, and those thing can't be well emulated, there is simply nothing in the Linux kernel nor in the Wine server to facilitate those yet. What about having a database of games and anticheat that does that, and what if the anticheat also have a whitelist for some apps to "inject" itself into the game process? Those are also needed to be handled and dealt with.
Plus, there are some really simple side channel exploits that your whitelisted app have vulns that you can grab a full-access handle to your anticheat protected game, rendering those kernel level protection useless, despite it also means external cheat and not full blown internal cheat, since interal cheat carrys way more risk, but also way more rewardings, such as fine-level game modification, or even that some 0days are found on the game network stack so maybe there is a buffer overflow or double-free, making sending malicious payload to other players and doing RCEs possible. (It is still possible to do internal cheat injection from external cheat, using techniques such as manual mapping/reflective DLL injecction, that effectively replicates PE loading mechanism, and then you hijack some execution routine at some point to call your injected-allocated code, either through creating a new thread, hijacking existing thread context, APC callback hijack or even exception vector register hijacking, and in general, hijack any kinds of control flow, but anticheat software actively look for those "illegal" stuff in memory and triggers red flag and bans you immediately)
From what I've seen over the years, the biggest problem for anticheat in Linux is that there is too much liberty and freedom, but the anticheat/antivirus is an antithesis to liberty and freedom. This is because anticheat wants to use strong protection mechanism borrowed from antivirus technique to provide a fair gaming experience, at the cost of lowering framerates and increasing processing power, and sometimes BSOD.
And I know it is very cliche at this point, but I always love to quote Benjamin Franklin: "Those who would give up essential liberty to purchase a little temporary safety, deserve neither liberty nor safety". I therefore only keep Windows to play games lately, and switched to a new laptop, installed CachyOS on it, and transfered all my development stuff over to the laptop. You can basically say I have my main PC at home as a more "free" xbox.
Speaking of xbox, they have even more strict control over the games, that one of the anticheat technique, HVCI (hypervisor-protected code integrity) or VBS, is straight out of the tech from xbox, that it uses Hyper-V to isolate game process and main OS, making xbox impossible to jailbreak. In Windows it prevents some degree of DMA attack by leveragng IOMMU and encrypting the memory content beforehand to makd sure it is not visible to external devices over the PCIe bus.
That said, in other words, it is ultimately all about the tradeoff between freedom and control.
> In my 6502 hacking days, the presence of an exclusive OR was a sure-fire indicator you’d either found the encryption part of the code, or some kind of sprite routine.
Correct. Most ciphers of that era should be Feistel cipher in the likes of DES/3DES, or even RC4 uses XOR too. Later AES/Rijndael, CRC and ECC (Elliptic Curve Cryptography) also make heavy use of XOR but in finite field terms which is based on modular arithmetic over GF(2), that effectively reduces to XOR (while in theory should be mod 2).
I was going to say "but RC4 and AES were published well after the 6502's heyday," but NESes were completely rocking it in '87 (and I'm told 65XX cores were used as the basis for several hard drive controllers of the era.) Alas, the closest I ever came to encryption on a (less than 32-bit system) was lucifer on an IBM channel controller in the forever-ago and debugging RC5 on an 8085.
I'm told 65XX cores were used as the basis for several hard drive controllers of the era
Western Design Center is still (apparently) making a profit at least in part licensing 6502 core IP for embedded stuff. There's probably a 6502 buried and unrecognized in all sorts of low-cost control applications laying around you.
I dunno. The 6502 has been a $2 part for a long time but needs RAM and some glue logic, for a similar price you can get an AVR-8 [1] or ESP-32 [2] and get some RAM and GPIO.
[1] faster, more registers than the IBM 360, << 64k RAM
65C02s are $8 now. That didn't stop me buying one when I was stuck at home during COVID. And a 6809 too.
But forget AVR. Yeah, for a buck or so the ATTiny85 was my go-to small MCU five years ago, and the $5 328 for bigger tasks.
But for the last three years both can be replaced by a 48 MHz 32 bit RISC-V CH32V003 for $0.10 for the 8 pin package (like ATTiny85, and also no external components needed) and $0.20 for the 20 pin package with basically the same number of GPIOs as the 328. At 2k RAM and 16K flash it's the same RAM and a little less flash than the ATMega328 -- but not as much as you'd think as RISC-V handles 16 and 32 bit values and pointers sooo much better.
And now you have the CH32V002/4/5/6 with enhanced CPU and more RAM and/or flash -- up to 8K rAM and 62K flash on the 006 -- and still for around the $0.10-$0.20 price
Hi Bruce! If you make it back to the states we'll have to drink a beer and wax poetic about the 6809. Do you know if anyone ever implement the embedded RISC-V profile in hardware? Not everything I do on small systems needs a 48MHz 32-bit. But if I could get away with a low I/O count, why not use the $0.10 part? Also pretty sure I saw 8051 based SoCs going for $2. I bet if you looked hard enough you could find something like a 6502 for about the same price.
There's probably no reason not to get some of the CH32VXXX's to play with. Every now and again I have an application that needs very low power and I'm happy to spring for an MSP430. But every time I buy an MSP430, TI EoLs the specific model I bought.
Heeey, how's the Cruz treating you? If it still is.
I don't know why you'd ever want to pay a cent more for a 6502 or 8051 or AVR than for a RISC-V or ARM (e.g. Puya PY32F002A). Especially when the CH32V002/4/6 run on anything from 2V to 5V (plus a margin) which is pretty rare, and they don't need any external components.
I don't know whether the M6809 designers were the first to ever analyse a body of real software to find instruction and addressing mode frequencies and the distribution of immediates in order to optimise the encoding of a new ISA -- in a way that the 8086 people clearly didn't [1], but I think they were the first to publish about it, and I was fascinated by their BYTE articles at the time.
MSP430 is also a fun ISA. I just wish they were cheaper, and the cheap ones has more than 512 bytes of RAM. FRAM is funky. I also loooove the instruction encoding e.g. `add.w r10,r11` is `0x5B0A` where `5` is `add`, `B` is src register, `0` means reg to reg word size, `A` is dst register. Just beautiful. Far nicer for emulating on a 6502 or z80 than Arm or RISC-V too. The R2/R3 const generation is a bit whack though.
[1] e.g. on one hand deciding it was worth squeezing a 5 bit offset from any of 4 registers into a 2-byte instruction, while also providing 8 and 16 bit offsets with 3 and 4 byte instructions. They were also confident enough to relegate the 6800's SEC/CLC/SEI/CLI/SEV/CLV to two-byte instructions (with a mask so you could do multiple at once). But not confident enough to do the same with DAA, or SEX. They kept the M6800 encoding for DAA (and for as much else as possible e.g. keeping the opcodes for indexed addressing, but expanding from one option to dozens), but SEX was new to them and they could have experimented with it.
Reading cryptography was that advanced at that time, I'm even more surprised that the venerable Norton Utilities for MS-DOS required a password, that was simply XORed with some constant and embedded in the executables. If the reserved space was zeroes, it considered it a fresh install and demanded a new password.
If it had been properly encrypted my young cracker self would have had no opportunity.
Self-correction: It is GF(2^8) and not GF(2), but GF(2^8) primitive operations (such as carryless multiplication) can be reduced into a bunch of table lookups and/or GF(2) operations, which is how to AES crypto accelerators are being done in hardware.
Well, running in CTR mode is really common now, and that ends up XORing the generated keystream into the plaintext… (CTR mode is essentially converting block ciphers into stream ciphers, if you want to see it that way.)
As someone who both plays the game and used the language at work, and used to do cheat development, I always wonder if I can write a Rust cheat in Rust.
It would be cool if we can use LLVM to lift the x86 code into LLVM bitcode and go to different platforms easily with ostate of the art optimizations, won't it?
Been there, done that during my PhD (code: [1]). Works reasonably well, except for compile times (for which I implemented a caching strategy). However, due to calling conventions, using LLVM isn't going to give the best possible performance. Some features like signal handling are extremely hard to implement with LLVM (I didn't, therefore). Although the overall performance results have been good, it's not an approach that I could strongly recommend.
Sadly compile times of LLVM-based recompilers make it impractical for competitive x86 emulation. We're not just talking a few single-frame stutters here and there, but considerable startup delays and pauses in-game.
LLVM's optimization passes also are less useful than you might think, since the vast majority of them is motivated by source->binary translation (like clang). They don't have much effect when recompiling an already optimized binary to another architecture.
I actually have to do this for programs that runs in bare metal. You can't afford to have nondeterministic panic like this. If things really gone wrong you'd have a watchdog and health checker to verify the state of program.
There's a crate that prevents linking panic symbol in the final stage of the executable generation, forcing it to be undefined symbol, so while it is hard to find out where the panic is, it effectively requires me to inspect throughout the code to find out. Sometimes I have to disassemble the object file to see this
Here's one nice thing about AMD is that there is znver4 and znver5 support baked in from CachyOS, so any Zen 4 laptop (7000, 8000 series) and Zen 5 (Strix Halo AI Max) would get good performance early on. I got a 8745HS laptop for just $400 and I swapped the 1T and 32GB RAM for 2x2T and 64GB RAM, and switched to CachyOS. Except for a weird keyboard issue when resuming from sleep, and some Arch kernel shenanigans, I got no problem so far.
Thanks Peter, but I wonder if there will there be .NET support? Since Temporal includes one, so it is a hard selling point for us .NET developers when MassTransit went commercial.
