바이너리 파일 검사기

프로그램 파일 — Windows PE(.exe, .dll), Linux ELF 바이너리, 또는 macOS/iOS Mach-O — 을 드롭하고, 더 무거운 도구를 꺼내기 전에 그 파일이 스스로에 대해 선언하는 내용을 읽어보세요: 헤더, 섹션과 세그먼트, 가져오는 라이브러리와 함수, 내보내기와 심볼, 그리고 내부의 모든 인쇄 가능 문자열을 MD5 및 SHA 해시와 섹션별 엔트로피와 함께 제공합니다. 파일은 절대 기기를 떠나지 않으며 절대 실행되지 않습니다: 업로드되는 것이 아니라 이 페이지에서 열려 읽힙니다. 의심스러운 바이너리야말로 낯선 사람의 서버에 건네서는 안 되는 파일이기 때문입니다.

마지막 업데이트:

또는 파일을 이 상자 안 어디에든 드롭하세요. 아래의 모든 내용은 파일 자체에서, 이 기기에서 읽어옵니다. 정적 분석만 수행합니다: 파일은 파싱될 뿐 절대 실행되지 않습니다. 제한: 128 MB.

이 페이지가 무엇인지 — 그리고 무엇이 아닌지

이것은 첫인상 정적 검사입니다: 파일은 파싱될 뿐 절대 실행되지 않으며, 여기 있는 어떤 것도 악성코드 판정이 아닙니다. 발견 사항은 유죄 판결이 아니라 관찰입니다 — 서명되지 않은 파일은 사실입니다(많은 합법적인 도구가 서명되지 않았습니다), 엔트로피가 7.2를 넘는 것도 사실입니다(패커가 이를 높이지만, 일반적인 압축 리소스도 마찬가지입니다), 그리고 Authenticode 서명 블록이 존재한다는 것은 서명이 유효한지에 대해 아무것도 말해주지 않으며, 그저 서명이 있다는 것만 말해줍니다. 신뢰하지 않는 파일에 대한 두 번째 의견이 필요하면, 개요 탭의 조회를 이용해 그 SHA-256을 공개 판정과 비교하세요 — 검색되는 것은 해시이며, 파일 자체는 절대 전송되지 않습니다. Android 패키지에는 전용 리더인 APK Analyzer가 있으며, 프로그램이 네트워크에서 무엇을 하는지는 PCAP Analyzer의 영역입니다. 그리고 동반 기사인 AI 에이전트가 내 앱을 리버스 엔지니어링할 수 있을까?는 자동화 분석이 이제 어디까지 왔는지를 설명합니다.

프로그램 파일이 실행 전에 선언하는 것

모든 네이티브 프로그램 파일은 운영체제의 로더를 위해 작성된 의도 선언으로 시작합니다. Windows PE는 대상 머신, 빌드 타임스탬프, 로드되기를 원하는 주소, 기대하는 서브시스템을 명시합니다; 섹션 테이블은 코드, 데이터, 리소스가 어디에 있는지를 보여주고, 가져오기 테이블은 호출하려는 모든 라이브러리와 함수를 이름별로 나열하는데, 이는 닫힌 바이너리가 가질 수 있는 목차에 가장 가까운 것입니다. ELF 바이너리는 클래스, 엔디언, 머신, 이를 실행할 인터프리터, 커널이 매핑해야 하는 세그먼트, 그리고 순서대로 필요한 공유 라이브러리를 선언합니다. Mach-O는 CPU와 파일 형식, 세그먼트와 섹션, 연결하는 dylib, 빌드를 식별하는 UUID, 그리고 코드가 서명되었는지 FairPlay로 암호화되었는지를 선언합니다. 이 중 어느 것도 파일을 실행하거나, 파일을 신뢰하거나, 파일을 업로드할 필요가 없습니다 — 모두 로더 자체가 읽을 헤더 안에 있습니다.

