I'm debugging my x64 c++ program to learn how it look in x64dbg. I see some register for r8-r15 on the right window, but I don't see r8d. There were others like r15d too. So what is it?
Here is a screenshot of my x64dbg.
The d suffix means its (the 64-bit register's) lower double-word. For example, r8d is accessing r8's lower 32-bit as if it is a 32-bit register.
You can find more info here.
Related
My tcl platform(osVersion) is v6.2
% puts $tcl_platform(osVersion)
6.2
How to downgrade tcl_platform(osVersion) to v6.1?
Thank you.
I try to find activetcl v8.5 on internet but the old version all links are invalid...
That value, which describes the version of the operating system that is running the script, is read out of a platform-specific location in your OS during the initialisation of an interpreter (technically, it is copied from data determined during startup of the first Tcl interpreter in a process, where that data is held in a location invisible to you). It is then free to be read or altered by your code... with whatever consequences that may entail.
Permanently changing that value is done by changing what OS is installed. That's totally out of scope for what an ordinary user script can do!
Tcl's implementation mostly doesn't use the OS version. It cares far more about whether API capabilities are exposed to it, and those are almost always at the more granular level of general platform (or transparently adapted around).
I want to disassemble Wii game executable binaries in C, which use the broadway microprocessor and unfortunately the only disassembler I am aware that I can use is libopcodes.
Documentation about this library is scarce and I'm using this tutorial https://blog.yossarian.net/2019/05/18/Basic-disassembly-with-libopcodes to get a basic disassembler, from which (after reading) I copy pasted the last complete code snippet. I initially used the default binutils version of Ubuntu 20, which worked for the x86 architecture but immediately segfaulted with no output for my architecture of interest (bfd_arch_powerpc and bfd_mach_ppc_750). I now built from source the latest binutils version (2.39.50), which now demands an fprintf_styled argument (I provided a very simple one which vprintfs to stdout). Now I am getting an a floating point exception on buffer_read_memory (?) when disassembling the tutorial's architecture and a segfault when diassembling mine.
I am not familiar at all with libopcodes and am pretty much blindly following the only tutorial I could find for it on the internet. If anyone could help be up to create a basic powerpc disassembler with libopcodes that disassembles a void* buffer (or at least point me to any resource) it would be greatly appreciated.
A ppc example usage of libbfd can be seen in the disasm() function of qtrace-tools/qtdis. This is used to disassemble a buffer of powerpc64 instructions.
I solved my issue. I had to install binutils-multiarch-dev to support bfd_arch_powerpc and bfd_mach_ppc_750. In my case, I also had to remove my custom installation of binutils because the custom build with no flags apparently does not support PowerPC and dis-asm.h from /usr/local/include was taking priority over the one in /usr/include.
Does anyone ever succeeded in installing MAtConvNet under Octave ?
If so could you please let me know the steps to proceed ?
thanks and regards
Arno
I was just looking into this issue myself. I have reached a point in researching this where I feel the issues are too complicated for my own project and are not worth my time trying to finish running down. However, if someone else is determined to track this down, hopefully this information will help.
The basic problem comes down Octave only compiling to support 32-bit architectures even if you use the 64-bit installer. If you want Octave to support 64-bit, you need to compile from source using the appropriate compiling options. The other details are as follows.
MatConvNet appears to require a 64-bit system to compile.
http://www.vlfeat.org/matconvnet/mfiles/vl_compilenn/
MatConvNet detects system architecture in in the mex_cuda_config function in vl_compilenn.m:
https://github.com/vlfeat/matconvnet/blob/master/matlab/vl_compilenn.m
Octave's computer function is not a perfect analog to Matlab's function, so the mex_cuda_config function in vl_compilenn.m would need to be modified or Octave's computer function would need to be updated. More specifically, the computer function's handling of the 'arch' argument needs to be changed.
There may be other issues, but this is where I would start if I had the time to invest in trying to track this down.
Recently I was trying to learn more about Windows Kernel. I downloaded right symbols
for my sys(win7 x64 free). I run IDA and open ntoskrnl.exe. IDA asked whether to attach pdb file. But most of functions were not resolved - sub_XXXXXX. So I ran Windbg, I unassembled randomly chosen function which has to be in ntoskrnl - KiSystemCall64. And it show output.
But there is no such function in IDA(or it was not resolved). To sum up, using the same symbols, functions which are unassembled in WinDBg, are not resolved(no sign of them) in IDA(and vice versa).
I would appreciate any help, suggestions from You.
Did you analyze the module after you loaded symbols for it? In the Modules window, right click the kernel and choose "Load debug symbols." After that's done, right click the module again and choose, "Analyze module."
-scott
From debugging the program I only know that before clicking a button a set of known data isn't in memory (confirmed by memory search) and after clicking it the data is in memory (all the time a different location).
How can I find the code that generates this data?
One of the major problems (which might be important to know) is that it is a .net-Program (which I can't analyze with Reflector because it is obfuscated). So I'm analyzing the assembly generated by .NET (in Olly / Immunity / IDA).
If it is .Net you could debug the IL code. It is not easy though, but it should be possible to find the il intruction that writes the sequence into memory.
Try debugging tools for windows with the so called SOS extension.
You could also try if it would be possible to generate say C# code from the obfuscated assemblies for debugging. But this will most certainly not better readable code than IL.
Add Cheat Engine to your toolkit.
If you can get the address it will write to you could right click it and choose "Find out what writes to this address".
P.S. For a reverse effect you can select an instruction in the memory view, right click and choose "Find out what addresses this instruction access".