Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bytecode VMs in surprising places (2024)

dubroy.com

Post reply on HN
Print view View original

31–40 of 74 posts

Re: Bytecode VMs in surprising places (2024)

#31

Post by faangguyindia »

anthk wrote: post #13

yt-dlp's jsinterp.py https://jxself.org/compiling-the-trap.shtml I've got subleq+eforth ( https://github.com/howerj/muxleq ) running in JS which is dead simple to do. No input but I could output ASCII mapping values to an array. https://esolangs.org/wiki/Subleq So, yes. yt-dlp runs propietary Youtube JS code defying the original purpose.

Why youtube does not use tls fingerprint to block ytdlp?

Re: Bytecode VMs in surprising places (2024)

#32

Post by wiseowise »

faangguyindia wrote: post #31
anthk wrote: post #13

yt-dlp's jsinterp.py https://jxself.org/compiling-the-trap.shtml I've got subleq+eforth ( https://github.com/howerj/muxleq ) running in JS which is dead simple to do. No input but I could output ASCII mapping values to an array. https://esolangs.org/wiki/Subleq So, yes. yt-dlp runs propietary Youtube JS code defying the original purpose.

Why youtube does not use tls fingerprint to block ytdlp?

Hopefully, an iota of decency.

Re: Bytecode VMs in surprising places (2024)

#33

Post by pocksuppet »

faangguyindia wrote: post #31
anthk wrote: post #13

yt-dlp's jsinterp.py https://jxself.org/compiling-the-trap.shtml I've got subleq+eforth ( https://github.com/howerj/muxleq ) running in JS which is dead simple to do. No input but I could output ASCII mapping values to an array. https://esolangs.org/wiki/Subleq So, yes. yt-dlp runs propietary Youtube JS code defying the original purpose.

Why youtube does not use tls fingerprint to block ytdlp?

possibly because yt-dlp updates rapidly and would simply switch to the correct fingerprint, but Google-approved clients use many different and uncontrollable fingerprints (as they use OS TLS facilities for example).

Re: Bytecode VMs in surprising places (2024)

#34

Post by petra »

drob518 wrote: post #24

On one hand, all these mini interpreters and compilers are cool. I have a soft spot for extensible systems. On the other hand, all these things are a huge security problem. When every subsystem and data format is carrying around its own Turing complete bytecode and JIT, they all need to be secure and bug free for the system to be secure and bug free. And that far more code surface to keep clean.

Maybe they can compile the bytecode to the x86 subset in this paper, and check if it is secure using their tool:

https://dl.acm.org/doi/pdf/10.1145/2254064.2254111

Re: Bytecode VMs in surprising places (2024)

#36

Post by raddan »

I was told by an engineer at Microsoft that Excel's formula interpreter is essentially a kind of bytecode-based stack machine. This came up in the context of a bug I found (while working on a project with Microsoft) that revealed that not only was there a small floating-point bug in some calculations, but (improbably, to me) that Excel preserved this inaccuracy across architectures for decades. So the bytecode interpreter made sense. That said, I've never seen this implementation myself, so it may still be rumor.

Re: Bytecode VMs in surprising places (2024)

#37

Post by segbrk »

m132 wrote: post #21
magnat wrote: post #15

Some other examples: - ACPI configuration for power management and platform stuff [1] - Bitcoin transactions [2] - TrueType fonts [3] [1] https://wiki.osdev.org/AML [2] https://en.bitcoin.it/wiki/Script [3] https://learn.microsoft.com/en-us/typography/opentype/spec/t...

Since ACPI was mentioned, let's not forget about EFI! https://uefi.org/specs/UEFI/2.10/22_EFI_Byte_Code_Virtual_Ma...

Since that page is a little dense, the higher-level version: PCI supports Option ROMs (OpRoms) - plug in device like a NIC or a GPU, your BIOS actually loads compiled code from it and executes it on the CPU. In many systems for example PXE booting (net booting) is actually a function of the NIC, executing code on the CPU to load an operating system. We're talking actual x86/x86_64 machine code here running in the privileged pre-boot environment. Not portable or secure in any way. OpRoms _may_ now be checked for SecureBoot signatures on systems where that's set up properly at least.

EFI ByteCode (EBC) is meant to help at least the portability side. I'm not sure if anybody is actually delivering devices with EBC OpRoms yet though. I'm also not sure if anybody is looking at using the EBC VM to sandbox untrusted OpRoms.

Post reply on HN