Microsoft MVP성태의 닷넷 이야기
.NET Framework: 522. 닷넷의 어셈블리 서명 데이터 확인 방법 [링크 복사], [링크+제목 복사],
조회: 20122
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
(연관된 글이 3개 있습니다.)

DLL 라이브러리 프로젝트를 하나 만들고 .snk 서명을 붙이니 다음과 같이 강력한 이름을 갖게 됩니다.

ClassLibrary1, Version=1.0.0.0, Culture=neutral, PublicKeyToken=a5061489c9b56357

먼저, PublicKeyToken의 값이 뭘 의미하는 걸까요?

간혹 PublicKeyToken(8바이트)을 PublicKey로 알고 계신 분들이 있는 듯 한데, PublicKeyToken도 해시값일 뿐 원래의 PublicKey(128바이트)는 따로 있습니다. 예를 들어, ildasm.exe를 이용해 ClassLibrary1.dll의 manifest를 살펴보면 ClassLibrary1.dll의 서명에 사용한 .snk 파일의 공개키를 볼 수 있습니다.

// Metadata version: v4.0.30319
.assembly ClassLibrary1
{
   // ... [생략]...
                                                                                                             
  .publickey = (00 24 00 00 04 80 00 00 94 00 00 00 06 02 00 00   // .$..............
                00 24 00 00 52 53 41 31 00 04 00 00 01 00 01 00   // .$..RSA1........
                FB D5 9D D2 0A DD 87 1F 53 E4 BA 6F E0 42 03 CC   // ........S..o.B..
                B4 C0 74 A2 FD DE E0 8D 43 82 87 FC 56 24 8A 0C   // ..t.....C...V$..
                1A 31 C8 F5 FF E8 BC DF 2A 61 BE 23 39 0E 3D 42   // .1......*a.#9.=B
                BF DF D6 B0 CF 89 AC 80 59 1D AD 7A 95 3A F5 AF   // ........Y..z.:..
                E2 73 35 84 FF 05 59 16 AB 44 F1 58 34 3F 5A 13   // .s5...Y..D.X4?Z.
                EB FE B3 2E B3 D1 00 FB FB 94 5A 7A D6 59 12 82   // ..........Zz.Y..
                F4 D7 A1 C6 58 7D 07 68 68 E8 49 5C 7C 6F 13 8C   // ....X}.hh.I\|o..
                4A 52 1F 22 8F 03 F2 1F F8 F7 D7 C6 4E E2 2A DE ) // JR."........N.*.
  .hash algorithm 0x00008004
  .ver 1:0:0:0
}

publickey가 길~~~게 있군요. ^^ 하지만 그것이 너무 길기 때문에 사용이 불편하므로 해당 어셈블리에만 PublicKey를 보유하고 외부적으로 강력한 이름을 표현할 때는 그것을 해시한 값(20바이트)의 마지막 8바이트를 편의상 쓰는 것 뿐입니다. 따라서, 서명된 코드의 검증 작업을 할 때 PublicKeyToken으로 하는 것이 아니고 PublicKey로 하므로 키가 너무 작은 것 같다는 걱정은 안하셔도 됩니다. (키의 기본값은 1024비트이고, 384 ~ 16384의 범위를 가질 수 있다고 합니다.)




그럼 .snk 파일의 개인키로 어셈블리를 서명했을 때 생성한 "해시 덩어리"는 어디 있을까요? 이에 대해서는 다음의 글에서 잘 설명해 주고 있습니다.

Dot NET Assemblies and Strong Name Signature
; http://resources.infosecinstitute.com/dot-net-assemblies-and-strong-name-signature/

이를 이해하려면 우선 PE 파일의 포맷에 대해 알면 좋습니다.

PE File Format
; http://yokang90.tistory.com/6

