Need .SYM REPAIR or .SYM CLEANUP

[MichaelDamsgaard]

I seem to have messed up my symbols.
No amount of removing the Symbol directory followed by a .SYM DOWNLOAD command will fix the issue.

See screenshot ..

I could surely trace down my problem by reading your excellent source code, but the issue might be disruptive
to others too, I gathered. So, - bug reported ;-)

PS (off-topic): I would nominate you for the Turing award in a heartbeat, if it was within my power. INCREDIBLE work !

[SinaKarvandi]

Hi,
Thanks for reporting this issue
You're very kind with your words, and I truly appreciate your support! Thank you for your nomination in spirit. Now, let's address the technical issue you're facing:

I couldn't quite understand what you mean by cleaning the directory. Do you mean that we should add a command like ".sym cleanup" to remove (delete) all symbols in the symbol path?

[MichaelDamsgaard]

Hi,

I wouldent presume to know what to suggest, really.
The structures and their dependencies exists largely in YOUR mind.

To me it is a "boolean" observation that "something is bugged" now - that wasent bugged when the VM was virgin :-)

It seems evident that some kind of information is persisted, apart from the symbol-folder itself.
Your debugger became upset with me for removing the symbol-folder (I did do a .sym unload beforehand).

I tried to remedy my sin by doing a .sym download, - and it fetches like 100 symbol-files and store them neatly in a new symbol-folder it creates. Works great ! - Except that the debugger is still unhappy, and report the same 5 errors again and again across sessions.

I cant help but think, that your mind in a split second will iterate over the pertinent structures and code, and you will
have one of those small "ahhh!" experiences, and fix it with your left hand at some point .. I love those small "ahhh" moments myself :-)

Its NOT an issue to me, - if it bothered me, I would simply re-virgin the VM from storage. I was just SO impressed with your accomplishments that I had to "become involved" by some miniscule extent.

[off-topic]

If you allow, - I would like to shortly describe my interest in your project ..

I am an old school (6502/6510/80535/8088/8086/80x86/MC68K, ao) programmer driven mostly by thirst for knowledge.

As a self-teaching experience I decided to write my OWN profiler for my OWN code .. just because a real programmer should be able to do so. Period.

I wrote a fairly well-working X64 debugger, and I am able to instrument libraries with an insane amount of breakpoints where I obtain a tickcount, and I have been using Zydis, Capstone and BeaEngine to find API-exit points.

Its just not good enough, or fast enough .. sigh.

I want to try another approach.
I want these values to become part of the context in my user-mode debugger implementation :

LastBranchToRip, LastBranchFromRip, LastExceptionToRip, LastExceptionFromRip

So, I need access to MSR 0x1D9, "reaching" for IA32_DEBUGCTL_MSR_LBR and IA32_DEBUGCTL_MSR_BTF,
and your brilliant project allowed me to use your kernel-driver to do exactly that.

My user-mode debugger can obtain a handle to your \\.\HyperDbgDebuggerDevice and a call to
DeviceIoControl CTL_CODE(FILE_DEVICE_UNKNOWN, $804, METHOD_BUFFERED, FILE_ANY_ACCESS) returns True

Unfortunately I still do not get the values I am looking for.

I have surely missed to perform some important step. Looking into your "UdInitializeUserDebugger" method currently.
So far, it bugchecks when I try calling it. I am must be barking up the wrong tree, but I suppose I have to start somewhere.

I seem to remember reading somewhere at some point, that I should ask your kernel-driver to take my process as "passive" attachment, such that I can read the extended context, if that makes any sense to you .. false memory ?

I am (also) still trying to ingest the massive amounts of code you have published, and most of it is far far above my head. But I am a happy-go-lucky-student. I will be in your audience for a LONG time.

Thank you for HyperDbg.

PS: Please excuse any bad english in the above. English is not my native language.

[SinaKarvandi]

Hi again,
Thank you for your response.

It seems evident that some kind of information is persisted, apart from the symbol-folder itself.
Your debugger became upset with me for removing the symbol-folder (I did do a .sym unload beforehand).

Yep, I got it, I try to make it silent in case of invalid symbols.

So, I need access to MSR 0x1D9, "reaching" for IA32_DEBUGCTL_MSR_LBR and IA32_DEBUGCTL_MSR_BTF,
and your brilliant project allowed me to use your kernel-driver to do exactly that.

