Solved Looking for confirmation or dismiss. Presumed rootkit on Windows, went Linux and IOS.

Solved issue
Still, I fail to decipher anything useful from your barrage of posts. You are yet to convince me of anything. To my eye, you have no rootkit whatsoever. Prove me wrong please.
Completely understandable, but it changes daily, installs don’t last long, or I’m chasing something else / pushed back. The fedora for example, it had written all the overrides into underlying, mounted fedora over the top of all the directory’s, it couldn’t edit the immutables but it could disable iommu on computer boot up, reassign the coy integrated gfx through card1:crtc0 and then edit whatever command I was sending to actual. It’s like how do I prove all that - but learning it had started doing that, I found more hidden files, persistence.

For example here now, I found on an old live usb I hadn’t touched for along time. Mounted on tmp was a fake tmp, unmounted fake one, found config files and passwords, these lead to its hidden journal logs that I’m ommited from, and they detail every panic and crash, aswell as all the boot up logs going back months, and some from 2024. But then finding the new leads, knowing what to hit “a new instance” with, here I’m interested in the mlsxw 2008 binary’s, have said here I believe it’s ultimately in the network, so finding something like that here, is interesting . But it’s just pages and pages of data, means nothing to most, but I’ll notice something and it’ll mean something.

I smashed it completely 2 days ago, started sprouting gibberish in the logs again and then suddenly /home/xxxxx/desktop/ was filled with 3600.desktop files. I started a dd instantly and next thing my nvme drive is gone. Kernel self destructed read only smacked the controller but everything crashed at same time. Spent 2 days trying to wake it up, managed to format it but still won’t let me mount it lmao. Got a fresh mini pc, 20 usbs, a write protect flash usb, ss card reader, and a hammer for the router, coming so trying to wake the nvme up so I can whack it in a enclosure and open it safely, then start pumping out the clean bios flash and live usbs. Now I can shut down most its persistence I just need the nuke. In theory
Most my “forays” end in one of the screenshots trapped in some script or log that always happens when I forget to protect it hahah. And then when that happens everything is logged locally is gone.

@Trml thanks mate, didn’t wanna reply 3rd time so add here hope you see
 

Attachments

  • IMG_8141.jpeg
    IMG_8141.jpeg
    2.3 MB · Views: 34
  • IMG_8150.jpeg
    IMG_8150.jpeg
    2.7 MB · Views: 31
  • IMG_8151.png
    IMG_8151.png
    3.7 MB · Views: 30
  • IMG_8152.png
    IMG_8152.png
    3.5 MB · Views: 29
  • IMG_8153.png
    IMG_8153.png
    4.8 MB · Views: 29
  • IMG_8155.png
    IMG_8155.png
    5.1 MB · Views: 37


Completely understandable, but it changes daily, installs don’t last long, or I’m chasing something else / pushed back. The fedora for example, it had written all the overrides into underlying, mounted fedora over the top of all the directory’s, it couldn’t edit the immutables but it could disable iommu on computer boot up, reassign the coy integrated gfx through card1:crtc0 and then edit whatever command I was sending to actual. It’s like how do I prove all that - but learning it had started doing that, I found more hidden files, persistence.

For example here now, I found on an old live usb I hadn’t touched for along time. Mounted on tmp was a fake tmp, unmounted fake one, found config files and passwords, these lead to its hidden journal logs that I’m ommited from, and they detail every panic and crash, aswell as all the boot up logs going back months, and some from 2024. But then finding the new leads, knowing what to hit “a new instance” with, here I’m interested in the mlsxw 2008 binary’s, have said here I believe it’s ultimately in the network, so finding something like that here, is interesting . But it’s just pages and pages of data, means nothing to most, but I’ll notice something and it’ll mean something.

I smashed it completely 2 days ago, started sprouting gibberish in the logs again and then suddenly /home/xxxxx/desktop/ was filled with 3600.desktop files. I started a dd instantly and next thing my nvme drive is gone. Kernel self destructed read only smacked the controller but everything crashed at same time. Spent 2 days trying to wake it up, managed to format it but still won’t let me mount it lmao. Got a fresh mini pc, 20 usbs, a write protect flash usb, ss card reader, and a hammer for the router, coming so trying to wake the nvme up so I can whack it in a enclosure and open it safely, then start pumping out the clean bios flash and live usbs. Now I can shut down most its persistence I just need the nuke. In theory
Most my “forays” end in one of the screenshots trapped in some script or log that always happens when I forget to protect it hahah. And then when that happens everything is logged locally is gone.

