hashpwn

Terms of Service & Privacy Policy Effective Date: Aug 31, 2025 Welcome to hashpwn.net (“we,” “our,” or “us”). By accessing or using hashpwn.net or any of its subdomains (collectively, the “Services”), you agree to comply with and be bound by these Terms of Service. This includes, but is not limited to, the forum and any Services we may provide under the hashpwn.net domain. If you do not agree, please discontinue use of the Services. 1. Eligibility You must be at least 18 years old to register for or use any hashpwn.net Services. By using our Services, you represent that you meet this requirement. 2. User Conduct When using any hashpwn.net Service, you agree not to: Post, share, or request personally identifiable information (PII). Share, request, or distribute illegally obtained data (e.g., combo lists, stolen data, etc). Engage in hate speech, harassment, or unlawful activities. Attempt to compromise, disrupt, or misuse any Service we provide. Post, share, request, or link to any sexually explicit, pornographic, or sexually suggestive content. Our Services are intended for ethical cybersecurity research, discussion, and learning. Illegal activity is strictly prohibited. 3. User Content You retain ownership of any content you post, upload, or submit to hashpwn.net Services. By submitting content, you grant hashpwn.net a non-exclusive, worldwide license to store, display, and distribute your content as necessary to operate and provide the Services. Requests for deletion of publicly posted content will be honored, except in rare cases where retention is required for legal, security, moderation, or administrative reasons (e.g., evidence of abuse). Account deletion and personal data removal requests will always be honored. 4. Privacy & Data Collection We respect your privacy. We collect basic technical information such as IP address, cookies, browser type, and usage analytics. We use this information only for site functionality, security, and moderation. We may log usage data to maintain service quality. We do not sell, rent, or share your information with third parties for advertising or marketing purposes. Users may request removal of their personal data. 5. Disclaimer of Warranties All Services provided by hashpwn.net are offered “as is” and without warranties of any kind, whether express or implied. We do not guarantee uptime, availability, or error-free operation for any Service. Use of hashpwn.net Services is at your own risk. 6. Limitation of Liability To the fullest extent permitted by law, hashpwn.net, its owners, administrators, moderators, and affiliates are not liable for any damages arising from use of our Services, including but not limited to loss of data, downtime, security issues, or service interruptions. 7. Termination We reserve the right to suspend, restrict, or terminate accounts or access to any hashpwn.net Service at our discretion for violations of these Terms or other reasons deemed necessary to protect the community and infrastructure. 8. Changes to the Terms We may update these Terms at any time. Changes will be posted on this page with a new effective date. Continued use of our Services after updates are posted constitutes acceptance of the revised Terms. 9. Contact For questions, concerns, or requests, please contact: @cyclone (Admin/Owner)

60 found_0.txt 122 left_0.txt left_0.txt found_0.txt

