Would it is possible to mount using OSFMount a .dd image taken of an Acer Liquid E smartphone's flash memory?
OSFMount used in environment Windows 8.1 / NTFS / 64-bit
The README file suggests not but wondered whether any tweeks are possible?
Thanks
Would it is possible to mount using OSFMount a .dd image taken of an Acer Liquid E smartphone's flash memory?
OSFMount used in environment Windows 8.1 / NTFS / 64-bit
The README file suggests not but wondered whether any tweeks are possible?
Thanks
Why not? ?
As long as the image contains volume(s) formatted with a filesystem that Windows recognizes, IMDISK ot OSFmount can mount it, the point might be if the dd image is recognized "as is" or if you need ot provide manually the offset to the bootsector/VBR of the volume or if the used filesystem is not among the ones Windows has a built-in IFS driver for.
If needed, it has to be underlined how these drivers mount to a drive letter under windows the *whatever* that gets a drive letter (which is a volume) but then the volume needs to be formatted in a filesystem that the Windows recognizes (or for which you can install a third party driver).
jaclaz
Hi Jaclaz, thanks for responding.
I have used every combination offered by the options in OSFMount and OSFM keeps stating "parameter is incorrect". If I view the "volume" through "This PC" I still get the same message.
Hi Jaclaz, thanks for responding.
I have used every combination offered by the options in OSFMount and OSFM keeps stating "parameter is incorrect". If I view the "volume" through "This PC" I still get the same message.
I am not at all familiar with the specific handy, but a "normal" Android device has a partition table, I have seen examples of MBR ones, but maybe there are GPT ones also, here is a detailed example
http//
IMDISK (and most probably also OFSmount which is a direct derivative, with some added forensic image formats added) uses a method similar to the one Windows uses to automagically find the offset to the partitions/volumes, that depends largely on the ID's in the partition table, so the first thing that you should check is first sector of your image is actually a MBR or not.
If it is not (or if the partition ID's in it's partition table or in the chain of the EPBR's are not recognized by windows) you may need (as an example by carving) to find the offset to the partitions/volumes with a "known" filessystem, and then again you might need to add relevant filesystem driver to your OS in order to "recognize" or "access" the contents.
Extremely simplified what IMDISK does (and I presume that OFSmount does exactly the same) is to expose an arbitrary (offset+extents) range of sectors in a file as a Volume, thus allowing the Windows mechanisms to assign to it a drive letter (or a mountpoint) and consequently use on it the correspondent filesystem driver.
The automatic detection of the range of sector can obviously fail, and you have to provide it as offset + extents manually.
jaclaz
Hi Jaclaz thanks for your reply, I followed your link, too. Even using the base address (0x20000000) it didn't work for OSFM. I received a very helpful and prompt response from Passmark, which was appreciated, and will continue to search for a solution for this particular acquired image.
once again, thanks.
Hi Jaclaz thanks for your reply, I followed your link, too. Even using the base address (0x20000000) it didn't work for OSFM.
Base address of WHAT? 😯
To remain in your preferred hex notation
0x20000000=0x100000*0x200
While it is common (on PC's) to have an offset to the first partition of 0x100000, those are bytes, not sectors.
Allow me to doubt that a device "wastes" 0x100000 sectors. ?
jaclaz