Cronodump가 읽지 못한 CronosPro DB를 스키마 복구와 파서 수정으로 CSV 변환
- Cronodump가 CroStru.dat를 읽지 못해 테이블명과 필드 정의를 확인할 수 없었고, 작성자는 난독화된 스키마를 복구해 값이 올바른 열에 배치되는지 검증함
- CronosPro의 .dat 파일은 데이터를 담고 .tad 파일은 각 레코드의 파일 내 위치를 가리키는 디렉터리 역할을 하며, CroStru·CroBank·CroIndex가 각각 스키마·레코드·검색 인덱스를 담당함
- 기존 Cronodump는 .tad로 레코드를 찾고 압축을 풀며 KOD 테이블로 보호된 레코드를 해독한 뒤 CroStru 스키마에 따라 CroBank 바이트를 필드로 나눠 CSV·PostgreSQL SQL·HTML로 내보냄
- 작성자는 Codex로 덤프 구조를 분석하고 Cronodump의 버전별 파서 가정을 고쳐, 기존 도구가 손상됐다고 판단한 데이터베이스를 변환함
- 읽을 수 있는 문자열만 뽑는 방식은 값과 열 이름이 어긋난 채 정상처럼 보일 수 있으므로, 날짜 의미·문자 인코딩·내부 필드 위치·첨부 파일 참조까지 보존하는 CSV 변환을 목표로 함
Hacker News opinions
AI가 붙으면서 리버스 엔지니어링 작업이 늘어나는 흐름이 마음에 듦. 나도 비슷한 프로젝트를 여러 번 해봤음.
어느 수준을 넘으면 결국 재미있는 노가다인데, AI가 잘하는 종류의 노가다이기도 함.
Kafka 검색 도구에서 Avro, Schema Registry, Protobuf, ConnectJson 등을 앞부분 바이트로 판별했는데, 틀린 역직렬화기를 골라도 에러 없이 그럴듯하게 파싱되는 경우가 더 위험했음. 그래서 미리 디코딩한 샘플 10개를 보여주고 사용자가 눈으로 고르게 했음. Schema Registry는 서버마다 같은 스키마 번호 10에 다른 스키마가 있어, 잘못된 서버를 골랐다가 한참 뒤에 발견했음.
KOD 키는 어디서 나오는지 궁금함. CronosPro를 리버스 엔지니어링해서 복구할 수 있는지도 알고 싶음.