Despite the name it is not just a load-and-leave situation. We aren't sure if the general community is aware of the degree of control the "loader" has over their box. We believe that the code of the loader MUST be public. If you want to make us feel better leave a like and a good word for us, as naturally this isn't our full-time job :))) For various reasons we cannot (and not willing to) accept any donations. However, we wish to have some testing version not too far in time. We greatly appreciate any PRs on GH.Īt this stage most likely not. Yes! As this project took a lot from the community we strongly believe it should continue to be shared and developed under GPL. If you know where to look you will find us on IRC
We're a group of passionates dating back to the (great) phreaking times. While this is the hardest to pull off properly, it doesn't rely on a hack but rather an official and documented Linux API.
We picked the third one (full PCI emulation) as it allows for creation of devices which are indistinguishable from real ones. This isn't hard in theory but has many pitfalls if we want to do it properly and none of us ever studied inner workings of PCI on x86 As described in the PCI document in the research repo there are three methods. If anyone in the community has an idea of what is the source of these we will be grateful for some pointers.Īs of now we're working on a robust PCI emulation layer. The current revision of the LKM causes some errors to be sent to the PMU. However, it's not really straight-forward as naturally the kernel doesn't have a high-level API to lie about nonexisting hardware While the latter is most likely not crucial, the former must be implemented. The kernel module is currently missing the PCI-IDs shimming and RTC emulation. The tool with instructions will be published in a separate repo. We are currently working on a toolset for generating the loader image automatically so that testing new iterations is easier for people not familiar with full inner workings of the kernel component & the bootloader itself. Thus, your forks and PRs will work properly.Īs of now the DSM installs & boots properly (sort of, continue reading). While the dates and authors in both repos are anonymized, the history is preserved. DSM Research/Docs: hosts documentation for developers regarding the inner details of DSM boot process RedPill LKM: contains the current version of the Linux kernel module source code along with implementation details description Both are automatic forks from our internal serves and are updated few times a day. We're happy to report it's back and fully public! Before further ado we have a small sneak-peek of the current state:īoth LKM code and the research materials are present in two repositories.
As some of you may be aware a lot of research materials as well as the code for parts of the kernel module were pulled from GH.
0 kommentar(er)
