Microsoft MVP성태의 닷넷 이야기
.NET Framework: 522. 닷넷의 어셈블리 서명 데이터 확인 방법 [링크 복사], [링크+제목 복사],
조회: 19678
글쓴 사람
정성태 (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

비밀번호

댓글 작성자
 




... 46  47  48  49  50  51  52  53  [54]  55  56  57  58  59  60  ...
NoWriterDateCnt.TitleFile(s)
12282정성태8/2/20209630디버깅 기술: 167. windbg 디버깅 사례: AppDomain 간의 static 변수 사용으로 인한 crash (2)
12281정성태8/2/202012157개발 환경 구성: 500. (PDB 연결이 없는) DLL의 소스 코드 디버깅을 dotPeek 도구로 해결하는 방법
12280정성태8/2/202011323오류 유형: 634. 오라클 (평생) 무료 클라우드 VM 생성 후 SSH 접속 시 키 오류 발생 [2]
12279정성태7/29/202012182개발 환경 구성: 499. 닷넷에서 접근해보는 InterSystems의 Cache 데이터베이스파일 다운로드1
12278정성태7/23/20209501VS.NET IDE: 149. ("Binary was not built with debug information" 상태로) 소스 코드 디버깅이 안되는 경우
12277정성태7/23/202010973개발 환경 구성: 498. DEVPATH 환경 변수의 사용 예 - .NET Reflector의 (PDB 연결이 없는) DLL의 소스 코드 디버깅
12276정성태7/23/202010214.NET Framework: 930. 개발자를 위한 닷넷 어셈블리 바인딩 - DEVPATH 환경 변수
12275정성태7/22/202012708개발 환경 구성: 497. 닷넷에서 접근해보는 InterSystems의 IRIS Data Platform 데이터베이스파일 다운로드1
12274정성태7/21/202012118개발 환경 구성: 496. Azure - Blob Storage Account의 Location 이전 방법 [1]파일 다운로드1
12273정성태7/18/202013763개발 환경 구성: 495. Azure - Location이 다른 웹/DB 서버의 경우 발생하는 성능 하락
12272정성태7/16/20208739.NET Framework: 929. (StrongName의 버전 구분이 필요 없는) .NET Core 어셈블리 바인딩 규칙 [2]파일 다운로드1
12271정성태7/16/202010785.NET Framework: 928. .NET Framework의 Strong-named 어셈블리 바인딩 (2) - 런타임에 바인딩 리디렉션파일 다운로드1
12270정성태7/16/202011619오류 유형: 633. SSL_CTX_use_certificate_file - error:140AB18F:SSL routines:SSL_CTX_use_certificate:ee key too small
12269정성태7/16/20208595오류 유형: 632. .NET Core 웹 응용 프로그램 - The process was terminated due to an unhandled exception.
12268정성태7/15/202010742오류 유형: 631. .NET Core 웹 응용 프로그램 오류 - HTTP Error 500.35 - ANCM Multiple In-Process Applications in same Process
12267정성태7/15/202012429.NET Framework: 927. C# - 윈도우 프로그램에서 Credential Manager를 이용한 보안 정보 저장파일 다운로드1
12266정성태7/14/202010160오류 유형: 630. 사용자 계정을 지정해 CreateService API로 서비스를 등록한 경우 "Error 1069: The service did not start due to a logon failure." 오류발생
12265정성태7/10/20209306오류 유형: 629. Visual Studio - 웹 애플리케이션 실행 시 "Unable to connect to web server 'IIS Express'." 오류 발생
12264정성태7/9/202018386오류 유형: 628. docker: Error response from daemon: Conflict. The container name "..." is already in use by container "...".
12261정성태7/9/202011288VS.NET IDE: 148. 윈도우 10에서 .NET Core 응용 프로그램을 리눅스 환경에서 실행하는 2가지 방법 - docker, WSL 2 [5]
12260정성태7/8/20209644.NET Framework: 926. C# - ETW를 이용한 ThreadPool 스레드 감시파일 다운로드1
12259정성태7/8/20209196오류 유형: 627. nvlddmkm.sys의 BAD_POOL_HEADER BSOD 문제 [1]
12258정성태7/8/202012349기타: 77. DataDog APM 간략 소개
12257정성태7/7/20209371.NET Framework: 925. C# - ETW를 이용한 Monitor Enter/Exit 감시파일 다운로드1
12256정성태7/7/20209793.NET Framework: 924. C# - Reflection으로 변경할 수 없는 readonly 정적 필드 [4]
12255정성태7/6/202010223.NET Framework: 923. C# - ETW(Event Tracing for Windows)를 이용한 Finalizer 실행 감시파일 다운로드1
... 46  47  48  49  50  51  52  53  [54]  55  56  57  58  59  60  ...