ReadProcessMemory(hProc,(LPCVOID)(7845CDDC),&PHP,4,NULL);
When I enter that i get this error in Dev-C++ Win32 :
C:\Dev-Cpp\main.cpp invalid suffix "CDDC" on integer constant
any idea why?
You probably want a hex constant, that is to say 0x7845CDDC.
ReadProcessMemory(hProc,(LPCVOID)(0x7845CDDC),&PHP,4,NULL);
ReadProcessMemory should have the lpBaseAddress parameter as a pointer to the base address in the specified process from which to read.
The problem with "7845CDDC" is that it is a Hex value (should be 0x7845CDDC), but you can enter the value as an Decimal as well (will be 2017840604).
So you can call:
ReadProcessMemory(hProc,(LPCVOID)(2017840604),&PHP,4,NULL);
Related
I want to print real physical address that is stored in a variable of type phys_addr_t. Now I'm doing something like this:
phys_addr_t paddr;
...
paddr = virt_to_phys(some_virt_addr);
pr_info("%pa", &paddr);
...
As for documentation:
Physical addresses types ``phys_addr_t``
========================================
::
%pa[p] 0x01234567 or 0x0123456789abcdef
For printing a ``phys_addr_t`` type (and its derivatives, such as
``resource_size_t``) which can vary based on build options, regardless of
the width of the CPU data path. Passed by reference.
but I'm a bit confused about Passed by reference, because it is already something like reference. So my actual questions are:
How to correctly print phys_addr_t using printk?
What does Passed by reference mean here?
What does the [p] postfix of %pa[p] mean?
If my example is not correct or inefficient, please show me how it should be.
You are doing it correctly:
phys_addr_t paddr = 0x1234;
printk(KERN_INFO "%pa\n", &paddr);
// Result: 0x0000000000001234
"Pass by reference" means to pass a pointer to the physical address you want to print (&paddr) instead of directly passing its value (paddr).
The [p] suffix in the documentation means that the last p is optional. You can use %pa or %pap. The final p is not necessary and also doesn't change the output format (as you can see from the source here).
Setup: I am debugging a simple C++ program compiled with option -fno-omit-frame-pointer, using libwarf for DWARF 5. Main work is to write a debugger using libdwarf.
For a particular local variable, dwarfdump shows:
DW_AT_location len 0x0002: 915c: DW_OP_fbreg -36
In the following I will refer to '-36' as 'op1', which I get from libdwarf.
Problem: Using op1 directly results in incorrect value for the variable.
(fbPointer is current value of frame base pointer).
int32_t data = (int32_t) ptrace(PTRACE_PEEKDATA, processPid, fbPointer + op1, 0);
I also tried decoding -36 as sleb128 and usleb128, and for both I got 220. Not a good value.
Trial/error shows that if I add 16 to op1, it will work for any number of int variables as parameters and local objects. However, it does not work for float/double.
Question: Is -36, as mentioned everywhere, offset of variable from frame-base pointer? If so, what am I doing wrong?
What are the preceding values in DW_AT_location: "len 0x0002: 915c:"? If they are important in evaluating op1, how do I get them via libdwart?
Thank you very much. It has been more than a week I am stuck at this point.
It seems that DW_OP_fbreg is a reference to DWARF register which in this case is 16 bytes off. That is, we need to add 16 to RBP, the real register, then add -36 to that. Finally, somehow in this case -36 is a plain number as opposed to encoded sleb128.
I am trying to animate an actor in Clutter, but when I enter a property that exists, something goes wrong.
actor.animate( AnimationMode.LINEAR, 400, scale_x:2);
gives me this error
Clutter-WARNING **: Cannot bind property '\x83\xec\u0014\x89\xc6e\xa1\u000c': objects of type 'ClutterTexture' do not have this property
Looks like Unicode-characters to me.
However, when I enter a property that does NOT exist
actor.animate( AnimationMode.LINEAR, 400, thisdoesntwork:2);
I get an error that makes much more sense
Clutter-WARNING **: Cannot bind property 'thisdoesntwork': objects of type 'ClutterTexture' do not have this property
I get the exact same problem when I try this alternative approach:
actor.animate( AnimationMode.LINEAR, 400, "scale-x", 2);
How come all properties that actually exist get converted to some mess, and what can I do to get this to work?
You should be using 2.0 for the value, not 2. 2 is an integer, 2.0 is a double. Vala can't provide type safety for variadic methods, so you have to be careful.
As for why you're seeing the behavior you are for properties which exist, my guess is it has to do with the fact that 2 is a (32-bit) integer and 2.0 is a (64-bit) double. This is simplifying things a bit, and I don't know how much experience you have with C (probably not a lot, since this is the sort of mistake someone coming from a dynamically typed language would make), however... Clutter (well, va_arg) expects a double so it parses 64 bits of data, but you only provided 32 bits, so the first 32-bits of the next argument (NULL) are included. Now, when it starts trying to parse the next argument it starts from the wrong location (32-bits into the argument), so you get the the remainder of NULL and part of whatever garbage happened to be on the stack... Unsuprisingly, that doesn't just so happen to be 32-bits of 0s so when Clutter tests to see if the value it just read == NULL it isn't and Clutter thinks it's been given a pointer to an null-terminated array of characters (which is how strings are represented in C). It reads the data at that location, which just so happens to be \x83\xec\u0014\x89\xc6e\xa1\u000c, and checks to see if there is a property with that name. There isn't, so it emits the error message you saw.
Now, if you switch to using a property which doesn't exist, Clutter will parse the argument (the name of the property), notice that it doesn't exist (just like it did with the second property above), and emit an error.
Excel AddIn using Excel DNA, VS2008, C#,
MyUDF(param1, parm2)
when I type in "=MyUDF" and hit enter, Excel displays a huge number like 970063926
and my c# code for MyUDF is not run
Anyone know what is this huge number?
thanks
This is just a bit of weird behaviour of Excel. The number being returned is an internal identifier for the UDF function, and by entering the function name without any brackets, you're causing it to be treated like a named range not a function. If you want to call the function with no arguments, use:
=MyUDF()
...if you type =MyUDF then you're asking Excel to dereference the function name, in the same way that it would dereference =A1 to the value in cell A1 or =MyNamedRange to whatever that named range referred to.
I don't think there's any practical use for the behaviour you've observed, but it certainly isn't going anywhere near your code to get this value that is being returned, so don't worry you haven't done anything wrong!
Is there any way to avoid this behavior?
If no parameter is specified, I would like the =MyUDF to return error instead a number.
I'm trying to hide some values in the registry (such as serial numbers) with C++/windows
so I've been looking at this article http://www.codeproject.com/KB/system/NtRegistry.aspx
which says:
How is this possible? The answer is
that a name which is a counted as a
Unicode string can explicitly include
NULL characters (0) as part of the
name. For example, "Key\0". To include
the NULL at the end, the length of the
Unicode string is specified as 4.
There is absolutely no way to specify
this name using the Win32 API since if
"Key\0" is passed as a name, the API
will determine that the name is "Key"
(3 characters in length) because the
"\0" indicates the end of the name.
When a key (or any other object with a
name such as a named Event, Semaphore,
or Mutex) is created with such a name,
any application using the Win32 API
will be unable to open the name, even
though they might seem to see it.
so I tried doing something similar:
HKEY keyHandle;
PHKEY key;
unsigned long status = 0;
wchar_t *wKeyName = new wchar_t[m_keyLength];
MultiByteToWideChar(CP_ACP, 0, m_keyName, m_keyLength, wKeyName, m_keyLength);
wKeyName[18] = '\0';
long result = RegCreateKeyExW(HKEY_LOCAL_MACHINE,
wKeyName,
0,
NULL,
0,
KEY_ALL_ACCESS,
NULL,
&keyHandle,
&status);
where m_keyName is the ASCII text and wKeyName is the wide char text, but in regedit I see that it is treated the same and the key is just cut where I put the '\0'.
what is wrong with it?
The problem is that you are using the Win32 API and not the NT Native API. There is a table about 1/2 way through the article that you referenced that contains the list of Native APIs. For example, you would use NtCreateKey or ZwCreateKey instead of RegCreateKeyExW. The Win32 API assumes that alls strings are terminated by a NUL character whereas the Native API counterparts use a UNICODE_STRING structure for the name.
I'll take a stab in the dark, as I have never tried to do this.
It appears that you are using the wrong function to create your registry key. You should be using the NtCreateKey method because RegCreateKeyEx[AW] will notice your '\0' and chop off past it.
Why not use the class provided in the example? It provides a method called CreateHiddenKey. To use it, simply call SetKey before it. It would be much cleaner.