이 페이지는 바로 그 층을 읽으며, 의도적으로 첫 번째 층만 읽습니다. 어떤 것도 디컴파일하지 않고, 어떤 것도 언패킹하지 않으며, 코드가 무엇을 하는지 알려주지 않습니다 — 그것은 Ghidra, IDA, 그리고 동반 기사가 살펴보는 에이전트 기반 도구 체인의 몫입니다. 첫인상의 목적은 분류입니다: 예상한 아키텍처인지, 서명되었는지, 네이티브 복장을 한 .NET 어셈블리인지, 한 섹션이 의심스러울 정도로 밀도 높은 데이터를 담고 있는지, 가져오기 목록에 프로그램이 호출해서는 안 될 라이브러리가 있는지, 그리고 보내온 파일이 다른 모든 사람이 받은 파일과 같은지 — 마지막 질문에는 해시가 단번에 답합니다(그리고 해시 생성기가 텍스트나 더 작은 파일에 대해 교차 확인합니다). 로컬에서 읽는 5분의 헤더가 무거운 도구를 설치하기도 전에 이 질문 대부분에 답합니다.

자주 묻는 질문

내 파일이 어딘가에 업로드되나요?

아니요. 파일은 이 페이지에서, 사용자의 기기에서 열려 파싱되며, 어떤 것도 업로드, 전송, 저장되지 않습니다 — 파일을 분석해도 네트워크 요청이 발생하지 않습니다. 페이지의 유일한 외부 링크는 VirusTotal 조회이며, 이는 파일의 SHA-256 해시를 텍스트로 검색합니다; 파일 자체는 절대 전송되지 않습니다. 페이지는 로드된 후 오프라인에서도 작동합니다.

이것으로 파일이 악성코드인지 알 수 있나요?

아니요, 그리고 그렇게 약속하는 헤더 리더는 과장하고 있는 것입니다. 이 페이지는 파일이 선언하는 것 — 형식, 아키텍처, 섹션, 가져오기, 내보내기, 문자열, 서명 존재 여부 — 을 보고하며, 이는 부주의한 경우를 잡아내기에 충분합니다: 실제로는 32비트 실행 파일인 “송장”, 불가능할 정도로 밀도 높은 섹션이 하나 있는 빌드, 해시가 공급업체가 게시한 어떤 것과도 일치하지 않는 서명되지 않은 업데이터 등입니다. 코드가 실제로 무엇을 하는지를 판단하려면 디컴파일, 샌드박스 실행, 또는 평판 있는 스캐너의 판정이 필요합니다. 여기서 깨끗해 보이는 결과는 “헤더에서 잘못돼 보이는 것이 없다”로 받아들이세요, 절대 안전 인증서로 여기지 마세요.

엔트로피란 무엇이며, 왜 7.2가 기준인가요?

섀넌 엔트로피는 바이트 구간이 얼마나 무작위적으로 보이는지를 0(모두 같은 바이트)부터 8(무작위와 구별할 수 없음)까지 측정합니다. 일반적인 컴파일된 코드와 텍스트는 7보다 훨씬 아래에 있습니다; 압축된 데이터는 8에 가깝고, 암호화된 데이터는 사실상 8입니다. 패커는 프로그램의 실제 코드를 압축하거나 암호화하므로, 대략 7.2를 넘는 섹션은 “여기 무언가가 압축됐다”는 표준 분류 신호입니다 — 하지만 설치 프로그램, 압축 리소스, 내장 미디어, 최신 런타임도 완전히 합법적인 파일에서 고엔트로피 섹션을 만들어냅니다. 이는 결론이 아니라 더 자세히 살펴볼 이유입니다.

내 파일은 왜 구조가 거의 표시되지 않나요?

페이지가 파일이 실제로 선언하는 것을 보고하는데, 어떤 파일은 선언하는 것이 매우 적기 때문입니다. 스트립된 ELF는 섹션 헤더 테이블이 전혀 없을 수 있습니다(세그먼트만 존재); 수작업으로 만들거나 잘린 파일은 헤더가 약속하는 구조보다 먼저 끝날 수 있는데 — 그 경우 참고 사항이 정확히 그렇게 말해주며, 표시되는 모든 것은 여전히 존재하는 바이트에서 읽어온 것입니다. 그리고 일부 형식은 심층 파서의 범위를 단순히 벗어납니다: 이름으로 식별되고(ZIP, PDF, 이미지 등), 지어낸 세부 사항 없이 일반적인 사실 — 크기, 해시, 엔트로피, 문자열 — 을 얻습니다.