Microsoft MVP성태의 닷넷 이야기
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
 
(연관된 글이 1개 있습니다.)
(시리즈 글이 11개 있습니다.)
.NET Framework: 202. CLR JIT 컴파일러가 생성한 기계어 코드 확인하는 방법
; https://www.sysnet.pe.kr/2/0/975

.NET Framework: 210. Windbg 환경에서 확인해 본 .NET 메서드 JIT 컴파일 전과 후
; https://www.sysnet.pe.kr/2/0/1023

.NET Framework: 395. C# - 프로퍼티로 정의하면 필드보다 느릴까요?
; https://www.sysnet.pe.kr/2/0/1545

.NET Framework: 396. C# - 프로퍼티로 정의하면 필드보다 느릴까요? - windbg / ollydbg
; https://www.sysnet.pe.kr/2/0/1546

.NET Framework: 542. 닷넷 - 특정 클래스가 로드되었는지 여부를 알 수 있을까?
; https://www.sysnet.pe.kr/2/0/10888

.NET Framework: 545. 닷넷 - 특정 클래스가 로드되었는지 여부를 알 수 있을까? - 두 번째 이야기
; https://www.sysnet.pe.kr/2/0/10893

.NET Framework: 763. .NET Core 2.1 - Tiered Compilation 도입
; https://www.sysnet.pe.kr/2/0/11539

디버깅 기술: 161. Windbg 환경에서 확인해 본 .NET 메서드 JIT 컴파일 전과 후 - 두 번째 이야기
; https://www.sysnet.pe.kr/2/0/12133

.NET Framework: 2015. C# - 인라인 메서드(inline methods)
; https://www.sysnet.pe.kr/2/0/13063

.NET Framework: 2016. C# - JIT 컴파일러의 인라인 메서드 처리 유무
; https://www.sysnet.pe.kr/2/0/13064

닷넷: 2132. C# - sealed 클래스의 메서드를 callback 호출했을 때 인라인 처리가 될까요?
; https://www.sysnet.pe.kr/2/0/13391




C# - 프로퍼티로 정의하면 필드보다 느릴까요? - windbg / ollydbg

오~~~ 재미있는 의견이 올라왔습니다. ^^

"
Visual Studio의 Disassembly는 어셈블리 코드를 최적화해서 보여주더라구요.
"

얼핏 생각하기에는 Visual Studio가 그럴 수 있을까??? 라는 생각이 듭니다. 사실, 역어셈블러를 만드는 것이 바이트에 따라 Intel 명령어 셋을 그대로 해석해야만 맞아들어가기 때문에 중간에 어떤 변조를 하게 되면 뒤이어 줄줄이 깨지기 때문입니다.

그래도 확인을 해봐야 합니다. ^^ 그래서, 이번에는 windbg로 해 보았습니다.

역시 지난번 예제를 x86/Release 빌드로 해서 실행한 후 windbg로 attach 시켰습니다.

sos를 로드하고,

0:007> .loadby sos clr

Form1_Load 메서드의 JIT 컴파일된 함수의 주소를 알아내서,

0:007> !name2ee *!WindowsFormsApplication1.Form1.Form1_Load
Module:      72511000
Assembly:    mscorlib.dll
--------------------------------------
Module:      00562ed4
Assembly:    WindowsFormsApplication1.exe
Token:       06000006
MethodDesc:  005663a8
Name:        WindowsFormsApplication1.Form1.Form1_Load(System.Object, System.EventArgs)
JITTED Code Address: 00820198
--------------------------------------
Module:      6dac1000
Assembly:    System.Windows.Forms.dll
--------------------------------------
Module:      6ff91000
Assembly:    System.Drawing.dll
--------------------------------------
Module:      71b01000
Assembly:    System.dll

그 주소를 역어셈블해 보았습니다.

