Pass dd Skip|오프셋을 16진수로 탐색

두 번째 명령이 다른 값을 출력하는 이유는 무엇입니까?

역사적인 이유로 곱셈 연산자 dd로 간주됩니다 . x따라서 0x30으로 평가됩니다.

Skip|seek 오프셋을 16진수 값으로 dd에 전달할 수 있습니까?

내가 아는 한 직접적으로는 아니다. 곱셈에 연산자를 사용하는 것 외에도 x숫자 뒤에 b'512 곱하기'(0x200) 및 K'1024 곱하기'(0x400)를 추가할 수도 있습니다. GNU dd를 사용하면 접미사 M, G, T, P, E및 Z를 Y사용하여 각각 20, 30, 40, 50, 60, 70, 80 또는 90의 거듭제곱을 곱하는 것을 의미할 수 있으며 대문자 또는 대문자일 수 있습니다. b접미사를 제외하고는 소문자입니다 . (다른 가능한 접미사도 많이 있습니다. 예를 들어 "10 ¹⁸EB 곱하기 " 는 "2 ⁵⁰ 곱하기 "를 의미합니다. GNU를 설치한 경우 자세한 내용은 참고자료를 참조하세요.)PiBinfo coreutils "block size"

위의 콘텐츠가 모호하거나, 부적절하거나, 짜증나거나, 심지어 우스꽝스럽다고 생각할 수도 있습니다. 걱정하지 마세요. 당신은 혼자가 아닙니다. 다행스럽게도 이를 완전히 무시하고 쉘의 산술 대체를 사용할 수 있습니다(bash 및 기타 Posix 호환 쉘은 물론 일부 비 Posix 쉘도 작동합니다). 쉘은 16진수를 이해하며 일반적인 방식으로 작성된 다양한 산술 연산자를 허용합니다. 표현식을 다음으로 둘러싸면 됩니다 $((...)).

# dd if=2013-Aug-uptime.csv bs=1 count=$((0x2B * 1024)) skip=$((0x37))

나는 이것이 오래된 스레드라는 것을 알고 있지만 질문은 여전히 ​​​​관련이 있습니다. 특히 나 같은 바보가 밤새 백업되지 않은 git에 fileB가 체크인되지 않았을 때 bash 기록에서 실수로 "cp fileA fileB"를 기억하고 실행할 때 그렇습니다. 그 후 몇 시간의 코딩이 필요했습니다 :-/

이 스레드의 개념 덕분에 손실된 파일을 완전히 복구할 수 있었지만 32Gb 디스크와 아주 작은 RAM(Ubuntu 18.04 실행)이 있는 원격 가상 사설 서버에서 파일을 잃어버렸고 "grep"을 사용하여 모든 시도가 실패했습니다. 위의 내용은 "메모리 부족"으로 빠르게 당신을 죽일 것입니다.

내 경우에는 그것이 hexdump -C /dev/sdX1 | grep 'shortString'나를 구했다. grep과 달리 매우 좁은 ASCII 표현인 16진수만 표시하므로 짧고 고유한 문자열만 찾는 것이 중요하며 해당 문자열에도 줄 바꿈이 가능하다는 점을 기억하세요. 일치하는 16진수 주소를 출력한 후에는 위와 비슷한 방식으로 "dd"를 사용할 수 있었습니다. 단, 기본적으로 블록 크기가 4096인 것으로 보이므로 16진수 바이트를 변환해야 할 뿐만 아니라 주소를 10진수로 변환하지만 이를 4096으로 나누어 dd의 건너뛰기 인수 4k 청크로 크기를 조정합니다. 도움이 되지 않습니다. 숫자가 dd에 비해 너무 크면 오류 메시지는 skip=전달된 숫자 대신 무효성에 대해 불평하는 것처럼 보입니다.

$((0xabcd))Bash를 사용하여 16진수->10진수 변환을 쉽게 얻는 방법에 대한 팁을 추가해 주신 분들께 감사드립니다 :-)

마지막으로 말씀드리겠습니다. 제 경우에는 동일한 파일의 복사본이 여러 개 있었고 모두 매우 유사했습니다. 그러나 hexdump에 의해 보고된 가장 높은 주소에서 가장 낮은 주소를 빼면 가능한 모든 복사본이 포함된 ~5MB 영역을 식별할 수 있었습니다. 이는 가장 낮은 주소에서 dd를 찾아 전체 영역을 임시 파일로 추출할 수 있음을 의미합니다. Vim 편집기는 이제 바이너리 콘텐츠를 매우 우아하게 처리하므로 임시 파일을 검사하고 필요한 경우 모양을 변경할 수 있습니다.