Januscape: Linux KVM Guest-to-Host Vulnerability in x86 Shadow MMU [image: 1783541008927-006e1164-01f5-4dfa-9392-bb1d42ea8ec3-image.jpeg] Januscape is a newly disclosed Linux KVM vulnerability affecting x86 virtualization hosts. Tracked as CVE-2026-53359, the issue is a use-after-free bug in the KVM/x86 shadow MMU code path. The bug is especially relevant for KVM environments that expose nested virtualization to untrusted guest VMs. At a high level, this is a guest-to-host isolation issue. A malicious guest with kernel-level privileges inside the VM can trigger corruption in the host kernel’s KVM shadow page state. The public proof-of-concept is a host panic/DoS, but the researcher says the same bug has also been turned into a full guest-to-host escape in a controlled environment. That full exploit has not been publicly released. The vulnerability was discovered and reported by Hyunwoo Kim, also known as @v4bel, and was reportedly used as a zero-day submission in Google’s kvmCTF program. The root cause is in how KVM reuses shadow MMU pages. KVM keeps shadow page tables that mirror guest-controlled paging structures in certain modes. When nested virtualization is enabled, KVM may need to shadow the nested EPT/NPT structures built by the guest hypervisor. This forces execution through the legacy shadow MMU path, even on modern systems that normally use hardware-assisted two-stage paging such as Intel EPT or AMD NPT. The vulnerable function, kvm_mmu_get_child_sp(), reused an existing child shadow page based on a matching guest frame number, but did not also verify that the shadow page role matched. In practice, two shadow pages can refer to the same GFN while serving different purposes. One may be a direct split page derived from a large mapping, while another may be an indirect shadow page for a guest page table. Reusing the wrong one breaks KVM’s internal reverse-map accounting. Once that accounting is wrong, KVM may fail to remove the correct reverse-map entry when tearing down shadow pages. Later, when the relevant memslot or shadow page is freed, stale pointers can remain. When KVM later walks or cleans up those structures, it can dereference or write through memory that has already been freed. The public PoC drives this into a host kernel panic through KVM’s own corruption detection path. This is not a QEMU bug. The vulnerable logic is in the in-kernel KVM implementation. That distinction matters because mitigations focused only on QEMU device emulation do not address this issue. The practical risk depends heavily on the environment. The most concerning targets are: x86 KVM hosts Multi-tenant virtualization platforms Cloud, hosting, CI, lab, or VPS environments Systems where guests are untrusted Hosts exposing nested virtualization to guests The attack requires root or equivalent kernel-level control inside the guest VM, because the published trigger is implemented as a guest kernel module. In many cloud or VPS scenarios, that is not a strong limitation, since customers commonly have root inside their own guest. The more important exposure condition is whether nested virtualization is available to the guest. The issue affects both Intel and AMD x86 systems because the vulnerable shadow MMU logic is shared across the KVM/x86 implementation. ARM64 KVM hosts are not affected by Januscape, although they have had separate KVM escape-class issues such as ITScape. The vulnerable code dates back to commit 2032a93d66fa from the Linux 2.6.36 era, around 2010. The mainline fix is commit 81ccda30b4e8, which updates the reuse check so KVM compares the shadow page role along with the GFN. In simple terms, KVM now only reuses a shadow page when both the frame number and the role match. Fixed stable kernel versions reported include: 7.1.3 6.18.38 6.12.95 6.6.144 6.1.177 5.15.211 5.10.260 Distribution backports may not line up cleanly with upstream version numbers, so admins should check vendor advisories and package changelogs rather than relying only on uname -r. For operators, this should be treated as a high-priority patching issue if nested virtualization is exposed to untrusted guests. The safest remediation is to update the host kernel to a vendor-patched build and reboot into the fixed kernel. If patching cannot be done immediately, disabling nested virtualization is the main mitigation for the guest-to-host path: kvm_intel.nested=0 kvm_amd.nested=0 After applying that mitigation, reboot the host or reload the KVM modules only if no guests are running. On production systems, rebooting into a known-good configuration is usually the cleaner approach. Useful checks on a KVM host include: uname -r lsmod | grep '^kvm' cat /sys/module/kvm_intel/parameters/nested 2>/dev/null cat /sys/module/kvm_amd/parameters/nested 2>/dev/null Inside a guest, nested virtualization exposure commonly shows up as vmx or svm CPU flags: grep -Eo 'vmx|svm' /proc/cpuinfo | sort -u For Proxmox, OpenStack, VPS, and general KVM operators, the key question is not simply “am I running KVM?” The better question is: “Can an untrusted guest reach nested virtualization on an unpatched x86 KVM host?” If yes, this deserves immediate attention. The public PoC is intended to demonstrate a host panic and should not be run on production infrastructure. A successful crash can take down all VMs sharing the same physical host. A failed crash also does not prove that the host is safe. This is one of those bugs where the operational risk is narrower than a generic remote kernel RCE, but severe in the right environment. For single-user local KVM labs, the impact may be limited. For multi-tenant x86 KVM infrastructure with nested virtualization enabled, it is a serious guest isolation failure. Sources: Januscape researcher repository: https://github.com/V4bel/Januscape Openwall oss-security disclosure: https://www.openwall.com/lists/oss-security/2026/07/06/7 NVD - CVE-2026-53359: https://nvd.nist.gov/vuln/detail/CVE-2026-53359 The Hacker News: https://thehackernews.com/2026/07/16-year-old-linux-kvm-flaw-lets-guest.html

RCR v0.3 — RuleFlow Chain Runner A GUI front-end for the RuleFlow pipeline: rulest + concentrator + ranker, all wired together to get the most out of the extracted Hashcat rules. What it actually does You feed it three files—a base wordlist, a target wordlist, and cracked passwords. You select an OpenCL device, choose a preset, and you can adjust the expected runtime (higher values ​​result in more chains generated), click Run, and the program runs through the entire chain: informed extraction, genetic rule extraction, rule cleaning/optimization, and then scoring and ranking the survivors from the larger results. Finally, you get a structured CSV file. The presets Mode Generations Populations Best for Fast 150 300 Quick tests, medium dictionaries Balanced 300 600 Daily driver, good default Maximum 500 1000 Deep runs, large or stubborn sets Why I built this The backend tools are solid, but running them one-by-one with long command lines gets old fast. This wraps the whole flow in a single window with: Live log with ANSI colors, horizontal scrolling for long lines, and auto-trim so it doesn't choke on verbosity Memory watchdog — monitors RAM/VRAM usage and auto-suggests switching to Low-Memory preset if a stage gets killed by OOM OpenCL device scanner — detects your GPU or falls back to CPU without manual --device flags MAB vs Legacy ranker — pick adaptive bandit sampling for huge skewed rule sets, or exhaustive scoring when you want full statistical accuracy Quick start git clone https://github.com/A113L/ruleflow.git cd ruleflow python rcr [image: 1783156184940-rcr-midrun.jpg] Requires Python 3 + tkinter. The backend scripts (rulest_v2.py, concentrator.py, ranker.py) should be in the same directory. Feedback or bug reports welcome — this is a personal tools that grew a UI, so rough edges are expected.

Escrow ID# 89868 • Algorithm: Blockchain, My Wallet, V2, -m 15200 • Total hashes: 153 • Price per hash: $99.7826 • Escrow URL: https://hashes.com/en/escrow/item/?id=89868 • Download hashes: 89868_15200.zip

Scheduled Host Maintenance Our host will be performing scheduled maintenance that requires a reboot of the VPS hosting hashpwn. During this maintenance, the forum and related hashpwn services will go offline temporarily. Expected downtime is less than 30 minutes, although we have not been given an exact ETA for when the reboot will occur. This notice is just to give everyone a heads up.