Microsoft MVP성태의 닷넷 이야기
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
(연관된 글이 4개 있습니다.)
Visual Studio의 .NET Disassembly 창의 call 호출에 사용되는 주소의 의미는?

아~~~ 토요일의 여유로움! ^^ 그래서 오늘은, 그동안 궁금했던 것 한가지를 파헤쳐 보기로 했습니다.

참고로, 이 글을 보기 전에 아래의 글을 한번 읽어보시는 것도 도움이 되겠습니다.

windbg로 확인하는 .NET CLR 메서드
; https://www.sysnet.pe.kr/2/0/940

예제를 위해, 다음과 같이 간단한 코드를 한번 만들어서 시작해 보겠습니다.

=== .NET 4.0 Console Application ===

static void Main(string[] args)
{
    SqlConnection connection = new SqlConnection();
    connection.CreateCommand();
}

이를 disassembly 창으로 보면 다음과 같이 나옵니다.

--- D:\...[생략]...\ConsoleApplication1\Program.cs 
    14:         {
00000000 55                   push        ebp 
00000001 8B EC                mov         ebp,esp 
00000003 83 EC 0C             sub         esp,0Ch 
00000006 89 4D FC             mov         dword ptr [ebp-4],ecx 
00000009 83 3D 3C 31 19 00 00 cmp         dword ptr ds:[0019313Ch],0 
00000010 74 05                je          00000017 
00000012 E8 14 44 36 73       call        7336442B 
00000017 33 D2                xor         edx,edx 
00000019 89 55 F8             mov         dword ptr [ebp-8],edx 
0000001c 90                   nop 
    15:             ShowAddress();
0000001d FF 15 04 34 19 00    call        dword ptr ds:[00193404h] 
00000023 90                   nop 
    16: 
    17:             SqlConnection connection = new SqlConnection();
00000024 B9 E0 9C C2 00       mov         ecx,0C29CE0h 
00000029 E8 34 0D 0D 73       call        730D0D62 
0000002e 89 45 F4             mov         dword ptr [ebp-0Ch],eax 
00000031 8B 4D F4             mov         ecx,dword ptr [ebp-0Ch] 
00000034 E8 1B AE 56 FF       call        FF56AE54 
00000039 8B 45 F4             mov         eax,dword ptr [ebp-0Ch] 
0000003c 89 45 F8             mov         dword ptr [ebp-8],eax 
    18:             connection.CreateCommand();
0000003f 8B 4D F8             mov         ecx,dword ptr [ebp-8] 
00000042 39 09                cmp         dword ptr [ecx],ecx 
00000044 E8 1B AE 56 FF       call        FF56AE64 
00000049 90                   nop 
    19:         }

call (E8) 명령어는 변위 주솟값을 오퍼랜드로 받기 때문에, (액면 그대로 해석하자면) "FF56AE64" 값은 -11096476으로 위의 call 명령어가 수행된 이후 메모리의 - 방향으로 11096476만큼 점프를 한 후 실행되는 구조가 됩니다.

여기서 잠깐, SqlConnection.CreateCommand의 함수 주소를 한번 구해볼까요?

MethodBase func = typeof(SqlConnection).GetMethod("CreateCommand", BindingFlags.Instance | BindingFlags.Public);
IntPtr pOld = func.MethodHandle.GetFunctionPointer();

이렇게 해서 출력해 보니, Jitted된 FunctionPointer 값이 0x19ce54로 나옵니다. 그렇다면, Main 프로그램의 connection.CreateCommand 호출이 발생한 [call 명령어 다음 주소 + (-11096476) == 0x19ce54]가 나와야 합니다. 정말로 그럴까요?

이를 확인하려면 call 명령어의 정확한 Instruction Pointer 값을 알아내야 합니다. 왜냐하면 Visual Studio의 disassembly 창에서는 0부터 시작하는 기계어 코드를 순서대로 나열할뿐 절대값 주소를 출력하지 않기 때문입니다.

바로 이런 때 필요한 것이 ^^ sos.dll입니다.

