|
I'm trying to code a driver that will read from either virtual or physical memory given an address and report the contents.
Obviously I would vrather read from virtual memory, but at this point I still have a lot to learn about the mysterious kernel lol...
This is where im looking: im going to try and copy the contents of an address into a buffer. The goal is one byte
using:
VOID
RtlCopyMemory(
IN VOID UNALIGNED *Destination,
IN CONST VOID UNALIGNED *Source,
IN SIZE_T Length
);
My first problem is how I am going to pass these parameters to my driver from my GUI.
Secondly, I could benifit from some insight on how this will work.
I am thinking that when my driver calls RtlCopyMemory() its going to get a pointer to a byte to copy, but I was planning on passing a virtual address. In that case i have the feeling I should also be passing a process handle, which is obviously not the case. So then is RtlCopyMemory intended to copy from physical memory into a buffer?
Other questions (lol):
What IRQL should I be operating at?
How can I convert a system::string^ into a LPCVOID, (system::string^ is from taking the text from a windows forms textbox)
I'm totally willing to write my own algorithm, I just dont know anything about the fundamental structure of system::string^. I dont even know what that ^ is lol...
|
|
|
|
|
You can pass in a buffer from user mode to kernel mode by defining custom IO control codes with different transfer types.
Read about it here - Defining Custom I/O Control Codes[^]
|
|
|
|
|
Hello,
Could anyone tell me how to access the CPU register in C?
Thanks
|
|
|
|
|
In Windows and x86, you can use the __asm keyword to write inline assembly and then access the registers by its name (eax, ebx etc.).
__asm is not supported in x64.
|
|
|
|
|
Thanks, Superman. And I wonder whether the keyword "register" is possible to be used to specify a register in the processor?
|
|
|
|
|
No. The register keyword is used as a hint to the compiler to store the variable into a general purpose register instead of a memory location.
|
|
|
|
|
There's no guarantee that the variable will be put into a register at all, so leave alone a "specific" register.
“Follow your bliss.” – Joseph Campbell
|
|
|
|
|
Hi guys!!
I have to change the colors of all windows in my MFC program for simulate a "nigth color/vision" effects, there's a fast way to do it?
For example change some register keys and restart the program.
Marco
|
|
|
|
|
Colours in windows are either set in the class (default background) or painted in the OnPaint() event, so your code needs to handle it. I don't think there is anything in the Registry that could help.
|
|
|
|
|
|
|
Hi,
I made one combobox which i canwrite some text, in C# and i build that as DLL.
And i call this to VC++.
My problem, when it is in C#,i can write text in combobox.
But in VC++,i cannot write.
When i press alphapets in keyboard nothing is displayed in combobox. only beep sound is coming.
Whats the mistake?
Anu
|
|
|
|
|
Anu_Bala wrote: Whats the mistake?
Given the information you have provided it could be anything at all. Perhaps there is something wrong in your code.
|
|
|
|
|
this i coded in C#
private void Callbutton_Click(object sender, RoutedEventArgs e)
{
String msg = comboBox1.Text;
comboBox1.Items.Add(msg);
CallClick(msg);
}
And im using this in VC++ and im using that 'msg' in vc++ code.
Anu
|
|
|
|
|
I am still none the wiser as to what you are doing. The above code is for a private C# event handler, called when some button is pressed. How does this relate to C++ and what exactly do you mean by the statement:
Anu_Bala wrote: And im using this in VC++ and im using that 'msg' in vc++ code.
|
|
|
|
|
Yes i created on C# dll with this coding and im using that in VC++.
public partial class SecondTab : UserControl
{
public delegate void NameTab(string msg);
public static event NameTab CallClick;
public SecondTab()
{
InitializeComponent();
}
private void Callbutton_Click(object sender, RoutedEventArgs e)
{
String msg = comboBox1.Text;
comboBox1.Items.Add(msg);
CallClick(msg);
}
}
This is my C# coding.
Im using in VC++ as follow
Tabcontrol::SecondTab::CallClick += gcnew Tabcontrol::SecondTab::NameTab(OnCallClick);
static void OnCallClick(System::String ^ msg)
{
CString m = msg;
}
I think now you understand my objective..
Anu
|
|
|
|
|
Anu_Bala wrote: I think now you understand my objective.
I understand that in the C++ function OnCallClick() you create a CString copy of the message from the ComboBox . Beyond that I have no idea what you are trying to achieve or what your problem is.
Your original post stated that you could not enter values into the ComboBox.
|
|
|
|
|
Yes,
I cannot enter any values in that combo box.
Just i tested this WPF C# dll with one WPF applcaiton.
In that its perfectly working and i can enter values.
But here i canot.I thought the combox is not working,so i add simple text box and test it with VC++.Again i cannot enter any value in textbox.
If i copy some text and paste there.Its get pasted.And CString perfectly return that value.
Anu
|
|
|
|
|
Sorry, but I have no idea why or how you cannot enter data from the keyboard and yet you can enter via copy and paste. As this is Managed C++ rather than ordinary I cannot offer any further suggestions, other than using the debugger and trying to figure out what is happening in the library at the time the Combo has the focus.
|
|
|
|
|
Anu_Bala wrote: I made one combobox which i canwrite some text, in C#
Anu_Bala wrote: Whats the mistake?
Yes, that's it.
You measure democracy by the freedom it gives its dissidents, not the freedom it gives its assimilated conformists.
|
|
|
|
|
Is there a way to declare a dynamic array in such a way so that it can't be deleted ?
What I'm actually trying to do is control access rights to an array returned by a function. I've basically managed to do what I meant but permission is still granted to deallocate memory for it, not that I/someone would do that because allocating memory for it is not allowed but it just seems improper for that access right to be granted when only the class it is a member of should be allowed to delete it.
The following code :
const int* const pMem = new int[5];
delete [] pMem;
is legal. Where as :
pMem = new int[5];
is not legal after declaration of pMem.
I don't imagine somebody would try to delete a const array but still, they can, so how can deletion be prevented ?
many thanks.
modified on Friday, January 1, 2010 7:10 PM
|
|
|
|
|
Instead of returning a pointer to a fundamental data type like int you could return a pointer to a custom class, let's say Integer , which has the delete and delete[] operators overloaded.
This way when the user tries to delete the returned pointer, your class method will be called in which you can decide to either delete memory or throw an exception or assert it or simply ignore it.
|
|
|
|
|
that's a good idea.
but unfortunately, I don't think it would be suitable for the case I have.
I've implemented a container class so the array at hand is an array of user defined types.
It would be ok if I could make a template subclass of user class, which was an exact copy and where the delete / operator delete was definately not overloaded by the user's class but so the container is more all round, I'll leave it how it is.
I think there's probably no reason for someone to delete the array when they can see it's declared const. So maybe the best solution is to just add a comment so a user knows not to delete it directly. Or an example of how to use the container.
Now, I have a better idea of what's possible and what's not.
thanks
|
|
|
|
|
doug25 wrote: Is there a way to declare a dynamic array in such a way so that it can't be deleted ?
Sounds like a common API problem, I could imagine three solution. Maybe use a data buffer class that can handle memory allocation/deallocation of its elements, something like std::vector with restrictions. Alternatively use a smart pointer template with shared ownership, something like boost::shared_ptr where the instance will be automatically destroyed when the last copy of the shared pointer is destroyed or gets out of scope. Alternatively, even if you didn't ask for it, let the caller provide a memory buffer and be responsible for the memory allocation/deallocation.
Hope it helps,
M
|
|
|
|
|
Hi,
thanks for the suggestions.
I've actually decided not to change what i've done so i'm not seeking further help but I'll try to explain the situation better so you understand the conclusion I've come to since it's a bit more complicated than it may seem.
I'm sure the implementation of the container is ok and user friendly. The only issue is that memory for a member array shouldn't be deallocated by a user despite them having the permission. Although this shouldn't be a problem because someone probably wouldn't assume they should deallocate memory via a const pointer that's a member of a container class (correct me if i'm wrong) and anyone who's used a map or vector container should know it's not up to them to manage the memory for a map or vector's member variables. The container I've implemented is a specialised map and like a map it manages it's own memory. Since the array is declared protected I'm sure users would have the sense to check whether it's safe to manually deallocate the memory it uses and the function to retrieve the array has a const specifier in it's declaration which means memory can't be allocated for it, which should indicate to users that they shouldn't delete the array themselves I'm assuming.
What would totally solve the issue is if the C++ language (or compilers) made it so a dynamic array declared const couldn't be deleted. I don't see why it's possible to deallocate memory pointed to by a const dynamic array variable using delete while it's not possible to allocate memory for it using new. Ah because the address of a const pointer can't change but memory for a given address can be deallocated.
Basically the container I've made is a map that stores elements in a contigious array where it's possible to specify the order that they are stored in. I say array but it's actually a block of memory allocated with operator new and never new [] or new. The memory is always freed with operator delete. The reason for managing memory allocation for the "array" this way is so the calling of elements constructors / destructors is more controlled i.e. constructor is not called when inserting element, it's only called when inserting a new element and destructors are not called when the array is resized which makes it a very useful kind of container.
A vector wouldn't work because being able to retrieve a dynamic array manipulated by the container is a key reason why this container would be useful compared to standard ones. When I want to store elements mapped to keys and pass a customly ordered array of the elements to some other function that requires an array of maybe void* this container will be extremely useful. I don't want to go into too much detail but that's why I've implemented the container to use an array and not vector. A vector will call destructors of elements when it is resized and that's quite undesirable in certain cases.
If I understand correctly boost::shared_ptr wouldn't work because to access the array the way I need / intend would require dereferencing the pointer to it which would mean the variable retrieved would be in the same condition as what is returned by the Array() function at the moment. But I'm not sure what you meant by using a shared_ptr ?
Using a buffer passed by the user wouldn't be a practical solution because of the way memory is managed using operator new and operator delete by the container. For the container to work properly, it would basically require that the user never allocates memory for the buffer because the container also associates indices with keys so things would get a bit complicated. The user would have to only ever call operator delete on the buffer and let the container do the rest.
So my conclusion is that bearing with the mild (I think) issue that the array returned by Array() can be deleted is probably the most simple solution. The user only needs to know not to delete it, and i'm sure most users would assume that.
|
|
|
|