I want to retrieve the binary file that has been loaded on a STM32W108 using JTAG. Has anyone done this before? If yes, can you post the instruction or and link to the instructions
Much appreciate.
If you specify what IDE you're using, then I might be able to give you more accurate instructions.
Here is the general method:
Open the linker-command file of your project and check the address space of the executable. You can also look for it in the map file, but you'll need to build the project first. Please note that the code-section and the data-section possibly reside in two separate memory regions.
Load the executable to RAM, or burn it to EPROM (whichever way you usually do it).
Search for the Memory-Save option, typically in either the View menu or the Debug menu.
Enter the memory address and size you found earlier, and click OK.
Related
I am developing a microcontroller application using the Azure RTOS ThreadX, and I wanted to use TraceX to publish the results in my master's thesis. The problem is that my application is running on a Cortex M0+ and only have 20k of RAM. From this 20k, I can only allocate 10k to the TraceX buffer.
I can only think of two ways of solving the problem:
The TraceX only save, for example, thread switch and event flag signals;
Be able to put a breakpoint before TraceX starts overwriting and save the buffer, and in the end put it together;
Someone had the same problem? How do you solve it?
Both options are possible:
To filter messages please look at the documentation here:
https://learn.microsoft.com/en-us/azure/rtos/tracex/chapter5#tx_trace_event_filter
The trace mechanisms is based on a few macros. You can look at the code in the macro TX_TRACE_IN_LINE_INSERT for the details. You may need to make this macro into a function in order to be able to put a breakpoint in your toolchain. These are implemented as macros for performance and footprint reasons.
I try to analyze a dll file with my poor assembly skills, so forgive me if I couldn't achieve something very trivial. My problem is that, while debugging the application, I find the code I'm looking for only in debug session, after I stop the debugger, the address is gone. The dll doesn't look to be obfuscated, as many of the code is readable. Take a look at the screenshot. The code I'm looking for is located at address 07D1EBBF in debug376 section. BTW, where did I get this debug376 section?
So my question is, How can I find this function while not debugging?
Thanks
UPDATE
Ok, as I said, as soon as I stop the debugger, the code is vanished. I can't even find it via sequence of bytes (but I can in debug mode). When I start the debugger, the code is not disassembled imediately, I should add a hardware breakpoint at that place and only when the breakpoint will be hit, IDA will show disassembled code. take a look at this screenshot
You see the line of code I'm interested in, which is not visible if the program is not running in debug mode. I'm not sure, but I think it's something like unpacking the code at runtime, which is not visible at design time.
Anyway, any help would be appreciated. I want to know why that code is hidden, until breakpoint hit (it's shown as "db 8Bh" etc) and how to find that address without debugging if possible. BTW, could this be a code from a different module (dll)?
Thanks
UPDATE 2
I found out that debug376 is a segment created at runtime. So simple question: how can I find out where this segment came from :)
So you see the code in the Debugger Window once your program is running and as you seem not to find the verry same opcodes in the raw Hex-Dump once it's not running any more?
What might help you is taking a Memory Snapshot. Pause the program's execution near the instructions you're interested in to make sure they are there, then choose "Take memory snapshot" from the "Debugger" Menu. IDA will then ask you wether to copy only the Data found at the segments that are defined as "loder segments" (those the PE loader creates from the predefined table) or "all segments" that seem to currently belong to the debugged program (including such that might have been created by an unpacking routine, decryptor, whatever). Go for "All segments" and you should be fine seeing memory contents including your debug segments (a segment
created or recognized while debugging) in IDA when not debugging the application.
You can view the list of segements at any time by pressing Shift+F7 or by clicking "Segments" from View > Open subviews.
Keep in mind that the programm your trying to analyze might choose to create the segment some other place the next time it is loaded to make it harder to understand for you what's going on.
UPDATE to match your second Question
When a program is unpacking data from somewhere, it will have to copy stuff somewhere. Windows is a virtual machine that nowadays get's real nasty at you when trying to execute or write code at locations that you're not allowed to. So any program, as long as we're under windows will somehow
Register a Bunch of new memory or overwrite memory it already owns. This is usually done by calling something like malloc or so [Your code looks as if it could have been a verry pointer-intensive language... VB perhaps or something object oriented] it mostly boils down to a call to VirtualAlloc or VirtualAllocEx from Windows's kernel32.dll, see http://msdn.microsoft.com/en-us/library/windows/desktop/aa366887(v=vs.85).aspx for more detail on it's calling convention.
Perhaps set up Windows Exception handling on that and mark the memory range als executable if it wasn't already when calling VirtualAlloc. This would be done by calling VirtualProtect, again from kernel32.dll. See http://msdn.microsoft.com/en-us/library/windows/desktop/aa366898(v=vs.85).aspx and http://msdn.microsoft.com/en-us/library/windows/desktop/aa366786(v=vs.85).aspx for more info on that.
So now, you should take a step trough the programm, starting at its default Entrypoint (OEP) and look for calls tho one of those functions, possibly with the memory protection set to PAGE_EXECUTE or a descendant. After that will possibly come some sort of loop decrypting the memory contents, copying them to their new location. You might want to just step over it, depending on what your interest in the program is by justr placing the cursor after the loop (thick blue line in IDA usually) and clicking "Run to Cursor" from the menu that appears upon right clicking the assembler code.
If that fails, just try placing a Hardware Breakpoint on kernel32.dll's VirtualAlloc and see if you get anything interestin when stepping into the return statement so you end up wherever the execution chain will take you after the Alloc or Protect call.
You need to find the Relative Virtual Address of that code, this will allow you to find it again regardless of the load address (pretty handy with almost all systems using ASLR these days). the RVA is generally calculated as virtual address - base load address = RVA, however, you might also need to account for the section base as well.
The alternative is to use IDA's rebasing tool to rebase the dll to the same address everytime.
Is it possible to add code to a current binary in IDA and then save then to recompile the binary? I've looked over Google, but no suggestions as to whether IDA can do this. If not, whats the best to add some pretty heavy modifications to obsolete firmware?
Would I have to load in additional classes/functions from a file?
You can't recompile your source data file with IDA (the program's 'Create an EXE file' tool found in its main main doesn't do anything - It's basically stubbed with a message box telling the used that the selected output file type is not supported).
Your only option might be to compile your code with the source file's compiler, add a new segment to the source file's image where you dump your custom (compiled)code and patch the appropriate locations in the original code (.text) segment to call into your code. Have no clue if IDA supports the kind of static patching required for steps #2 and #3, but you'll probably find other tools to help you with that (you could start with OllyDbg).
I haven't ever tried to do anything of that sort before, so take my suggestion with a pinch of salt. I have however seen various binaries that have arbitrary segments attached to them.
EDIT: Take a look at this question while you are at it - IDA pro asm instructions change
when i have to do small updates on my binary, i like hexedit, kinda nice & options are easy. (small updates ;) )
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".
It's a simple problem. Sometimes Windows will just halt everything and throws a BSOD. Game over, please reboot to play another game. Or whatever. Annoying but not extremely serious...
What I want is simple. I want to catch the BSOD when it occurs. Why? Just for some additional crash logging. It's okay that the system goes blue but when it happens, I just want to log some additional information or perform one additional action.
Is this even possible? If so, how? And what would be the limitations?
Btw, I don't want to do anything when the system recovers, I want to catch it while it happens. This to allow me one final action. (For example, flushing a file before the system goes down.)
BSOD happens due to an error in the Windows kernel or more commonly in a faulty device driver (that runs in kernel mode). There is very little you can do about it. If it is a driver problem, you can hope the vendor will fix it.
You can configure Windows to a create memory dump upon BSOD which will help you troubleshoot the problem. You can get a pretty good idea about the faulting driver by loading the dump into WinDbg and using the !analyze command.
Knowing which driver is causing the problem will let you look for a new driver, but if that doesn't fix the problem, there is little you can do about it (unless you're very good with a hex editor).
UPDATE: If you want to debug this while it is happening, you need to debug the kernel. A good place to pick up more info is the book Windows Internals by Mark Russinovich. Also, I believe there's a bit of info in the help file for WinDbg and there must be something in the device driver kit as well (but that is beyond my knowledge).
The data is stored in what's called "Minidumps".
You can then use debugging tools to explore those dumps. The process is documented here http://forums.majorgeeks.com/showthread.php?t=35246
You have two ways to figure out what happened:
The first is to upload the dmp file located under C:\Minidump***.dmp to microsoft service as they describe it : http://answers.microsoft.com/en-us/windows/wiki/windows_10-update/blue-screen-of-death-bsod/1939df35-283f-4830-a4dd-e95ee5d8669d
or use their software debugger WinDbg to read the dmp file
NB: You will find several files, you can tell the difference using the name that contain the event date.
The second way is to note the error code from the blue screen and to make a search about it in Google and Microsoft website.
The first method is more accurate and efficient.
Windows can be configured to create a crash dump on blue screens.
Here's more information:
How to read the small memory dump files that Windows creates for debugging (support.microsoft.com)