Visual Studio의 "Immediate Window"에서 sos를 로드하고, (그 전에, 반드시 Debug 메뉴의 "Enable unmanaged code debugging"을 체크하고!)

!load "C:\\Windows\\Microsoft.NET\\Framework\\v4.0.30319\\SOS.dll"
extension c:\windows\microsoft.net\framework\v4.0.30319\sos.dll loaded

우선, Main 메서드가 컴파일 된 어셈블리 코드 및 SqlConnection.CreateCommand를 호출한 call 명령어의 위치를 알아야겠지요.

!name2ee ConsoleApplication1.exe!ConsoleApplication1.Program.Main
PDB symbol for clr.dll not loaded
Module:      00192e9c
Assembly:    ConsoleApplication1.exe
Token:       7891ac1506000001
MethodDesc:  001933f0
Name:        ConsoleApplication1.Program.Main(System.String[])
JITTED Code Address: 00c31ff0

이어서 JITTED Code Address를 대상으로 디스어셈블을 하면 아래와 같은 결과를 확인할 수 있습니다.

!u 00c31ff0
Normal JIT generated code
ConsoleApplication1.Program.Main(System.String[])
Begin 00c31ff0, size 4f
>>> 00C31FF0 55               push        ebp
00C31FF1 8BEC             mov         ebp,esp
00C31FF3 83EC0C           sub         esp,0Ch
00C31FF6 894DFC           mov         dword ptr [ebp-4],ecx
00C31FF9 833D3C31190000   cmp         dword ptr ds:[0019313Ch],0
00C32000 7405             je          00C32007
00C32002 E814443673       call        73F9641B (JitHelp: CORINFO_HELP_DBG_IS_JUST_MY_CODE)
00C32007 33D2             xor         edx,edx
00C32009 8955F8           mov         dword ptr [ebp-8],edx
00C3200C 90               nop
00C3200D FF1504341900     call        dword ptr ds:[00193404h] (ConsoleApplication1.Program.ShowAddress(), mdToken: 06000002)
00C32013 90               nop
00C32014 B9E09CC200       mov         ecx,0C29CE0h (MT: System.Data.SqlClient.SqlConnection)
00C32019 E8340D0D73       call        73D02D52 (JitHelp: CORINFO_HELP_NEW_CROSSCONTEXT)
00C3201E 8945F4           mov         dword ptr [ebp-0Ch],eax
00C32021 8B4DF4           mov         ecx,dword ptr [ebp-0Ch]
00C32024 E81BAE56FF       call        0019CE44 (System.Data.SqlClient.SqlConnection..ctor(), mdToken: 060024ec)
00C32029 8B45F4           mov         eax,dword ptr [ebp-0Ch]
00C3202C 8945F8           mov         dword ptr [ebp-8],eax
00C3202F 8B4DF8           mov         ecx,dword ptr [ebp-8]
00C32032 3909             cmp         dword ptr [ecx],ecx
00C32034 E81BAE56FF       call        0019CE54 (System.Data.SqlClient.SqlConnection.CreateCommand(), mdToken: 060024c9)
00C32039 90               nop
00C3203A 90               nop
00C3203B 8BE5             mov         esp,ebp
00C3203D 5D               pop         ebp
00C3203E C3               ret

오호,,, 위의 "call 0x19ce54" 값은 MethodHandle.GetFunctionPointer의 값으로 반환받은 값과 동일하다는 것을 알 수 있습니다. 그렇다면, !u 명령어로 보여지는 어셈블리 코드 값의 call 명령어에 나오는 값은 변위값이라기 보다는 (서비스 차원에서) 계산되어진 최종 주솟값을 보여주는 것이라고 판단할 수 있습니다. (사실, 기계어 코드로 나온 E81BAE56FF에서 "0xff56ae1b" 값이 실제 변위값입니다.)

호기심 차원에서, 여기서 잠깐 실제 SqlConnection.CreateCommand의 기계어 주소를 확인해 볼까요?

