Microsoft MVP성태의 닷넷 이야기
.NET Framework: 522. 닷넷의 어셈블리 서명 데이터 확인 방법 [링크 복사], [링크+제목 복사],
조회: 27780
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
(연관된 글이 1개 있습니다.)
(시리즈 글이 6개 있습니다.)
.NET Framework: 522. 닷넷의 어셈블리 서명 데이터 확인 방법
; https://www.sysnet.pe.kr/2/0/10816

.NET Framework: 667. bypassTrustedAppStrongNames 옵션 설명
; https://www.sysnet.pe.kr/2/0/11257

.NET Framework: 668. 지연 서명된 DLL과 서명된 DLL의 차이점
; https://www.sysnet.pe.kr/2/0/11258

.NET Framework: 669. 지연 서명된 어셈블리를 sn.exe -Vr 등록 없이 사용하는 방법
; https://www.sysnet.pe.kr/2/0/11259

디버깅 기술: 91. windbg - 풀 덤프 파일로부터 강력한 이름의 어셈블리 추출 후 사용하는 방법
; https://www.sysnet.pe.kr/2/0/11261

개발 환경 구성: 390. C# - 컴파일러 옵션 OSS signing / Public Signing
; https://www.sysnet.pe.kr/2/0/11627




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

비밀번호

댓글 작성자
 




... [106]  107  108  109  110  111  112  113  114  115  116  117  118  119  120  ...
NoWriterDateCnt.TitleFile(s)
11274정성태8/22/201719372.NET Framework: 674. Thread 타입의 Suspend/Resume/Join 사용 관련 예외 처리
11273정성태8/22/201721633오류 유형: 415. 윈도우 업데이트 에러 Error 0x80070643
11272정성태8/21/201724788VS.NET IDE: 120. 비주얼 스튜디오 2017 버전 15.3.1 - C# 7.1 공개 [2]
11271정성태8/19/201719228VS.NET IDE: 119. Visual Studio 2017에서 .NET Core 2.0 프로젝트 환경 구성하는 방법
11270정성태8/17/201730712.NET Framework: 673. C#에서 enum을 boxing 없이 int로 변환하기 [2]
11269정성태8/17/201721486디버깅 기술: 93. windbg - 풀 덤프에서 .NET 스레드의 상태를 알아내는 방법
11268정성태8/14/201721057디버깅 기술: 92. windbg - C# Monitor Lock을 획득하고 있는 스레드 찾는 방법
11267정성태8/10/201725115.NET Framework: 672. 모노 개발 환경
11266정성태8/10/201724916.NET Framework: 671. C# 6.0 이상의 소스 코드를 Visual Studio 설치 없이 명령행에서 컴파일하는 방법
11265정성태8/10/201753170기타: 66. 도서: 시작하세요! C# 7.1 프로그래밍: 기본 문법부터 실전 예제까지 [11]
11264정성태8/9/201724079오류 유형: 414. UWP app을 signtool.exe로 서명 시 0x8007000b 오류 발생
11263정성태8/9/201719565오류 유형: 413. The C# project "..." is targeting ".NETFramework, Version=v4.0", which is not installed on this machine. [3]
11262정성태8/5/201718248오류 유형: 412. windbg - SOS does not support the current target architecture. [3]
11261정성태8/4/201720833디버깅 기술: 91. windbg - 풀 덤프 파일로부터 강력한 이름의 어셈블리 추출 후 사용하는 방법
11260정성태8/3/201718935.NET Framework: 670. C# - 실행 파일로부터 공개키를 추출하는 방법
11259정성태8/2/201718170.NET Framework: 669. 지연 서명된 어셈블리를 sn.exe -Vr 등록 없이 사용하는 방법
11258정성태8/1/201718971.NET Framework: 668. 지연 서명된 DLL과 서명된 DLL의 차이점파일 다운로드1
11257정성태7/31/201719162.NET Framework: 667. bypassTrustedAppStrongNames 옵션 설명파일 다운로드1
11256정성태7/25/201720656디버깅 기술: 90. windbg의 lm 명령으로 보이지 않는 .NET 4.0 ClassLibrary를 명시적으로 로드하는 방법 [1]
11255정성태7/18/201723207디버깅 기술: 89. Win32 Debug CRT Heap Internals의 0xBAADF00D 표시 재현 [1]파일 다운로드3
11254정성태7/17/201719567개발 환경 구성: 322. "Visual Studio Emulator for Android" 에뮬레이터를 "Android Studio"와 함께 쓰는 방법
11253정성태7/17/201719910Math: 21. "Coding the Matrix" 문제 2.5.1 풀이 [1]파일 다운로드1
11252정성태7/13/201718447오류 유형: 411. RTVS 또는 PTVS 실행 시 Could not load type 'Microsoft.VisualStudio.InteractiveWindow.Shell.IVsInteractiveWindowFactory2'
11251정성태7/13/201717133디버깅 기술: 88. windbg 분석 - webengine4.dll의 MgdExplicitFlush에서 발생한 System.AccessViolationException의 crash 문제 (2)
11250정성태7/13/201720696디버깅 기술: 87. windbg 분석 - webengine4.dll의 MgdExplicitFlush에서 발생한 System.AccessViolationException의 crash 문제 [1]
11249정성태7/12/201718521오류 유형: 410. LoadLibrary("[...].dll") failed - The specified procedure could not be found.
... [106]  107  108  109  110  111  112  113  114  115  116  117  118  119  120  ...