Kernel updates

[LJ-78]

Was starting to poke at what it might look like to handle newer linux kernels. I noticed you mentioned short comings due to certain symbols no longer being exported. When I was playing around with GDB and a newer kernel it looked like maybe it wasnt able to get the base address correctly? I'm testing on Ubuntu 20.04 with kernels 5.4 and 5.15 installed. 5.4 seems to move thru the function seeking the base address no problem, but 5.15 seems to get hung up post string checks. I was wondering if you had a process that you used to build out the details used to generate the base address. The strings still seem to exist, I think maybe its the last set of checks that are executed...the check that it ends with at least 0x100 0x00? Not certain on that...

If it is the case that it is not getting the base address correctly and that is solvable, I dont know that it would really help the lack of certain symbols no longer getting exported. Is there perhaps a better way to deal with the modern kernels in linux?

[ufrisk]

Hi,

This is definitely something I'd have to look into. Unfortunately I don't think the fix is very easy for me since they moved around how they do the symbols in recent kernels so I'd have to spend some considerable amount of time to get this working again.

It's very important that I get it working again so I'll definitely do it.

I'm totally choked with other work and projects in the coming week (or weeks) so it may be a few days before I'm able to really sit down and research possible ways forward with regards to this.

Since this is more of an architectural change in the way Linux does symbols there is no clear easy process for me to follow that would resolve this issue in no-time. My normal process otherwise is looking at memory, printf, printk and debugging in visual studio :\

I really hope to be able to push an update in the coming month though.

[LJ-78]

Yes, I've been doing some reading in regards to the symbols they no longer export. Mainly I noticed it in a blog post about writing rootkits for kernels 5.7 and up. Seems they no longer export kallsyms_lookup_name(). Seems some solutions exist. One write up I saw mentioned used kprobe. In that blog article the author ends up using that as method. Though previously the author just mentions iterating over the addresses using sprint_symbol and strcmp till the functions needed are identified. I thought maybe using that in the kernel modules you had developed could be something worked up. However, I think first I need to figure out getting the base address figured out. I'm not sure if I'm using the debugger correctly, but fairly confident the function KMD_Linux48KernelBaseSeek is failing with the current heuristics used (as mentioned though it does find the process strings.) I'll likely be poking at that to see if I cant figure it out. Its good opportunity to learn more about with the kernel at this level. Thanks. i look forward to anything you figure out. Should I figure something out i'll be sure to let ya know.

[ufrisk]

I finally finished up my other more urgent tasks I had at hand so I looked into this.

It seems like the initial kernel-base locator check isn't working due to some changes. If I hard code the physical address it works fine on 5.15.0-82-generic (Ubuntu 22.04) with no other changes 👍

The fix should be fairly easy for me to implement and I'll issue the fix in the coming week :) I just have to finish it up first and do some testing first. I'll let you know here when I've fixed it.

Thanks for making me aware of this issue.

[ufrisk]

This should now be updated for 5.15 kernels (latest Ubuntu 20.04).

6.2 kernels (latest Ubuntu 22.04) will require more work. Quite a lot more work I'm afraid so I won't commit to a time schedule even though I'll be looking into it.

But your issue should now be resolved. Please let me know if the fix works.

[ufrisk]

Ubuntu 22.04 (kernel 6.2) should now be fixed as well.

Also, I released a new lx64_exec_root module.

Remaining are a few existing modules, such as the mount, which currently won't work. I'll have to look into it as well. But the primary kernel inject and a few of the modules (such as the lx64_exec_root) will work on the lastest Ubuntu kernels if DMA access is possible.

Thanks for making me aware of this issue. Since it's now resolved I'm closing this issue.

Please let me know if you should run into more issues around this.

And best wishes with your DMA attacking 😃 If you find PCILeech to be useful please consider sponsoring the project for as little as $2/month 💖