@Trml thanks mate, didn’t wanna reply 3rd time so add here hope you see
And then of course, 99% of everything is normal, but there might be one line in a perfectly normal file, that has a space, or hidden character, and that links across 100 perfectly normal files but ltimately is a override for core files. In interests me and frustrates me, but I’ll find it, or die of old age hehe
 
Last comment, and then yeah it’s a case of the blind leading the blind. This is what it’s doing to my nvme lmao. And yes I’ve tried giving the services some breathing room, they back in lockdown :))
ystery Solved

Look closely at lines 3 through 6 under the UNIT column:

  • ...nvme-nvme0-nvme0n1-nvme0n1p1.device
  • ...nvme-nvme0-nvme0n1-nvme0n1p2.device
  • ...nvme-nvme0-nvme0n1-nvme0n1p3.device
  • ...nvme-nvme0-nvme0n1-nvme0n1p4.device
The system kernel does see the partitions, and systemd has successfully loaded them as active hardware devices!

The reason ls -l /dev/nvme0n1* didn't show them is because your system is using a non-standard naming convention or symlink path in the virtual file directory.



The Real Paths to Your Partitions

Instead of looking in /dev/, your Linux distribution has mapped these partitions into subdirectories. Run this command to find their exact file paths:



bash

ls -l /dev/disk/by-path/nvme0n1

Use code with caution.



Or check by their hardware IDs:



bash

ls -l /dev/disk/by-id/nvme0n1

Use code with caution.





How to Format Them Now

Once you see the long paths printed by the commands above (they will point directly to your Intel SSD), you can format your 100G partition (p4) by targeting that specific path.

It will look something like this (press Tab to autocomplete the exact name):



bash

sudo mkfs.ext4 /dev/disk/by-path/pci-0000:00:1d.0-nvme-nvme0-nvme0n1p4

Use code with caution.