그리하여, PE 파일의 Optional Header에 있는 DataDirectory 배열에 .NET 정보에 해당하는 "COM_DESCRIPTOR" 디렉토리가 있을 텐데, 그 내부에 명시된 위치 값을 찾아가야 합니다. 귀찮으니... 이럴 때는 CFF Explorer를 이용하면 다음과 같이 ".NET Directory"를 바로 찾을 수 있고, 거기서 서명 데이터의 위치를 가리키는 "StrongNameSignature RVA" 값을 찾을 수 있습니다.

strong_sig_0.png

보는 바와 같이 "StrongNameSignature RVA" 값은 0x2050인데, 이름에서 알 수 있듯이 이 값은 RVA 값입니다. RVA 값이 파일의 어떤 위치를 나타내는지는 이 또한 그와 관련된 약간의 지식이 필요합니다.

RVA to RAW (PE File 관련)
; http://yokang90.tistory.com/21

제가 테스트하고 있는 ClassLibrary1.dll의 경우 "Section Headers"에 다음의 3가지 섹션만 있었는데요.

strong_sig_1.png

이 중에서 ".text" 섹션의 "Virtual Address: 0x2000"과 크기(0x9e4)로 봤을 때 "StrongNameSignature RVA" 값이 0x2050이므로 ".text" 섹션에 속한다는 것을 알 수 있습니다. 그리고 ".text" 섹션의 "Raw Address" 값, 즉 ".text" 섹션이 시작하는 파일의 위치가 0x200이기 때문에 "StrongNameSignature"의 파일 위치는 "0x2050 - 0x2000 + 0x200 == 0x250"이 됩니다. 이를 "Hex Editor"에서 확인해 보면 다음과 같은 영역의 값이 "개인키로 서명된 어셈블리의 해시 값(128바이트)"임을 알 수 있습니다.

strong_sig_2.png

참고로, "지연 서명된 어셈블리"를 CFF Explorer에서 불러 저 영역을 (찾아서) 확인하면 128바이트 영역이 모두 0으로 채워져 있습니다. 즉, 지연 서명된 어셈블리는 .snk 파일의 공개키와 그로 인한 공개키 토큰은 부여받았지만, 개인키가 없었으므로 서명 데이터는 비어있게 됩니다. 또한 아예 서명되지 않은 어셈블리는 "StrongNameSignature RVA" 값과 "StrongNameSignature Size"가 모두 0의 값을 가지며 ".Flags" 값에는 "Strong Name signed" 필드가 해제되어 있습니다.




프로그램으로 서명 데이터를 찾고 싶다면 다음의 C/C++ 소스 코드를 참고하시면 됩니다.

Finding the Raw Strong Name Signature
; http://blogs.msdn.com/b/shawnfa/archive/2005/01/26/361109.aspx

해당 소스코드를 Visual Studio에서 빌드 가능한 프로젝트로 첨부했으니 참고하세요.




결국 서명 데이터는 PE 포맷 내에 잘 정리되어 있기 때문에 "강력한 이름의 어셈블리"를 일반 어셈블리로 돌리는 것은 매우 쉽습니다. 위에서 소개했던 "Dot NET Assemblies and Strong Name Signature" 글에서도 중간에 보면 서명을 해제하는 방법에 대해 설명하고 있습니다.

간단하게 하고 싶다면, CFF Explorer의 "Rebuilder" 노드에서 "Remove Strong Name Signature"를 설정하고 "Rebuild" 버튼을 눌러주면 됩니다.

strong_sig_3.png



[연관 글]






[최초 등록일: ]
[최종 수정일: 3/9/2021]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer at outlook.com

비밀번호

댓글 작성자
 




