I inherited an application using a large number of text based files for configuration.
The file's names are constructed dynamically in the software, so I can't search directly for a file name in the source code.
Is there any way to break into a program running in the debugger when it touches a particular text file?
In your debugger, set a breakpoint at the CreateFile (kernel32.dll) import.
OllyDbg specific:
Press CTRL + G, type in the function name and press F2.
You can set a breakpoint at a specific location (such as calling the function to open the file) if a variable has a specific value.
If you know the place where the files are being open or if the dynamically created file names are assigned to some variable, create an conditional breakpoint that breaks the code execution only if the filename is matching the file that you're interested in.
Related
I had sort of an odd idea and was wondering whether it would be possible. Here's a rough outline of my plan.
Scenario: An application loads and interprets values from a config file at startup. I want to fuzz the application via the config file, without rewriting the config file.
Note: The config file is closed later on in the program, and the function that opens the config file is used to open various other files, so I do not want to hook this function. While SetKMode() and SetProcPermissions() are used here, answers that apply to Windows in general are just as helpful as Windows CE answers.
Plan:
Attain debug privileges over this process via SetKMode() and SetProcPermissions and attach a debugger via DebugActiveProcess()
Break after the function that loads the file returns
Create a temporary modified version of the file and open it in the parent process
Use VirtualAlloc() to allocate space for the FILE structure in the debugee
Transfer the entire FILE structure for the temporary file to the debugee using WriteProcessMemory()
Swap the pointer for the config file loaded by the debuggee to the pointer for the temporary file
Allow the debugee to run the file
Before the debugee closes the file, copy the old pointer for the original config file back to the new pointer so that it closes the correct file
Would the debugger be able to read the file? Would the parent be able to close the file after it's finished?
Edit:
Transferring the old pointer back to the debugee every time it tries to close the file no longer seems like a good solution after some RE, so on top of my current question I have an additional question: Would the debugee be able to close the file the debugger opened? Would that be a problem? And would the fact that the original file isn't closed properly be a problem?
Edit:
Sorry I'm a dummy who forgot that if I'm going through the trouble of injecting all this I can just inject a new filename and swap the pointer long before the call to fopen.
Assuming the entire file is loaded into memory and then parsed, I would hook whatever function loads the file data into memory, use a conditional to check the filename so you're only executing your code after the correct file is loaded into memory by checking the filename. Then I would perform my fuzzing by modifying the file data in memory and then return execution to the target process before the file dats is then parsed. In this manner you aren't touching any file permissions, only memory.
To automate it create a "loader' which executes the target process, injects, executes your hook and then checks for crash or other unwanted behavior.
I'm using System function System(mypath/test.xls) to open and edit an excel sheet in C++ run time. It opens my excel sheet, allows me to edit ans close the same. After closing the excel sheet, the control goes to the code again. Everything works fine unless there is already some other excel sheet opened. If there is some other excel sheet already opened in the machine, I will not able to edit and close so that control goes to code. Can anyone suggest any solutions for this issue.
What is happening is your System(..) function call is asking the Windows shell to find the application associated with your file (test.xls) , which is Excel. Then if Excel is already running it is asked to open file. If the application is not running, then Windows starts the application for you.
So if the application is not already running and it is started for you it becomes associated with your program as a 'child' process. Therefore your System(..) call waits for it to end before continuing. If however Excel is already running then once Windows informs that instance of your desire to open the file test.xls, your call to System(..) returns immediately.
You can avoid this by explicitly running the Excel program by giving the full path to the Excel EXE file. And including the /x command line argument and full path to your file. The /x causes Excel to open a new process and then open your file. This new process is a child of your program's so the System(..) call will wait..
I'm not familiar with the System(..) call (is it like the system(..) one?) you may have to provide the switch /x, and path arguments as distinct arguments to this call rather than in one long string. Also there may be options on how your child process is launched, so waiting for it to return may be optional and so forth.
I've developed a program by a customer who's experiencing when he do a certain operation. This isn't happening always on the same place and on the same data and, moreover, it is not happening nor in my local developing machine nor in my test Virtual Machine (which is free of all developing equipment).
Given these conditions, I've decided to compile with MAP (enabled in Configuring Properties-> Linker->Debugger with option /MAP) to see which function is causing crash.
If I've correctly understood, when the program crash I've to check down the offset error and then, search in my MAP under the column RVA+BASE:
Address Publics by Value Rva+Base Lib:Object
0001:00037af0 ?PersonalizzaPlancia#CDlgGestioneDatiProgetto#MosaicoDialogs##IAEXXZ 00438af0 f DlgGestioneDatiProgetto.obj
0001:00038000 ?SalvaTemporanei#CDlgGestioneDatiProgetto#MosaicoDialogs##IAEXXZ 00439000 f DlgGestioneDatiProgetto.obj
Actually, my crash happens at offset: 00038C90 So I should think that it's somewhere in the method:
MosaicoDialogs::CDlgGestioneDatiProgetto::PersonalizzaPlancia
but this is not absolutely possible, so assuming that the computer can't be wrong, I'm the one who's doing it bad.
Can someone explain me how to read MAP in correct way?
don't bother - instead, build the project with symbols enabled and strip them into a pdb file.
Modify the program a little, to write a minidump when it crashes using a unhandled exception handler
Give the newly compiled program to the customer, and when it crashes call MiniDumpWriteDump.
Ask the customer to send this .dmp file to you, and you then simply load it up in Visual Studio (or WinDbg) and it will match up the symbols to the program, and will also match up the code. You should be able to see the exact line of code and some of the variables involved. (if using VS, when you load the .dmp file, top right corner will be an option to "start debugging" click that as it will 'start debugging' at the point of the crash)
Try it first locally - put a div by zero error somewhere in your program and see if you can debug the dump after its been run. Note that you must keep the exact same symbol file for each build of your program - they match exactly. You cannot expect a symbol file for one build to match another build, even if nothing changed.
There are tutorials for this kind of thing, such as this one from CodeProject that looks like it describes what you need.
Reading of MAP files to find out crash location is explained nicely in this code project article.
http://www.codeproject.com/Articles/3472/Finding-crash-information-using-the-MAP-file
Hope helps.
For postmortem debugging, there's an alternative that would not required the use of a map file. Rather, it would require you to create a simple registry script to enable some WER (Windows Error Reporting) flags to trap the crash dump file. First, build your application with debug symbols. Then, follow the instructions for Collecting User-Mode Dumps. Basically, you create a sub key under the "LocalDumps" key. This sub key must be the name of your application, for example, "myapplication.exe". Then, create the "DumpCount", "DumpType", and "DumpFolder" keys/values. Have the user run the registry script. This will enable trapping the dump locally. Then, have the user force the crash to collect the dump file. The user can then send the dump file to you to debug using the symbols you created earlier. Lastly, you'll need to create a registry script that removes the keys/values you added to the registry.
Is it possible to modify an executable file on runtime (I'm asking about Windows XP/Vista/7/Server)? I've just evaluated SmartUtils Portable Storage application. It can create so called "managed executable storage files" that modify them-self at runtime... Such storage file is like standard self-extracting archive (the data is apended to an executable module) but the main difference it that you are able to view and modify its content without the main program. How is it possible? I need similar functionality in my project (C++): I want to be able to create executable that can modify data attached to it.
If all you're really asking is how SmartUtils Portable Storage does it's magic, then I would suggest that it is a self-executing zip archive. The EXE of the archive (just as WinZip or 7-Zip create) auto-extracts and executes your application exe from a temp folder, and gives you an API that boils down to ways to extract, manipulate, and then modify that original self-executing archive.
So Windows is never trying to modify a running .exe. Rather, your .exe (temp file extracted & run) is what is executing (and the libraries bound to it), which manipulates the source .exe (really a self-executing archive - possibly .zip).
The next time the user "runs" the modified "exe", again your .exe is extracted & run, and it can again manipulate the self-extracting .exe.
I hope that makes sense to you.
And this is just a best guess!
Yes - a common technique is to append data files at the end of an executable.
Typical scheme is to write a 0x00000000 integer to the end of the executable and then append each file followed by it's size in bytes.
Then when the executable needs to read the data it checks the last 4bytes in it's own file, uses that as the file length and copies that number of bytes form it's own file, it then checks the next 4 bytes as another length and copies that as a file , until it gets a length of 0000. If you also need to code the file names - that adds a little complexity but it's basically the same idea.
You can append a TOC pointer to an EXE (and probably a magic ID cookie) so you can verify that it is a TOC pointer, and then use that to back up to the start of each appended record.
As long as you don't mess up the file's header & main contents, it should still be loadable by the OS.
However, you sacrifice any signing your EXE had - and you probably have various permissions issues to contend with...
I have written tools for my development environment that opens a Windows EXE, extrapolates the resources in it, modifies various ones, and repackages the whole thing. We use this to mark a beta as release (so it modifies the version records).
You can do anything you want to an EXE file if you know the structure of it and rebuild it correctly.
Since this is tagged as Windows, you might also consider "Alternate Data Streams". That allows you to treat a single file almost as a directory. You can add a stream called Program.EXE:ExtraData to your program and write to that with the normal file functions.
Then again, your executable most likely will be in Program Files\, which isn't writeable for normal (non-elevated) users.
I have a command line executable that alters some bits in a file that i want to use from my program.
Is it possible to create my own executable that uses this tool and distribute only one executable?
[edit] Clarification:
The command line tool takes an offset and some bits and changes the bits at this offset in a given file. So I want to create a patcher for an application that changes specific bits to a specific value, so what I can do i write something like a batch file to do it but i want to create an executable that does it, i.e. embed the tool into a wrapper program that calls it with specific values.
I can code wrapper in (windows) c\c++, asm but no .net please.
It would be easier to roll your own implementation of this program than to write the wrapper; it sounds like it is trivial -- just open the file, seek to the right location, write your bits, close the file, you're done.
The easiest way is to embed this exe into your own and write it to disk to run it.
You can add the executable as a binary stream resource in your executable and when you need it you can extract it in a temporary folder and create new process with the temporary file.
The exact code you need to do this depends on whether you are writing .Net or C++ code.
Short answer: No.
Less short answer: Not unless it's an installer or a self extracting archive executeable.
Longer, speculative answer: If the file system supports alternate data streams, you could possibly add a stream containing the utility to your program, then your program could access it's own alternate data stream, extracting the utility when you need it. Ahaha.
You could append the one executable onto the end of the other and write some code to unpack it to a temporary folder.
I've done a similar thing before but with a configuration file and some bitmaps appended to an EXE in Windows. The way I did it was to firstly append my stuff onto the end of the EXE and then write a little struct after that which contains the file offset of the data which in your case would be the offset of the 2nd exe.
When running your app, seek to the end of the file minus the size of the struct, extract the file offset and copy the 2nd exe to a temporary folder, then launch it.
OK, here is a little more details as requestd. This is some pseudo-code to create the combined EXE. This is a little utility you run after compiling your main EXE:
Open destination file
Open main exe as a binary file
Copy main exe to destination file
offset = size of main exe
Open 2nd exe as a binary file
Copy 2nd exe to the output file
Write the offset to the output file
Now for the extraction procedure. This goes in your main EXE:
Find the location of our own EXE file (GetModuleFileName() under Windows)
Open the file in binary mode
Seek to the end minus sizeof(offset) (typically 4 bytes)
Read the offset value
Seek to the offset position
Open a temporary file in binary mode
Read bytes from the main EXE and write to the temporary file
Launch the temporary file
I think the easiest way to do this for your purposes is probably to use a self extracting executable package. For example, use a tool like Paquet Builder which will package the exe (and any other files you want) and can be configured to call the exe or a batch file or whatever else you want when the user unpacks the self-extracting executable.
If the exe was built to be relocatable (essentiall linker flag /fixed:no), you can actually do a LoadLibrary on it, get the base address, set up a call chain and call (jump) into it. It would not be worth the effort, and very few exe's are built this way so you would have to have the code to rebuild it, at which point you wouldn't be in this exercise.
So... No.
I'm more intrigued by the developer who doesn't mind writing in C/C++/asm, but 'not .net' - but is apparently stymied by fopen/fseek/fwrite - since that's about all the program you describe sounds like it's doing.
I think this is also possible by using AutoIt's FileInstall function. For this you'll have to setup AutoIt, create a script with the FileInstall function to include the who exe's and then use f.i. the function RunWait to execute them. Compile to an exe and you should be done.