0:007> u 00820198
00820198 55              push    ebp
00820199 8bec            mov     ebp,esp
0082019b 56              push    esi
0082019c 8bf1            mov     esi,ecx
0082019e ff3584212003    push    dword ptr ds:[34B2184h]
008201a4 6a00            push    0
008201a6 6a00            push    0
008201a8 6a00            push    001fd01aa 6a00            push    0
008201aa 6a00            push    0
008201ac 8b158c212003    mov     edx,dword ptr ds:[34B218Ch]
008201ae 33c9            xor     ecx,ecx
008201b4 e81d1fc46b      call    System_Windows_Forms_ni+0x1520d8 (6dc120d8)

008201b6 b9bcb49172      mov     ecx,offset mscorlib_ni+0x40b4bc (7291b4bc)
008201bb e80f1f58fe      call    007820d4
008201c0 8bc8            mov     ecx,eax
008201c5 0fb68640010000  movzx   eax,byte ptr [esi+140h]
008201c7 884104          mov     byte ptr [ecx+4],al
008201ce e8aa811370      call    System_ni+0x608380 (72108380)

008201d1 b9bcb49172      mov     ecx,offset mscorlib_ni+0x40b4bc (7291b4bc)
008201d6 e8f41e58fe      call    007820d4
008201db 8bc8            mov     ecx,eax
008201e0 0fb68640010000  movzx   eax,byte ptr [esi+140h]
008201e2 884104          mov     byte ptr [ecx+4],al
008201e9 e88f811370      call    System_ni+0x608380 (72108380)

008201ec 5e              pop     esi
008201f1 5d              pop     ebp
008201f2 c20400          ret     4
008201f3

역시나 지난번 글에서 봤던 것처럼 2개의 코드가 반복되는 것을 볼 수 있고 기계어 코드도 완전히 동일합니다.

그렇다면 일단 Visual Studio가 최적화해서 역어셈블하는 것은 아닌 듯합니다.

ollydbg는 어떨까요? 그래서 이번엔 ollydbg로 attach한 다음 "JITTED Code Address: 00820198"의 주소를 덤프해 보았습니다.

windbg_prop_field_1.png

오호~~~ 역시나 동일합니다. 이것으로 테스트 끝~~~! ^^




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

[연관 글]






[최초 등록일: ]
[최종 수정일: 5/17/2022]

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

비밀번호

댓글 작성자
 



2013-11-29 06시07분
[땡초] 간단한 코드라 예외 상황이 발생하지 않아서일까요?
.NET 코드가 런타임에서 변조하는 경우, 이때 VS가 최적화해서 보여주지 않을까 하네요.
아무튼 좋은 아티클 감사합니다.
[guest]
2013-11-29 06시14분
아마 ollydbg랑 visual studio랑 디스어셈블리 코드 결과가 다른 것은 최적화라는 측면보다는 디스어셈블의 방식이 달라서일 것입니다. 리버서들이 사용하는 용어로 ollydbg는 재귀 순회라는 방식으로 디스어셈블을 하고, windbg(아마도 visual studio도 포함해서) 같은 경우에는 선형 스윕을 기본적으로 채택하고 있습니다.

그렇긴 해도, 특별히 난독화 처리 기법이 들어가지 않는 한 2개의 역어셈블 결과는 거의 같을 것입니다.
정성태
2022-04-28 09시25분
(이전에 ollydbg였던) x64dbg
; https://x64dbg.com/
정성태

