I am not an expert in incident reaction, but I thought the safe way was to image the affected machine, turn it off, take a clean machine, boot a clean OS image with the affected image mounted read only in a VM, and do the investigation like that ?
Assume that the malware has replaced system commands, possibly used a kernel vulnerability to lie to you to hide its presence, so do not do anything in the infected system directly ?
Maybe if your company infrastructure is affected but not the server you use to host your side projects on with “coolify” unless IT security is your hobby.
Nice article, thank you.
Did you also consider using bpftrace while debugging?
I do not have much experience with it, but I think you can see the kernel call stack with it and I know you can also see the return value (in eax).
That would be less effort than qemu + gdb + disabling kernel aslr, etc.
I have no practical experience with bpftrace, so it did not occur to me. I'll give it a try and perhaps there's gonna be a 2nd part of this investigation.
Author here, thanks for the feedback on legibility, I have now just learned about the CSS `tab-size` property to control how much space tabs get rendered with. I have reduced it, should be better now.
Just one point about testable assembly: I like the Golang guidelines which require to write a Go version before implementing the same in assembly. That way there is a baseline to compare with in terms of correctness and performance. Also the Go project has recently introduced mutation testing and test coverage on assembly code which is very interesting.
Finally about detecting at runtime the presence of simd: I am confused why a third-party dependency or even the std is needed. At least on x64, it’s just one instruction (“cpuid”) and then checking if a bit is set, right?
I agree with the premise, just use a specific version of your dependencies, that’s generally fine.
However: You absolutely do need a lock file to store a cryptographic hash of each dependency to ensure that what is fetched has not been tampered with. And users are definitely not typing a hash when adding a new dependency to package.json or Cargo.toml.
> And users are definitely not typing a hash when adding a new dependency to package.json or Cargo.toml
I actually much prefer that: specify the git revision to use (i.e. a SHA1 hash). I don't particularly care what "version number" that may or may not have.
I wrote a toy Kotlin compiler, for fun.
Then one day a Jetbrains employee opens an issue which only says: “Why? Just why?”.
Maybe it’s the language barrier… but I did not find that particularly polite.
On the other hand I open sourced my blog and received lots of small contributions to fix typos or such which were nice.
The guy was probably upset that someone might be trying to compete with them while their compiler is itself open source. But it still sucks that they couldn’t be more subtle about it. In the end both they and you got upset. A small change in his tone and you might both come off with a nice feeling, him for knowing you were just playing around, and you for perhaps getting recognition from a Kotlin dev.
Obviously I can't change how it made you feel, and as such it was a crappy reply to receive, but on one level at least it's a genuine question that projects should have an answer for.
It kinda matters if you build something as a proof of concept, or you build it to exercise some new technique, or you build it to improve the state of the art, or you build it as the foundation for a product etc.
You wrote it "for fun". That's an excellent reason to write something. I can appreciate your effort in that context. It's going to have rough edges etc. And when it's not fun anymore you move on.
Someone else might write the same thing, but for a different reason. Maybe they want a "better Kotlin compiler". They intend to make it perfect, build a product around it and so on. This sort of project encourages a different level of scrutiny than something fun.
So giving context to a project helps attract the right kind of attention. And more importantly the right kind of other-peoples-time.
But yeah, asking like that is not terribly polite.
>genuine question that projects should have an answer for.
Just because they take issue with the wording doesn't mean that they don't have an aswer for that question. Also, that is an awful entry point for a discussion about the purpose of the project.
A toy Kotlin compiler could probably be useful to bootstrap Kotlin from source, without any existing Kotlin binaries. Looks like there is no path to do that right now.
I’m a bit confused by this writeup. It seems to me that you’re experiencing two issues:
1. An object that’s really a Rust Vec under the hood is awkward when you try to pass ownership to C. ISTM you end up solving it by creating what is, in effect, a handle, and freeing that using a custom free function. Is this really a problem with Rust FFI? This style of API is very common in native C code, and it’s a lot more flexible and future-proof than having a library user call free() directly.
2. You’re consuming the API in Rust and being sad that there’s no native defer statement. But Rust can do RAII — could you build a little wrapper struct that implements Drop?
Valgrind sometimes has problems with encapsulated C libraries slow anonymous memory leaks. For example, the session caching in modern libcurl is obfuscated fairly well from novices.
Valgrind is good to run as a sanity check, but I prefer a month under a regression test hammer to validate something isn't going to slowly frag itself before scheduled maintenance. =3
I have implemented polling against a cluster of mixed mariadb/mysql databases which do not offer listen/notify. It was a pain in the neck to get right.
- The batch size needs to be adaptative for performance, latency, and recovering smoothly after downtime.
- The polling timeouts, frequency etc the same.
- You need to avoid hysteresis.
- You want to be super careful about not disturbing the main application by placing heavy load on the database or accidentally locking tables/rows
- You likely want multiple distributed workers in case of a network partition to keep handling events
It’s hard to get right especially when the databases at the time did not support SKIP LOCKED.
In retrospect I wish I had listened to the WAL. Much easier.
Assume that the malware has replaced system commands, possibly used a kernel vulnerability to lie to you to hide its presence, so do not do anything in the infected system directly ?
reply