home.social

#unicornengine — Public Fediverse posts

Live and recent posts from across the Fediverse tagged #unicornengine, aggregated by home.social.

fetched live
  1. #unicornengine is great, but it has two major drawbacks.

    No support for interrupts, not even basic “do it yourself” stubs. Everything is stripped from its parent #qemu code.

    No support for hardware backed threading.
    This is a variant of the first drawback.

    This means that any firmware that uses IRQ driven IO, timers (even built in like in #aarch64), or multithreading, or even just an idle thread and a main thread will be easily emulatable.

    I can understand why you wouldn’t want to have specific hardware blocks, like the ARM GIC, but the possibility to handle your own emulated hardware interrupts would have been nice. Right now you’d need to write everything from scratch.

    #fimwareemulation #emulation

  2. It uses a custom #MachO loader with the #UnicornEngine to load an obfuscated macOS framework, which is only needed once for initial registration.

  3. I DID IT!
    With lots of help from @dadoum, I have created a custom mach-o loader, using the #UnicornEngine to emulate a binary extracted from macOS Lion. It's a replacement for "nacserver", the program I wrote that required installing Darling and other complex dependencies. Should make developing pypush much easier!

    github.com/JJTech0130/jelly

    #iMessage #pypush #macho

  4. Here's what happens when #UnicornEngine tries to access Emulated Memory that isn’t mapped ... And how we map it in #RustLang

    Article: lupyuen.github.io/articles/uni

  5. To intercept every #Arm64 Instruction that will be emulated by #UnicornEngine ... Just attach a Code Execution Hook to the Emulator

    Article: lupyuen.github.io/articles/uni

  6. #UnicornEngine lets us attach a Memory Access Hook ... That's called to intercept every Arm64 Memory Access in the Emulator

    Article: lupyuen.github.io/articles/uni