에이프스타인 PDF를 원본 인코딩 첨부파일에서 복원하기
(neosmart.net)- 미 법무부가 공개한 에이프스타인 이메일 아카이브는 잘못된 인코딩과 과도한 검열로 인해 심각한 오류와 비판을 받고 있음
- 일부 이메일에는
Content-Transfer-Encoding: base64형식의 첨부파일이 그대로 포함되어 있어, 이 데이터를 복원하면 원본 PDF를 재구성할 수 있음 - 그러나 OCR 품질 저하, Courier New 폰트의 1과 l 구분 문제, 잘못된 스캔 품질 등으로 인해 자동 복원이 거의 불가능한 상태
- 작성자는 tesseract, Adobe Acrobat Pro, AWS Textract 등을 활용해 복원을 시도했으나, 모두 불완전한 결과를 얻음
- 이 사례는 디지털 포렌식과 문서 복원 기술의 한계를 드러내며, 커뮤니티가 협력해 해결해야 할 기술적 도전 과제로 제시됨
법무부 공개 자료의 문제점
- 최근 공개된 에이프스타인 아카이브는 공범 이름부터 무관한 여성 사진까지 과도하게 검열된 상태로 배포됨
- 일부 파일은 Quoted-Printable 인코딩 오류로 손상되어 열람 불가 상태
- 심지어 이메일 자격 증명이 노출되어 레딧 이용자들이 에이프스타인 계정에 접근할 수 있었음
- 이러한 부실한 처리로 인해 Pam Bondi가 이끄는 법무부의 전문성 부족이 지적됨
base64 첨부파일 발견
- 이메일
EFTA00400459에서 76페이지 분량의 base64 인코딩 데이터가 발견됨- 이는
DBC12 One Page Invite with Reply.pdf파일을 SMTP 전송용으로 인코딩한 형태 - 단순히 복사 후
base64 -d > output.pdf명령으로 복원 가능해야 하지만, 실제로는 OCR 스캔본만 존재해 오류 다수 발생
- 이는
- OCR 결과에는 잘못된 문자 삽입, 누락, 비합법 base64 문자(예: [, ,) 등이 포함되어 디코딩 불가
OCR 및 폰트 문제
- Adobe Acrobat Pro와 tesseract를 이용한 OCR 재처리 시도 결과, 모두 공백 삽입 및 문자 인식 오류 발생
-
tesseract는 문자 집합을 base64 유효 문자로 제한했음에도 라인 길이 불일치와 부분 인식 중단 문제 발생 - 가장 큰 원인은 Courier New 폰트로,
1과l의 구분이 거의 불가능함- 낮은 해상도 JPEG 스캔과 압축 아티팩트로 인해 시각적 식별조차 어려움
- 이로 인해 수작업 교정이 필수적이며, 디코딩 시
1과l을 바꿔가며 시도해야 함
복원 시도와 도구 비교
-
imagemagick과ghostscript는 대용량 처리 중 메모리 초과로 실패,pdftoppm이 대안으로 사용됨 -
AWS Textract는 가장 나은 결과를 보였으나, 여전히 라인 길이 오차와 비결정적 결과 존재- 입력 이미지를 2배 확대하여 인식률을 높였으나 완전한 복원에는 실패
-
qpdf를 이용한 PDF 구조 복원 시도는 손상된 cross-reference 테이블로 인해 실패
커뮤니티 제안 및 후속 논의
- 글 말미에서 작성자는 다른 첨부파일 복원 시도를 커뮤니티에 제안
-
Content-Transfer-Encoding과base64검색 시 일부 유용한 데이터 존재
-
- 여러 사용자가 ML 기반 OCR, 폰트별 CNN 학습, crowdsourcing 캡차 방식 등 다양한 접근법 제시
- 일부는 PDF 복원 성공 사례를 공유하며,
pdfimages사용이pdftoppm보다 선명한 결과를 제공한다고 보고
- 일부는 PDF 복원 성공 사례를 공유하며,
- 최종적으로, 1/l 구분 자동화 알고리듬, 스트리밍 디컴프레서 기반 오류 탐지, 픽셀 단위 비교 등 고급 복원 기법이 논의됨
기술적 의의
- 이 사건은 디지털 문서 인코딩 오류와 OCR 한계가 실제 정보 접근을 어떻게 방해하는지를 보여줌
- 법적 증거물의 디지털 처리 품질 관리와 문서 포렌식 자동화 기술의 중요성을 부각
- 커뮤니티 협업을 통한 복원 시도는 공공 데이터 투명성 확보와 기술적 검증 가능성의 사례로 평가됨
Hacker News 의견들
-
Pam Bondi의 법무부 팀이 이 일에 최고의 인력을 투입하지 않은 것 같음
- 초반에 FB 요원들 간의 메시지 대화가 흥미로웠음. 혹시 일부러 엉망으로 처리해서 정보가 다시 검열되기 전에 흘러나가게 한 악의적 준수(malicious compliance) 였을지도 모른다는 생각을 함
- 인터넷이 그녀의 실수를 다 찾아주고 있어서, 오히려 크라우드소싱으로 잘 해결되고 있는 듯함. 사람들 덕분에 오류가 계속 수정되는 중임
-
Claude Opus가 만든 스크립트를 공유함
스크립트 링크 / 텍스트 출력 / 정리된 버전
첫 페이지 정도는 읽을 수 있는 PDF를 생성함- 혹시 정상화된 PDF로 다시 내보내거나 스크린샷을 공유할 수 있는지 궁금함. 내 PDF 리더들이 전부 열기를 거부함
- 450명이 참석한 공개 행사였다는 걸 확인함. Mount Sinai 기사와 Business Insider 기사에서 이름이 일치하지만 날짜가 다름
- 멋진 작업임
-
Tesseract는 특정 폰트로 학습시킬 수 있음. 이게 좋은 출발점이 될 것 같음
참고: Tesseract 학습 데이터 가이드 -
이건 이진 PDF 디코딩 문제임. 가능한 인코딩 수가 제한되어 있으므로 다음 접근을 제안함
- 오픈소스 PDF 디코더 사용
- 첫 모호한 문자 전까지 바이트 디코딩
- 다음 비트가 유효하면 1, 아니면 l로 판단
- 둘 다 유효하면 백트래킹
이렇게 하면 중간 문자만 빠르게 테스트할 수 있어 전체 탐색이 선형적으로 가능함
- 하지만 압축 단계가 중간에 있어서 백트래킹이 훨씬 많아질 수도 있음
- 이런 건 afl로 처리하는 게 어울림
-
이건 nerd snipe처럼 보이지만, 사실 브루트포스로 더 빨리 끝낼 수 있음. 76명이 한 페이지씩 타이핑하면 블로그 글이 올라오기 전에 끝남
- 한 사람이 76페이지를 다 치는 것도 가능함. 예전엔 이런 작업을 종종 했음
- 하지만 76명을 정확하게 필사하게 만드는 건 쉽지 않음
- 나한텐 76명의 친구가 없어서, Craigslist나 Fiverr에 올려야 할 듯함. 관리가 꽤 복잡할 것 같음
-
PDF가 워낙 복잡한 포맷이라, 정부가 아예 새로운 안전한 오픈 포맷을 만들어 표준화하는 게 낫다고 생각함
-
justice.gov 검색창에서 같은 이메일의 여러 버전을 찾을 수 있었음
원본: EFTA00400459.pdf
추가 버전:
EFTA02153691.pdf
EFTA02154109.pdf
EFTA02154246.pdf
여러 버전을 비교하면 더 쉽게 해결할 수 있을 듯함- 다른 base64 인코딩과 폰트를 가진 버전도 발견함: EFTA00775520.pdf.
“1”과 “l” 문제는 그대로지만 참고용으로 유용할 수 있음
- 다른 base64 인코딩과 폰트를 가진 버전도 발견함: EFTA00775520.pdf.
-
(1, l) 조합의 모든 순열을 시도하면 어떨까 생각함. 76페이지 × 69줄 × 1회 등장이라 치면 2^5244 가지 가능성임. CPU 여분 있는 사람?
- 사실 훨씬 쉬움. 각 수정이 정상적인 PDF 구조로 디코딩되는지 순차적으로 검사하면 됨.
압축이 기본이라면 체크섬 덕분에 더 쉬워짐. 다만 기존 도구로는 불가능하고, 디코더 내부에 계측된 테스트 하네스를 직접 만들어야 함 - 아니면 Epsteincoin 같은 암호화폐를 만들어, 이 문제를 푸는 데 컴퓨팅 파워를 모으면 됨
- 사실 훨씬 쉬움. 각 수정이 정상적인 PDF 구조로 디코딩되는지 순차적으로 검사하면 됨.
-
행사 세부 정보: Dubin Breast Center 2nd Annual Benefit (Archive)
- 행사 포스터에는 2012년 12월 10일 Mandarin Oriental에서 열린 Dubin Breast Center 2주년 자선행사로,
Elisa Port와 Ruttenberg 가족을 기리는 내용이 적혀 있음.
사회자는 Cynthia McFadden, 공연에는 여러 뮤지션이 참여함
- 행사 포스터에는 2012년 12월 10일 Mandarin Oriental에서 열린 Dubin Breast Center 2주년 자선행사로,
-
pdftoppm과 Ghostscript(Imagemagick을 통해 호출)는 전체 페이지를 다시 래스터화하기 때문에 느림
pdfimages나 mutool로 스캔된 이미지를 직접 추출하는 게 훨씬 빠름
테스트 결과 pdfimages가 pdftoppm보다 13배 빠름