성태의 닷넷 이야기
홈 주인
모아 놓은 자료
프로그래밍
질문/답변
사용자 관리
사용자
메뉴
아티클
외부 아티클
유용한 코드
온라인 기능
MathJax 입력기
최근 덧글
[정성태] VT sequences to "CONOUT$" vs. STD_O...
[정성태] NetCoreDbg is a managed code debugg...
[정성태] Evaluating tail call elimination in...
[정성태] What’s new in System.Text.Json in ....
[정성태] What's new in .NET 9: Cryptography ...
[정성태] 아... 제시해 주신 "https://akrzemi1.wordp...
[정성태] 다시 질문을 정리할 필요가 있을 것 같습니다. 제가 본문에...
[이승준] 완전히 잘못 짚었습니다. 댓글 지우고 싶네요. 검색을 해보...
[정성태] 우선 답글 감사합니다. ^^ 그런데, 사실 저 예제는 (g...
[이승준] 수정이 안되어서... byteArray는 BYTE* 타입입니다...
글쓰기
제목
이름
암호
전자우편
HTML
홈페이지
유형
제니퍼 .NET
닷넷
COM 개체 관련
스크립트
VC++
VS.NET IDE
Windows
Team Foundation Server
디버깅 기술
오류 유형
개발 환경 구성
웹
기타
Linux
Java
DDK
Math
Phone
Graphics
사물인터넷
부모글 보이기/감추기
내용
<div style='display: inline'> <h1 style='font-family: Malgun Gothic, Consolas; font-size: 20pt; color: #006699; text-align: center; font-weight: bold'>bypassTrustedAppStrongNames 옵션 설명</h1> <p> 프로그램을 실행했을 때 다음과 같은 예외가 발생할 수 있습니다.<br /> <br /> <pre style='margin: 10px 0px 10px 10px; padding: 10px 0px 10px 10px; background-color: #fbedbb; overflow: auto; font-family: Consolas, Verdana;' > Unhandled Exception: System.IO.FileLoadException: Could not load file or assembly 'ClassLibrary1, Version=1.0.0.0, Culture=neutral, PublicKeyToken=90aac46759611727' or one of its dependencies. Strong name validation failed. (Exception from HRESULT: 0x8013141A) ---> System.Security.SecurityException: Strong name validation failed. (Exception from HRESULT: 0x8013141A) --- End of inner exception stack trace --- at ClassLibrary1.Class1.Do() at ConsoleApp1.Program.Main(String[] args) in C:\ConsoleApp1\Program.cs:line 11 </pre> <br /> 원인은 간단합니다. 강력한 이름(Strong-named)으로 서명된 어셈블리를 로드하려고 했지만 해당 어셈블리의 내용이 임의로 변경된 경우 서명된 내용과 달라 로딩 시 예외가 발생한 것입니다.<br /> <br /> 재현을 한번 해볼까요? ^^<br /> <br /> 우선 다음과 같은 코드를 가진 라이브러리를 생성하고 서명을 한 후,<br /> <br /> <pre style='margin: 10px 0px 10px 10px; padding: 10px 0px 10px 10px; background-color: #fbedbb; overflow: auto; font-family: Consolas, Verdana;' > // ClassLibrary1.dll 프로젝트 using System; namespace ClassLibrary1 { public class Class1 { public void Do() { Console.WriteLine("TEST IS GOOD"); } } } </pre> <br /> 콘솔 EXE에서 이렇게 사용합니다.<br /> <br /> <pre style='margin: 10px 0px 10px 10px; padding: 10px 0px 10px 10px; background-color: #fbedbb; overflow: auto; font-family: Consolas, Verdana;' > // .NET 4.0 이상의 ConsoleApp1.exe 프로젝트 using System; namespace ConsoleApp1 { class Program { static void Main(string[] args) { ClassLibrary1.Class1 cl = new ClassLibrary1.Class1(); cl.Do(); Console.WriteLine("Press..."); Console.ReadLine(); } } } </pre> <br /> 빌드한 결과물에서, dnSpy.exe 등을 이용해 Class1.Do 메서드의 내용을 임의로 수정하거나 다음의 글에 따라,<br /> <pre style='margin: 10px 0px 10px 10px; padding: 10px 0px 10px 10px; background-color: #fbedbb; overflow: auto; font-family: Consolas, Verdana;' > 닷넷의 어셈블리 서명 데이터 확인 방법 ; <a target='tab' href='http://www.sysnet.pe.kr/2/0/10816'>http://www.sysnet.pe.kr/2/0/10816</a> </pre> <br /> 서명 데이터를 임의로 바꿔주면 됩니다.<br /> <br /> <hr style='width: 50%' /><br /> <br /> 그런데, 이렇게 변조된 DLL을 사용함에도 불구하고 여전히 정상적으로 실행될 것입니다. 왜냐하면, .NET 3.5 SP1부터는 "Full Trust" 상태의 AppDomain에 어셈블리가 로딩될 때는 서명을 검증하지 않기 때문입니다. 이에 대해서는 다음의 글들이 자세하게 설명하고 있습니다.<br /> <br /> <pre style='margin: 10px 0px 10px 10px; padding: 10px 0px 10px 10px; background-color: #fbedbb; overflow: auto; font-family: Consolas, Verdana;' > How to: Disable the Strong-Name Bypass Feature ; <a target='tab' href='https://learn.microsoft.com/en-us/dotnet/framework/app-domains/how-to-disable-the-strong-name-bypass-feature'>https://learn.microsoft.com/en-us/dotnet/framework/app-domains/how-to-disable-the-strong-name-bypass-feature</a> Strong Name Bypass ; <a target='tab' href='https://learn.microsoft.com/ko-kr/archive/blogs/shawnfa/strong-name-bypass'>https://learn.microsoft.com/ko-kr/archive/blogs/shawnfa/strong-name-bypass</a> </pre> <br /> 정리하면 다음의 조건인데요.<br /> <br /> <ol> <li>Fully signed (delay signed assemblies still require a skip verification entry) </li> <li>Fully trusted (without considering its strong name evidence) </li> <li>Loaded into a Fully trusted AppDomain </li> <li>Loaded from a location under the AppDomain's ApplicationBase</li> </ol> <br /> 따라서 "Fully trusted"로 실행되는 ConsoleApp.exe 내의 "Fully trusted AppDomain" 내에 (변조되었지만) ClassLibrary1.dll이 로드되기 때문에 서명 확인 절차가 생략되므로 Class1.Do 메서드의 내용을 임의로 수정했어도 별다른 영향 없이 잘 실행이 된 것입니다.<br /> <br /> 만약 이전처럼 무조건 서명 데이터를 검증하도록 만들고 싶다면 app.config 파일에 bypassTrustedAppStrongNames 옵션을 다음과 같이 설정해 주면 됩니다.<br /> <br /> <pre style='margin: 10px 0px 10px 10px; padding: 10px 0px 10px 10px; background-color: #fbedbb; overflow: auto; font-family: Consolas, Verdana;' > <?xml version="1.0" encoding="utf-8"?> <configuration> <runtime> <span style='color: blue; font-weight: bold'><bypassTrustedAppStrongNames enabled="false" /></span> </runtime> </configuration> </pre> <br /> 즉, .NET 3.5 SP1 이후부터는 bypassTrustedAppStrongNames 옵션의 기본 값이 true인 체로 실행되고 있는 것입니다.<br /> <br /> <hr style='width: 50%' /><br /> <br /> 반면, 변조된 ClassLibrary1.dll을 ASP.NET 웹 애플리케이션에서 참조하는 경우에는 상황이 달라집니다. 로컬에서 IIS 또는 IIS Express에 상관없이 다음과 같은 예외가 발생합니다.<br /> <br /> <div style='BACKGROUND-COLOR: #ccffcc; padding: 10px 10px 5px 10px; MARGIN: 0px 10px 10px 10px; FONT-FAMILY: Malgun Gothic, Consolas, Verdana; COLOR: #005555'> System.IO.FileLoadException: 'Could not load file or assembly 'file:///C:\WebApplication1\bin\ClassLibrary1.dll' or one of its dependencies. Strong name signature could not be verified. The assembly may have been tampered with, or it was delay signed but not fully signed with the correct private key. (Exception from HRESULT: 0x80131045)'<br /> </div><br /> <br /> 재미있는 것은, 검증이 이뤄지는 DLL의 위치가 ASP.NET의 "/bin" 폴더 및 그 하위인 경우로만 제한된다는 것입니다. 즉, 그 이외의 위치에 있는 DLL인 경우는 검증 대상이 아니라는 것인데, 가령 ClassLibrary1.dll 파일을 몇몇 폴더에 복사해 다음과 같은 식으로 직접 테스트해 볼 수 있습니다.<br /> <br /> <pre style='margin: 10px 0px 10px 10px; padding: 10px 0px 10px 10px; background-color: #fbedbb; overflow: auto; font-family: Consolas, Verdana;' > protected void Page_Load(object sender, EventArgs e) { string path = AppDomain.CurrentDomain.BaseDirectory; // "C:\\WebApplication1" { string filePath = Path.Combine(path, "ClassLibrary1.dll"); Assembly asm = Assembly.LoadFrom(filePath, null); <span style='color: blue; font-weight: bold'>// OK - c:\WebApplication1\ClassLibrary1.dll</span> } { string filePath = Path.Combine(path, "Test", "ClassLibrary1.dll"); Assembly asm = Assembly.LoadFrom(filePath, null); <span style='color: blue; font-weight: bold'>// OK - c:\WebApplication1\Test\ClassLibrary1.dll</span> } { string filePath = Path.Combine(path, "bin", "Test", "ClassLibrary1.dll"); Assembly asm = Assembly.LoadFrom(filePath, null); <span style='color: blue; font-weight: bold'>// 검증 실패 - c:\WebApplication1\bin\Test\ClassLibrary1.dll</span> } } </pre> <br /> 더욱 재미있는 것은, ASP.NET의 경우 bypassTrustedAppStrongNames 조건을 false로 주어도 여전히 bin 폴더(및 그 하위) 이외에 배포된 DLL은 검증 과정 없이 직접 로딩이 가능하다는 점입니다. 또한 그 반대로 bypassTrustedAppStrongNames 조건을 true로 주어도 bin 폴더(및 그 하위)의 경우에는 검증 작업이 생략되지 않습니다. (아쉽게도 그 이유는 아직 모르겠습니다. ASP.NET이 특별 대우인 것인지, 아니면 bypassTrustedAppStrongNames를 타기 위한 4가지 조건에 안 맞는 것이 있는지!)<br /> <br /> (<a target='tab' href='http://www.sysnet.pe.kr/bbs/DownloadAttachment.aspx?fid=1161&boardid=331301885'>첨부 파일은 이 글의 예제 코드를 포함</a>합니다.)<br /> </p><br /> <br /><hr /><span style='color: Maroon'>[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]</span> </div>
첨부파일
스팸 방지용 인증 번호
9243
(왼쪽의 숫자를 입력해야 합니다.)