I'm stuck in a situation and cannot figure out what I messed up. Easiest way to explain is probably some minimal example: http://play.golang.org/p/14lbOBsCCo
I am tying to modify a value of a struct via its pointer but end up modifing some memory other the part I want. Line 92 is where my issue is.
How would you debug a situation like this (tools etc.), and how do I get the broker.Port set?
Thanks for hints/suggestions!
You're not using pointers throughout. Start off with a Registry of type:
type Registry []*Broker
and work from there
Working example
As far as debugging tricks, this was my process:
Value isn't being changed, so something is being copied by value
Notice that Registry is type []Broker, but we want to modify Brokers, so it needs to be a pointer
Change type Registry to []*Broker
Keep attempting to compile, letting the compiler tell me every place we are using a value where we need a pointer (woohoo fast compile times and static typing)
Related
I'm trying to use Rust's Windows WriteProcessMemory in a project of mine in order to replicate the process hollowing technique. Although I use it in nearly exactly the same way in another place in the project, I'm having trouble getting this one to work. It looks to me like the whole buffer isn't getting copied to the location I enter, and/or the u8 integers are being squished into u64s when written.
The WriteProcessMemory call returns BOOL(1), which evaluates to true, and makes me think it is running successfully. If I provide the lpnumberofbyteswritten variable, it comes back as the same size as the shellcode buffer I intended to write. But the memory doesn't look right if I read it after writing, and the shellcode doesn't run properly (whereas in the other place in my project it does). Have I made a silly mistake? If so, does anyone see where?
Thank you!
I need to hold a specific value (a string, to be exact) throughout the lifetime of a single WinDbg session.
The reason for that, is that I need to address this variable in a few places throughout the lifetime of the WinDbg session (through .if statements, to be exact), and I want it to be defined at the startup of the session - using an argument that'll be passed. It can't be undefined or disposed - I must be able to address it in any point in the debugging session, and of course I don't want to risk that it might be redefined.
I was thinking of using a file for that purpose, or a shared memory, but I much prefer to solve this using WinDbg scripting.
If it's possible, it's obviously a much more elegant solution.
I've done some reading online on this matter and the issue is that I couldn't find a reference where the differences between Aliases (defined by an aS command) and User-Defined Pseudo-Registers (the registers in the range $t0..$t19, which are accessed by using the r command) were described. I couldn't find really understand the use cases for each.
The seemed to me Aliases is the better option, due to the fact that they can be named, in contrast to User-Defined Pseudo-Registers which have set names (wasn't sure regarding how to pick the "right" registered, to minimize possible collisions with other scripts which might use it, or is there any difference at all).
Am I missing something here?
Which should I use in this case, or are they both unsuitable for this situation?
I'm new to reverse-engineering all in all and been having real difficulty to find exactly what makes a message box appears in the application which I don't have the source code for.
I tried using the very slow search for text to see if it would find the "Error when trying to download (...)". But looks like the message text is received from the wire and, therefore, is not a const string inside the binary.
I also have absolutely no clue of where the function is because I can't "instantly break" when the message pops up, so I would like to know if is there a way to create a watch for value kind of thing?
The idea is to make IDA be prepared to break if any address has the int32 value 65000 (decimal) assigned to it.
If you want to "watch for the value 'Error when trying to download (...)'" - then you'd probably find out that it is very complicated, resource heavy, although possible. You'd have to "trace" into every opcode that the processor executes and check where ever you need (e.g - the stack) for that value (or a pointer to it), which can be done with PIN Tools. This tool allows you to efficiently execute any assembly code you wish between each opcode, function call or "block" (as represented in IDA), by manipulating surrounding opcodes so they won't get affected. It's a really interesting thing to try.
However, what you probably want to do is break on MessageBoxW or MessageBoxA. Simply navigate there (press G and write MessageBoxW and place a breakpoint). This will break when the application will call MessageBoxW, and you can then inspect the stack to see where it was called from.
Can we store the the address of the Object in windows Registry and later from some other function read the address we've stored and make changes in that Object directly.
If it is possible, any pointers to getting started tutorial ..!
You could store the address of an object in the registry and then come back later, read it, and then modify the object. For example in C you could have a pointer, convert it to a long, and store it in the registry:
SomePointer *p;
long i = (long)p;
// now store i in the registry
And later, get it back:
int new_i = read value from registry
SomePointer *new_p = (SomePointer *)i;
You really don't want to do that, though.
First, that pointer is only valid for the current instance of the program. If you exit the program and restart, then the pointer is no good. In addition, the pointer will be meaningless to any other application that might be running at any time. Also, in a garbage collected environment that can move things around in memory, the pointer could become invalid at any time.
Also, there's a performance impact. Accessing the registry is very slow.
From a software construction standpoint, it's really bad form to use a global resource such as the registry to solve the local problem of sharing data in a single program.
And, finally, from a practical standpoint, it makes no sense. If you have access to the source code so that you can modify it to write and read the registry, then you can use a more robust and less intrusive way to share the data. For example, the module that writes the registry could instead just export a symbol, and the module that you would have had reading the registry can access that exported symbol.
So, yes ... it is possible to store a pointer in the registry, and later read it back and access the object to which the pointer refers. But it's a really bad idea.
Anyone knows anything about running executable from memory in OSX?
anything like this:
char *exeFile[size];
loadFromFile(exeFile, "/path/to/data");
execute(exeFile);
I want do that for security reasons. for example It is possible to encrypt exe and decrypt it before launch.
Well, yes, you can do it but its complex. I don't have access to working code right now but I do know others that are/have used it. The key is "NSCreateObjectFileImageFromMemory()", which is deprecated, but that said a few big apps like Skype reputed use it so its probably not going to disappear anytime soon (YMMV).
You have to allocate a memory buffer that's a multiple of the pagesize with vm_allocate. Copy the mach-o executable of the same architecture as the current process to there. Call NSCreateObjectFileImageFromMemory() which returns an object image. Then call successively NSLinkModule, NSLookupSymbolInModule and NSAddressOfSymbol. That last one gets you an actual function pointer to call.
This should give you most of what you need to know, and if you search you may find code that does it too. Good luck!