!name2ee System.Data.dll!System.Data.SqlClient.SqlConnection.CreateCommand
Module:      001934dc
Assembly:    System.Data.dll
Token:       6d37ad85060024c9
MethodDesc:  00c299a4
Name:        System.Data.SqlClient.SqlConnection.CreateCommand()
JITTED Code Address: 076db240

웬일인지, 0019CE54 != 076db240 다른 결과를 보여주고 있습니다. 그렇다면 0019CE54 위치의 코드를 마저 확인해 봐야할 필요가 있습니다.

!u 0019CE54
Unmanaged code
0019CE54 B8A499C200       mov         eax,0C299A4h
0019CE59 90               nop
0019CE5A E88162B473       call        73CE30E0
0019CE5F E9DCE35307       jmp         076DB240
0019CE64 00B000EB7CB0     add         byte ptr [eax+B07CEB00h],dh
0019CE6A 02EB             add         ch,bl
0019CE6C 78B0             js          0019CE1E
0019CE6E 05EB74B008       add         eax,8B074EBh
0019CE73 EB70             jmp         0019CEE5
0019CE75 B00A             mov         al,0Ah

아하 정말 그렇군요. C/C++에서 마치 IAT(Import Address Table)을 이용해서 외부 주솟값을 참조하듯, .NET에서도 외부 DLL의 함수를 부를 때 위와 같이 일종의 stub 코드를 경유하는 것을 확인할 수 있습니다.




sos와 GetFunctionPointer 관계를 알아보느라 잠시 본론에서 멀어졌는데요. ^^ 어쨌든 위와 같이 해서 구하고자 했던 "connection.CreateCommand 호출이 발생한 call 명령어 다음 주소" 값이 00C32039라는 것은 알아냈습니다.

다시 한번 disassembly 코드를 적어보고,

--- Disassembly 창 ---
00000044 E8 1B AE 56 FF       call        FF56AE64  (unsigned 10진수: 4283870820, signed 10진수: -11096476)

이제, 예전에 하기로 했던 계산을 마치면 결과는 다음과 같습니다.

00C32039 + FF56AE64 = 10019CE9D ==> 4byte 값만 취하면 ==> 0x19CE9D != (예상값 0x19ce54)

음... 아쉽게도 0x19ce9d 값으로는 이론과 맞지 않는 결과가 나와버렸습니다. 그래도 어쩐지 희망이 보이는 것 같습니다. 왠지 SOS.dll의 call에서 보여준 절대 주솟값 0x19ce54와 어딘지 비슷해 보입니다. 그 차이는 정확히 0x19ce9d - 0x19ce54 = 0x49 값이 되고, 이는 Disassembly 창에서만 보여주던 "0부터 시작하는 독특한 코드 주솟값"의 위치와 일치합니다.

diff_disassembly_view_code_1.png

휴... 그렇군요. Visual Studio의 disassembly 창에서 보여주는 call 명령어의 옵셋값은 그 윈도우에서만 유효한, 즉 개발자 입장에서는 매우 도움이 안되는 값을 출력해 주고 있는 것입니다.

암튼... ^^ 여기까지 해서 MethodHandle.GetFunctionPointer와 Visual Studio의 Disassembly 창의 call 명령어, sos.dll의 !u 명령어로 본 어셈블리 코드값에 대한 관계를 알아보았습니다.

(첨부 파일은 제가 수행한 예제 코드입니다.)



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

[연관 글]






[최초 등록일: ]
[최종 수정일: 6/22/2021]

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

비밀번호

댓글 작성자
 



2011-08-03 05시01분
!name2ee 명령어에 대해서 기억해 두어야 할 점.

windbg에서는 name2ee 명령어를 다음과 같이 모듈명만 명시해주어도 되지만,

!name2ee ConsoleApplication1!ConsoleApplication1.Program.Main

Visual Studio에서는 다음과 같이 EXE까지 명시를 해주어야 합니다.

!name2ee ConsoleApplication1.exe!ConsoleApplication1.Program.Main
정성태