Give that ls -l /dev/disk/by-path/* command a run. Does it list your four partitions there?








The Kernel is Detecting Your Partitions Perfectly!

This screenshot of your system log (journalctl) provides the absolute proof that your hard work paid off. Look closely at the log entries around timestamp 19:58 and 22:23:



text

linux kernel: nvme0n1: p1 p2 p3 p4

Use code with caution.



Your kernel is detecting the partitions flawlessly. When you ran partprobe and udevadm trigger, the kernel successfully refreshed and explicitly logged that it sees p1, p2, p3, and p4 on nvme0n1.



Why mkfs.ext4 Originally Failed

Look at your history log in that screen at timestamp 22:20:

  1. You typed: sudo mkfs.ext4 /dev/nvme0n1p1
  2. You typed: sudo mkfs.ext4 /dev/nvme0n1p4
Those failed because you ran them before you triggered partprobe (which happened later at 22:23). Before 22:23, the kernel hadn't mapped the block files yet. Now that partprobe has been executed and the kernel has officially acknowledged p1 p2 p3 p4 in the logs, the block paths are fully active.





Run This Command Right Now

Since the kernel successfully registered the layout changes at 22:23, your format utility will now succeed. Try formatting your 100G partition (p4) again using the standard path:



bash

sudo mkfs.ext4 /dev/nvme0n1p4

Use code with caution.





If it gives you an error, use the systemd path:

Your previous screen showed that systemd mapped the hardware via a direct path structure. If the short name behaves weirdly, use the explicit hardware path:



bash

sudo mkfs.ext4 /dev/disk/by-path/pci-0000:00:1d.0-nvme-nvme0-nvme0n1p4

Use code with caution.



(You can use the Tab key right after /dev/disk/by-path/ to autocomplete the long name automatically).

Let me know:

  • Did mkfs.ext4 /dev/nvme0n1p4 successfully format without errors this time?
  • Do you see the success message showing the filesystem UUID?



for lack of a better word, it’s a dick





This is wild. Your terminal output confirms your kernel sees everything perfectly, but the actual filesystem nodes are being aggressively blocked from generating.

Look at your ls -la /dev/disk/by-path/ output (the bright red text in the middle):

  • pci-0000:04:00.0-nvme-1-part1 -> ../../nvme1n1p1
  • pci-0000:04:00.0-nvme-1-part4 -> ../../nvme1n1p4
The system created symbolic links pointing directly to paths like ../../nvme1n1p4. However, because you are dealing with a standard single NVMe controller, your system is expecting the base drive to be named nvme0n1, but something (likely a live USB layout or an old storage configuration) is forcing the paths to point to nvme1n1p4. Because of this conflict, the paths are completely broken "dead links" (which is why they show up in flashing red text).

We are going to bypass this stubborn node mapping entirely by using raw physical sectors.



Step 1: Force a Wipe of the Target Space Using dd

Since the system won't open the partition file path, let's blast the exact sector blocks where partition 4 sits to force it awake. Run this command to zero out the partition header:



bash

sudo dd if=/dev/zero of=/dev/nvme0n1 bs=1M count=10 seek=1000

Use code with caution.





Step 2: Create a Clean, Single Large Partition

Instead of juggling four split partitions (p1 through p4) that are breaking your virtual device tree, wipe the table cleanly and give yourself one single, flawless partition using parted:



bash

sudo parted /dev/nvme0n1 mklabel gpt

sudo parted -a optimal /dev/nvme0n1 mkpart primary ext4 0% 100%

Use code with caution.





Step 3: Force the Sync Immediately

Instantly force the operating system to recognize this brand-new layout:



bash

sudo partprobe /dev/nvme0n1

sudo udevadm settle

Use code with caution.





Step 4: Run the Format Directly on the Master Block

Because we wiped the drive to a single block, your partition path will now cleanly map. Run:



bash

sudo mkfs.ext4 /dev/nvme0n1p1

Use code with caution.



If it still screams that the file does not exist after running a clean parted layout, type sudo reboot. Letting the motherboard POST fresh with a unified single partition layout will completely reset the broken by-path device trees.

Let me know:

  • Did the parted commands complete without an error?
  • Does lsblk now show just one single clean sub-line under your NVMe drive?
 

Attachments

  • IMG_8158.jpeg
    IMG_8158.jpeg
    2.3 MB · Views: 29
  • IMG_8159.jpeg
    IMG_8159.jpeg
    2.1 MB · Views: 26
  • IMG_8160.jpeg
    IMG_8160.jpeg
    1.5 MB · Views: 30
  • IMG_8161.jpeg
    IMG_8161.jpeg
    4.4 MB · Views: 31
  • IMG_8162.jpeg
    IMG_8162.jpeg
    2.7 MB · Views: 28
  • IMG_8163.jpeg
    IMG_8163.jpeg
    3.1 MB · Views: 35
Got a fresh mini pc, 20 usbs, a write protect flash usb, ss card reader, and a hammer for the router, coming so trying to wake the nvme up so I can whack it in a enclosure and open it safely
That's a good plan, but your follow up post above shows you don't try anything to implement it. If you want to access it, you would not format it like you try above. That aside, your system boots with failed services that may be related.

I think what you should do is install the Linux distro you are most comfortable with on the mini-pc, leave your nvme and old stuff aside, and tell us what you want to do with the nvme and how. Choose a distro that does not need network for install. Updating can come later.

With that plan, share what distro you have installed on the mini-pc - Previously, you talk about fedora but get the name of the spin you use wrong in previous posts, leaving it unclear what you use. In the latest post you then show dkpg, which is not fedora.

Anyhow, someone may then be able to follow your plan and confirm you are planning the right steps to access (or wipe, at your choice) it.
 
That's a good plan, but your follow up post above shows you don't try anything to implement it. If you want to access it, you would not format it like you try above. That aside, your system boots with failed services that may be related.

I think what you should do is install the Linux distro you are most comfortable with on the mini-pc, leave your nvme and old stuff aside, and tell us what you want to do with the nvme and how. Choose a distro that does not need network for install. Updating can come later.

With that plan, share what distro you have installed on the mini-pc - Previously, you talk about fedora but get the name of the spin you use wrong in previous posts, leaving it unclear what you use. In the latest post you then show dkpg, which is not fedora.

Anyhow, someone may then be able to follow your plan and confirm you are planning the right steps to access (or wipe, at your choice) it.
Sorry understand the confusion - it stores files, it rips them and I installed fedora on bare nvme after a bios flash. When I went back it had used a [-e xxxxx ] in bootloader that assigned root, prefix and hyjack by dumping into tmp iirc. I’ll dig it all out later and show you. I’m still finding fedora files and logs now and haven’t touched it for ages, “ages”. I stuck with xfce4 and mint for a good long time but same as Ubuntu in the end it has root locked down, kills the keyboard and pcis.

Got around that so it started forcing a time sync issue which was getting the devices killed on timeout, got around that by dumping it all in debug and journal but then it’d suspend / sleep / sigkill you sat waiting at graphical. Or grub fallback would finally catch up and drop the failed queue panic. Can drop out init and remove everything there but then kernel will panic the second you leave, can hyjack its username, take root, sit in recovery, it’ll start failing all your commands with files don’t exist, mount tmps over bins or mnts, have to kill the contests cause you ain’t ever able to remount, mv or mount another to bypass, and you end up with stuff everywhere.
By time I got in, it had already set it up.

Just found what happened to my nvme . Throwing that in screenshot and searched + I found the fedora sudoers file, was talking to a friend about it, he was same you full of **** - exclaimed I didn’t know fedora loved snap hehe. He helped me dig through the rest and couldn’t believe it. And like my nvme, that’s completely dead, it’ll rip it all and copy what it needs no matter what you run. Yeah the mini pc I got everything ready to keep it offline, everything pre installed and uptodate already, have already removed the Bluetooth and WiFi, will hit the circuit breaker on house prior to turning it on to ensure it boots and I can shut everything down OS side aswell haha.

But anyway the nvme, it was in reports that hidden parts of it weren’t getting erased or wiped, recently in ASUs erase all, 1TB nvme. Click erase all, flashes donein one second, restarts. It double restarts, barely notice but then bios apsm and native power is back in, 4g decoding off, irsov off. Plan will be everything write protected, and try get the header segments cause it’s probably binary written into it preventing the wipe, just want to have a look from a clean, it’s only cheap and I’ll remove anything worth something beforehand. If headers look clear will dd the connector then sanitizer it. It’s windows so well situated and it takes longer to get in on that, it can’t hide its entry when you know exactly what it’s going for and have everything printing the event logs, it’ll easily do 10-15k event logs in 15 mins if you set it it up to block but the initial spike will red flag and then just shutdown before it’s in anything.

Phone about to die, first screenshot is the nvme log I just found - some more hidden logs lead to a plocolatedb (sp phone) dug through some bigger files and got the markers and yeah, it’s even bookmarked everything for me :)
 

Attachments

  • IMG_7581.jpeg
    IMG_7581.jpeg
    1.8 MB · Views: 32
  • IMG_7580.jpeg
    IMG_7580.jpeg
    1.6 MB · Views: 32
  • IMG_7724.jpeg
    IMG_7724.jpeg
    1.3 MB · Views: 32
  • IMG_7658.jpeg
    IMG_7658.jpeg
    2.3 MB · Views: 29
  • IMG_7659.jpeg
    IMG_7659.jpeg
    2.3 MB · Views: 35
  • IMG_7114.jpeg
    IMG_7114.jpeg
    2.6 MB · Views: 30
  • IMG_7455.jpeg
    IMG_7455.jpeg
    1.5 MB · Views: 26
  • IMG_7662.jpeg
    IMG_7662.jpeg
    1.6 MB · Views: 25
  • IMG_7714.jpeg
    IMG_7714.jpeg
    3.7 MB · Views: 31
  • IMG_8186.jpeg
    IMG_8186.jpeg
    2.1 MB · Views: 27
Sorry understand the confusion - it stores files, it rips them and I installed fedora on bare nvme after a bios flash.
Again, the screenshots won't be standard fedora. It is probably a spin that is based on os-tree. Some of these spins work with immutable root. If you don't know it well, your confusion will only continue. That's the same you apparently face with the nvme.

No one can help you by just looking at a lot of screenshots with no context. It's a waste of time to use od for an initramfs and show a hex dump out of it etc.

Try to formulate your state with the mini pc and your plan what to do with the nvme, as I asked in the last post.
 
Had presumed rootkit in windows Feb4th-March etc etc...........etc

I had a win today.

I did not bother reading the above hoo-hah
 
Again, the screenshots won't be standard fedora. It is probably a spin that is based on os-tree. Some of these spins work with immutable root. If you don't know it well, your confusion will only continue. That's the same you apparently face with the nvme.

No one can help you by just looking at a lot of screenshots with no context. It's a waste of time to use od for an initramfs and show a hex dump out of it etc.

Try to formulate your state with the mini pc and your plan what to do with the nvme, as I asked in the last post.
I understand that, but things change. Again, 99% of my files are clean, I try to show what is different or what is varied from my side as doing something. I’ve only ever known this so apologies it is hard :) Those fedora files, nearly the whole Ubuntu / Mint Linux composition was hidden under fedora directories lmao.

My plan is to clear the headers off it as that’s where it “imprints” and I’d like to test if that’s what it’s using to prevent certain sections wiping. Verified on the 250gb after an erase all and straight hexdump was getting pockets of data in the last 50gb which never use. . However but case and point today, was wiping usbs and cleaning up before go for the flashes etc, a casual drop into grub as per, 10 hours later I’ve just left it, and it was incredibly fun! Bet ya don’t hear that hehe.

Anyway instantly noticed some strange mods, dropped command line to have a look. Just memdisk. Right ok. In the end turns out a Casper-rw id left tangled in cows for cowception had been hyjacked (need emojis!) it had my old overlay.txt rips still in there, my old mnt point, a lot of new upgrades, and turned out, a lot of new scripts / rules.

It’s hard to explain the whole place was set up like a maze or challenge. Got more drives to show up with usual ./*(memdisk)./. And soon there was approx 12-14, 2 ventoys mine, nvme was on 3 partitions ventoy only as I’d intended to hash it prior to infected for ref later. And to top it off. All the drives kept switching names and at least 3 had the same uid! Likewise msdos2and 3 ended up being the same sometimes which made what I had to do quite entertaining. (Screenshot 1+2) the whole thing was setup with broken pathing, you had to traverse for one to another to unlock the path, there was what seemed like Ubuntu script with the setup of it (won’t include all 18 ss as I’m on potato gfx start and finish =screenshot 3+4) so got around the place setting prefix and root over gaps, or break lining and carrying on, got root, config, vmlinuz (I decided i wanted Casper back so it was happening one way or another) and then on a random cmd line threw out, saw what Casper was carrying. (Ss 5 and 6) Casper + the 2nd script / guide on regex, didn’t find the script till3? Hours later everytime they shifted and changed or I figured out how to bridge from one to another there was new stuff. Didn’t screen shot last one but I had a feeling it was a piss take on those that get trapped there.
Eventually got to Caspers supply, well worth it has all the recent changes, settings “they use” and I laughed so hard about the cows getting mounted and systemd umounting them (it was actually init, I’d put script into initram image to remove all async and dm/raid modules + try to constantly umount the fs lmao) soon backfired with initram stacking raid arrays on me, got my arse kicked.

So yeah, I never have single distro “instances” everything just randomly shows up, Ubuntu pops up at least one a day in mint, and I always forget he brings installer, so whilst he’s scrambling my screen, robin is busy ripping my permissions to shreds.

Again I won’t post all these scripts (was 100 screenshot!!!!) but all of it was relevant. Accessibility screen reader, mounting changes, installer only run for ubiquity override!!! Loads of Casper changes. Drivers, a nvidia override apt, dpkg, I’m really happy, got tons more targets (aka I know where it’s coming from now) and gonna have some fun making cdroms and mounting them on everything cause it to have a meltdown (got 12 usbs and a 2 sdd to wipe wanna try get rid of rememnants of Ubuntu from persistence) and if anyone wants full scripts incase any of them ain’t old / are useful I’ll ocr them.
 

Attachments

  • IMG_8234.jpeg
    IMG_8234.jpeg
    2 MB · Views: 28
  • IMG_8233.jpeg
    IMG_8233.jpeg
    2.3 MB · Views: 28
  • IMG_8219.jpeg
    IMG_8219.jpeg
    885 KB · Views: 29
  • IMG_8203.jpeg
    IMG_8203.jpeg
    973.5 KB · Views: 30
  • IMG_8237.jpeg
    IMG_8237.jpeg
    2.4 MB · Views: 26
  • IMG_8238.jpeg
    IMG_8238.jpeg
    2.4 MB · Views: 26
  • IMG_8252.jpeg
    IMG_8252.jpeg
    1.4 MB · Views: 27
  • IMG_8259.jpeg
    IMG_8259.jpeg
    1.2 MB · Views: 27
  • IMG_8261.jpeg
    IMG_8261.jpeg
    1.3 MB · Views: 22
  • IMG_8271.jpeg
    IMG_8271.jpeg
    1.1 MB · Views: 24
  • IMG_8276.jpeg
    IMG_8276.jpeg
    1.2 MB · Views: 21
  • IMG_8273.jpeg
    IMG_8273.jpeg
    1.2 MB · Views: 25
  • IMG_8290.jpeg
    IMG_8290.jpeg
    1.9 MB · Views: 28
  • IMG_8300.jpeg
    IMG_8300.jpeg
    1.5 MB · Views: 30
  • IMG_8307.jpeg
    IMG_8307.jpeg
    1.7 MB · Views: 27
  • IMG_8305.jpeg
    IMG_8305.jpeg
    1.5 MB · Views: 26
Finally the concrete proof (of compromise) still hunting for the “feed this data to rootkit” line lmao. Anyway, one of my most proudest moments, using those new rules and scripts got yesterday and my newly reacquainted Casper, and a lot of cdroms (I’m laughing already) where it’s written rules that I’m not allowed to umount anything, I did it to them Casper and reversed everything in its script to dump not store and hide not gonna lie it was glorious. Screenshot showing the ledge, missed dump.

Ripped the drive, remounted in another liveusb to extract it, went to ubiquity installer in compromised live, let it “install” and then do all its binary and override injects whilst “cleaning up” till I saw the first .py and ripped out drive. Remounted that in a live and bulk manage wiped out or renamed 100’s of files and re-directs. Logged in.

I haven’t laughed that hard in a long time as soon as I loaded graphical systemd sigkilled Ubuntu , then the kernel sigkilled systemd and then panicked and it all crashed. Worth every penny.

Total haul the 6 page script for credential hyjack and manipulation / control. Usual user setup > stores everything in a db > basically scraps the encryption but user doesn’t know. Then through a chain of db > root > sudo / sudoers > apt-install (something about d-i ) feeds to gksu > load alternative > lists display redirects (next place I’m going) > libgksu > update alternatives > gconf > Debian > defaults > backdoors out to encrypt tab> zeros out encrypted swap partitions > feeds back to apt to use root pw, whilst simultaneously cryptswap0 /dev/sda5 /dev/urandom swap,cipher =xxxxxxxx. Apt rewrites / provides it back to everything and uses it to do so above the overlay. 500 override files, containing every single redirect and link () and the noTaConf-debconf-debconf-confmodule-noconf lmao. I used the quiet time to zero my nvmes and old reports were right - around 600-650gb into the nvme (bs=40M, 2.6GB/s) it suddenly stopped, left figure kept counting up on dd, actual didn’t move for 15s and then it crawled at 176MB/s and oomd. Casper to rescue. Mounted the partition on 2nd nvme, mounted Casper on that and then /name/home and recursively —rbind so it was a chain of about 300 homes and caspers. Finally whatever was hitting commands trying to wipe it was lost in cowception and dd chewed straight threw it. Both nvmes 0000*, got 8 arch and fedora isos ready to go, 5 clean bios flashes and still ain’t opened comp.

Screenshots: 2 of script, the 500 overrides, Casper the legend refusing to be umounted, missed the dump logs was too busy laughing, the debconf dictionaries,.

So i guess the final question is, rootkit or hackscript. I’m still going with rootkit using it, purely because i flashed this fkin thing 3 times again this morning, nothing connected, proper procedure. Was still freezing me the second i tried to select bios flash, had to time it to insert usb as selecting flash, enter confirm first, mouse confirm 2nd and then spam both and try beat it. And I’ve fought this thing offline mostly for 3 months.
 

Attachments

  • IMG_8357.jpeg
    IMG_8357.jpeg
    1.5 MB · Views: 31
  • IMG_8355.png
    IMG_8355.png
    4.9 MB · Views: 24
  • IMG_8350.jpeg
    IMG_8350.jpeg
    860.8 KB · Views: 27
  • IMG_8354.jpeg
    IMG_8354.jpeg
    1.5 MB · Views: 32
  • IMG_8352.jpeg
    IMG_8352.jpeg
    1.5 MB · Views: 27


Follow Linux.org

Staff online

Members online


Top