Unicorn Engine
toolbox
Our great sponsors
Unicorn Engine | toolbox | |
---|---|---|
14 | 109 | |
7,074 | 2,235 | |
1.8% | 3.4% | |
1.3 | 9.1 | |
1 day ago | 15 days ago | |
C | Shell | |
GNU General Public License v3.0 only | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
Unicorn Engine
-
Show HN: Tetris, but the blocks are ARM instructions that execute in the browser
OFRAK Tetris is a project I started at work about two weeks ago. It's a web-based game that works on desktop and mobile. I made it for my company to bring to events like DEF CON, and to promote our binary analysis and patching framework called OFRAK.
In the game, 32-bit, little-endian ARM assembly instructions fall, and you can modify the operands before executing them on a CPU emulator. There are two segments mapped – one for instructions, and one for data (though both have read, write, and execute permissions). Your score is a four byte signed integer stored at the virtual address pointed to by the R12 register, and the goal is to use the instructions that fall to make the score value in memory as high as possible. When it's game over, you can download your game as an ELF to relive the glory in GDB on your favorite ARM device.
The CPU emulator is a version of Unicorn (https://www.unicorn-engine.org/) that has been cross-compiled to WebAssembly (https://alexaltea.github.io/unicorn.js/), so everything on the page runs in the browser without the need for any complicated infrastructure on the back end.
Since I've only been working on this for a short period of time leading up to its debut at DEF CON, there are still many more features I'd eventually like to implement. These include adding support for other ISAs besides ARM, adding an instruction reference manual, and lots of little cleanups, bug fixes, and adjustments.
My highest score is 509,644,979, but my average is about 131,378.
I look forward to feedback, bug reports, feature requests, and strategy discussions!
-
It Takes 6 Days to Change 1 Line of Code
Entails hundreds of hours of single-stepping through that opcode in Linux kernel using an indirect operand pointing toward its own opcode (self-modifying code).
Even the extraordinaire Fabrice Bellard (author of QEMU) admitted that it is broke and did a total rewrite, which fixed tons of other issues.
-
QEMU Version 7.0.0 Released
This is how I found out a snippet of assembly code that can actually distinguished between a KVM hypervisor and most of today’s emulator.
-
Can you make a MacOS Server on the Raspberry Pi for iMessage bridging server?
Actually, that gives me an idea. Unicorn Engine (https://github.com/unicorn-engine/unicorn) is FOSS and claims to be able to emulate many CPU architectures like x86. Do you think it could be possible to just run a regular Hackintosh setup through Unicorn Engine‘s x86 emulator? Definitely it would be very slow, and there is chance that it will just not work, but that would make the process fairly easy as Hackintosh setup is pretty well documented. Though I have to admit that I only just found Unicorn Engine and I can find almost no documentation for it other than on their github. I would be a bit skeptical of unicorn engine, but do you think that this could be possible?
-
TIL That Flatpak apps can emulate non-native apps like Apple Rosetta. (TL;DR on bottom)
https://www.unicorn-engine.org/ for example.
toolbox
-
ChromeOS is Linux with Google’s desktop environment
The team has both made a ton of effort switching off their proprietary Skia based rendering tech and adopting standard Wayland, and has put forward huge effort to making running incredibly well integrated real Linux containers just work.
The headline is true. ChromeOS is Linux with Google’s desktop environment. But it obfuscates the details. It's a damned by omission statement. It has some really good sauce to help you not notice often, but it's not at all a Linux desktop environment one can regularly use. You can do a lot of Linux desktop-y things but only through well crafted special unique wrapped processes that mostly but not fully help mock & emulate a regular Linux desktop. Even though it now runs Wayland, the apps you want to run will have atypical intermediates up the wazoo.
And no one else uses any of this tech. ChromiumOs has so much interesting container tech, does such an interesting job making containers think they have a regular Linux / FreeDesktop environment. It's far far far far deeper virtualization than for example https://github.com/containers/toolbox . But you know what? Google has made zero effort to get these pieces adopted elsewhere. It's open source but not intended for use outside Chromium/ChromeOS. I respect & think ChromeOS is a quite viable Linux, and it's so much closer to the metal & more interesting, amazing tech, but my gods Microsoft has gone 300x further to establish wsl2 as a sustainable community effort folks could use & target, in a way that ChromiumOS has done nothing about.
It's sad how Google has transformed from a company that appreciated & worked with ecosystems, that drove things collectively forward, into an individual player that does their own things & delivers from on high. ChromiumOS is such an incredible effort, but it's so internernally drive & focused, and it's hard to believe in such a wildcat effort, even though it's so so good. It keeps coming into better alignment with Linux Desktop actual, but via shims and emulations that no one else cares about or which seems marketed elsewhere. And that inward focus makes the whole effort both so exceptional & promising, but suspect. Such a different nearby but alternative & separately governed universe. ChromiumOS/ChromeOS do excellent at faking being a Linux desktop, and wonderfully have increasingly drawn more strength from that universe, but are still wholly their own very distinct very separate very controller other space. In many ways that's great, secure, good, and miraculously transparently done. But it's still hard to really trust, being such a weird alien impostor, faking so much for end user apps, and there's tension in believing ChromeOS will keep straddling the rift in pro-user manifestations forever.
-
Introduction to Immutable Linux Systems
I'm really, really happy with my current setup of Fedora immutable + toolbox [0]. This tool lets you create containers that are fully integrated with the system, so you have acces to the entire Fedora repos, can run graphical apps, etc. while still having everything inside a container in your home directory. That means no Flatpak required. Highly recommended.
-
Codespaces but open-source, client-only, and unopinionated
Seems like toolbox is also in this space; https://github.com/containers/toolbox
- What’s the safest way to compile apps from source in a binary-based distribution like Fedora?
-
Silverblue: Nvidia drivers in toolbox?
I'd probably try running it on the host system first. If you want to use your nvidia gpu inside toolbox, you would indeed need to install the drivers in the container: https://github.com/containers/toolbox/issues/116
-
Seamlessly run other Linux distributions inside your terminal
How is it different from Toolbox? (https://github.com/containers/toolbox)
Quoting the README:
It implements the same concepts introduced by https://github.com/containers/toolbox but in a simplified way using POSIX sh and aiming at broader compatibility.
-
Devs using SilverBlue, how to use your IDE?
### fix vscode not opening links in toolbox https://github.com/containers/toolbox/issues/291 ``` sudo dnf install flatpak-xdg-utils sudo ln -s /usr/bin/flatpak-xdg-open /usr/bin/xdg-open
-
20 Years of Nix
> What’s the escape hatch to bring those into the dev environment?
One thing you can do is try the Nix package manager on your Linux or macOS system. -- If it's not in nix, you can just do it the way you did things before.
If you want to try NixOS:
1. Writing a package is only necessary for sharing code.. you can still just have Python, setup a virtual env, & run the program as you would.
2. You could use a tool like Podman or Docker, to run stuff in containers. I've heard stuff like https://github.com/containers/toolbox helps this.
(Among other solutions).
-
Debian and immutable OS
Containers, containers everywhere! That is really the whole concept and benefit of an immutable OS. Your underlying OS and libraries become an image you can boot, update, and roll back if needed. Since your system is read only you will run all of your apps as Flatpaks or inside of a toolbox container. The benefit of all of this is additional security and stability. If a new package breaks your system, just rollback to an old one. It's hard to compromise your system too if it is immutable. It is sort of neat to think that conceptually I should never have to worry about borking my system again. But here is where I run into some issues for a typical home Linux user...
What are some alternatives?
distrobox - Use any linux distribution inside your terminal. Enable both backward and forward compatibility with software and freedom to use whatever distribution you’re more comfortable with. Mirror available at: https://gitlab.com/89luca89/distrobox
podman - Podman: A tool for managing OCI containers and pods.
QEMU - Official QEMU mirror. Please see https://www.qemu.org/contribute/ for how to submit changes to QEMU. Pull Requests are ignored. Please only use release tarballs from the QEMU website.
MicroPython - MicroPython - a lean and efficient Python implementation for microcontrollers and constrained systems
capstone - Capstone disassembly/disassembler framework: Core (Arm, Arm64, BPF, EVM, M68K, M680X, MOS65xx, Mips, PPC, RISCV, Sparc, SystemZ, TMS320C64x, Web Assembly, X86, X86_64, XCore) + bindings. [Moved to: https://github.com/capstone-engine/capstone]
Reverse-Engineering-Tutorial - A FREE comprehensive reverse engineering tutorial covering x86, x64, 32-bit ARM & 64-bit ARM architectures.
TinyVM - TinyVM is a small, fast, lightweight virtual machine written in pure ANSI C.
box86 - Box86 - Linux Userspace x86 Emulator with a twist, targeted at ARM Linux devices
qemu-t8030 - iPhone 11 emulated on QEMU
CarpVM - "interesting" VM in C. Let's see how this goes.
box64 - Box64 - Linux Userspace x86_64 Emulator with a twist, targeted at ARM64 Linux devices
batect - (NOT MAINTAINED) Build And Testing Environments as Code Tool