... 61  62  [63]  64  65  66  67  68  69  70  71  72  73  74  75  ...
NoWriterDateCnt.TitleFile(s)
12067정성태11/27/201911745디버깅 기술: 137. 실제 사례를 통해 Debug Diagnostics 도구가 생성한 닷넷 웹 응용 프로그램의 성능 장애 보고서 설명 [1]파일 다운로드1
12066정성태11/27/201911606디버깅 기술: 136. windbg - C# PInvoke 호출 시 마샬링을 담당하는 함수 분석 - OracleCommand.ExecuteReader에서 OpsSql.Prepare2 PInvoke 호출 분석
12065정성태11/25/201910485디버깅 기술: 135. windbg - C# PInvoke 호출 시 마샬링을 담당하는 함수 분석파일 다운로드1
12064정성태11/25/201912668오류 유형: 580. HTTP Error 500.0/500.33 - ANCM In-Process Handler Load Failure
12063정성태11/21/201911694디버깅 기술: 134. windbg - RtlReportCriticalFailure로부터 parameters 정보 찾는 방법
12062정성태11/21/201911775디버깅 기술: 133. windbg - CoTaskMemFree/FreeCoTaskMem에서 발생한 덤프 분석 사례 - 두 번째 이야기
12061정성태11/20/201911936Windows: 167. CoTaskMemAlloc/CoTaskMemFree과 윈도우 Heap의 관계
12060정성태11/20/201912314디버깅 기술: 132. windbg/Visual Studio - HeapFree x64의 동작 분석
12059정성태11/20/201911905디버깅 기술: 131. windbg/Visual Studio - HeapFree x86의 동작 분석
12058정성태11/19/201912716디버깅 기술: 130. windbg - CoTaskMemFree/FreeCoTaskMem에서 발생한 덤프 분석 사례
12057정성태11/18/20199838오류 유형: 579. Visual Studio - Memory 창에서 유효한 주소 영역임에도 "Unable to evaluate the expression." 오류 출력
12056정성태11/18/201913674개발 환경 구성: 464. "Microsoft Visual Studio Installer Projects" 프로젝트로 EXE 서명 및 MSI 파일 서명 방법파일 다운로드1
12055정성태11/17/20199397개발 환경 구성: 463. Visual Studio의 Ctrl + Alt + M, 1 (Memory 1) 등의 단축키가 동작하지 않는 경우
12054정성태11/15/201910746.NET Framework: 869. C# - 일부러 GC Heap을 깨뜨려 GC 수행 시 비정상 종료시키는 예제
12053정성태11/15/201912423Windows: 166. 윈도우 10 - 명령행 창(cmd.exe) 속성에 (DotumChe, GulimChe, GungsuhChe 등의) 한글 폰트가 없는 경우
12052정성태11/15/201911521오류 유형: 578. Azure - 일정(schedule)에 등록한 runbook이 1년 후 실행이 안 되는 문제(Reason - The key used is expired.)
12051정성태11/14/201914000개발 환경 구성: 462. 시작하자마자 비정상 종료하는 프로세스의 메모리 덤프 - procdump [1]
12050정성태11/14/201911674Windows: 165. AcLayers의 API 후킹과 FaultTolerantHeap
12049정성태11/13/201911764.NET Framework: 868. (닷넷 프로세스를 대상으로) 디버거 방식이 아닌 CLR Profiler를 이용해 procdump.exe 기능 구현
12048정성태11/12/201912524Windows: 164. GUID 이름의 볼륨에 해당하는 파티션을 찾는 방법
12047정성태11/12/201914383Windows: 163. 안전하게 eject시킨 USB 장치를 물리적인 재연결 없이 다시 인식시키는 방법
12046정성태10/29/201910363오류 유형: 577. windbg - The call to LoadLibrary(...\sos.dll) failed, Win32 error 0n193
12045정성태10/27/20199705오류 유형: 576. mstest.exe 실행 시 "Visual Studio Enterprise is required to execute the test." 오류 - 두 번째 이야기
12044정성태10/27/20199935오류 유형: 575. mstest.exe - System.Resources.MissingSatelliteAssemblyException: The satellite assembly named "Microsoft.VisualStudio.ProductKeyDialog.resources.dll, ..."
12043정성태10/27/201910740오류 유형: 574. Windows 10 설치 시 오류 - 0xC1900101 - 0x4001E
12042정성태10/26/201911135오류 유형: 573. OneDrive 하위에 위치한 Documents, Desktop 폴더에 대한 권한 변경 시 "Unable to display current owner"
... 61  62  [63]  64  65  66  67  68  69  70  71  72  73  74  75  ...