So, if I get it correctly, you gonna use Last Branch Record features of Intel processors in the debugger. Which will be really interesting.

I have surely missed to perform some important step. Looking into your "UdInitializeUserDebugger" method currently.
So far, it bugchecks when I try calling it. I am must be barking up the wrong tree, but I suppose I have to start somewhere.

You can directly import the DLL of HyperDbg, 'hprdbgctrl' into your user-mode debugger and it will perform all the necessary initialization for you.

I seem to remember reading somewhere at some point, that I should ask your kernel-driver to take my process as "passive" attachment, such that I can read the extended context, if that makes any sense to you .. false memory ?

Honestly, I didn't get what you mean. Can you re-explain it? What do you mean by 'passive'?

[MichaelDamsgaard]

So, if I get it correctly, you gonna use Last Branch Record features of Intel processors in the debugger. Which will be really interesting.

Yes, Exactly. I have the faint hope that one will be able to dicern expected API
return-home adresses, in a fast way - Its an experiment :-)

You can directly import the DLL of HyperDbg, 'hprdbgctrl' into your user-mode debugger and it will perform all the necessary initialization for you.

Us Delphi (Pascal) scriptkids hear that a lot, - and its true - we can.
However, - it involves much translating, wrapping/importing, coffey-drinking and a better than fair
chance of severe hairloss.

It would be a project much like the pascal-repository that Zydis affords its audience.
I wouldent dare attempt to do a correct translation with this level of stuff.

So, I would be happy setteling for a few "magic bullet" DeviceIoControl's for this small project:-)

Honestly, I didn't get what you mean. Can you re-explain it? What do you mean by 'passive'?

My bad, - I think I narrowed the question down a bit ..

Question becomes:
What are the requirements for my experimental usermode profiling debugger for it to
gain (and keep) access to the Last Branch Record features in its eventhandler context ?

Sorry if its a stupid question.

Did you see this .. Found it yesterday :

https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/manage/performance-monitoring-hardware

Hyper-V apparently offers the information, just by asking for it ..
But I would much rather integrate with your work.
Your debugger could do the same I gather (?)

I envision commands like:
.settings MSR_LBR on global
.settings MSR_LBR on PID
.settings MSR_LBR on PID, TID
.settings MSR_LBR off

Same with MSR_BTF

Am I way off ?

I am thinking "feature" label ;-)

PS: Just found this: https://rayanfam.com/topics/pinitor
That is spot on what I am trying to do in x64 .. 10 years later ;-D

Thanks for your time.

[SinaKarvandi]

Question becomes:
What are the requirements for my experimental usermode profiling debugger for it to
gain (and keep) access to the Last Branch Record features in its eventhandler context ?

You can import 'hprdbgctrl' into your project and then configure the MSR registers from user-mode.

As an example you can use this code:
For RDMSR:
https://github.com/HyperDbg/HyperDbg/blob/master/hyperdbg/hprdbgctrl/code/debugger/commands/debugging-commands/rdmsr.cpp
WRMSR:
https://github.com/HyperDbg/HyperDbg/blob/master/hyperdbg/hprdbgctrl/code/debugger/commands/debugging-commands/wrmsr.cpp

After that, you can intercept the interrupts (as long a I remember LBR sends an interrupt once its buffer is filled), and then safely send the buffer back to the user-mode by using the 'LogInfo' functions in HyperDbg.

But, generally, it's on the to-do list to add both Intel PT and LBR into the supporting modules for HyperDbg but I don't have an estimation when we can add these features to HyperDbg.

[MichaelDamsgaard]

Thank you.

Especially the WRMSR example you link to is very relevant, as it does exactly what I want to do, and does it exactly like the way I am trying to do it.

Get a handle to the kernel module: SUCCESS
Send DeviceIOControl command: SUCCESS

But, no joy so far.

I am supposed to set the register for every debug event right before calling ContinueDebugEvent() I gather ?

[SinaKarvandi]

I am supposed to set the register for every debug event right before calling ContinueDebugEvent() I gather ?
No, you don't have to register anything.

If you don't want to deal with the user-mode internals of the debugger, you can just call HyperDbgInterpreter(char * Command) with the commands. It will interpret and set everything for you.

Please also check the 'hyperdbg-cli' project and see how we used this function.