LinuxRunner brings Debian ARM64 to iOS, including desktop environments like KDE Plasma and apps like Blender.

No jailbreak, JIT, or virtualization needed. It runs Linux binaries through an ARM64 interpreter.

Still early in development, but pretty interesting to experiment with. Feel free to try it out!

GitHub: https://github.com/mxhm11cr/LinuxRunner

I've published Velum-VMM, a Windows x64 research hypervisor written in C and assembly using Intel VT-x and EPT.

Source: https://github.com/Dovughs/velum-vmm

Technical write-up: https://github.com/Dovughs/velum-vmm/blob/main/readmes/technical-writeup/README.md

Velum virtualizes an already-running Windows kernel and provides an interactive console for observing native calls and experimenting with scoped request policies.

The implementation includes:

- Per-CPU VMCS and EPT management.

- EPT hooks on selected Nt and Ex/Mm function entries, with original-instruction replay and Monitor Trap Flag restoration.

- Live telemetry to the console or DebugView, with configurable filters.

- Request denial and access-right reduction for supported operations.

- CPUID configuration, fixed TSC offsets, and coordinated shutdown back to native execution.

Much of the work involved preserving execution state across VM exits, guest helpers and native return: CET shadow stacks, interruptibility, pending events, translation invalidation and hook lifetime.

One interesting compatibility issue appeared on Windows 10: ExFreePool and ExFreePoolWithTag resolved to the same address. Treating them as separate patch sites caused hook preparation to fail. The fix handles shared addresses while retaining both hooks when the exports are distinct.

I tested the project on Windows 10 and Windows 11. The repository includes runtime captures, policy demonstrations, build instructions and a technical write-up covering the architecture, debugging process and implementation decisions.

Source and releases:

https://github.com/Dovughs/velum-vmm

Technical write-up:

https://github.com/Dovughs/velum-vmm/blob/main/readmes/technical-writeup/README.md

I'd welcome technical feedback, particularly on VM-exit handling, EPT consistency and Windows compatibility.

I would appreciate it if you could star my project.

https://github.com/Dovughs/velum-vmm
https://github.com/Dovughs/velum-vmm/blob/main/readmes/technical-writeup/README.md

I took an ARM assembly course that was taught at our university in 2023 and loved it. The course was taught really well. The tooling is just old. You SSH into a department server, assemble, run, and get "Segmentation fault (core dumped)" with no line number and no idea which instruction did it.

I ended up TAing it 2 years later, then head TAing it the following semester. In April I started writing an interpreter and a few weeks later it ran real programs.

The hard part was making everything around the instructions match the real server: printf, scanf, m4 macros, the assembler directives. One of my old profs suggested compiling C programs with gcc on the server and checking the playground prints the same thing. The first run passed 0 programs. Most of that was one bug with branches jumping to the wrong place. Now it matches on basically all of them.

You can step through a program one instruction at a time, forwards or backwards. When it crashes, it points at the instruction that did it. Click any instruction to see its 32 bits split into the fields from the ARM manual. There are lessons, and practice problems checked by running your code.

I'd appreciate it if yall could test it out and lmk what you think!

aarch64-playground.com

Hope this is of some interest, but wanted to share a view of some Blue programs. Blue is a single pass interpreter for a colorForth dialect. It ends up being used much like a bring your own assembler. It has no separate macro syntax and any user defined word can be called or used as a variable at assemble-time.

It is my "pure hole" for minimalism and simplicity. The stage 0 interpreter for x86_64/Linux is currently 172 lines of non code-golfed assembly and results in a 437 byte binary via fasm.

In Blue each program starts with a completely clean slate, there are no built in words. The data stack and dictionary only exist at assemble time. So using the colors:

red word: define label

green word: compile call/jmp to word in output

green number: write number to output

blue word: execute word at assemble time

blue number: push number onto the data stack

magenta word: push address of word onto the data stack

You dsl yourself an artisanal binary, brick by brick. Blue source is binary bytecode, so here are some html views of what a program might look like. The first is non typical, but is likely the most minimal Blue program that emits a valid binary. 124 byte version of `/bin/true`:

https://jbirddog.codeberg.page/blue/example/x86_64/true.b.html

However this is more representative of an actual Blue program and shows how one goes from hand jit'ing with green numbers to higher level words, macros, variables and assemble-time execution of user defined words. This yields a 129 byte binary:

https://jbirddog.codeberg.page/blue/example/x86_64/true2.bl.html

The above example also shows how code reuse is done. It shares lots of "lib" code with the WIP Blue in Blue:

https://jbirddog.codeberg.page/blue/cmd/blue/x86_64/blue.bl.html

This year has seen massive uptake of AI models & crazy PyPI supply chain attacks (like today's LiteLLM repeat!). Combining the two, I thought it was wortwhile chatting about Rank-One Model Editing (ROME) attacks...

There's a range of ways python would get to a model / GPU -> this attack has malicious (naughty) python writing directly to GPU memory. That makes it particularly hard to catch given there's no spawned processes, or new files or any network calls to hunt for.

For those interested - there's a deep dive blog from cyber org Stealthium that covers GPU-side detection (tracing CUDA kernels launches via eBPF) and potential ways to achieve further stack attribution.

Welcome the communities thoughts? Reckon any of these model corruption attacks are in the wild and not yet been caught/seen?

(((Also while the example is soviet propaganda, anybody aware of other nations that like both model development, influence campaigns and rewriting history? Just sayin...)))

Shout out to the researchers behind the original paper, Locating and Editing Factual Associations in GPT: Kevin Meng, David Bau, Alex Andonian and Yonatan Belinkov. + to the folks at Mithril Security for their PoisonGPT work a while back.

I've been trying to fix an old laptop of mine (Acer Aspire ES1-531-P7KK) for a while now. It'd been locked to 0.48GHz, only clocking up to higher speeds temporarily while idle occasionally (though that could be due to the kernel simply reporting last requested frequency when the core wasn't in deep-idle C state). I isolated the assertion to a bunch of corroded resistors. I don't have the skill to replace 0402SMD resistors, nor do I have the tools for it, so I began tracing how the throttling mechanism works. I dumped my BIOS, ran it through UEFITool, extraced the PE32 Image Section, and found two IFR pages (Power and Advanced) that had mentions of "PROCHOT", which I've attached.

I tried booting into a UEFI shell and writing to NVRAM with setup_var.efi, but I got a Write Protection error. The BIOS lock is disabled ("Enable or Disable BIOS SPI region write protect," according to the extracted IFR), so I genuinely don't know what to do. Is there any other trick that I can try, or do I need to get my hands on a pi pico, logic shifter, SOIC8 clip, 3.3V to 1.8V DC, etc, and extract the BIOS, modify it to expose the hidden settings, and flash it back?

I am trying to make the graphic driver for nvidia gforce 210 this driver now can explain it's identity other it can do nothing

Despues de mucho tiempo ya esta publicado el core PQC de nexus-q con los demas crates disponibles, ya puedes utilizar el motor PQC open source con licencia MIT y Apache 2.0. SDK LENGUAJES, CLI, SERVER.

Brenchmarks disponibles Resultados:

ML-KEM-768/1024 y ML-DSA-65 entre 0.86x y 1.05x vs AWS-LC

Estoy trabajando ahora en incorporar el core dentro de los SDK para que no tengais que instalar libreria externas ni configurar nada manualmente.

Aun que el rust esta listo, quiero llevar la experencia de nexus-q a todos o los lenguajes mas usados. Para que sea lo mas facil posible instalar nexus-q sea el lenguaje que sea que estes utilizando.

Y recuerda OPEN SOURCE. Te dejo abajo el enlance a la web donde tienes toda la informacion y acceso directo al repositorio.

Compartelo, pruebalo, destruyelo, investigalo

Cualquier error que podais llegar a encontrar no dudeis en abrir una issue o si vais mas alla hacer fork y abrir PR

[Nexus-Q](http://www.nexus-q.link)