> allocscope-trace attaches to another process as a debugger. By using breakpoints on memory allocation functions such as malloc it tracks allocations made by that process.
Looks like it's using breakpoints so I'd expect it to be orders of magnitude slower. And looking at the source code it's also using `libunwind`, so even if it wasn't using breakpoints it'd still be at least another order of magnitude slower since Bytehound has a custom unwinder that's specially optimized for this purpose.
One advantage it has is that it can be attached to an already running process; Bytehound can't do that. (I have ideas how I could do that, and it should be technically doable by dynamically injecting Bytehound's .so into the target process' address space, but so far I haven't needed it so I did not implement it)
The main difference is that binwalk goes through a file linearly, searching for patterns like magic bytes, and tries to extract everything it finds.
The problems with this:
- very noisy, finding a lot of false positives (license code, format inside another format, etc).
- very slow, trying to extract irrelevant things
- imprecise, because it finds patterns in the middle of a file, where it's actually not relevant on the first level of extraction
unblob solves these problems by being smarter about the file formats, recognizing them by their specification, for example unpacks format header structs and carves out files based the information in the header (size, offset).
See a simple example for NTFS [1].
We also went to great lengths preventing unnecessary work by skipping formats inside another [2].
We are using hyperscan [3] instead of grepping byte sequences with Python, which is orders of magnitudes faster. It can also handle 4Gb+ files because of this which binwalk cannot.
It's used for a year now in production and it's way more precise and faster than binwalk. We are getting less false-positives too, and even if unblob fails to extract everything, we still get meaningful information out of firmwares, where binwalk just failed with no output previously.
Indeed, it's a smarter alternative for binwalk, which we started because binwalk was not a good fit for us :) Should probably include comparison somewhere in the docs.
Adding a comparison, or at least the clear differentiators, to the documentation would be very helpful.
As someone who uses `binwalk` extensively in a professional setting, with tooling built around `binwalk`, it would be useful to see (a) how `unblob` would integrate and (b) if it could be a replacement or supplemental.
I've also hit this issue. About a year ago I made an effort to use blink, but after a bit of work I recall essentially discovering that any support was effectively abandoned. I wish they would remove the note in the FAQ about supporting multiple engines, as it doesn't seem to be the case.
At most it’s a description of an aspect of the project’s internal architecture. It means absolutely nothing to the end user.
I believe that the Nyxt website should have a big red banner warning people that, because it uses a rendering engine that is not conformant and, I suppose, is a work in progress, it can’t actually serve as a practical web browser.
This would save people from wasting time installing it only to find out that it doesn’t work. And remove the misleading comments about it being engine-agnostic. I really don’t understand what they hope to accomplish by forcing people to discover the true nature of their project the hard way, but it leaves a bad taste in my mouth. The same goes for Suckless’ surf browser and others. For their part, the wekitGTK website falsely claims that their engine is “a full-featured port of the WebKit rendering engine”. As mentioned in another comment, these rendering errors do not appear in Safari, which uses WebKit.
It is definitely also worth mentioning the now-stabilized procedural macros [1] (unless I missed where they are described). proc macros power some of the more complex macro usage in the rust ecosystem (like rocket and actix-webs router macros, any sort of custom derive, etc).
Location: Huntsville, AL, USA
Remote: Yes
Willing to relocate: No
Technologies: Rust, C, C++, python, Xen, KVM, hypervisor development, Linux kernel development, IDA Pro
Résumé/CV: https://alschwalm.com/resume/resume.pdf
Email: adamschwalm@gmail.com
I am currently a technical lead for a hypervisor product. My career has primarily been focused on low-level security and performance for quasi-embedded systems, but I also have experience with reverse engineering and machine learning applications. I am passionate about using modern technologies like rust to improve the security posture of products and would like to continue to work in that area.
https://github.com/alschwalm/transient - A tool for quickly creating short-lived virtual machines for doing kernel or hypervisor testing, made after I got tired of dealing with races and general complexity from libvirt-based tools.
VirtIO is very usable via QEMU, without libvirt (naturally, because in the configuration described in the article, libvirt is just calling QEMU). It is usually as simple as `qemu-system-x86_64 -drive file=/path/to/my/disk,if=virtio`.
I'm concerned about self hosting a service like this as well, so I put mine behind an nginx reverse proxy that requires a client cert for auth. That way, an attacker won't even be able to reach the bitwarden server to try to get in (unless there's a vulnerability in nginx).
You can host it all behind Wireguard. That way, an attacker doesn't have access to your Nginx proxy. After all, why would the whole internet need access to your Bitwarden server (or a reverse proxy serving it)?
