I am looking for a way to bypass a limit that is implemented the same way as the following
kexec_load_disabled:
{
.procname = "kexec_load_disabled",
.data = &kexec_load_disabled,
.maxlen = sizeof(int),
.mode = 0644,
/* only handle a transition from default "0" to "1" */
.proc_handler = proc_dointvec_minmax,
.extra1 = &one,
.extra2 = &one,
},
I have root access and I can load kernel modules aswell. I can use /proc/kallsymsto find the address of proc_dointvec_minmax, so I suppose I can somehow manage to write a kernel module that when loaded is able to overwrite the function so it allows going back to 0 again, then set the value to 0 and restore the original instructions? I assume I need to reconfigure the MMU first to allow writes to the kernel instructions? Or can I somehow add a breakpoint in proc_dointvec_minmax so that when it's hit I grab the arguments and modify those? Once I have a starting point I should be able to continue on my own, but right now I am not sure about what approach to choose/what the easiest way to solve it would be.
Related
I have some models (geometries) which have some vertexinformation. For example position, normal, color, texcoord each of this information has its own vertexbuffer. But some of these models have texture coordinates some not...
To manage these differences I wrote a vertexshader which is checking, if the flag inside the constantbuffer "hasTextureCoordinates" is == 1. And if so it uses the texcoord parameter or not.
But Directx does not realy like this workaround and prints out:
D3D11 INFO: ID3D11DeviceContext::Draw: Element [3] in the current Input Layout's declaration references input slot 3, but there is no Buffer bound to this slot. This is OK, as reads from an empty slot are defined to return 0. It is also possible the developer knows the data will not be used anyway. This is only a problem if the developer actually intended to bind an input Buffer here. [ EXECUTION INFO #348: DEVICE_DRAW_VERTEX_BUFFER_NOT_SET]
I'm not sure if every hardware handles this correctly, also it's not nice to see inside the output this "warnings" every frame...
I know i could write two shaders, one with and one without texcoods, but the problem is that this is not the only maybe missing parameter... some has color other not, some has color and texturecoordinates and so on. And to write a shader for each combination of vertexbuffer inputs is extremly redundant. this is extremly bad, because if we change one shader, we have to change all other too. There is also the possibility of put parts of the shader to different files and include them, but it's confusing.
Is there a way to say directx that the specific vertexbuffer is optional?
Or does someone knows a better solution for this problem?
You can suppress this specific message programmatically. As it's an INFO rather than an ERROR or CORRUPTION message, it's safe to ignore.
#include <wrl/client.h>
using Microsoft::WRL::ComPtr;
ComPtr<ID3D11Debug> d3dDebug;
if ( SUCCEEDED( device.As(&d3dDebug) ) )
{
ComPtr<ID3D11InfoQueue> d3dInfoQueue;
if ( SUCCEEDED( d3dDebug.As(&d3dInfoQueue) ) )
{
#ifdef _DEBUG
d3dInfoQueue->SetBreakOnSeverity( D3D11_MESSAGE_SEVERITY_CORRUPTION, true );
d3dInfoQueue->SetBreakOnSeverity( D3D11_MESSAGE_SEVERITY_ERROR, true );
#endif
D3D11_MESSAGE_ID hide[] =
{
D3D11_MESSAGE_ID_SETPRIVATEDATA_CHANGINGPARAMS,
D3D11_MESSAGE_ID_DEVICE_DRAW_VERTEX_BUFFER_NOT_SET, // <--- Your message here!
// Add more message IDs here as needed
};
D3D11_INFO_QUEUE_FILTER filter = {};
filter.DenyList.NumIDs = _countof(hide);
filter.DenyList.pIDList = hide;
d3dInfoQueue->AddStorageFilterEntries( &filter );
}
}
In addition to suppressing 'noise' messages, in debug builds this also causes the debug layer to generate a break-point if you do hit a ERROR or CORRUPTION message as those really need to be fixed.
See Direct3D SDK Debug Layer Tricks
Note I'm using ComPtr here to simplify the QueryInterface chain, and I assume you are keeping your device as a ComPtr<ID3D11Device> device as I do in in Anatomy of Direct3D 11 Create Device
I also assume you are using VS 2013 or later so that D3D11_INFO_QUEUE_FILTER filter = {}; is sufficient to zero-fill the structure.
My application has a number of modules that each require some variables to be stored in off-chip non-volatile memory. To make the reading and writing of these easier, I'm trying to collect them together into a contiguous region of RAM, to that the NVM driver can address a single block of memory when communicating with the NVM device.
To achieve this, I have created a custom linker script containing the following section definition.
.nvm_fram :
{
/* Include the "nvm_header" input section first. */
*(.nvm_header)
/* Include all other input sections prefixed with "nvm_" from all modules. */
*(.nvm_*)
/* Allocate a 16 bit variable at the end of the section to hold the CRC. */
. = ALIGN(2);
_gld_NvmFramCrc = .;
LONG(0);
} > data
_GLD_NVM_FRAM_SIZE = SIZEOF(.nvm_fram);
The data region is defined in the MEMORY section using the standard definition provided by Microchip for the target device.
data (a!xr) : ORIGIN = 0x1000, LENGTH = 0xD000
One example of a C source file which attempts to place its variables in this section is the NVM driver itself. The driver saves a short header structure at teh beginning of the NVM section so that it can verify the content of the NVM device before loading it into RAM. No linker error reported for this variable.
// Locate the NVM configuration in the non-volatile RAM section.
nvm_header_t _nvmHeader __attribute__((section(".nvm_header")));
Another module that has variables to store in the .nvm_fram section is the communications (CANopen) stack. This saves the Module ID and bitrate in NVM.
// Locate LSS Slave configuration in the non-volatile RAM section.
LSS_slave_config_t _slaveConfig __attribute__((section(".nvm_canopen"))) =
{ .BitRate = DEFAULT_BITRATE, .ModuleId = DEFAULT_MODULEID };
Everything compiles nicely, but when the linker runs, the following error stops the build.
elf-ld.exe: Link Error: attributes for input section '.nvm_canopen' conflict with
output section '.nvm_fram'
It's important that the variables can be initialised with values by the crt startup, as shown by the _slaveConfig declaration above, in case the NVM driver cannot load them from the NVM device (it's blank, or the software version has changed, etc.). Is this what's causing the attributes mismatch?
There are several questions here and on the Microchip forums, which relate to accessing symbols that are defined in the linker script from C. Most of these concern values in the program Flash memory and how to access them from C; I know how to do this. There is a similar question, but this doesn't appear to address the attributes issue, and is a little confusing due to being specific to a linker for a different target processor.
I've read the Microchip linker manual and various GCC linker documents online, but can't find the relevant sections because I don't really understand what the error means and how it relates to my code. What are the 'input and output section attributes', where are they specified in my code, and how do I get them to match eachother?
The problem is due to the _nvmHeader variable not having an initial value assigned to it in the C source, but the _slaveConfig variable does.
This results in the linker deducing that the .nvm_fram output section is uninitialised (nbss) from the .nvm_header input section attributes. So, when it enconters initialised data in the .nvm_canopen input section from the _slaveConfig variable, there is a mismatch in the input section attributes: .nvm_fram is for uninitialised data, but .nvm_canopen contains initialised data.
The solution is to ensure that all variables that are to be placed in the .nvm_fram output section are given initial values in the C source.
// Type used to hold metadata for the content of the NVM.
typedef struct
{
void* NvmBase; // The original RAM address.
uint16_t NvmSize; // The original NVM section size.
} nvm_header_t;
// The linker supplies the gld_NVM_FRAM_SIZE symbol as a 'number'.
// This is represented as the address of an array of unspecified
// length, so that it cannot be implicitly dereferenced, and cast
// to the correct type when used.
extern char GLD_NVM_FRAM_SIZE[];
// The following defines are used to convert linker symbols into values that
// can be used to initialise the _nvmHeader structure below.
#define NVM_FRAM_BASE ((void*)&_nvmHeader)
#define NVM_FRAM_SIZE ((uint16_t)GLD_NVM_FRAM_SIZE)
// Locate the NVM configuration in the non-volatile RAM section.
nvm_header_t _nvmHeader __attribute__((section(".nvm_header"))) =
{
.NvmBase = NVM_FRAM_BASE, .NvmSize = NVM_FRAM_SIZE
};
The answer is therefore that the output section attributes may be determined partly by the memory region in which the section is to be located and also by the attributes of the first input section assigned to it. Initialised and uninitialised C variables have different input section attributes, and therefore cannot be located within the same output section.
In IDA Pro 6.1, I have a dll which has twenty calls to the "CreateFileA" and "CreateFileW" function APIs.
I would like to specify breakpoints for all the CreateFileA/CreateFileW automatically.
I could do it manually for all the xrefs, but that is tedious.
Is there a way to specify a breakpoint directly for the CreateFileA/CreateFileW call?
Thanks a lot :)
You could set a break point at the first instruction of both CreateFile, or you could whip something up with IDAPython to create the breakpoints.
Iterate over all the instructions/calls and look for calls to the appropriate function.
add_bpt() I believe is the call,
Here's a script I wrote up to accomplish what you want. It sets soft-breakpoints at the locations that call your specified functions.
// Script used to set a breakpoint at the callsite
// of the specified function using cross-references.
#include <idc.idc>
static SetBreakpoint(location)
{
// Sets a breakpoint to be activated when
// the debugger runs over the address.
AddBptEx(location, 0, BPT_SOFT);
}
static CrossReferenceSource(source)
{
// Find the linear address of the source
// location to start xref'ing from.
auto sourcefn = LocByName(source);
auto iterfn = DfirstB(sourcefn);
if (sourcefn != BADADDR && iterfn != BADADDR)
{
do
{
Message("Setting breakpoint # 0x%08x\n", iterfn);
SetBreakpoint(iterfn);
iterfn = DnextB(sourcefn, iterfn);
} while(iterfn != BADADDR);
}
}
static main()
{
auto source = "FunctionName";
Message("--- Setting breakpoints at cross-reference ---\n");
CrossReferenceSource(source);
Message("--- Finished settings breakpoints --\n");
}
Replace "FunctionName" with the name of your function and run it within IDA's 'Execute Script' window available through File > Script command
A known limitation is that it won't recognize indirect cross-references (e.g. calls using the registers).
If CreateFileA/W are all imports (ie, externs defined in an .idata section), can you not just select the symbol in question and hit F2 (add breakpoint)? The Breakpoint settings dialog that comes up allows you to specify the Hardware breakpoint mode, which in this case we would want to limit to Read (since the symbol's value would be written to at startup when imports are resolved), which should only happen in 'call ds:CreateFileA' instances.
Some breakpoint notes from the IDA Help:
It is impossible to create more than 4 hardware breakpoints
Please note that hardware breakpoints occur AFTER the instruction execution while software breakpoints occur BEFORE the instruction.
As far as I know and according with kornman00 "CreateFile" is imported from a dll. In fact, it is imported directly from Kernel32.dll, You can take a look here if you are not sure how it works.
https://msdn.microsoft.com/en-us/library/windows/desktop/aa363858%28v=vs.85%29.aspx
Therefore, In order to do what you are looking for, the best approach is going directly to it, set the breakpoint in kernel32.CreateFileA or kernel32.CreateFileW. The differences are just if the app use Ansichar or Widechar.
Obviously in order to do that, you need to start the debug process because kernel32 must be load for your app before you will be able to set a break-point there.
If you are getting confuse my advice is "load the binary in a simpler debugger" and try to figure out what we explained you before
This C function can be used to disable or enable windows decorations in many window managers. If 'mode' is 'd' the window will hide the decorations, otherwise if the 'mode' is 'D' the window will show them.
void window_tune_decorations(Display *disp, Window win, char mode) {
long hints[5] = { 2, 0, 0, 0, 0};
Atom motif_hints = XInternAtom(disp, "_MOTIF_WM_HINTS", False);
switch (mode) {
case 'D':
hints[2] = 1;
/* fall through */
case 'd':
XChangeProperty(disp, win, motif_hints, motif_hints, 32, PropModeReplace, (unsigned char *)hints, 5);
break;
default:
fputs("Invalid mode.\n", stderr);
}
}
I would like to implement a ``toggle mode''. So my question is, there a way to detect if a windows has the decorations?
I tried using XGetWindowProperty with _MOTIF_WM_HINTS, but I am not sure how to interpret the output.
You interpret the data you get from XGetWindowProperty the same way you interpret data sent to XChangeProperty.
In the case of _MOTIF_WM_HINTS it's an array of 5 longs, or perhaps the struct MwmHints (syn. MotifWmHints). It's a struct of 5 long fields, plus several #defined bit flags. It is inherited from the Motif window manager, but we don't usually keep Motif includes and libraries around nowadays, so the struct gets copied to various places (bad practice but everyonee is doing it). You may find its definition in xprops.h of Gnome and several other places. Look it up on the 'net and copy to your code, or find it in an include file you already depend on, or just look at the definition and keep using the array of 5 longs, your choice.
You need to check the right flags in the right fields. For decorations, check if the window is override-redirect first. If it is, it is undecorated (obviously) and you cannot add any decorations. If the window manager is not running, it's undecorated as well, and you cannot add any decorations in this case too.
Otherwise, if the window does not have the property at all (XGetWindowProperty sets type to None), you may assume it's decorated.
If it does have the property, and MWM_HINTS_DECORATIONS bit is set in flags, then it has exactly the decorations specified in the decorations field by the MWM_DECOR_* bit values. If the field is non-zero, there are some decorations present. AFAIK if MWM_HINTS_DECORATIONS is unset, then the window is (surprisingly) decorated. But please test this yourself, I don't remember and don't have an X11 machine around at the moment so I can't check it.
Naturally, some window managers don't use _MOTIF_WM_HINTS (e.g. ones that were around before Motif). If you have one of those, you cannot check or set decorations with this method.
Don't forget to XFree(hints).
I am unable to figure out how to properly use the EM_SETHANDLE mechanism to set the text for an edit control. Get and Set window text will be too slow for my application.
From the documentation I understand that the allocated buffer will be sued by the control and it works partially for me.
When the text is entered in the control, it is seen in the buffer but when the buffer is updated using memcpy etc (no bug in the code), the updated text won't show properly. I even tried EM_SETHANDLE (SetHandle() ) after every update but it fails after a couple of attempts. There is some kind of heap allocation failure. RedrawWindow() won't work either.
I am unable to get any proper info on the net on the usage. Help!
My code, leaving the app specific details, looks like this.
// init
HANDLE m_hMem = HeapAlloc(...)
m_edit.SetHandle(m_hMem)
// on some event
char *pbuf = (char*)m_hMem;
memcpy(...)
thanks in advance
The docs for EM_GETHANDLE tells you that this memory has to be movable memory allocated by LocalAlloc.
I'm guess you can get away with something like this:
int cbCh = sizeof(TCHAR) > 1 ? sizeof(TCHAR) : IsUsingComCtlV6() ? sizeof(WCHAR) : sizeof(char);
HLOCAL hOrgMem = SendMessage(hEdit,EM_GETHANDLE,0,0);
HLOCAL hNewMem = LocalReAlloc(hOrgMem,cbCh * cchYourTextLength,LMEM_MOVEABLE);
if (hNewMem)
{
//LocalLock, assign string, LocalUnlock
SendMessage(hEdit,EM_SETHANDLE,(WPARAM)hNewMem,0);
}
Looks like you need to allocate the memory with LocalAlloc. See the companion message EM_GETHANDLE: http://msdn.microsoft.com/en-us/library/bb761576(v=vs.85).aspx