Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • D dynamorio
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 1,467
    • Issues 1,467
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 44
    • Merge requests 44
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Package Registry
    • Infrastructure Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • DynamoRIO
  • dynamorio
  • Issues
  • #1538
Closed
Open
Issue created Nov 28, 2014 by Derek Bruening@derekbrueningContributor

dr_query_memory_ex() should not fail on kernel memory

From m...@google.com on September 10, 2014 05:27:53

My config: Win 8.1 x64, using DynamoRIO for 32-bit processes DynamoRIO version: 4.2.2725

When I call dr_query_memory_ex() with 0x7fff0000 (== MmUserProbeAddress) as an argument it fails (returns false). There's no info in documentation about the function behavior if we pass kernel memory address as an argument. There's no way to retrieve MmUserProbeAddress from user mode, so now the only way to enumerate process memory is to ignore memory regions where dr_query_memory_ex() fails, but that looks like an ugly hack (I can miss other issues by silencing the error). The proposition from Derek was to return DR_MEMTYPE_KERNEL for kernel memory regions, which should solve the problem.

Original issue: http://code.google.com/p/dynamorio/issues/detail?id=1538

Assignee
Assign to
Time tracking