I am analyzing an executable based on its execution trace. I have obtained the execution trace using NtTrace tool. The output is a sequence of native api calls with arguments. I have managed to interpret most of the API calls except the following ones:
NtQueryKey( KeyHandle=0x46a, KeyInformationClass=7 [KeyHandleTagsInformation], KeyInformation=0x312c4e0, Length=4, ResultLength=0x312c4dc [4] ) => 0
NtDeviceIoControlFile( FileHandle=0xbe4, Event=0xce8, ApcRoutine=null, ApcContext=null, IoStatusBlock=0x124cf2b0 [0/0xffc], IoControlCode=0x00012017, InputBuffer=0x124cf298, InputBufferLength=0x10, OutputBuffer=null, OutputBufferLength=0 ) => 0
In NtQueryKey, how can I map the KeyHandle=0x46a to an actual registry key. Further, in NtDeviceIoControlFile based on IoControlCode=0x00012017 is it possible to find whether it is a TCP_RECV, TCP_SEND, etc...
Thank you.
Process Monitor from Sysinternals (now part of Microsoft) will show you the actual key path when displaying registry activity. It also can monitor network activity.
Sysinternals Tools
Just look back in the trace to find the point at which that key handled was opened. You may have to repeat this process recursively if the key was opened relative to another key. In the future, I recommend using procmon from sysinternals. The output is much better.
Related
The deatil tab associated with the operation says:
KeySetInformationClass: KeySetHandleTagsInformation, Length: 0
I'm using Process Monitor (ProcMon) to monitor the Registry changes an installer makes and I cannot find an explanation for what this operation does.
Maybe is the same question that was asked here in Reddit (https://www.reddit.com/r/learnprogramming/comments/2c0w1f/registrywhat_does_regsetinfokey_do/).
I bumped with the same issue than you did and came out with that response. Based on the documentation (https://msdn.microsoft.com/en-us/library/ff553399(v=vs.85).aspx) and the actual behaviour I see in the binary it looks like it checking a registry key value.
I have a VB6 application that I'm trying to make log out differently. What I have is a flag in the registry (existing) which states if the application is set to Debug mode so that it would log out.
Within my code I then have lots of if statements checking if this is true. This means that there is a lot of processing time checking if a statement is true, which maybe not much really but as it does it so often it's an overhead I would like to reduce.
The code is full of statements like this
If isDebug = True Then
LogMessage("Log what is happening")
End If
So what I'm looking for is a better way to do this. I know I can set a debug mode within Project Properties -> Make, but this needs to be set prior to building the .exe and I want to be able to set this in production via the registry key.
Consider using a command line argument to set debug mode. I used to do this.
Dim sCommandLine() As String
sCommandLine = Split(Command$)
For I = 0 To UBound(sCommandLine)
' do something with each arg
Next I
You can also persist command line args inside the IDE, so you always have them when debugging. When running outside of the IDE, make a shortcut to the compiled application with the arguments in it.
I do something almost identical to what you have in mind in a lot of my code. Add this:
Sub LogDebug(ByVal strMsg As String)
If (isDebug) Then
LogMessage(strMsg)
End If
End Sub
Then just call LogDebug in your main program body, or call LogMessage directly if it's something you always want to log, regardless of the debug flag.
I'm assuming isDebug is a boolean here. If it's a function call, you should just create a global flag that you set at the beginning of the code, and check that instead of looking at the registry over and over. I don't think checking a boolean is that much of a processing load, is it?
You want to call a function if a runtime flag is set. The only thing I can see that could be faster is:
If isDebug Then
LogMessage("Log what is happening")
End If
But I doubt that either would be the cause of performance problems. Most logging frameworks promote code like that and even put the flag/log level as a parameter to the function. Just be sure that you don't have other places where you needlessly compute a log message outside of the conditional statement.
You might evaluate why you need logging and if the logs produced are effective for that purpose.
If you are looking for a problem that can be trapped using VB error handling, consider a good error handling library like HuntERR31. With it you can choose to log only errors instead of the debug message you are now doing. Even if you don't use the library, the docs have a very good description of error handling in VB.
Another answer still:
Read your registry flag into your app so that it's a session based thing (i.e. when you close and restart the app the flag will be checked again - there's no point in checking the registry with every single test).
Then (as per Tom's post) assign the value to a global variable and test that - far faster than a function.
To speed up logging you may want to consider dimensioning a string buffer in your app and, once it has reached a specific size, fire it into your log file. Obviously there are certain problems with this approach, namely the volatility of the memory, but if you want performance over disk access I would recommend such an approach.
This would, of course, be a lot easier if you could show us some code for your logging process etc.
I want to calculate the bytes sent and recieved by a particular process .I want to use powershell for that.
Something which I can do using Resource Monitor->Network Activity.
How can i do that using get-counter?
There is a really good Scripting Guy article on using the Get-Counter cmdlet here:
Scripting Guy - Get-Counter
The trick will be finding the counter that you need, and I don't think you can get the granularity you're after as these are the same counters that PerfMon uses. It's more focused around the whole Network Interface than it is around the individual processes using the interface. With that said, if it's the only thing using the given interface it should do the trick nicely.
Have a look at the Network Interface options available for a start:
(get-counter -list "Network Interface").paths
You can't, it seems. I'm absolutely unable to find the counters the performance monitor is reading from, though other people may chime in. There may be some other way than get-counter too, but that is what you specifically requested.
Looking through the counters, the closest thing you will find is the "IO Read Bytes/sec" and "IO Write Bytes/sec" counters on the process object.
The problem with those is that they count more than just network activity. The description in perfmon says:
"This counter counts all I/O activity generated by the process to
include file, network and device I/Os."
That being said, if you know that the process you want to monitor only or mainly writes to the network connection, this may be better than not measuring anything at all.
You'd go about it like this (I'll use Chrome as an example since it is conveniently running and using data right now):
get-counter "\Process(chrome*)\IO Read Bytes/sec"
This will just give you a one-time reading. If you want to keep reading you can add the continous switch.
The PerformanceCounterSampleSet object that is returned is not exactly pretty to work with, but you can find the actual reading in $obj.countersamples.cookedvalue.
The list will be fairly long (if you browse like me). Chrome is running in many separate processes, so we'll do a bit of math to get them all added up, and presented in KB.
Final result:
get-counter "\Process(chrome*)\IO Read Bytes/sec" -Continuous | foreach {
[math]::round((($_.countersamples.cookedvalue | measure -sum).sum / 1KB), 2)
}
Running this will just continously output a reading of how many KB/s Chrome is using.
I am playing around with the demo of IDA and I am trying to do some reverse engineering of a program to figure out the structure of one of its files that it uses. My final goal is to be able to read that file directly from my own program.
Using Process Monitor I was able to find the subroutine that calls kernel32_ReadFile. What I would like to know is how do I find out what the hFile variable is pointing to before it makes the call to ReadFile
I have been exploring around the menus while in debug mode and I have not found anywhere inside IDA where I can look up information about what file is associated with a file handle.
How do I map a handle to a real file?
This MSDN page describes ways to get the file name from a file handle:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa366789(v=vs.85).aspx
Is that the information you were looking for? I'm not sure why you can't see the the file name directly in Process Monitor.
I would set a breakpoint on CreateFileA and CreateFileW and see what files are being opened. You can then match the returned HANDLE value to the subsequent ReadFile call.
On win32, using winapi, is there anyway to know which comports (from com0 upwards) actually exist as devices?
At the moment I am just attemping to open them all (0 to 9), but I can't figure out the difference of failure between one not existing, and one not simply being available for use because someone else is using it. Both situations seem to return the same last error, so I was wondering if I could list all the comports available on the system.
I believe you can call QueryDosDevice() and pass null for the first parameter and then parse the results.
Search google for "enumerate com ports". This is an example link.
The name is unfortunate, but "SetupAPI" is the relevant part of the Windows API. Call SetupDiCreateDeviceInfoList once for device interface class GUID_DEVINTERFACE_COMPORT. Then call SetupDiEnumDeviceInfo repeatedly, starting at index 0 until GetLastError()==ERROR_NO_MORE_ITEMS.