CARVIEW |
Select Language
HTTP/2 200
date: Thu, 24 Jul 2025 01:18:31 GMT
content-type: text/html; charset=utf-8
vary: X-PJAX, X-PJAX-Container, Turbo-Visit, Turbo-Frame, X-Requested-With,Accept-Encoding, Accept, X-Requested-With
etag: W/"3dc2dd32014ac65ad9d243640b49a57e"
cache-control: max-age=0, private, must-revalidate
strict-transport-security: max-age=31536000; includeSubdomains; preload
x-frame-options: deny
x-content-type-options: nosniff
x-xss-protection: 0
referrer-policy: no-referrer-when-downgrade
content-security-policy: default-src 'none'; base-uri 'self'; child-src github.githubassets.com github.com/assets-cdn/worker/ github.com/assets/ gist.github.com/assets-cdn/worker/; connect-src 'self' uploads.github.com www.githubstatus.com collector.github.com raw.githubusercontent.com api.github.com github-cloud.s3.amazonaws.com github-production-repository-file-5c1aeb.s3.amazonaws.com github-production-upload-manifest-file-7fdce7.s3.amazonaws.com github-production-user-asset-6210df.s3.amazonaws.com *.rel.tunnels.api.visualstudio.com wss://*.rel.tunnels.api.visualstudio.com objects-origin.githubusercontent.com copilot-proxy.githubusercontent.com proxy.individual.githubcopilot.com proxy.business.githubcopilot.com proxy.enterprise.githubcopilot.com *.actions.githubusercontent.com wss://*.actions.githubusercontent.com productionresultssa0.blob.core.windows.net/ productionresultssa1.blob.core.windows.net/ productionresultssa2.blob.core.windows.net/ productionresultssa3.blob.core.windows.net/ productionresultssa4.blob.core.windows.net/ productionresultssa5.blob.core.windows.net/ productionresultssa6.blob.core.windows.net/ productionresultssa7.blob.core.windows.net/ productionresultssa8.blob.core.windows.net/ productionresultssa9.blob.core.windows.net/ productionresultssa10.blob.core.windows.net/ productionresultssa11.blob.core.windows.net/ productionresultssa12.blob.core.windows.net/ productionresultssa13.blob.core.windows.net/ productionresultssa14.blob.core.windows.net/ productionresultssa15.blob.core.windows.net/ productionresultssa16.blob.core.windows.net/ productionresultssa17.blob.core.windows.net/ productionresultssa18.blob.core.windows.net/ productionresultssa19.blob.core.windows.net/ github-production-repository-image-32fea6.s3.amazonaws.com github-production-release-asset-2e65be.s3.amazonaws.com insights.github.com wss://alive.github.com api.githubcopilot.com api.individual.githubcopilot.com api.business.githubcopilot.com api.enterprise.githubcopilot.com; font-src github.githubassets.com; form-action 'self' github.com gist.github.com copilot-workspace.githubnext.com objects-origin.githubusercontent.com; frame-ancestors 'none'; frame-src viewscreen.githubusercontent.com notebooks.githubusercontent.com; img-src 'self' data: blob: github.githubassets.com media.githubusercontent.com camo.githubusercontent.com identicons.github.com avatars.githubusercontent.com private-avatars.githubusercontent.com github-cloud.s3.amazonaws.com objects.githubusercontent.com release-assets.githubusercontent.com secured-user-images.githubusercontent.com/ user-images.githubusercontent.com/ private-user-images.githubusercontent.com opengraph.githubassets.com copilotprodattachments.blob.core.windows.net/github-production-copilot-attachments/ github-production-user-asset-6210df.s3.amazonaws.com customer-stories-feed.github.com spotlights-feed.github.com objects-origin.githubusercontent.com *.githubusercontent.com; manifest-src 'self'; media-src github.com user-images.githubusercontent.com/ secured-user-images.githubusercontent.com/ private-user-images.githubusercontent.com github-production-user-asset-6210df.s3.amazonaws.com gist.github.com; script-src github.githubassets.com; style-src 'unsafe-inline' github.githubassets.com; upgrade-insecure-requests; worker-src github.githubassets.com github.com/assets-cdn/worker/ github.com/assets/ gist.github.com/assets-cdn/worker/
server: github.com
content-encoding: gzip
accept-ranges: bytes
set-cookie: _gh_sess=jdZ7WdpMBFRhS7qQsDdd4QB6tguDOBARbvS6iyzIOfk4TxvcbUO9Wos32L2p1zBmDNWANZ0dW6Mq7sEJDJSX7Ph9%2BK%2FCMX79HXgBIH3WOGDxAW479brmYraff8G85214ZjnruhGN4rTZSK5wulTjAaDL08clwPsNBXanYxCyu%2FX1zFZajpJtdwSo6NhKDOSvqFmpM5IdQzfa%2FiDe%2Fx2pA0s%2BDAq6AceLczUoTMCSkg4wVC7SvRS2RAwXI8L5rC0KkwL8b9niAWspR9%2FzmeO78g%3D%3D--OhRf%2BiVRN7kU1c86--%2FHSPQcDOUVvDb%2Bb5MKzxtA%3D%3D; Path=/; HttpOnly; Secure; SameSite=Lax
set-cookie: _octo=GH1.1.649053691.1753319910; Path=/; Domain=github.com; Expires=Fri, 24 Jul 2026 01:18:30 GMT; Secure; SameSite=Lax
set-cookie: logged_in=no; Path=/; Domain=github.com; Expires=Fri, 24 Jul 2026 01:18:30 GMT; HttpOnly; Secure; SameSite=Lax
x-github-request-id: BA80:12BD61:11B54A9:156B66B:688189E6
Tags · 0vercl0k/wtf · GitHub
Toggle v0.5.7's commit message
Toggle v0.5.6's commit message
Toggle v0.5.2's commit message
Skip to content
Navigation Menu
{{ message }}
-
-
Notifications
You must be signed in to change notification settings - Fork 140
Tags: 0vercl0k/wtf
Tags
v0.5.7
Fix regressing while single-stepping after a breakpoint in WHV (#228) In v0.5.5 I introduced a regression in WHV where the code handling the single step exception generated after handling a breakpoint didn't properly remove the trap flag which leads to another VMEXIT but this time is not expected. I thought the bit would get stripped off by the CPU it was getting removed by the CPU but maybe VMX behaves differently? I've looked through the manuals a bit but I didn't really find anything conclusive. If you know why / where this is documented please let me know :)
v0.5.6
Disable single stepping once we've stepped over the breakpoint (fix #223 ) (#224) This PR fixes a regression in the KVM backend that was introduced in `v0.5.5` when implementing RIP traces. The issue happens when the user has a breakpoint set-up that won't move execution; in that case `wtf` needs to step-over that breakpoint to carry on execution. To do that, it temporarily removes the breakpoint off of memory and will single-step this instruction. After the single-step, we receive a fault and we can figure out that the reason why we're getting this fault is because we were single-stepping over a breakpoint in which case we need to re-enable it, etc. Because that single-step bit wasn't properly unset in that case, execution would carry on and re-enter with another single step instruction but this time the state didn't indicate that it was because we were performing a step-over, so `wtf` aborts. Here is an illustration of the bug with the HEVD/KVM with logging on: ``` bubuntu:~/wtf/targets/hevd$ sudo ../../src/build/wtf run --name hevd --input ./inputs/A --backend kvm ... Running ./inputs/A kvm: exit_reason = KVM_EXIT_DEBUG @ 0x7ff6f5bb111e kvm: Handling bp @ 0x7ff6f5bb111e Hevd: Hello! kvm: Disarming bp and turning on RFLAGS.TF (rip=0x7ff6f5bb111e) kvm: Turning on RFLAGS.TF kvm: exit_reason = KVM_EXIT_DEBUG @ 0x7ff83e2e6360 kvm: Received debug trap @ 0x7ff83e2e6360 <------------------------ first, expected trap kvm: Resetting breakpoint @ 0xd37411e kvm: Turning off RFLAGS.TF <------------------------ this was actually not done kvm: exit_reason = KVM_EXIT_DEBUG @ 0x7ff83e2e6365 kvm: Received debug trap @ 0x7ff83e2e6365 <------------------------- second trap which is unexpected Got into OnDebugTrap with LastBreakpointGpa_ = none -------------------------------------------------- Run stats: Dirty pages: 53248 bytes, 13 pages, 0 MB UffdPages: 90112 bytes, 22 pages, 0 MB VMExits: 3 Instructions executed: 2 #1 cov: 0 exec/s: 0.0 lastcov: 0.0s crash: 0 timeout: 0 cr3: 0 uptime: 0.0s ``` Here is the expected output / the fixed version: ``` bubuntu:~/wtf/targets/hevd$ sudo ../../src/build/wtf run --name hevd --input ./inputs/A --backend kvm ... Running ./inputs/A kvm: exit_reason = KVM_EXIT_DEBUG @ 0x7ff6f5bb111e kvm: Handling bp @ 0x7ff6f5bb111e Hevd: This is a breakpoint executed before the first instruction :) kvm: Disarming bp and will turn on single step (rip=0x7ff6f5bb111e) kvm: Turning on SINGLESTEP kvm: exit_reason = KVM_EXIT_DEBUG @ 0x7ff83e2e6360 kvm: Received debug trap @ 0x7ff83e2e6360 kvm: Resetting breakpoint @ 0xd37411e kvm: Turning off SINGLESTEP kvm: exit_reason = KVM_EXIT_DEBUG @ 0xfffff8046f122bb0 kvm: Handling bp @ 0xfffff8046f122bb0 Hevd: DbgPrintEx: [-] Invalid IOCTL Code: 0x%X kvm: The bp handler ended up moving @rip from 0xfffff8046f122bb0 to 0xfffff8046ca955ec so no need to do the step-over dance kvm: exit_reason = KVM_EXIT_DEBUG @ 0x7ff6f5bb1124 kvm: Handling bp @ 0x7ff6f5bb1124 Hevd: Back from kernel! kvm: The bp handler asked us to stop so no need to do the step-over dance -------------------------------------------------- Run stats: Dirty pages: 663552 bytes, 162 pages, 0 MB UffdPages: 684032 bytes, 167 pages, 0 MB VMExits: 4 Instructions executed: 6400 #1 cov: 0 exec/s: 0.0 lastcov: 0.0s crash: 0 timeout: 0 cr3: 0 uptime: 0.0s ```
v0.5.2
Load x87 state properly (#193) The way `@fptw` was handled has been wrong for a long time but I finally figured out. This updates all the backends to do the right thing. Other more minor changes: - The code that reads the CPU state has been updated to be compatible with [snapshot](https://github.com/0vercl0k/snapshot). It also should be now able to load precise values for 80-bit registers. Loading 'old' dumps should also work as they were before (with the buggy code) to not break them - Updated bxcpu to be able to load `@fpst` registers with a `frac` / `exponent` (cf yrp604/bochscpu@cab8051) - Minor updates to the README - Update the CI to get rid of warnings as well as removing the CodeQL scanning (it hasn't reported a single hit since it's been turned on -_-)
PreviousNext
You can’t perform that action at this time.