indeed, I could reproduce it, just force push `master` into a PR, github UI will close the PR, marked it as merged, delete the source branch ... but of course nothing happens in the git repo :/
> To load the rootkit into kernel space, it is necessary to approximately match the kernel version used for compiling; it does not have to be strictly the same.
A kernel module doesn't have to match the kernel version, it has to be able to resolve all the symbols (function calls, variables etc) it uses into valid symbols supplied by the kernel you are loading on.
The greater the difference between the kernel version you compiled for, and the kernel version you are trying to load it on, the greater the chance something you are relying on changed and the module loader cant resolve all the symbols and so it fails.
So saying a kmod has to match the kernel version is good practice but the reality is not quite as strict.
Red Hat has a list of "white listed" symbols that they try to maintain across a major version of RHEL so if your kmod only relies on them and nothing else then it should load on any kernel version within that release. But that's a Red Hat thing, not a Linux kernel thing.
Perhaps also worth noting that rootkits don't have to follow the usual rules; you don't have to rely on the kernel linker if you don't want to.
(Tradeoff of runtime DIY symbol resolution / code grovelling being it's more work, and more likely to be crashy).
As a rootkit author you have considerably more flexibility than most module authors who are constrained by "sanity", maintainability, accepted practice and licensing terms.
I don't know the exact rules, but note that this is targeting RHEL6 and Red Hat makes a deliberate effort to preserve kernel ABI compatibility so it is probably a lot easier than on most Linux distributions.
(context: my son is DT1) We learn (in France) that hypoglycemia can lead to unconsciousness, but cannot be fatal as the liver will eventually take over and release glucose to the organism, as it always does for healthy persons. Glucagen injection is the way to get this release to happen fast, but it can be delayed if necessary.
The difference between 'doubt' and 'doute' is the vowel sound, not a presence/absence of 'b'. 'debt' and 'dette' don't sound quite identical to me (as a native English speaker and learner of French) but they're very close and the difference isn't that there's a 'b' sound in there. Maybe it's that French 't' is slightly different.
French t is dental, English t is alveolar---in non-technical language, that means the French t is pronounced slightly further forward in your mouth, compared to the English t.
The English t is also aspirated a lot of the time (though not as consistently at the end of a word as at the beginning), while the French t is never aspirated.
There could be differences between the two short e sounds as well, but that depends more on which particular accents of English/French you're talking about.
What would you put in the "light" QR code ? If you put the date of the test, then the organizer can access it. If you don't, then they can't check whether your test is recent enough to be authorized to attend their event.
Like the original author states, than can't be done without a trusted 3rd party ( say a token with a service telling you whether the pass is valid at current date)
I'm personally a big fan of vanilla GDB, at least for plain C debugging. Disclaimer: I spent >5years on a PhD work searching how to extend GDB for parallel and embedded programming.
I can't easily see the surrounding code
I have Emacs on the side window, so I use GDB to see the immediately surrounding code, and Emacs to see the rest of the function. I do exactly the same for Python debbuging with PDB
I have to manually request information rather than just glancing at the display
I just print the variables I want to see, there are not so many of them I'm actually interested in while debugging
I have to remember syntax rather than just clicking on things
...and in this case, it took me a few tries to correctly deref this pointer to an fixed-size array
those are the tradeoff between flexibility and ease. You can access any memory locations, and cast it in many different ways, examine the assembly to precisely understand the next steps, examine the bits to precisely understand the storage (only endianness issues remained tricky to follow)
> those are the tradeoff between flexibility and ease
It isn't a required tradeoff. Most of the gdb frontends I tried display the local variables at all time, but also allow writing arbitrary gdb expressions if I want to. Having both is clearly better.
I will rewrite this sentence, "invalid instruction" is too limited. It should be something like "an instruction that traps, and which isn't already used for another purpose".
Syscalls trap but they are already used; and INT3/CC are valid instructions.
Your description still has problems on architectures like x86 with instructions of different lengths. In particular, you pretty much have to use a single-byte instruction to do the trap; a multi-byte one runs the risk of clobbering other code that could well be jumped to. That’s why INT3 exists as a single-byte instruction to begin with!
