Microsoft MVP성태의 닷넷 이야기
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
 
(연관된 글이 2개 있습니다.)

지연 서명된 어셈블리를 sn.exe -Vr 등록 없이 사용하는 방법

지난 글에서,

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

지연 어셈블리를 참조한 EXE를 실행하려면 "sn.exe -Vr [어셈블리 경로]"와 같은 명령어를 이용해 서명 확인 작업을 생략하도록 명시해야만 정상적으로 동작한다고 했습니다.

혹시, 다른 방법은 없을까요? 없으면 이 글을 안 썼겠지요. ^^

지난번 글을 잘 읽어보신 분들이라면 눈치채셨을 수도 있을 텐데요,

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

간단하게, 지연 서명된 어셈블리의 "Flags" 값을 "0x01"에서 "0x09"로 바꿔 지연 서명된 것이 아닌, 서명된 어셈블리라고 CLR에게 알려주면 됩니다. 실제로, CFF Explorer 같은 도구를 이용해 다음과 같이 직접 "Flags" 값을 바꾼 후,

delay_signed_to_signed_1.png

실행하면 bypassTrustedAppStrongNames의 기본값(true) 덕분에 EXE 파일에서 그냥 실행이 됩니다.




그렇다면, 반대로도 가능하겠지요? ^^

서명된 어셈블리의 "Flags" 값을 "0x01"로 바꾸면 이는 '지연 서명된 어셈블리'와 같게 됩니다. 그래도 서명 데이터는 올바르기 때문에 이를 참조한 EXE 실행에는 영향이 없습니다. 또한, 이렇게 바뀐 DLL을 변조하면 서명 데이터가 올바르지 않기 때문에 "System.Security.SecurityException: Strong name validation failed." 예외가 발생합니다. 왜냐하면, '지연 서명된 어셈블리'이기 때문에 bypassTrustedAppStrongNames의 혜택을 받지 못하기 때문입니다. 물론, 그 대신 sn.exe -Vr 등록을 하면 정상적으로 실행됩니다.

정리해 보면, 해당 어셈블리가 지연 서명 또는 서명되었느냐에 대한 여부는 Flags 값에 의해 좌우된다는 점입니다.




참고로, Flags 값을 변경해주는 "CorFlags" 도구가 있지만,

CorFlags.exe (CorFlags Conversion Tool)
; https://docs.microsoft.com/en-us/dotnet/framework/tools/corflags-exe-corflags-conversion-tool

아쉽게도 지원되는 옵션이 한정되어 있기 때문에,

Options:
/ILONLY+ /ILONLY-       Sets/clears the ILONLY flag
/32BITREQ+ /32BITREQ-   Sets/clears the bits indicating 32-bit x86 only
/32BITPREF+ /32BITPREF- Sets/clears the bits indicating 32-bit preferred
/UpgradeCLRHeader       Upgrade the CLR Header to version 2.5
/RevertCLRHeader        Revert the CLR Header to version 2.0

이 글에서 실습한 StrongNameSigned 값을 설정하는 용도로는 사용할 수 없습니다.




[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]

[연관 글]






[최초 등록일: ]
[최종 수정일: 8/2/2017]

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

비밀번호

댓글 작성자
 




[1]  2  3  4  5  6  7  8  9  10  11  12  13  14  15  ...
NoWriterDateCnt.TitleFile(s)
13601정성태4/19/2024189닷넷: 2243. C# - PCM 사운드 재생(NAudio)파일 다운로드1
13600정성태4/18/2024276닷넷: 2242. C# - 관리 스레드와 비관리 스레드
13599정성태4/17/2024291닷넷: 2241. C# - WAV 파일의 PCM 사운드 재생(Windows Multimedia)파일 다운로드1
13598정성태4/16/2024324닷넷: 2240. C# - WAV 파일 포맷 + LIST 헤더파일 다운로드1
13597정성태4/15/2024386닷넷: 2239. C# - WAV 파일의 PCM 데이터 생성 및 출력파일 다운로드1
13596정성태4/14/2024771닷넷: 2238. C# - WAV 기본 파일 포맷파일 다운로드1
13595정성태4/13/2024887닷넷: 2237. C# - Audio 장치 열기 (Windows Multimedia, NAudio)파일 다운로드1
13594정성태4/12/20241012닷넷: 2236. C# - Audio 장치 열람 (Windows Multimedia, NAudio)파일 다운로드1
13593정성태4/8/20241050닷넷: 2235. MSBuild - AccelerateBuildsInVisualStudio 옵션
13592정성태4/2/20241206C/C++: 165. CLion으로 만든 Rust Win32 DLL을 C#과 연동
13591정성태4/2/20241167닷넷: 2234. C# - WPF 응용 프로그램에 Blazor App 통합파일 다운로드1
13590정성태3/31/20241072Linux: 70. Python - uwsgi 응용 프로그램이 k8s 환경에서 OOM 발생하는 문제
13589정성태3/29/20241142닷넷: 2233. C# - 프로세스 CPU 사용량을 나타내는 성능 카운터와 Win32 API파일 다운로드1
13588정성태3/28/20241196닷넷: 2232. C# - Unity + 닷넷 App(WinForms/WPF) 간의 Named Pipe 통신파일 다운로드1
13587정성태3/27/20241154오류 유형: 900. Windows Update 오류 - 8024402C, 80070643
13586정성태3/27/20241296Windows: 263. Windows - 복구 파티션(Recovery Partition) 용량을 늘리는 방법
13585정성태3/26/20241095Windows: 262. PerformanceCounter의 InstanceName에 pid를 추가한 "Process V2"
13584정성태3/26/20241047개발 환경 구성: 708. Unity3D - C# Windows Forms / WPF Application에 통합하는 방법파일 다운로드1
13583정성태3/25/20241157Windows: 261. CPU Utilization이 100% 넘는 경우를 성능 카운터로 확인하는 방법
13582정성태3/19/20241417Windows: 260. CPU 사용률을 나타내는 2가지 수치 - 사용량(Usage)과 활용률(Utilization)파일 다운로드1
13581정성태3/18/20241586개발 환경 구성: 707. 빌드한 Unity3D 프로그램을 C++ Windows Application에 통합하는 방법
13580정성태3/15/20241136닷넷: 2231. C# - ReceiveTimeout, SendTimeout이 적용되지 않는 Socket await 비동기 호출파일 다운로드1
13579정성태3/13/20241493오류 유형: 899. HTTP Error 500.32 - ANCM Failed to Load dll
13578정성태3/11/20241628닷넷: 2230. C# - 덮어쓰기 가능한 환형 큐 (Circular queue)파일 다운로드1
13577정성태3/9/20241874닷넷: 2229. C# - 닷넷을 위한 난독화 도구 소개 (예: ConfuserEx)
[1]  2  3  4  5  6  7  8  9  10  11  12  13  14  15  ...