Microsoft MVP성태의 닷넷 이야기
.NET Framework: 522. 닷넷의 어셈블리 서명 데이터 확인 방법 [링크 복사], [링크+제목 복사],
조회: 19670
글쓴 사람
정성태 (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)
12104정성태1/7/202011455DDK: 9. 커널 메모리를 읽고 쓰는 NT Legacy driver와 C# 클라이언트 프로그램 [4]
12103정성태1/7/202014141DDK: 8. Visual Studio 2019 + WDK Legacy Driver 제작- Hello World 예제 [1]파일 다운로드2
12102정성태1/6/202011786디버깅 기술: 152. User 권한(Ring 3)의 프로그램에서 _ETHREAD 주소(및 커널 메모리를 읽을 수 있다면 _EPROCESS 주소) 구하는 방법
12101정성태1/5/202011131.NET Framework: 876. C# - PEB(Process Environment Block)를 통해 로드된 모듈 목록 열람
12100정성태1/3/20209151.NET Framework: 875. .NET 3.5 이하에서 IntPtr.Add 사용
12099정성태1/3/202011449디버깅 기술: 151. Windows 10 - Process Explorer로 확인한 Handle 정보를 windbg에서 조회 [1]
12098정성태1/2/202011043.NET Framework: 874. C# - 커널 구조체의 Offset 값을 하드 코딩하지 않고 사용하는 방법 [3]
12097정성태1/2/20209621디버깅 기술: 150. windbg - Wow64, x86, x64에서의 커널 구조체(예: TEB) 구조체 확인
12096정성태12/30/201911626디버깅 기술: 149. C# - DbgEng.dll을 이용한 간단한 디버거 제작 [1]
12095정성태12/27/201912998VC++: 135. C++ - string_view의 동작 방식
12094정성태12/26/201911166.NET Framework: 873. C# - 코드를 통해 PDB 심벌 파일 다운로드 방법
12093정성태12/26/201911183.NET Framework: 872. C# - 로딩된 Native DLL의 export 함수 목록 출력파일 다운로드1
12092정성태12/25/201910603디버깅 기술: 148. cdb.exe를 이용해 (ntdll.dll 등에 정의된) 커널 구조체 출력하는 방법
12091정성태12/25/201912117디버깅 기술: 147. pdb 파일을 다운로드하기 위한 symchk.exe 실행에 필요한 최소 파일 [1]
12090정성태12/24/201910770.NET Framework: 871. .NET AnyCPU로 빌드된 PE 헤더의 로딩 전/후 차이점 [1]파일 다운로드1
12089정성태12/23/201911495디버깅 기술: 146. gflags와 _CrtIsMemoryBlock을 이용한 Heap 메모리 손상 여부 체크
12088정성태12/23/201910486Linux: 28. Linux - 윈도우의 "Run as different user" 기능을 shell에서 실행하는 방법
12087정성태12/21/201910917디버깅 기술: 145. windbg/sos - Dictionary의 entries 배열 내용을 모두 덤프하는 방법 (do_hashtable.py) [1]
12086정성태12/20/201912969디버깅 기술: 144. windbg - Marshal.FreeHGlobal에서 발생한 덤프 분석 사례
12085정성태12/20/201910701오류 유형: 586. iisreset - The data is invalid. (2147942413, 8007000d) 오류 발생 - 두 번째 이야기 [1]
12084정성태12/19/201911346디버깅 기술: 143. windbg/sos - Hashtable의 buckets 배열 내용을 모두 덤프하는 방법 (do_hashtable.py) [1]
12083정성태12/17/201912595Linux: 27. linux - lldb를 이용한 .NET Core 응용 프로그램의 메모리 덤프 분석 방법 [2]
12082정성태12/17/201912452오류 유형: 585. lsof: WARNING: can't stat() fuse.gvfsd-fuse file system
12081정성태12/16/201914200개발 환경 구성: 465. 로컬 PC에서 개발 중인 ASP.NET Core 웹 응용 프로그램을 다른 PC에서도 접근하는 방법 [5]
12080정성태12/16/201912123.NET Framework: 870. C# - 프로세스의 모든 핸들을 열람
12079정성태12/13/201913349오류 유형: 584. 원격 데스크톱(rdp) 환경에서 다중 또는 고용량 파일 복사 시 "Unspecified error" 오류 발생
... [61]  62  63  64  65  66  67  68  69  70  71  72  73  74  75  ...