dd: conv option disabled

I am using ADB Shell for imaging my Android phone.

WHICH "Android phone"?
EXACT make/model please, EXACT Android version, additionally.

jaclaz

Android Phone is QMobile Noir LT700
and Android version is Android 5.0 Lollipop.

Did you try imaging it with Magnet Acquire ? The Community Edition is free and it has "dd" for physical imaging as well

https://www.magnetforensics.com/acquire-community/

Please write a feedback here if you succeed, now and then I make statistics of physical imaging tools for smartphones.

Android Phone is QMobile Noir LT700
and Android version is Android 5.0 Lollipop.

Good, are you sure that /dev/block/mmcblk0p22 represents a valid partition/block device i.e. typically a boot or system or data one?

I mean, have you checked *like* here
http//androidcreations.weebly.com/how-to-get-android-mounts-and-partition-images.html
the mappings?

Or *like* here
http//www.digitalinternals.com/mobile/android-mmc-mmcblk-partition-layout/259/
Or where have you found that mapping (specific for your phone)?

AFAIK each phone model (and sometimes even a same phone in different releases) may have different mappings.

jaclaz

For taking a bit-by-bit image, I am using the dd command but it returns dd conv option disabled.

What dd are you using?

The standard GNU coreutils dd does not contain that message, so it's not normal behaviour.

I find an android dd from netmite that does – in which case it indicates that the binary has been compiled for small memory footprint, and all conv processing simply disabled.

You may have to ask whoever supplied the dd (or the package in which it is included).

Nothing to do about that, except find another dd that works better, or recompile it … but I'll leave any instructions for that to the Android experts.

And perhaps add that untested tools may not be as friendly as in this particular case – which at least tells you something is not quite right. Even if it's tempting to skip it, tool validation is a must. You may need to reevaluate the Android software distribution that you are using – it may not be up to the requirements of forensic use.

Android Phone is QMobile Noir LT700
and Android version is Android 5.0 Lollipop.

Good, are you sure that /dev/block/mmcblk0p22 represents a valid partition/block device i.e. typically a boot or system or data one?

I mean, have you checked *like* here
http//androidcreations.weebly.com/how-to-get-android-mounts-and-partition-images.html
the mappings?

Or *like* here
http//www.digitalinternals.com/mobile/android-mmc-mmcblk-partition-layout/259/
Or where have you found that mapping (specific for your phone)?

AFAIK each phone model (and sometimes even a same phone in different releases) may have different mappings.

jaclaz

Yes, I have checked that and in my mobile it is for USERDATA.

For taking a bit-by-bit image, I am using the dd command but it returns dd conv option disabled.

What dd are you using?

The standard GNU coreutils dd does not contain that message, so it's not normal behaviour.

I find an android dd from netmite that does – in which case it indicates that the binary has been compiled for small memory footprint, and all conv processing simply disabled.

You may have to ask whoever supplied the dd (or the package in which it is included).

Nothing to do about that, except find another dd that works better, or recompile it … but I'll leave any instructions for that to the Android experts.

And perhaps add that untested tools may not be as friendly as in this particular case – which at least tells you something is not quite right. Even if it's tempting to skip it, tool validation is a must. You may need to reevaluate the Android software distribution that you are using – it may not be up to the requirements of forensic use.

I am using the Android dd Sir. I don't know why it is not working. I have installed busybox but even after that its giving the same error.

I am using the Android dd Sir. I don't know why it is not working. I have installed busybox but even after that its giving the same error.

I am still suspecting that the dd (without the conv) works fine, but you get what you input in dd and this evidently is not a filesystem image.

You could try inspecting it with a hex editor or try carving it to see what it contains.

Try making with dd a copy of another /dev/block/mmcblk0p?? , possibly the one that is root or boot or system and see if with that the tools you are attempting to use do recognize a filesystem.

jaclaz

I have done that its still returning the same, just the size of image increases , nothing else changes.