The Stack Overflow podcast is back! Listen to an interview with our new CEO.
7

This doesn't happen during the system call. It happens in user-mode. WOW64 processes have two user-mode stacks - a 32-bit stack, which is the one you normally use, and a 64-bit stack. The WOW64 ntdll does not make system calls. Where the native 32-bit ntdll would sysenter (via an indirect call to SharedUserData!SystemCallStub) the WOW64 ntdll has an ...


5

This would be a comment but since I still don't have enough reputation for comments, I will leave it as an answer: For a dump to work correctly, there are a couple of more things you need to do besides fixing the section headers: Travel the data directories and make sure they all point to the proper table Once you are sure the data directories point to the ...


3

I am no expert in the matter but that seems highly unlikely. There are 2 ways how to approach that I know of: detect/exploit/sniff known interface Like SPI,JTAG,... or even memory interface (address,data and control buses) and do the dump with some MCU to PC adapter attached to it or dump to SD card or what ever. This is not invasive approach but needs to ...


3

So your question is somewhat vague. However, even without providing additional information of your target system, version and used profile, I try to give an introductive answer for Windows systems. You can use the Process Environment Block (PEB) stored in the _EPROCESS Structure to identify the heap segments. There are three important points, which you ...


2

Those numbers are metadata and is called Token IDs. You can click on those in the dnSpy and you will be taken to the editor of the selected item. As for your first question, remember that .net apps are JITed before the actual executions so addresses will change. If I would have to do this I would change the code on the .net level.


2

If you only want the firmware, you can find it in this link. And this link might be of use. Apparently the chip on your box is a BCM3361, a MIPS32 according to Broadcom. I think you can emulate it with QEMU, no obvious issues there. Your dump is more likely to be a mix of code and data. It's pretty hard to dissociate data from code; you'll have to go in ...


2

I believe binwalk gave false postive output It is likely the output is not false positive. You can see the strings used in certificates. For instance I know that there are firmwares that are packed/unpacked and/or encrypted/unencrypted This is the direction you would want to check. Binwalk has an entropy analysis option, and it can display a graph of it....


2

So your definition of a "snapshot" is somewhat vague. Hopefully my answer matches your idea: Did you already take a look at the OllyDumpEx Plugin? This plugin is process memory dumper for OllyDbg and Immunity Debugger. Very simple overview: OllyDumpEx = OllyDump + PE Dumper - obsoleted + useful features Of course you can simply dump the raw memory ...


2

I suggest you to look at the USBDM project which claims to support BDM (background debug mode) for the RS08 and HCS08 series, among others, which I think should be compatible with your chip. Even though they talk about Codewarrior, in theory the source code should allow you to implement your own code dumping tool.


2

you can craft a powershell script in case of emergency (no python no internet only base machine cant install anything whatever ) the code below is rubbish hack you may need to declare proper managed types etc to make it robust it is just to show an idea $procid = (Get-Process -Name $args[0]).Id $baseaddr = (Get-Process -Name $args[0] -Module)[0]....


1

you could write a script which will get all xref's toGetProcAddressthen go one by one to checkGetProcAddress second parametes lpProcName next follow disassembly trace return value eax to first memory write e.g. mov dword ptr [unknown_ptr], eax and rename the pointer. For inspiration look at IDAscope plugin: https://hex-rays.com/contests/2012/index.shtml#...


1

open the dumped file in a hexeditor say hxd select the bytes from offset 0x400 to 0xfff and delete them (all the bytes would be 0x00) save the file your imports should turn out ok pointer to raw data would normally be 0x400 but since this is a memory as you say the pe header would be 0x1000 bytes deleting the extra bytes should align the text segment as ...


1

I have recently made an API in python to read and write memory - could be useful for a quick solution. https://github.com/samsonpianofingers/pymem you could use this like this import pymem handle = pymem.open_process_name("program.exe") address = 0x12c0000 size = 1000 buffer = pymem.read_bytes(handle, address, size) with open("dump.bin", "wb") as f: f....


1

A Hex Editor that supports binary templates to parse and view data is probably the best tool to view where a sqlite database starts and ends. Then you can copy these hex bytes out to a seperate file and view as database from there on. An example of such a hex editor is 010 editor and here is an example of a sqlite binary template for sqlite.


1

with gdb you can define a canned sequence and execute it a sample canned sequence could be stepi {count} append memory {filepath} {start} {end} a sample run on cygwin gdb over gdb $ gdb gdb GNU gdb (GDB) Cygwin 7.9.1-1 (gdb) define dumpy Type commands for definition of "dumpy". End with a line saying just "end". >si 10000 >append value ../../...


1

I don't see a reason why you shouldn't be able to dump a block to the disk from the stack directly. Starting with #include <fcntl.h> char *block; int main(void) { int fd=open("/tmp/myfile", O_WRONLY|O_APPEND|O_CREAT, 0666); write(fd, block, 0x400000); close(fd); } and continuing with gcc -m32 -S b.c you arrive at this b.s file .LC0: ...


1

In case of IdaPro being available - it works on Linux as well - you could consider using an Ida script, like this: static main() { DumpMem(); } static DumpMem() { auto h; auto ea; auto eaStart = <here your start address>; Message("dumping..."); h = fopen("dumped.bin", "wb"); ...


Only top voted, non community-wiki answers of a minimum length are eligible