잘못된 FTP 모드로 업로드 된 손상된 파일 복구

일부 파일이 잘못된 모드로 FTP에 업로드되었습니다 (명령 줄을 통해). 나는 텍스트 모드로 업로드 된 바이너리 파일을 가지고 있으며 이제 열 수 없다고 생각한다.

원본 파일에 대한 액세스 권한이 없습니다. 어떻게 든이 파일을 복구 할 수 있습니까? 파일을 올바른 형식으로 가져올 수있는 도구가 있습니까?

나는 최근에 같은 문제에 직면해야했다. Linux - & gt; Windows, ASCII 모드. 필자는 ASCII로 전송 된 바이너리를 복구 할 수있는 Python 프로그램을 작성했습니다. 그것은 바이트 bruteforcer, 그리고 그것이 작동하는 방법은 다음과 같습니다 :

1. 손상된 아카이브를 바이트 스트림으로 엽니 다.
2. 0d 다음에 0a (ASCII 13, ASCII 10)가 오는 모든 항목을 찾습니다.
3. 0d에 이어 0a가 나오는 것을 모두 제거하고 바이트 주소를 저장하십시오.
4. 각각의 주소를 순환하여 바이너리에있을 예정인 경우 0d를 복원하고 열려고 시도합니다. (필자는 bz2 아카이브를 다루고 있었고 CRC 체크섬 알고리즘을 통해 무결성을 검사했습니다. 압축되지 않은 데이터를 아카이브에 하드 코딩 된 데이터와 대조).

바이너리에서 유효한 0d 0a 바이트 쌍의 수는 그다지 높지 않을 것이다. 유효한 0d 0 쌍을 갖는 이진 확률은 매우 낮습니다. bz2 아카이브가이 bruteforce 메소드로 수정하는 데 걸리는 시간은 100kb 미만의 파일의 경우 10 초 미만입니다. 나는 다른 유형의 파일들로 그것을 검사하지는 않았지만 가능하다.

이 질문은 프로그래밍과 관련이 없기 때문에 여기에 코드를 붙여 넣지는 않을 것입니다. 이것은 일종의 경쟁 과제 였고 소스 ​​공개에 익숙하지 않다고 생각하지만 필요하다면 저에게 알려주세요.

건배, 그리고 메리 크리스마스 모두! :)

파괴를 취소 할 수 있는지 여부를 아는 것은 관련된 운영 체제를 알고 있어야합니다. 그 결과는 서버 및 클라이언트에서 사용하는 운영 체제.

최악의 문제는 줄 끝 문자입니다. Windows에서 캐리지 리턴 (ASCII 값 13) 사용 리눅스가 사용하는 동안에는 줄 바꿈 (ASCII 값 10)이 뒤 따른다. 줄 바꿈.

텍스트 모드 FTP 전송은 이것을 번역합니다. 바이너리 모드는 그렇지 않습니다. 파괴가 어디서 오는가.

Windows에서 Linux로 이전하는 경우 LF가 원래 LF인지 또는 CR-LF의 조합인지를 판별하는 것은 불가능합니다. 데이터가 손실되면 파괴를 취소하는 것이 불가능합니다.

다른 사람이 언급했듯이 데이터가 손상되어 잠재적으로 복구 할 수 없습니다.

그러나 0x0D 0x0A는 대부분의 바이너리 파일 형식에서 특히 일반적으로 사용되는 바이트 시퀀스가 ​​아니므로 파일을 수정했는지 확인하는 것이 좋습니다.

그만큼 fixgz 유틸리티 바로 그거야. 그것의 이름에도 불구하고, 그것은 .gzip 파일에 특정한 것이 없으며 모든 파일에서 사용될 수 있습니다.

행운을 빕니다!