R-Studio에 대해 알려진 사용자 정의 파일 형식을 만듭니다. 서명으로 파일 형식 결정 파일 서명이란 무엇입니까?
개념 " 매직넘버"프로그래밍에는 세 가지 의미가 있습니다.
- 데이터 서명
- 선택된 고유한 값, 다른 값(예: UUID)과 동일해서는 안 됩니다.
- 나쁜 프로그래밍 습관.
데이터 서명
매직넘버, 또는 서명, - 리소스나 데이터를 고유하게 식별하는 데 사용되는 정수 또는 텍스트 상수입니다. 이러한 숫자 자체는 아무런 의미가 없으며 적절한 컨텍스트나 주석 없이 프로그램 코드에 나타나면 혼란을 야기할 수 있습니다. 반면에 값이 가까운 숫자라도 다른 숫자로 변경하려고 하면 완전히 예측할 수 없는 결과를 초래할 수 있습니다. 이러한 이유로 이러한 숫자를 아이러니하게도 매직 넘버라고 불렀습니다. 현재 이 이름은 용어로 확고히 자리 잡았습니다. 예를 들어, 컴파일된 Java 언어 클래스는 16진수 "매직 넘버" 0xCAFEBABE로 시작합니다. 널리 알려진 두 번째 예는 다음과 같습니다. 실행 가능 파일 OS 마이크로소프트 윈도우확장자가 .exe인 경우 바이트 시퀀스 0x4D5A(MS-DOS 창시자 중 한 명인 Mark Zbikowski의 이니셜인 ASCII 문자 MZ에 해당)로 시작됩니다. 덜 알려진 예는 디버그 모드에서 주소가 0xDEADBEEF인 Microsoft Visual C++(Microsoft Visual Studio 2005 버전 이후)의 초기화되지 않은 포인터입니다.
유닉스 계열에서는 운영체제파일 형식은 일반적으로 이름 확장자에 관계없이 파일 서명에 따라 결정됩니다. 파일 서명을 해석하는 표준 파일 유틸리티를 제공합니다.
잘못된 프로그래밍 습관
"마법의 숫자"라고도 불리는 것은 소스 텍스트에 숫자 값이 있고 그 의미가 분명하지 않은 경우 잘못된 프로그래밍 관행입니다. 예를 들어, Java로 작성된 다음과 같은 코드 조각은 좋지 않습니다.
drawSprite(53, 320, 240);
최종 int SCREEN_WIDTH = 640; 최종 int SCREEN_HEIGHT = 480 ; 최종 int SCREEN_X_CENTER = SCREEN_WIDTH/2; 최종 int SCREEN_Y_CENTER = SCREEN_HEIGHT / 2; 최종 int SPRITE_CROSSHAIR = 53 ; ... drawSprite(SPRITE_CROSSHAIR, SCREEN_X_CENTER, SCREEN_Y_CENTER);
이제 명확해졌습니다. 이 선은 화면 중앙에 스프라이트(조준경의 십자선)를 표시합니다. 대부분의 프로그래밍 언어에서 이러한 상수에 사용되는 모든 값은 컴파일 타임에 계산되어 값이 사용되는 위치로 대체됩니다. 따라서 소스 텍스트의 이러한 변경은 프로그램 성능을 저하시키지 않습니다.
또한 매직 넘버는 프로그램 오류의 잠재적인 원인입니다.
- 동일한 매직 넘버가 프로그램에서 두 번 이상 사용되거나 잠재적으로 사용될 수 있는 경우 이를 변경하려면 명명된 상수 값을 한 번만 편집하는 대신 각 항목에 대한 편집이 필요합니다. 모든 발생 사항이 수정되지 않은 경우 적어도 하나의 오류가 발생합니다.
- 적어도 한 번은 매직 넘버의 철자가 처음에 잘못되었을 수 있으며 이는 감지하기가 매우 어렵습니다.
- 매직 넘버는 암시적 매개변수나 다른 매직 넘버에 따라 달라질 수 있습니다. 명시적으로 식별되지 않은 이러한 종속성이 충족되지 않으면 적어도 하나의 오류가 발생합니다.
- 하나의 매직 넘버 발생을 수정할 때, 독립적이지만 동일한 수치를 갖는 다른 매직 넘버를 실수로 변경하는 것이 가능합니다.
매직 넘버와 크로스 플랫폼
때때로 매직 넘버가 크로스 플랫폼 코드에 해를 끼치는 경우가 있습니다. 사실 C의 32비트 및 64비트 운영 체제에서는 char , short 및 long long 유형의 크기가 보장되는 반면 int , long , size_t 및 ptrdiff_t 의 크기는 변경될 수 있습니다(처음 두 개의 경우, 컴파일러 개발자의 선호도에 따라 마지막 두 개는 대상 시스템의 비트 용량에 따라 다름). 오래되었거나 잘못 작성된 코드에는 유형의 크기를 나타내는 "마법의 숫자"가 있을 수 있습니다. 비트 용량이 다른 시스템으로 이동할 때 미묘한 오류가 발생할 수 있습니다.
예를 들어:
const size_t NUMBER_OF_ELEMENTS = 10; 오랫동안[NUMBER_OF_ELEMENTS]; memset(a, 0, 10 * 4); // 부정확함 - long은 4바이트로 가정되고, 매직 개수의 요소가 사용됩니다. memset(a, 0, NUMBER_OF_ELEMENTS * 4); // 부정확함 - long은 4바이트로 가정됩니다. memset(a, 0, NUMBER_OF_ELEMENTS * sizeof(long)); // 완전히 정확하지 않음 - 유형 이름이 중복됨(유형이 변경되면 여기에서도 변경해야 함) memset (a , 0 , NUMBER_OF_ELEMENTS * sizeof (a [ 0 ])); // 정확하고 0이 아닌 크기의 동적 배열에 최적입니다. memset(a, 0, sizeof(a)); // 정확합니다. 정적 배열에 최적입니다.
마법이 아닌 숫자
모든 숫자를 상수로 변환할 필요는 없습니다. 예를 들어,
알려진 유형의 파일을 스캔하여 검색(또는 종종 서명으로 파일 검색)은 R-Studio 데이터 복구 유틸리티에서 사용되는 가장 효과적인 검색 중 하나입니다. 특정 서명을 사용하면 디렉터리 구조 및 파일 이름에 대한 정보가 부분적으로 또는 완전히 누락된(손상된) 경우 특정 유형의 파일을 복원할 수 있습니다.
일반적으로 디스크 파티션 테이블은 파일 위치를 결정하는 데 사용됩니다. 디스크를 책과 비교하면 파티션 테이블은 목차와 유사합니다. 스캔할 때 R-Studio는 지정된 특정 서명을 사용하여 디스크 파티션 테이블에서 알려진 파일 형식을 검색합니다. 이는 사실상 모든 파일 유형에 고유한 서명이나 데이터 패턴이 있다는 사실로 인해 가능합니다. 파일 서명은 파일 시작 부분의 특정 위치에서 발견되며 대부분의 경우 파일 끝에서도 발견됩니다. 스캔할 때 R-Studio는 발견된 데이터를 알려진 파일 형식의 서명과 일치시켜 이를 식별하고 데이터를 복구할 수 있습니다.
알려진 파일 형식을 검색하는 기술을 사용하여 R-Studio를 사용하면 다시 포맷되고 파티션 테이블을 덮어쓴 디스크에서 데이터를 복구할 수 있습니다. 또한 디스크 파티션이 덮어쓰여지거나 손상되거나 삭제된 경우 알려진 파일 형식을 검색하는 것이 유일한 옵션입니다.
그러나 거의 모든 것에는 단점이 있으며 R-Studio에서 사용되는 알려진 파일 형식도 예외는 아닙니다. 따라서 알려진 파일 형식을 검색할 때 R-Studio를 사용하면 조각화되지 않은 파일만 복구할 수 있지만 이미 언급했듯이 대부분의 경우 이것이 가능한 최신 방법입니다.
R-Studio에는 이미 가장 일반적인 파일 형식의 서명이 포함되어 있습니다(보기 전체 목록알려진 유형의 파일은 R-Studio 온라인 도움말 섹션에서 찾을 수 있습니다.)
필요한 경우 사용자는 R-Studio에 새 파일 형식을 추가할 수 있습니다. 예를 들어, 고유한 유형의 파일이나 R-Studio의 마지막 릴리스 날짜 이후에 개발된 파일을 찾아야 하는 경우 알려진 유형의 파일에 고유한 서명을 추가할 수 있습니다. 이 과정은 다음에 논의될 것이다.
알려진 유형의 사용자 정의 파일
알려진 파일 형식의 사용자 정의 파일 서명은 다음 위치에 저장됩니다. XML 파일 e는 설정 대화 상자에서 지정됩니다. 서명 추가는 두 부분으로 구성됩니다.
- 파일의 시작 부분과 파일의 끝 부분에 있는 파일 서명을 결정합니다.
- 파일 서명과 파일 형식에 대한 기타 정보가 포함된 XML 파일을 생성합니다.
이 모든 작업은 R-Studio를 사용하여 수행할 수 있습니다. 동시에 XML 문서 작성(편집) 분야나 16진수 편집 분야의 전문가일 필요는 없습니다. 이 가이드(기사)에서는 사용자 자신을 대상으로 합니다. 입문 단계, 이 프로세스의 모든 단계에 대해 자세히 논의합니다.
예: MP4 파일에 대한 서명 추가(XDCam-EX 코덱)
Sony XDCAM-EX를 사용하여 생성된 .MP4 파일의 예를 사용하여 파일 서명을 추가하는 방법을 살펴보겠습니다. 예를 들어, 아직 컴퓨터 하드 드라이브에 저장하지 못한 파일의 SD 카드가 손상된 경우 이 기능을 사용할 수 있습니다.
첫 번째 단계: 파일 서명 결정
파일 서명을 결정하려면 동일한 형식의 파일 예를 고려하십시오.
Sony XDCAM-EX의 비디오 파일 4개는 다음과 같습니다.
ZRV-3364_01.MP4
ZRV-3365_01.MP4
ZRV-3366_01.MP4
ZRV-3367_01.MP4
고려하기 쉽도록 작은 파일로 둡니다. 큰 파일은 16진수로 보기가 더 어렵습니다.
1. R-Studio에서 파일을 엽니다. 이렇게 하려면 각 파일을 마우스 오른쪽 버튼으로 클릭하고 상황에 맞는 메뉴에서 보기/편집을 선택합니다.
2. 파일을 비교해 보겠습니다. 우리는 네 개의 파일 모두에서 동일한 패턴을 찾을 것입니다. 그가 나타날 것이다 파일 서명. 일반적으로 파일 서명은 파일 시작 부분에 있지만 때로는 끝 부분에 있습니다.
3. 파일 시작 부분에 파일 서명을 정의합니다. 이 예에서는 파일의 맨 처음에 위치합니다. 이것이 항상 발생하는 것은 아닙니다. 파일 서명이 파일의 시작 부분에 있지만 첫 번째 줄(오프셋)에는 없는 경우가 많습니다.
아래 이미지를 보면 4개 파일의 내용이 모두 다른 것처럼 보이지만 모두 동일한 파일 서명으로 시작합니다. 
확대하려면 이미지를 클릭하세요.
확대하려면 이미지를 클릭하세요.
확대하려면 이미지를 클릭하세요.
확대하려면 이미지를 클릭하세요.
이미지에서 강조 표시된 부분은 파일 서명입니다. 이런 유형의파일. 텍스트와 16진수 형식으로 모두 표시됩니다.
텍스트 형식의 파일 서명은 다음과 같습니다.
....ftypmp42....mp42........무료
점(“.”)은 텍스트 형태로 표현할 수 없는 문자를 나타냅니다. 따라서 파일 서명의 16진수 형식도 제공해야 합니다.
00 00 00 18 66 74 79 6D 70 34 32 00 00 00 00 6D 70 34 32 00 00 00 00 00 00 00 08 66 72 65 65
4. 같은 방식으로 파일 서명을 정의하지만 파일 맨 끝에 있습니다. 다른 파일 서명, 다른 길이일 수 있습니다.
아래 이미지는 파일 끝에 있는 파일 서명을 강조 표시합니다. 
확대하려면 이미지를 클릭하세요.
확대하려면 이미지를 클릭하세요.
확대하려면 이미지를 클릭하세요.
확대하려면 이미지를 클릭하세요.
선택한 영역(파일 서명) 이전의 데이터는 4개 파일 모두 동일하므로 주의하시기 바랍니다. 이는 파일 시그니처는 아니지만, 4장의 사진(파일)이 모두 동일한 카메라를 사용하여 동일한 매개변수로 촬영되었음을 나타내는 기술 정보입니다. 일반적으로 파일 서명을 통해 기술 정보와 일치하는 패턴을 구별하는 것이 가능합니다. 이 예에서는 파일 서명 시작 전 마지막 줄에 'RecordingMode type="normal"' 텍스트가 표시되는데, 이는 이것이 서명이 아닌 일종의 파일 매개변수임을 분명히 나타냅니다. 실수로 포함되지 않도록 항상 이 줄에 특별한 주의를 기울이십시오. 기술적 인 정보파일 서명의 일부입니다.
우리의 경우 파일 서명은 다음 텍스트입니다.
...
점은 텍스트 형식으로 표현할 수 없는 문자를 나타냅니다.
16진수에서 파일 서명은 다음과 같습니다.
3N 2F 4E 6F 6E 52 65 61 6N 54 69 6A 65 4A 65 74 61 3E 0D 0A 00
참고: 서명이 항상 파일 끝에 있는 것은 아닙니다.
두 번째 단계: 알려진 파일 형식을 설명하는 XML 파일 만들기
이제 파일 서명을 정의한 후 XML 파일을 생성하고 R-Studio에 해당 파일 형식을 포함할 수 있습니다. 이 작업은 두 가지 방법으로 수행할 수 있습니다.
2.1 내장 사용하기 그래픽 편집기파일 서명:
도구 메뉴에서 설정 항목을 선택하고, 열리는 설정 대화 상자에서 알려진 파일 형식 탭을 클릭한 다음 사용자 파일 형식 편집 버튼을 클릭합니다. 
확대하려면 이미지를 클릭하세요.
사용자 파일 형식 편집 대화 상자에서 파일 형식 만들기 버튼을 클릭합니다.
다음 옵션을 설정합니다.
- Id - 고유한 디지털 식별자입니다. 이 번호무작위로 선택됩니다. 유일한 점은 다른 파일 형식의 디지털 식별자와 일치해서는 안 된다는 것입니다.
- 그룹 설명 - 발견된 파일이 R-Studio에 위치하게 될 그룹입니다. 다음 중 하나를 설정할 수 있습니다. 새 그룹, 또는 이미 존재하는 것 중 하나를 선택하십시오. 우리에게는 이것이 "멀티미디어 비디오(멀티미디어: 비디오)" 그룹이 될 것입니다.
- 설명 - 간단한 설명파일 유형. 이 예에서는 "Sony cam video, XDCam-EX" 등을 사용할 수 있습니다.
- 확장자 - 이 유형의 파일 확장자입니다. 우리의 경우 - mp4.
기능 매개변수는 선택사항이므로 우리의 경우에는 이를 사용할 필요가 없습니다. 
확대하려면 이미지를 클릭하세요.
다음으로 시작 및 끝 파일 서명을 입력해야 합니다. 이렇게 하려면 시작을 선택한 다음 상황에 맞는 메뉴서명 추가 명령. 
확대하려면 이미지를 클릭하세요.
그런 다음 해당 필드를 두 번 클릭하세요.<пустая сигнатура> (
확대하려면 이미지를 클릭하세요.
그런 다음 최종 파일 서명을 만듭니다. From 열에 21을 입력해야 합니다. 
확대하려면 이미지를 클릭하세요.
알려진 파일 형식에 대한 고유한 서명을 성공적으로 만들었습니다.
이제 저장해야 합니다. 두 가지 방법이 있습니다. 저장 버튼을 클릭하여 설정 대화 상자의 기본 탭에 지정된 기본 파일에 저장할 수 있습니다. 또는 다른 이름으로 저장... 버튼을 클릭하고 서명을 다른 파일에 저장하세요.
2.2 알려진 파일 형식을 설명하는 XML 파일을 수동으로 생성:
생성을 위해 이 파일 XML 버전 1.0과 UTF-8 인코딩을 사용해 보겠습니다. 그것이 무엇인지 모르더라도 절망하지 마세요. 그냥 아무거나 열어보세요. 텍스트 에디터(예: Notepad.exe) 첫 번째 줄에 다음 텍스트를 입력합니다.
다음으로 파일 형식(FileType)을 정의하는 XML 태그를 만듭니다. 이전에 설명한 XML 속성을 고려하면 태그는 다음과 같습니다.
바로 뒤에 삽입하자
다음으로 파일 서명(태그
있는 경우 끝 서명(파일 끝에)도 정의해야 합니다. 이는 동일한 태그를 사용하지만 "from" 요소와 "end" 속성을 사용합니다. 다음과 같이 보일 것입니다:
최종 파일 서명에는 텍스트가 아닌 문자가 포함되지 않았지만 슬래시와 대괄호가 포함되어 있다는 점을 기억하십시오. XML 구문의 혼란과 오류를 피하기 위해 서명에서 문자 "/", "를 대체합니다.<" и ">" 16진수 값입니다.
마지막에는 파일 서명 뒤에 FileType 및 FileTypeList 닫는 태그가 있어야 합니다.
따라서 전체 파일은 다음과 같아야 합니다.
기억하세요: XML 구문은 대소문자를 구분하므로 올바른 태그는 다음과 같습니다.
확장자가 .xml인 텍스트 형식으로 파일을 저장해 보겠습니다. 예: SonyCam.xml.
알려진 파일 형식에 대한 자체 서명을 성공적으로 만들었습니다. 이 예는 사용자 정의 파일 유형을 생성하는 기본 원칙을 이해하기에 충분합니다. 경험이 많은 사용자는 XML 버전 2.0을 사용할 수 있습니다. R-Studio 온라인 도움말 섹션에서 이에 대한 자세한 내용을 읽을 수 있습니다.
3단계: 알려진 파일 형식을 설명하는 파일 확인 및 추가
다음 단계는 XML 파일을 R-Studio에 추가(업로드)하는 것입니다. 이 경우 자동으로 확인됩니다.
이전 단계에서 생성된 XML 파일을 R-Studio로 로드해 보겠습니다. 이렇게 하려면 도구 메뉴에서 설정 항목을 선택하세요. 설정 대화 상자의 메인 탭에 있는 사용자 파일 형식 영역에 우리가 만든 XML 파일(SonyCam.xml)을 추가합니다. 적용 버튼을 클릭하세요. 
확대하려면 이미지를 클릭하세요.
2. 새 파일 형식을 다운로드하라는 요청에 예라고 대답합니다. 
확대하려면 이미지를 클릭하세요.
3. 파일 형식이 성공적으로 로드되었는지 확인하려면 설정 대화 상자의 알려진 파일 형식 탭을 클릭합니다. 멀티미디어 비디오 그룹(멀티미디어: 비디오)에 파일 유형을 추가했음을 기억하십시오. 이 그룹(폴더)을 확장하면 XML 파일을 생성할 때 지정한 설명이 포함된 요소(Sony cam video, XDCam-EX(.mp4))가 표시됩니다. 
확대하려면 이미지를 클릭하세요.
확대하려면 이미지를 클릭하세요.
파일 구문에 오류가 있으면 해당 메시지가 표시됩니다. 
확대하려면 이미지를 클릭하세요.
이 경우 XML 파일에 오류가 있는지 다시 확인하세요. 기억하세요: XML 구문은 대소문자를 구분하며 모든 태그의 끝에는 닫는 태그가 있어야 합니다.
4단계: 알려진 파일 형식을 설명하는 파일 테스트
우리가 만든 사용자 정의 파일 형식이 올바른지 확인하기 위해 이동식 USB 플래시 드라이브에서 .mp4 파일을 찾아보겠습니다.
1. Windows Vista 또는 Windows 7에서는 디스크 전체(빠르지 않음) 포맷을 수행하거나 디스크 공간 정리 유틸리티(예: R-Wipe & Clean)를 사용하여 다음을 수행합니다. 완전한 제거디스크에서 사용 가능한 모든 데이터. 허락하다 USB 디스크 FAT32로 포맷되었습니다(검색된 파일의 크기는 2GB를 초과하지 않습니다).
2. 복사해보자 테스트 파일캐시 메모리의 내용이 디스크에 저장되도록 컴퓨터를 디스크로 저장하고 컴퓨터를 재부팅합니다. 비활성화할 수도 있습니다. 외장 드라이브그런 다음 다시 연결하세요.
3. OS에서 드라이브는 예를 들어 논리 드라이브 F:\로 정의됩니다.
4. R-Studio를 시작하겠습니다. 드라이브(F:\)를 선택하고 스캔 버튼을 클릭하세요. 
확대하려면 이미지를 클릭하세요.
5. 스캔 대화 상자의 (파일 시스템) 영역에서 변경... 버튼을 클릭하고 모든 상자를 선택 취소합니다. 이렇게 하면 파티션 테이블을 사용하여 파일 시스템 및 파일 검색을 비활성화합니다. 
확대하려면 이미지를 클릭하세요.
6. 알려진 파일 형식에 대한 추가 검색 확인란을 선택합니다. 이렇게 하면 R-Studio가 스캔 시 알려진 파일 형식을 검색할 수 있습니다.
7. 스캔을 시작하려면 스캔 버튼을 클릭합니다.
8. R-Studio가 디스크를 검색하는 동안 기다려 보겠습니다. 스캔 정보 탭에는 스캔 진행률(진행률)이 표시됩니다. 
확대하려면 이미지를 클릭하세요.
9. 스캔이 완료되면 추가 발견 파일 요소를 선택하고 두 번 클릭합니다. 
확대하려면 이미지를 클릭하세요.
10. 테스트 파일은 Sony cam video, XDCam-EX 폴더(또는 두 번째 단계에서 지정한 파일 유형 설명에 해당하는 다른 이름의 폴더)에 위치합니다. 
확대하려면 이미지를 클릭하세요.
파일 이름, 날짜 및 위치(폴더)가 다음과 같은 이유로 복원되지 않은 것을 확인할 수 있습니다. 이 정보파일 시스템에 저장됩니다. 따라서 R-Studio는 자동으로 각 파일을 새 이름으로 표시합니다.
그러나 파일의 내용이 손상되지 않은 것은 분명합니다. 이를 확인하기 위해 VLC 미디어 플레이어와 같은 적절한 프로그램에서 열어 보겠습니다. 
확대하려면 이미지를 클릭하세요.
결론
알려진 파일 형식을 검색하는 R-Studio의 기능을 사용하면 파일 시스템을 덮어쓴 디스크에서도 데이터를 복구할 수 있습니다. 서명을 사용하면 매우 효과적으로 파일을 검색할 수 있습니다. 이는 예에서와 같이 복원되는 파일 유형을 정확히 알고 있는 경우 특히 유용합니다. 사용자 정의 파일 형식을 생성하는 기능을 사용하면 특정 파일 서명이 있는 모든 파일을 알려진 파일 형식 목록에 추가할 수 있습니다.
많은 사람들이 rarjpeg와 같은 파일에 대해 들어봤을 것입니다. 이것은 jpeg 이미지와 rar 아카이브가 서로 밀접하게 붙어 있는 특별한 유형의 파일입니다. 정보 전송 사실을 숨기는 데 탁월한 컨테이너입니다. 다음을 사용하여 rarjpeg를 만들 수 있습니다. 다음 명령:
유닉스: 고양이 image1.jpg archive.rar > image2.jpg
윈도우: 복사 /b image1.jpg+archive.rar image2.jpg
아니면 16진수 편집기가 있는 경우.
물론 정보 전송 사실을 숨기기 위해 JPEG 형식뿐만 아니라 다른 형식도 사용할 수 있습니다. 각 형식에는 고유한 특성이 있으므로 컨테이너 역할에 적합할 수도 있고 적합하지 않을 수도 있습니다. 가장 널리 사용되는 형식으로 붙여넣은 파일을 찾는 방법이나 접착 사실을 표시하는 방법을 설명하겠습니다.
병합된 파일을 검색하는 방법은 세 그룹으로 나눌 수 있습니다.
- EOF 마커 이후 영역을 확인하는 방법. 많이 사용되는 파일 형식에는 원하는 데이터를 표시하는 파일 끝 표시가 있습니다. 예를 들어, 사진 뷰어는 이 마커까지의 모든 바이트를 읽지만 그 뒤의 영역은 무시됩니다. 이 방법은 JPEG, PNG, GIF, ZIP, RAR, PDF 형식에 이상적입니다.
- 파일 크기를 확인하는 방법. 일부 형식(오디오 및 비디오 컨테이너)의 구조를 통해 실제 파일 크기를 계산하고 이를 원본 크기와 비교할 수 있습니다. 형식: AVI, WAV, MP4, MOV.
- CFB 파일을 확인하는 방법. CFB(Compound File Binary Format)는 Microsoft에서 개발한 문서 형식으로 자체 파일 시스템을 갖춘 컨테이너입니다. 이 방법은 파일의 이상 징후를 탐지하는 데 기반을 둡니다.
파일이 끝난 후에도 수명이 있습니까?
JPEG
이 질문에 대한 답을 찾으려면 병합된 파일의 "조상"인 형식의 사양을 자세히 살펴보고 그 구조를 이해해야 합니다. 모든 JPEG는 서명 0xFF 0xD8로 시작합니다.이 서명 뒤에는 서비스 정보, 선택적으로 이미지 아이콘, 마지막으로 압축된 이미지 자체가 있습니다. 이 형식에서는 이미지 끝 부분에 2바이트 서명 0xFF 0xD9가 표시됩니다.
PNG
PNG 파일의 처음 8바이트는 0x89, 0x50, 0x4E, 0x47, 0x0D, 0x0A, 0x1A, 0x0A 서명으로 채워집니다. 데이터 스트림을 종료하는 종료 서명: 0x49, 0x45, 0x4E, 0x44, 0xAE, 0x42, 0x60, 0x82.RAR
모든 rar 아카이브의 공통 서명: 0x52 0x61 0x72 0x21 (Rar!). 그 다음에는 아카이브 버전 및 기타 관련 데이터에 대한 정보가 제공됩니다. 아카이브가 0x0A, 0x25, 0x25, 0x45, 0x4F, 0x46 서명으로 끝나는 것으로 실험적으로 확인되었습니다.형식 및 서명 표:
이러한 형식의 접착을 확인하는 알고리즘은 매우 간단합니다.
- 초기 서명을 찾으십시오.
- 최종 서명을 찾으세요.
- 최종 서명 후 데이터가 없으면 파일이 깨끗하고 첨부 파일이 포함되어 있지 않은 것입니다! 그렇지 않으면 최종 서명 후 다른 형식을 찾아야 합니다.
GIF 및 PDF
예를 들어 잘못된 문서 생성으로 인해 PDF 문서에 둘 이상의 EOF 마커가 있을 수 있습니다. GIF 파일의 최종 서명 수는 파일의 프레임 수와 같습니다. 이러한 형식의 특징을 기반으로 첨부 파일 존재 여부를 확인하는 알고리즘을 개선하는 것이 가능합니다.- 포인트 1은 이전 알고리즘에서 반복됩니다.
- 포인트 2는 이전 알고리즘에서 반복됩니다.
- 최종 서명을 찾으면 해당 위치를 기억하고 자세히 살펴보세요.
- 이런 방식으로 마지막 EOF 마커에 도달하면 파일이 깨끗해집니다.
- 파일이 끝 서명으로 끝나지 않으면 goto는 발견된 마지막 끝 서명의 위치입니다.
지퍼
ZIP 아카이브의 특징은 세 가지 다른 서명이 있다는 것입니다. 아카이브의 구조는 다음과 같습니다.| 로컬 파일 헤더 1 |
| 파일 데이터 1 |
| 데이터 설명자 1 |
| 로컬 파일 헤더 2 |
| 파일 데이터 2 |
| 데이터 설명자 2 |
| ... |
| 로컬 파일 헤더 |
| 파일 데이터 n |
| 데이터 설명자 n |
| 아카이브 암호 해독 헤더 |
| 추가 데이터 기록 보관 |
| 중앙 디렉토리 |
ZIP 아카이브를 확인하려면 중앙 디렉터리의 끝 서명을 찾고 18바이트를 건너뛰고 주석 영역에서 알려진 형식의 서명을 찾아야 합니다. 큰 사이즈이 의견은 또한 접착 사실을 나타냅니다.
크기가 중요하다
AVI
AVI 파일의 구조는 다음과 같습니다. 각 파일은 RIFF 서명(0x52 0x49 0x46 0x46)으로 시작됩니다. 바이트 8에는 형식(0x41 0x56 0x49 0x20)을 지정하는 AVI 서명이 있습니다. 4바이트로 구성된 오프셋 4의 블록에는 데이터 블록의 초기 크기(바이트 순서 - 리틀 엔디안)가 포함됩니다. 다음 크기가 포함된 블록 번호를 찾으려면 헤더 크기(8바이트)와 4~8바이트 블록에서 얻은 크기를 추가해야 합니다. 총 파일 크기를 계산합니다. 계산된 크기가 실제 파일 크기보다 작을 수 있습니다. 계산된 크기 이후 파일에는 0바이트만 포함됩니다(1Kb 경계를 정렬하는 데 필요함).크기 계산의 예:
WAV
AVI와 마찬가지로 WAV 파일은 RIFF 서명으로 시작하지만 이 파일은 바이트 8 - WAVE(0x57 0x41 0x56 0x45)의 서명을 갖습니다. 파일 크기는 AVI와 동일한 방식으로 계산됩니다. 실제 크기는 계산된 크기와 완전히 일치해야 합니다.MP4
MP4 또는 MPEG-4는 비디오 및 오디오 스트림을 저장하는 데 사용되는 미디어 컨테이너 형식이며 자막 및 이미지 저장 기능도 제공합니다.오프셋 4바이트에는 파일 유형 ftyp(66 74 79 70)(QuickTime 컨테이너 파일 유형) 및 파일 하위 유형 mmp4(6D 6D 70 34)라는 서명이 있습니다. 인정을 위해 숨겨진 파일, 우리는 파일 크기를 계산하는 기능에 관심이 있습니다.
예를 살펴보겠습니다. 첫 번째 블록의 크기는 오프셋 0에 있으며 28(00 00 00 1C, Big Endian 바이트 순서)입니다. 또한 두 번째 데이터 블록의 크기가 위치한 오프셋을 나타냅니다. 오프셋 28에서 다음 블록 크기는 8(00 00 00 08)입니다. 다음 블록 크기를 찾으려면 이전에 발견된 블록의 크기를 더해야 합니다. 따라서 파일 크기는 다음과 같이 계산됩니다.
MOV
널리 사용되는 이 형식은 MPEG-4 컨테이너이기도 합니다. MOV는 독점적인 데이터 압축 알고리즘을 사용하고 MP4와 유사한 구조를 가지며 오디오 및 비디오 데이터와 관련 자료를 저장하는 데 동일한 목적으로 사용됩니다.MP4와 마찬가지로 모든 mov 파일에는 오프셋 4에 4바이트 ftyp 서명이 있지만 다음 서명의 값은 qt__(71 74 20 20)입니다. 파일 크기 계산 규칙은 변경되지 않았습니다. 파일 시작 부분부터 시작하여 다음 블록의 크기를 계산하여 합산합니다.
이 형식 그룹에서 "고정" 파일이 있는지 확인하는 방법은 위에 제공된 규칙에 따라 크기를 계산하고 이를 확인 중인 파일 크기와 비교하는 것입니다. 현재 파일 크기가 계산된 파일 크기보다 훨씬 작은 경우 이는 접착 사실을 나타냅니다. AVI 파일을 확인할 때 테두리 정렬을 위해 추가된 0이 있기 때문에 계산된 크기가 파일 크기보다 작을 수 있다는 것이 허용됩니다. 이 경우 계산된 파일 크기 뒤에 0이 있는지 확인해야 합니다.
복합 파일 바이너리 형식 확인
Microsoft에서 개발한 이 파일 형식은 OLE(Object Linking and Embedding) 또는 COM(Component Object Model)이라고도 합니다. DOC, XLS, PPT 파일은 CFB 형식 그룹에 속합니다.CFB 파일은 512바이트 헤더와 데이터 스트림 또는 서비스 정보를 저장하는 동일한 길이의 섹터로 구성됩니다. 각 섹터에는 특수 번호를 제외하고 음수가 아닌 고유한 숫자가 있습니다. "-1" - 사용 가능한 섹터 번호, "-2" - 체인을 닫는 섹터 번호입니다. 모든 섹터 체인은 FAT 테이블에 정의되어 있습니다.
공격자가 특정 .doc 파일을 수정하고 그 끝에 다른 파일을 붙여넣었다고 가정해 보겠습니다. 몇 가지가 있습니다 다양한 방법으로이를 감지하거나 문서에서 이상 징후를 나타냅니다.
비정상적인 파일 크기
위에서 언급했듯이 모든 CFB 파일은 동일한 길이의 헤더와 섹터로 구성됩니다. 섹터 크기를 알아내려면 파일 시작 부분의 오프셋 30에서 2바이트 숫자를 읽고 2를 이 숫자만큼 거듭제곱해야 합니다. 이 숫자는 각각 9(0x0009) 또는 12(0x000C)와 같아야 하며 파일 섹터 크기는 512 또는 4096바이트입니다. 섹터를 찾은 후 다음 동등성을 확인해야 합니다.(파일 크기 - 512) 모드 섹터 크기 = 0
이 평등이 만족되지 않으면 파일 접착 사실을 지적할 수 있습니다. 그러나 이 방법에는 심각한 단점이 있습니다. 공격자가 섹터 크기를 알고 있는 경우 붙여넣은 데이터의 크기가 섹터 크기의 배수가 되도록 파일과 추가 n바이트를 붙여넣기만 하면 됩니다.
알 수 없는 섹터 유형
공격자가 이전 검사를 우회하는 방법을 알고 있다면, 이 방법정의되지 않은 유형의 섹터가 있는지 감지할 수 있습니다.평등을 정의해보자:
FileSize = 512 + CountReal * SectorSize, 여기서 FileSize는 파일 크기, SectorSize는 섹터 크기, CountReal은 섹터 수입니다.
또한 다음 변수를 정의합니다.
- CountFat – FAT 섹터 수입니다. 파일(4바이트) 시작 부분부터 오프셋 44에 위치합니다.
- CountMiniFAT – MiniFAT 섹터 수입니다. 파일(4바이트) 시작 부분부터 오프셋 64에 위치합니다.
- CountDIFAT – DIFAT 섹터 수. 파일(4바이트) 시작 부분부터 오프셋 72에 위치합니다.
- CountDE – 디렉터리 항목 섹터 수입니다. 이 변수를 찾으려면 오프셋 48에 있는 첫 번째 섹터 DE를 찾아야 합니다. 그런 다음 FAT에서 DE의 완전한 표현을 얻고 DE 섹터 수를 계산해야 합니다.
- CountStreams – 데이터 스트림이 있는 섹터 수입니다.
- CountFree – 사용 가능한 섹터 수
- CountClassified – 특정 유형의 섹터 수
분명히 CountClassified와 CountReal이 동일하지 않으면 파일이 병합될 수 있다고 결론을 내릴 수 있습니다.
나의 상사는 나에게 꽤 흥미로운 임무를 주었다. 짧은 시간 내에 서명을 기반으로 바이러스 본문을 찾고 사용된 패커/암호화 프로그램을 결정할 수 있는 실행 파일 분석기를 작성하십시오. 완성된 프로토타입은 몇 시간 안에 나타났습니다.
저자의 말
서명 분석
서명을 사용하여 악성 개체를 검색하는 것은 모든 바이러스 백신이 수행할 수 있는 작업입니다. 일반적으로 서명은 검사 중인 파일이 바이러스이고 잘 정의된 바이러스인지 확인할 수 있는 특정 특성에 대한 공식화된 설명입니다.
여기에는 다양한 기술이 있습니다. 대안은 N바이트의 악성 개체로 구성된 시그니처를 사용하는 것입니다. 이 경우 어리석은 비교가 아니라 특정 마스크를 사용한 비교(예: 바이트 EB ?? ?? CD 13 찾기)를 수행할 수 있습니다. 또는 "이러한 바이트는 프로그램의 진입점에 있어야 합니다" 등과 같은 추가 조건을 설정합니다. 악성 코드의 서명은 특별한 문제입니다.
같은 방식으로 실행 파일이 하나 또는 다른 암호기 또는 패커(예: 진부한 ASPack)로 압축되어 있음을 확인할 수 있는 일부 표시가 설명됩니다. 우리 잡지를 주의 깊게 읽으셨다면 PEiD와 같은 도구에 대해 들어보셨을 것입니다. 이 도구는 전송된 PE 파일에 대해 가장 일반적으로 사용되는 패커, 암호화 도구 및 컴파일러(데이터베이스에 많은 수의 서명이 있음)를 식별할 수 있습니다. . 아아, 프로그램의 새 버전은 오랫동안 출시되지 않았으며 최근 공식 웹 사이트에 프로젝트가 더 이상 개발되지 않을 것이라는 메시지가 나타났습니다. PEiD의 기능(특히 플러그인 시스템을 고려할 때)이 나에게 매우 유용할 수 있기 때문에 안타까운 일입니다. 짧은 분석 끝에 이것이 선택 사항이 아니라는 것이 분명해졌습니다. 하지만 영어 블로그를 뒤져보니 나에게 맞는 것이 무엇인지 금방 찾을 수 있었습니다. YARA 프로젝트(code.google.com/p/yara-project).
YARA란 무엇인가요?
처음부터 나는 인터넷 어딘가에 특정 서명과 검사 중인 파일 간의 일치성을 결정하는 작업을 수행하는 오픈 소스 개발이 이미 존재한다고 확신했습니다. 그러한 프로젝트를 찾을 수 있다면 쉽게 웹 애플리케이션의 레일에 배치하고 거기에 다른 서명을 추가하여 나에게 필요한 것을 얻을 수 있습니다. YARA 프로젝트에 대한 설명을 읽으면서 그 계획이 더욱 현실적으로 느껴지기 시작했습니다.
개발자들은 이를 맬웨어 연구자들이 악성 샘플을 식별하고 분류하는 데 도움이 되는 도구로 자리매김했습니다. 연구원은 다음에 대한 설명을 만들 수 있습니다. 다른 유형맬웨어의 형식화된 특성을 설명하는 텍스트 또는 바이너리 패턴을 사용하는 맬웨어입니다. 이것이 서명을 얻는 방법입니다. 실제로 각 설명은 분석기의 트리거링 논리가 결정되는 기준으로 일련의 행과 일부 논리적 표현으로 구성됩니다.
검사 중인 파일에 대해 규칙 중 하나의 조건이 충족되면 그에 따라 결정됩니다(예: 이러한 웜). 우리가 말하는 내용을 이해하기 위한 규칙의 간단한 예는 다음과 같습니다.
Silent_banker 규칙: 은행가
{
메타:
설명 = "이것은 단지 예일 뿐입니다."
thread_level = 3
in_the_wild = 사실
문자열:
$a = (6A 40 68 00 30 00 00 6A 14 8D 91)
$b = (8D 4D B0 2B C1 83 C0 27 99 6A 4E 59 F7 F9)
$c = "UVODFRYSIHLNWPEJXQZAKCBGMT"
상태:
$a 또는 $b 또는 $c
}
이 규칙에서 우리는 $a, $b, $c 변수에 설명된 샘플 문자열 중 하나 이상을 포함하는 모든 파일을 Silent_banker 트로이 목마로 분류해야 한다고 YARA에 알립니다. 그리고 이것은 매우 간단한 규칙입니다. 실제로 규칙은 훨씬 더 복잡할 수 있습니다(이에 대해서는 아래에서 설명하겠습니다).
이를 사용하는 프로젝트 목록조차도 YARA 프로젝트의 권위에 대해 말하며 이는 다음과 같습니다.
- VirusTotal Malware Intelligence Services(vt-mis.com);
- jsunpack-n(jsunpack.jeek.org);
- 우리는 귀하의 웹사이트를 감시합니다(wewatchyourwebsite.com).
모든 코드는 Python으로 작성되었으며 사용자에게는 개발에 사용할 모듈 자체와 YARA를 독립형 애플리케이션으로 사용할 수 있는 실행 파일이 모두 제공됩니다. 작업의 일환으로 저는 첫 번째 옵션을 선택했지만 이 기사에서는 단순함을 위해 분석기를 콘솔 애플리케이션으로만 사용하겠습니다.
약간의 조사 끝에 저는 YARA에 대한 규칙을 작성하는 방법과 PEiD의 프리웨어 및 패커에서 바이러스 서명을 첨부하는 방법을 빠르게 알아냈습니다. 하지만 설치부터 시작하겠습니다.
설치
앞서 말했듯이 프로젝트는 Python으로 작성되었기 때문에 Linux, Windows, Mac에 쉽게 설치할 수 있습니다. 처음에는 바이너리만 가져갈 수 있습니다. 콘솔에서 애플리케이션을 호출하면 실행 규칙을 얻게 됩니다.
$yara
사용법: yara ... ... 파일 | PID
즉, 프로그램 호출 형식은 다음과 같습니다. 먼저 프로그램 이름이 있고 그 다음에는 옵션 목록이 있으며 그 뒤에는 규칙이 있는 파일이 표시되고 맨 끝에는 파일 이름이 표시됩니다. 검사된 항목(또는 파일이 포함된 디렉터리) 또는 프로세스 식별자입니다. 이제 나는 이러한 규칙이 어떻게 작성되는지 좋은 방법으로 설명하고 싶지만 무미건조한 이론으로 즉시 부담을 주고 싶지는 않습니다. 따라서 우리는 YARA가 우리가 설정한 작업 중 하나, 즉 서명을 통한 본격적인 바이러스 탐지를 수행할 수 있도록 다른 방식으로 작업을 수행하고 다른 사람의 서명을 빌릴 것입니다.
나만의 바이러스 백신
가장 중요한 질문: 알려진 바이러스의 서명 데이터베이스를 어디서 얻을 수 있습니까? 바이러스 백신 회사는 이러한 데이터베이스를 적극적으로 공유합니다(일부는 더 관대하고 다른 일부는 덜). 솔직히 말해서 처음에는 누군가 인터넷 어딘가에 그런 것들을 공개적으로 게시할 것이라는 의심조차 했습니다. 그러나 결과적으로 좋은 사람들이 있습니다. 인기 있는 ClamAV 바이러스 백신의 적합한 데이터베이스는 누구나 사용할 수 있습니다(clamav.net/lang/en). "최신 안정 릴리스" 섹션에서 다음 링크를 찾을 수 있습니다. 최신 버전바이러스 백신 제품 및 ClamAV 바이러스 데이터베이스 다운로드 링크. 우리는 주로 main.cvd(db.local.clamav.net/main.cvd) 및 daily.cvd(db.local.clamav.net/daily.cvd) 파일에 관심을 가질 것입니다.
첫 번째에는 기본 서명 데이터베이스가 포함되어 있고 두 번째에는 가장 완전한 데이터베이스가 포함되어 있습니다. 이 순간다양한 추가 기능을 갖춘 베이스. 100,000개 이상의 맬웨어 노출이 포함된 Daily.cvd는 이러한 목적에 매우 충분합니다. 하지만 ClamAV 데이터베이스는 YARA 데이터베이스가 아니므로 원하는 형식으로 변환해야 합니다. 하지만 어떻게? 결국 우리는 ClamAV 형식이나 Yara 형식에 대해 아직 아무것도 모릅니다. 이 문제는 ClamAV 바이러스 서명 데이터베이스를 YARA 규칙 세트로 변환하는 작은 스크립트를 준비하여 이미 해결되었습니다. 이 스크립트는 clamav_to_yara.py라고 하며 Matthew Richard(bit.ly/ij5HVs)가 작성했습니다. 스크립트를 다운로드하고 데이터베이스를 변환합니다.
$ 파이썬 clamav_to_yara.py -f daily.cvd -o clamav.yara
결과적으로 clamav.yara 파일에서 즉시 사용할 수 있는 서명 데이터베이스를 받게 됩니다. 이제 실제로 YARA와 ClamAV 데이터베이스의 조합을 시도해 보겠습니다. 서명을 사용한 폴더 검사는 단일 명령으로 수행됩니다.
$ yara -r clamav.yara /pentest/msf3/data
-r 옵션은 현재 폴더의 모든 하위 폴더에 걸쳐 검사를 반복적으로 수행하도록 지정합니다. /pentest/msf3/data 폴더에 바이러스 본문이 있는 경우(적어도 ClamAV 데이터베이스에 있는 바이러스 본문) YARA는 이를 즉시 보고합니다. 원칙적으로 이것은 기성 서명 스캐너입니다. 편의성을 높이기 위해 ClamAV 데이터베이스 업데이트를 확인하고 새 서명을 다운로드한 후 YARA 형식으로 변환하는 간단한 스크립트를 작성했습니다. 그러나 이것은 이미 세부 사항입니다. 작업의 한 부분이 완료되었습니다. 이제 패커/암호화 프로그램을 식별하기 위한 규칙 작성을 시작할 수 있습니다. 하지만 그러기 위해서는 그들을 조금 상대해야 했습니다.
규칙에 따라 플레이하세요
따라서 규칙은 특정 파일을 특정 범주에 할당할 수 있는 프로그램의 주요 메커니즘입니다. 규칙은 별도의 파일(들)에 설명되어 있으며 외관상 C/C++ 언어의 struct() 구성과 매우 유사합니다.
배드보이를 지배하다
{
문자열:
$a = "win.exe"
$b = "http://foo.com/badfi le1.exe"
$c = "http://bar.com/badfi le2.exe"
상태:
$a 및 ($b 또는 $c)
}
원칙적으로 규칙을 작성하는 데 복잡한 것은 없습니다. 이번 글에서는 주요 내용만 다루었고 자세한 내용은 매뉴얼을 참조하세요. 현재 가장 중요한 10가지 사항은 다음과 같습니다.
1. 각 규칙은 키워드 규칙으로 시작하고 그 뒤에 규칙 식별자가 옵니다. 식별자는 C/C++의 변수와 동일한 이름을 가질 수 있습니다. 즉, 문자와 숫자로 구성될 수 있으며 첫 번째 문자는 숫자가 될 수 없습니다. 최대 길이식별자 이름 - 128자.
2. 일반적으로 규칙은 정의 섹션(문자열)과 조건 섹션(조건)이라는 두 섹션으로 구성됩니다. 문자열 섹션은 주어진 파일이 특정 조건을 만족하는지 여부를 조건 섹션이 결정하는 기준으로 데이터를 지정합니다.
3. 문자열 섹션의 각 줄에는 $ 기호로 시작하는 고유한 식별자가 있습니다. 이는 일반적으로 PHP의 변수 선언과 같습니다. YARA는 다음과 같은 일반 문자열을 지원합니다. 큰따옴표("") 및 그 안에 포함된 16진수 문자열 바지 멜빵(()) 및 정규 표현식:
$my_text_string = "여기에 텍스트를 입력하세요"
$my_hex_string = ( E2 34 A1 C8 23 FB )
4. 조건 섹션에는 규칙의 모든 논리가 포함되어 있습니다. 이 섹션에는 파일이나 프로세스가 규칙과 일치하는 시기를 결정하는 부울 표현식이 포함되어야 합니다. 일반적으로 이 섹션은 이전에 선언된 행을 참조합니다. 그리고 문자열 식별자는 문자열이 파일이나 프로세스 메모리에서 발견되면 true를 반환하고 그렇지 않으면 false를 반환하는 부울 변수로 처리됩니다. 위의 규칙은 win.exe 문자열과 두 URL 중 하나를 포함하는 파일 및 프로세스가 규칙 이름에 따라 BadBoy로 분류되어야 함을 지정합니다.
5. 16진수 문자열은 보다 유연하게 만드는 세 가지 구성인 와일드카드, 점프 및 대체를 허용합니다. 대체는 알 수 없는 문자열의 위치이며 임의의 값으로 대체될 수 있습니다. "?" 기호로 표시됩니다.
$hex_string = ( E2 34 ?? C8 A ? FB )
이 접근 방식은 길이가 알려진 문자열을 지정할 때 매우 편리하지만 내용은 다를 수 있습니다. 문자열의 일부 길이가 다를 수 있는 경우 범위를 사용하는 것이 편리합니다.
$hex_string = ( F4 23 62 B4 )
이 항목은 줄 중간에 4~6개의 다른 바이트가 있을 수 있음을 의미합니다. 대체 선택을 구현할 수도 있습니다.
$hex_string = ( F4 23 (62 B4 | 56) 45 )
즉, 세 번째 바이트 대신 62 B4 또는 56이 있을 수 있으며 이러한 항목은 F42362B445 또는 F4235645 행에 해당합니다.
6. 주어진 문자열이 파일이나 프로세스 주소 공간의 특정 오프셋에 있는지 확인하려면 at 연산자가 사용됩니다.
100에서는 $a, 200에서는 $b
문자열이 특정 주소 범위 내에 있을 수 있으면 in 연산자가 사용됩니다.
$a(0..100) 및 $b(100..파일 크기)
파일이 주어진 세트의 특정 숫자를 포함해야 함을 지정해야 하는 경우가 가끔 발생합니다. 이는 of 연산자를 사용하여 수행됩니다.
예제1의 규칙
{
문자열:
$foo1 = "더미1"
$foo2 = "더미2"
$foo3 = "더미3"
상태:
($foo1,$foo2,$foo3) 중 2개
}
위의 규칙에서는 파일에 세트($foo1,$foo2,$foo3)의 두 줄이 포함되어야 합니다. 파일에 특정 행 수를 지정하는 대신 any(주어진 세트에서 최소 한 행) 및 all(주어진 세트에서 모든 행) 변수를 사용할 수 있습니다.
7. 마지막으로 고려해야 할 흥미로운 가능성은 하나의 조건을 여러 행에 적용하는 것입니다. 이 기능은 of 연산자와 매우 유사하지만 for..of 연산자가 더 강력합니다.
string_set의 표현식: (boolean_expression)
이 항목은 다음과 같이 읽어야 합니다. string_ 세트에 지정된 문자열 중 최소한 표현식 조각은 boolean_expression 조건을 충족해야 합니다. 즉, boolean_expression은 string_set의 각 문자열에 대해 평가되며 해당 표현식은 True를 반환해야 합니다. 다음으로 구체적인 예를 사용하여 이 구성을 살펴보겠습니다.
PEiD 만들기
따라서 규칙에 따라 모든 것이 어느 정도 명확해지면 프로젝트에서 패커 및 암호 탐지기를 구현하기 시작할 수 있습니다. 처음에는 같은 PEiD의 유명 패커들의 사인을 원본 자료로 빌렸습니다. 플러그인 폴더에는 필요한 내용이 포함된 userdb.txt 파일이 있습니다. 내 데이터베이스에는 1850개의 서명이 있었습니다.
상당히 많기 때문에 완전히 가져오려면 일종의 스크립트를 작성하는 것이 좋습니다. 이 데이터베이스의 형식은 간단합니다. 일반적인 형식이 사용됩니다. 텍스트 파일, 다음과 같은 레코드를 저장합니다.
서명 = 50 E8 ?? ?? ?? ?? 58 25 ?? F0 FF FF 8B C8 83 C1 60 51 83 C0 40 83 EA 06 52 FF 20 9D C3
ep_only = 사실
첫 번째 줄은 PEiD에 표시될 패커의 이름을 지정하지만 우리에게는 규칙 식별자가 됩니다. 두 번째는 서명 자체입니다. 세 번째는 ep_only 플래그로, 주어진 행을 진입점 주소에서만 검색할지 아니면 전체 파일에서 검색할지 여부를 나타냅니다.
예를 들어 ASPack에 대한 규칙을 만들어 보겠습니다. 결과적으로 이것에 대해 복잡한 것은 없습니다. 먼저 규칙을 저장하고 호출할 파일(예: packers.yara)을 생성해 보겠습니다. 그런 다음 PEiD 데이터베이스에서 이름에 ASPack이 포함된 모든 서명을 검색하고 이를 규칙으로 전송합니다.
규칙 ASPack
{
문자열:
$ = ( 60 E8 ?? ?? ?? ?? 5D 81 ED ?? ?? (43 | 44) ?? B8 ?? ?? (43 | 44) ?? 03 C5 )
$ = ( 60EB ?? 5D EB ?? FF ?? ?? ?? ?? E9 )
[.. 자르다..]
$ = ( 60 E8 03 00 00 00 E9 EB 04 5D 45 55 C3 E8 01 )
상태:
그 중 하나에 대해: ($at 진입점)
}
발견된 모든 레코드에는 ep_only 플래그가 true로 설정되어 있습니다. 즉, 이러한 행은 진입점 주소에 위치해야 합니다. 따라서 우리는 "for any of them: ($at 진입점)"이라는 조건을 작성합니다.
따라서 진입점 주소에 주어진 행 중 적어도 하나가 존재한다는 것은 파일이 ASPack으로 압축되었음을 의미합니다. 또한 이 규칙에서는 모든 행이 식별자 없이 $ 기호를 사용하여 지정된다는 점도 참고하세요. 이는 조건 섹션에서 특정 항목에 액세스하지 않고 전체 세트를 사용하기 때문에 가능합니다.
결과 시스템의 기능을 확인하려면 콘솔에서 다음 명령을 실행하십시오.
$ yara -r packers.yara somefi le.exe
거기에 ASPack과 함께 패키지된 몇 가지 애플리케이션을 제공한 후 모든 것이 작동한다고 확신했습니다!
준비된 프로토타입
YARA는 매우 명확하고 투명한 도구임이 밝혀졌습니다. 웹 관리자를 작성하고 웹 서비스로 작동하도록 설정하는 것은 어렵지 않았습니다. 약간의 창의성을 발휘하면 분석기의 건조한 결과가 이미 다른 색상으로 표시되어 감지된 악성 코드의 위험 정도를 나타냅니다. 데이터베이스의 작은 업데이트와 많은 암호화폐에 대한 간단한 설명이 제공되며 때로는 압축 풀기 지침도 제공됩니다. 프로토타입이 제작되어 완벽하게 작동하고 있으며, 보스들이 기뻐서 춤을 추고 있습니다!
텔레그램 헤더의 기능 코드(FC)는 요청 텔레그램(요청 또는 전송/요청) 및 승인 또는 응답 텔레그램(승인 프레임, 응답 프레임)과 같은 텔레그램 유형을 식별합니다. 또한 기능 코드에는 실제 전송 기능과 메시지의 손실 및 중복을 방지하는 제어 정보 또는 FDL 상태의 스테이션 유형이 포함됩니다.
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | FC: 기능 코드 요청 |
| 1 | 텔레그램 요청 | |||||||
| 엑스 | FCV = 대체 비트가 켜짐 | |||||||
| 엑스 | href=”http://profibus.felser.ch/en/funktionscode.htm#aufruffolgebit”>FCB = 대체 비트(프레임 수에서) | |||||||
| 1 | 0(0x0) | CV = 클럭 값() | ||||||
| 1 | 다른 | 예약된 | ||||||
| 0 | 0(0x0) | TE = 시간 이벤트(시계 동기화) | ||||||
| 0 | 3(0x3) | SDA_LOW = 승인된 데이터 보내기 - 낮은 우선순위 | ||||||
| 0 | 4(0x4) | SDN_LOW = 데이터 전송이 승인되지 않음 - 우선순위가 낮음 | ||||||
| 0 | 5(0x5) | SDA_HIGH = 승인된 데이터 보내기 - 높은 우선순위 | ||||||
| 0 | 6(0x6) | SDN_HIGH = 데이터 전송이 승인되지 않음 | ||||||
| 0 | 7(0x7) | MSRD = 멀티캐스트 응답으로 요청 데이터 보내기 | ||||||
| 0 | 9(0x9) | FDL 상태 요청 | ||||||
| 0 | 12(0xC) | SRD 낮음 = 데이터 전송 및 요청 | ||||||
| 0 | 13(0xD) | SRD 높음 = 데이터 전송 및 요청 | ||||||
| 0 | 14(0xE) | 응답으로 ID 요청 | ||||||
| 0 | 15(0xF) | 응답으로 LSAP 상태 요청 1) | ||||||
| 0 | 다른 | 예약된 | ||||||
1) 이 값은 더 이상 정의되지 않았지만 예약된 표준의 마지막 버전에 있습니다.
| 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | FC: 기능 코드 응답 |
| 0 | 응답 전보 | |||||||
| 0 | 예약된 | |||||||
| 0 | 0 | 노예 | ||||||
| 0 | 1 | 마스터가 준비되지 않았습니다. | ||||||
| 1 | 0 | 토큰 없이 마스터 준비됨 | ||||||
| 1 | 1 | 마스터 준비 완료, 토큰 링 | ||||||
| 0(0x0) | 좋아요 | |||||||
| 1(0x1) | UE = 사용자 오류 | |||||||
| 2(0x2) | RR = 리소스 없음 | |||||||
| 3(0x3) | RS = SAP가 활성화되지 않음 | |||||||
| 8(0x8) | DL = 데이터 부족(DP의 일반적인 경우) | |||||||
| 9(0x9) | NR = 응답 데이터가 준비되지 않았습니다. | |||||||
| 10(0xA) | DH = 데이터 높음(DP 진단 보류 중) | |||||||
| 12(0xC) | RDL = 데이터가 수신되지 않았으며 데이터가 낮음 | |||||||
| 13(0xD) | RDH = 데이터가 수신되지 않았으며 데이터가 높음 | |||||||
| 다른 | 예약된 | |||||||
프레임 카운트 비트 프레임 카운트 비트 FCB(b5)는 승인 또는 응답 스테이션(응답자)에 의한 메시지 중복과 호출 스테이션(개시자)에 의한 손실을 방지합니다. 승인 없는 요청(SDN)과 FDL 상태, Ident 및 LSAP 상태 요청은 여기서 제외됩니다.
보안 시퀀스의 경우 개시자는 각 응답자에 대해 FCB를 전달해야 합니다. 요청 텔레그램(요청 또는 전송/요청)이 처음으로 응답자에게 전송되거나 현재 비작동으로 표시된 응답자에게 재전송되는 경우 FCB는 응답자에 정의된 대로 설정되어야 합니다. 개시자는 FCV=0 및 FCB=1을 사용하여 요청 텔레그램에서 이를 달성합니다. 응답자는 이러한 종류의 텔레그램을 첫 번째 메시지 주기로 평가하고 개시자 주소(SA)와 함께 FCB=1을 저장해야 합니다(다음 표 참조). 이 메시지 주기는 개시자에 의해 반복되지 않습니다. 동일한 응답자에 대한 후속 요청 텔레그램에서 개시자는 FCV=1을 설정하고 각각의 새로운 요청 텔레그램으로 FCB를 변경해야 합니다. FCV=1로 주소가 지정된 요청 텔레그램을 수신하는 모든 응답자는 FCB를 평가해야 합니다. 동일한 개시자(동일한 SA)의 마지막 요청 텔레그램과 비교할 때 FCB가 변경된 경우 이는 이전 메시지 주기가 적절하게 종료되었음을 의미하는 유효한 확인입니다. 요청 전문이 다른 개시자(다른 SA)에서 시작된 경우 FCB 평가는 더 이상 필요하지 않습니다. 두 경우 모두 응답자는 주소가 지정된 새 전문을 수신할 때까지 소스 SA와 함께 FCB를 저장해야 합니다. 승인 또는 응답 텔레그램이 손실되거나 손상된 경우 요청 재시도 시 개시자가 FCB를 변경해서는 안 됩니다. 이는 이전 메시지 주기에 결함이 있음을 나타냅니다. 응답자가 FCV=1이고 동일한 개시자(동일한 SA)로부터 마지막 요청 텔레그램과 동일한 FCB를 갖는 요청 텔레그램을 수신하는 경우 이는 요청 재시도를 나타냅니다. 응답자는 준비 상태로 유지된 승인 또는 응답 텔레그램을 차례로 재전송해야 합니다. 위에서 언급한 확인 또는 승인되지 않은 다른 주소(SA 또는 DA)가 있는 전보의 수신(SDN, 승인 없이 데이터 전송)까지 응답자는 가능한 모든 요청 재시도에 대비하여 마지막 승인 또는 응답 전보를 보유해야 합니다. . 확인되지 않고 요청 FDL 상태, ID 및 LSAP 상태가 있는 요청 텔레그램의 경우 FCV=0 및 FCB=0입니다. 응답자의 평가는 더 이상 필요하지 않습니다.
| b5 | b4 | 비트 위치 | ||
| FCB | FCV | 상태 | 의미 | 행동 |
| 0 | 0 | 다 = TS/127 | 승인 없이 요청 FDL 상태/ID/LSAP 상태 요청 |
마지막 확인 삭제 |
| 0/1 | 0/1 | DA#TS | 다른 응답자에게 요청 | |
| 1 | 0 | 다 = TS | 첫 번째 요청 | FCBM:= 1 샘:=SA 마지막 확인/응답 삭제 |
| 0/1 | 1 | 다 = TS SA = 샘 FCB#FCBM |
새로운 요청 | 마지막 확인/응답 삭제 FCBM:=FCB 재시도를 위해 승인/응답을 보류합니다. |
| 0/1 | 1 | 다 = TS SA = 샘 FCB = FCBM |
재시도 요청 | FCBM:=FCB 확인/응답을 반복하고 계속해서 준비 상태를 유지합니다. |
| 0/1 | 1 | 다 = TS SA#샘 |
새로운 개시자 | FCBM:=FCB SAM:= SA 재시도 준비 상태에서 승인/응답 보류 |
FCBM은 메모리에 FCB를 저장했습니다. SAM은 메모리에 SA를 저장했습니다.
