I am writing a MOV file, in which I am supplying a bunch of CMSampleBuffers to pass along to an AVAssetWriterInput object.
While this is going on, I am tracking the byte size of the compressed data inside the CMSampleBuffers to write to a log file on the system.
The only thing that I am missing, is the MOV header size.
The difference between my count and the saved file size, is typically about 2000 bytes or so of data. I can't figure out how to get the exact size written to the file system from AVAssetWriter.
Now, I could just find the file size after the MOV file is closed, but for some reason, NSFileSystemManager "attributesOfItemAtPath" "NSFileSize" never matches the byte count with I look at the file in the bash shell.
Suggestions are welcome!
bob.
Related
I'm using SetFilePointer to rewrite the second half of the MBR with something, its a user-mode application and i opened a handle to PhysicalDrive
At first i tried to set the size parameter in WriteFile to 256 but the writefile gave the INVALID_PARAMETER error, as it turns out based on some search on other questions here it seems like this is because we are forced to write in multiplicand of the sector size when the handle is PhysicalDrive for some reason
then i tried to set the filePointer to 256, and Write 512 bytes, both of them return no error, but for some unknown reason it writes from the beginning of the sector! as if the SetFilePointer didn't work even tho the return value of SetFilePointer is OK and it returns 256
So my questions is :
Why the write size have to be multiplicand of sector size when the handle is PhysicalDrive? which other device handles are like this?
Why is this happening and when I set the file pointer to 256, WriteFile still writes from the start?
isn't this really redundant, considering that even if I want to change 1 byte then I have to read the entire sector, change the one byte and then write it back, instead of just writing 1 byte, it seems like 10 times more overhead! isn't there a faster way to write a few bytes in a sector?
I think you are mixing the file system and the storage (block device). File system stays above storage device stack. If your code obtains a handle to a file system device, you can write byte by byte. But if you are accessing storage device stack, you can only write sector by sector (or block size).
Directly writing to block device is definitely slow as you discovered. However, in most cases, people just talk to file systems. Most file system drivers maintain cache and use algorithms for both read and write to improve performance.
Can't comment on file pointer based offset before seeing the actual code. But I guess it might be not sector aligned or it's not used at all.
so, i was trying to read a DLL file, everything was fine till i reach the Optional Header Data Directories, specifically its first member, the Export Table.
My problem is that i can't move the offset of my reader because the virtual address member is based on memory VA, and my reader is based on file offset. May a visual example helps:
As you can see, the loaded virtual address that this PE viewer reads at the Export Table Address from the Data Directory(Optional Header) is the value 0x00002630(lets refer to it as hex1 from now on).
However, when i click on the Export Table to see the actual content, the program does the conversion of this address from memory to file offset, redirecting me to this address as the result:
The address that it redirects me is the 0x00001a30(lets refer to it as hex2 from now on).
I did some tests on my own like dividing the hex1 per 8 because i thought it could be the transition from memory alignment which is 4096 and the file alignment which is 512 but it didn't gave me the same result as hex2. I also did some weird stuff to try to get that formula, but it gave me even more bizarre results.
So, my question would be, how could i get/calculate that file offset(hex2) if i only know the memory offset at the Data Directory(hex1)?
Assuming you are using MSVC C/C++, you first need to locate the array of IMAGE_SECTION_HEADER structures following the Optional Header. The SDK has a macro called IMAGE_FIRST_SECTION(pNtHeaders) in which you just pass the pointer of your PE header to make this process easier. It basically just skips past the optional header in memory which is where the section headers start. This macro will also work on either 32-bit or 64-bit Windows PE files.
Once you have the address of the IMAGE_SECTION_HEADER array, you loop through the structures up to FileHeader.NumberOfSections using pointer math. Each of the structures describe the relative starting of a memory address (VirtualAddress) for each of the named PE sections along with the file offset (PointerToRawData) to that section within the file you have loaded.
The size of the section WITHIN the file is SizeOfRawData. At this point, you now have everything you need to translate any given RVA to a file offset. First range check each IMAGE_SECTION_HEADER's VirtualAddress with the RVA you are looking up. I.e.:
if (uRva >= pSect->VirtualAddress && (uRva < (pSect->VirtualAddress + pSect->SizeOfRawData))
{
//found
}
If you find a matching section, you then subtract the VirtualAddress from your lookup RVA, then add the PointerToRawData offset:
uFileOffset = uRva - pSect->VirtualAddress + pSect->PointerToRawData
This results in an offset from the beginning of the file corresponding to that RVA. At this point you have translated the RVA to a file offset.
NOTE: Due to padding, incorrect PE files, etc., you may find not all RVAs will map to a location within the file at which point you might display an error message.
I am trying to recreate a disk image manually through bash. I have an empty disk the same size as the original and I am trying to insert each file at same address as the original disk so that both hash's match. However I cant seem to find the commands to do this. I was advised to use DD or DCFLDD but I cant figure out how to do this with the documentation online. I have a disk, image.dmg and the first file is ._.Trashes with an inode of 4 and size of 4096 bytes.
With dd you may like to use the following arguments:
bs=BYTES
read and write up to BYTES bytes at a time
count=N
copy only N input blocks
seek=N skip N obs-sized blocks at start of output
skip=N skip N ibs-sized blocks at start of input
In other words, to copy N bytes at offset X in file A to offset Y in file B, something like the following should do:
dd bs=1 count=N if=A skip=X of=B seek=Y
I am having a few issues with my code. I am trying to read both of the PE headers inside of an executable file. However, when I invoke ReadFile, it sets [hFile] to 5A, which is not the handle I put inside from CreateFile. From what I understand, ReadFile should not change this in any way. However, when I store the handle inside another variable and use it to set the file pointer, the next ReadFile instruction still gives me the MZ header instead of the PE header, which is located at offset 3C from the MZ header.
Summary: ReadFile changes my handle, SetFilePointer sees the change as an invalid handle, SetFilePointer does not change the pointer for the next read when given a valid handle.
format PE console 4.0
entry start
include 'win32ax.inc'
section '.data' data readable writeable
thisFile db "thisfile.exe",0
read db ?
hFile dd ?
section '.text' data readable executable
start:
;========Open File================
invoke CreateFile,thisFile,GENERIC_READ,FILE_SHARE_READ,0,\
OPEN_EXISTING,FILE_ATTRIBUTE_NORMAL,0
mov [hFile],eax
;========MZ HEADER================
invoke ReadFile,[hFile],read,2,NULL,0 ; = MZ, , however, changes [hFile]
;to 5A? Why does it change it?
invoke printf,read
;========PE HEADER================
invoke SetFilePointer,[hFile],03Ch,0,FILE_CURRENT ; = 0, beginning of file ATM
;Should make next read = PE
invoke ReadFile,[hFile],read,3,NULL,0 ; = PE
invoke printf,read
invoke getchar
invoke ExitProcess,0
Here you're reading 2 bytes into read:
invoke ReadFile,[hFile],read,2,NULL,0
But look at how you've declared read:
read db ?
That's a single byte. So the second byte you're reading with ReadFile will get written into whatever follows read in memory, which happens to be hFile. Thus, you're overwriting the least significant byte of hFile.
There's another place in your code where you're trying to read 3 bytes into read, but I guess that will fail since by then your hFile will be invalid.
What you need to do is to reserve more space for read, as much as you ever plan on storing in it. Let's say that you want 4 bytes, you could get that with:
read db 4 dup(0)
or
read: times 4 db 0
or
read rb 4
or
read dd ?
Since you're passing read to printf as a string, keep in mind that strings are expected to be NUL-terminated.
Today I am trying to remove some bytes from an EXE file.
Inside the EXE I found a path to a file that the EXE needs to load. I want to change the path, and to do that I have to remove some ../../ characters. When I do that and save the file, it looses its icon and a 'win32 unknow format error' is displayed when I try to execute it.
If I don't remove those bytes but replace them by 0, the icon is not lost, and the file looks right. Yet, the path is incorrect.
So, it looks like when I remove bytes, position of other information inside the file is lost, including resources (the icon). After removeing those bytes, I need to add other 6 bytes, to keep the same size and position of other data. Where should I do that? If I add those bytes at the end of the file, it doesn't work. Could you give me some clues? Thanks!
After removing the ../../ from the start of the string, stick six 0 bytes at the end of the string (I'm assuming you can identify the end manually). That way the offset of everything in the file remains the same. By removing the 6 bytes entirely, the offset of things after the string would change. By replacing the 6 bytes with 0s, the offset of the string would change (it would now really be at wherever it was + 6).