Raw binary file injector - specially designed for quickbms

[elit]

I just finished binary file injector. I could not find good enough tool or with supporting big files on the net so I made this one. It have some advanced features that probably none other have.

With this tool, you can inject data from one file to another. You can chose from which offset of input file to read and how many bytes to copy into output file, for which you also can chose offset where to start writing.

But, it doesn't end there. If your input file name is a decimal number(extension is ignored), like "34234" or "34234.*" for example, and for output file offset you specify negative number like -1, name of input file itself will be taken as a number and used as offset to output file. This mean for example "prog.exe 34234 outfile -ooff=-1 ..." literally mean: "read data from file "34234" and write it to outfile at offset 34234. This is to make seamless cooperation with quickbms tool when you export files as raw chunks. Just make sure name is a decimal number(and not hexadecimal).

Furthermore, tool support so called "nostrict" mode. Normally, you cannot write beyond output file boundary and can only overwrite existing bytes. Output file must also exist. This is default behavior for quickbms usage. But, with -nostrict you can create new output file, grow existing one(write more than its current size) or append data to its end. This means you can copy part of input file into new file or inject new data appending to output. You could for example create new file stripped without initial header of original one, or inject virus into binary if you love cats...
...ehm, anyway, hope you find it useful.

EDIT(v1.2.1):
rawinjector_v1.2.1_fix.zip

[elit]

New version upped in the first post. Now support zeroing of data. This is an alternative to quickbms -Z option so that .bms script can be used solely for read/extraction, while all writing operations are offloaded to rawinjector.

This is intended to be used when you dump raw chunks whose filenames are offsets and then want to zero original data file(for repacking). Input files(chunks) and/or their offsets must still exist and be provided.

[elit]

New version 1.2: Input filename used as an offset to output can now have an extension(which will be ignored for offset calculation).

[ShivShubh]

Originally Posted by elit

New version 1.2: Input filename used as an offset to output can now have an extension(which will be ignored for offset calculation).

Possible bug - When I used this injector to inject few files on a 10GB+ file then it said something like "size of the output is zero". It worked fine for a 500 MB file though.

[elit]

Originally Posted by ShivShubh

Possible bug - When I used this injector to inject few files on a 10GB+ file then it said something like "size of the output is zero". It worked fine for a 500 MB file though.

If its output file reported and not input file, then this can only happen if that file has 0 size and you try to inject data into it in default 'strict' mode.
Try to check what is the size of that output file *before* injecting, it should be empty 0 bytes file. You can still write to it if you use -nostrict flag then, if thats what you need.

[ShivShubh]

Originally Posted by elit

If its output file reported and not input file, then this can only happen if that file has 0 size and you try to inject data into it in default 'strict' mode.
Try to check what is the size of that output file *before* injecting, it should be empty 0 bytes file. You can still write to it if you use -nostrict flag then, if thats what you need.

I will check again. But then I think why the same settings worked on a 500 MB file ? I was injecting 11 MB file on 500 MB file, it worked fine. Tried with same settings on 10 GB file, it was saying that 10 GB file (output) is empty. I was using strict mode.

[elit]

Originally Posted by ShivShubh

I will check again. But then I think why the same settings worked on a 500 MB file ? I was injecting 11 MB file on 500 MB file, it worked fine. Tried with same settings on 10 GB file, it was saying that 10 GB file (output) is empty. I was using strict mode.

In strict mode, output file must already have a size and range of bytes existing where you are writing. In other words, in default mode you can only overwrite existing bytes. So of course it worked on 500mb file.
And it obviously cannot work on empty file size as it contain no bytes(to be overwritten), here you can only append new data into it, meaning growing its size and for that you need -nostrict mode.

Strict mode is meant to write within output file boundaries. That is because it was designed for quickbms usage to write same amount of data back(to same offset) to get same file CRC as was original(before you zero it for example), here different size/crc would mean wrong data/corruption.

EDIT: My apology I misread you comment. You saying that file was not empty but 10gb size and there it did not worked correct? I will check it, but are you sure file was not in fact 0 bytes? And also offset+size where you wanted to write was within output files boundaries? Can you post more info or screenshots?

EDIT2: I believe you are correct, I did not tested myself but noticed that standard fseek function only have int as return value, this is certainly issue. I will change it using 64bit variant and that will solve problem. Update soon...

[elit]

New version 1.2.1 upped. Replaced 2 functions for true 64bit variants, it should now work correctly on big files. Big thanks to @ShivShubh for bug report(pls let me know if it work now, it should).

Furthermore, I separated output info from error messages. Final output info is written to stdout while errors, warnings and special info is written to stderr. This is helpful if you want to suppress output(with > nul) for quiet mode but still want to see or redirect possible errors that may occur.

[ShivShubh]

Originally Posted by elit

New version 1.2.1 upped. Replaced 2 functions for true 64bit variants, it should now work correctly on big files. Big thanks to @ShivShubh for bug report(pls let me know if it work now, it should).

Furthermore, I separated output info from error messages. Final output info is written to stdout while errors, warnings and special info is written to stderr. This is helpful if you want to suppress output(with > nul) for quiet mode but still want to see or redirect possible errors that may occur.

It works now and apparently its faster than the other tool I have.

[FitGirl]

Thanks for the tool, it's faster than SFK.

[elit]

Originally Posted by FitGirl

Thanks for the tool, it's faster than SFK.

Glad you found it to be helpful FG, yes it should be with the speed "to the core" as I code exclusively in: (get ready)
"Pure-Superior-Master-Race C" language - aka PSMRC. Hehe.

Btw:
When you use -ooff=-1 to read offset from input file name, you can use either full path:

C:\aaa\343432

or relative:

343432, aaa\343432

You can use double quotes for either:

"C:\aaa\343432" or "343432"

You can use single extension or multiple:

343432.wem or 343432.raw.wem or 343432._raw_wem.org or whatever you want

It will always strip double quotes from path if any, then path itself(looking for either '\\' or '/' so it support Unix paths in Win) and then convert pure filename up to first '.' to integer offset and skip everything after it. And path itself(aka dirs) can contain '.' characters thats not problem.