... [16]  17  18  19  20  21  22  23  24  25  26  27  28  29  30  ...
NoWriterDateCnt.TitleFile(s)
13232정성태1/27/20234841스크립트: 43. uwsgi의 --processes와 --threads 옵션
13231정성태1/27/20233759오류 유형: 839. python - TypeError: '...' object is not callable
13230정성태1/26/20234128개발 환경 구성: 660. WSL 2 내부로부터 호스트 측의 네트워크로 UDP 데이터가 1개의 패킷으로만 제한되는 문제
13229정성태1/25/20235141.NET Framework: 2090. C# - UDP Datagram의 최대 크기
13228정성태1/24/20235252.NET Framework: 2089. C# - WMI 논리 디스크가 속한 물리 디스크의 정보를 얻는 방법 [2]파일 다운로드1
13227정성태1/23/20234933개발 환경 구성: 659. Windows - IP MTU 값을 바꿀 수 있을까요? [1]
13226정성태1/23/20234633.NET Framework: 2088. .NET 5부터 지원하는 GetRawSocketOption 사용 시 주의할 점
13225정성태1/21/20233891개발 환경 구성: 658. Windows에서 실행 중인 소켓 서버를 다른 PC 또는 WSL에서 접속할 수 없는 경우
13224정성태1/21/20234250Windows: 221. Windows - Private/Public/Domain이 아닌 네트워크 어댑터 단위로 방화벽을 on/off하는 방법
13223정성태1/20/20234454오류 유형: 838. RDP 연결 오류 - The two computers couldn't connect in the amount of time allotted
13222정성태1/20/20234130개발 환경 구성: 657. WSL - DockerDesktop.vhdx 파일 위치를 옮기는 방법
13221정성태1/19/20234358Linux: 57. C# - 리눅스 프로세스 메모리 정보파일 다운로드1
13220정성태1/19/20234470오류 유형: 837. NETSDK1045 The current .NET SDK does not support targeting .NET ...
13219정성태1/18/20234015Windows: 220. 네트워크의 인터넷 접속 가능 여부에 대한 판단 기준
13218정성태1/17/20233949VS.NET IDE: 178. Visual Studio 17.5 (Preview 2) - 포트 터널링을 이용한 웹 응용 프로그램의 외부 접근 허용
13217정성태1/13/20234531디버깅 기술: 185. windbg - 64비트 운영체제에서 작업 관리자로 뜬 32비트 프로세스의 덤프를 sos로 디버깅하는 방법
13216정성태1/12/20234786디버깅 기술: 184. windbg - 32비트 프로세스의 메모리 덤프인 경우 !peb 명령어로 나타나지 않는 환경 변수
13215정성태1/11/20236350Linux: 56. 리눅스 - /proc/pid/stat 정보를 이용해 프로세스의 CPU 사용량 구하는 방법 [1]
13214정성태1/10/20235893.NET Framework: 2087. .NET 6부터 SourceGenerator와 통합된 System.Text.Json [1]파일 다운로드1
13213정성태1/9/20235436오류 유형: 836. docker 이미지 빌드 시 "RUN apt install ..." 명령어가 실패하는 이유
13212정성태1/8/20235181기타: 85. 단정도/배정도 부동 소수점의 정밀도(Precision)에 따른 형변환 손실
13211정성태1/6/20235218웹: 42. (https가 아닌) http 다운로드를 막는 웹 브라우저
13210정성태1/5/20234304Windows: 219. 윈도우 x64의 경우 0x00000000`7ffe0000 아래의 주소는 왜 사용하지 않을까요?
13209정성태1/4/20234211Windows: 218. 왜 윈도우에서 가상 메모리 공간은 64KB 정렬이 된 걸까요?
13208정성태1/3/20234183.NET Framework: 2086. C# - Windows 운영체제의 2MB Large 페이지 크기 할당 방법파일 다운로드1
13207정성태12/26/20224455.NET Framework: 2085. C# - gpedit.msc의 "User Rights Assignment" 특권을 코드로 설정/해제하는 방법파일 다운로드1
... [16]  17  18  19  20  21  22  23  24  25  26  27  28  29  30  ...