... 61  62  63  64  65  [66]  67  68  69  70  71  72  73  74  75  ...
NoWriterDateCnt.TitleFile(s)
12288정성태8/5/202016022오류 유형: 637. WCF - The protocol 'net.tcp' does not have an implementation of HostedTransportConfiguration type registered.
12287정성태8/5/202017529오류 유형: 636. C# - libdl.so를 DllImport로 연결 시 docker container 내에서 System.DllNotFoundException 예외 발생
12286정성태8/5/202018874개발 환경 구성: 501. .NET Core 용 container 이미지 만들 때 unzip이 필요한 경우
12285정성태8/4/202018557오류 유형: 635. 윈도우 10 업데이트 - 0xc1900209 [2]
12284정성태8/4/202017895디버깅 기술: 169. Hyper-V의 VM에 대한 메모리 덤프를 뜨는 방법
12283정성태8/3/202018839디버깅 기술: 168. windbg - 필터 드라이버 확인하는 확장 명령어(!fltkd) [2]
12282정성태8/2/202016610디버깅 기술: 167. windbg 디버깅 사례: AppDomain 간의 static 변수 사용으로 인한 crash (2)
12281정성태8/2/202020254개발 환경 구성: 500. (PDB 연결이 없는) DLL의 소스 코드 디버깅을 dotPeek 도구로 해결하는 방법
12280정성태8/2/202018395오류 유형: 634. 오라클 (평생) 무료 클라우드 VM 생성 후 SSH 접속 시 키 오류 발생 [2]
12279정성태7/29/202020132개발 환경 구성: 499. 닷넷에서 접근해보는 InterSystems의 Cache 데이터베이스파일 다운로드1
12278정성태7/23/202016768VS.NET IDE: 149. ("Binary was not built with debug information" 상태로) 소스 코드 디버깅이 안되는 경우
12277정성태7/23/202018670개발 환경 구성: 498. DEVPATH 환경 변수의 사용 예 - .NET Reflector의 (PDB 연결이 없는) DLL의 소스 코드 디버깅
12276정성태7/23/202018080.NET Framework: 930. 개발자를 위한 닷넷 어셈블리 바인딩 - DEVPATH 환경 변수
12275정성태7/22/202020225개발 환경 구성: 497. 닷넷에서 접근해보는 InterSystems의 IRIS Data Platform 데이터베이스파일 다운로드1
12274정성태7/21/202019594개발 환경 구성: 496. Azure - Blob Storage Account의 Location 이전 방법 [1]파일 다운로드1
12273정성태7/18/202022337개발 환경 구성: 495. Azure - Location이 다른 웹/DB 서버의 경우 발생하는 성능 하락
12272정성태7/16/202015507.NET Framework: 929. (StrongName의 버전 구분이 필요 없는) .NET Core 어셈블리 바인딩 규칙 [2]파일 다운로드1
12271정성태7/16/202018493.NET Framework: 928. .NET Framework의 Strong-named 어셈블리 바인딩 (2) - 런타임에 바인딩 리디렉션파일 다운로드1
12270정성태7/16/202019125오류 유형: 633. SSL_CTX_use_certificate_file - error:140AB18F:SSL routines:SSL_CTX_use_certificate:ee key too small
12269정성태7/16/202016447오류 유형: 632. .NET Core 웹 응용 프로그램 - The process was terminated due to an unhandled exception.
12268정성태7/15/202019044오류 유형: 631. .NET Core 웹 응용 프로그램 오류 - HTTP Error 500.35 - ANCM Multiple In-Process Applications in same Process
12267정성태7/15/202021112.NET Framework: 927. C# - 윈도우 프로그램에서 Credential Manager를 이용한 보안 정보 저장파일 다운로드1
12266정성태7/14/202018012오류 유형: 630. 사용자 계정을 지정해 CreateService API로 서비스를 등록한 경우 "Error 1069: The service did not start due to a logon failure." 오류발생
12265정성태7/10/202016917오류 유형: 629. Visual Studio - 웹 애플리케이션 실행 시 "Unable to connect to web server 'IIS Express'." 오류 발생
12264정성태7/9/202028248오류 유형: 628. docker: Error response from daemon: Conflict. The container name "..." is already in use by container "...".
12261정성태7/9/202019484VS.NET IDE: 148. 윈도우 10에서 .NET Core 응용 프로그램을 리눅스 환경에서 실행하는 2가지 방법 - docker, WSL 2 [5]
... 61  62  63  64  65  [66]  67  68  69  70  71  72  73  74  75  ...