Microsoft MVP성태의 닷넷 이야기
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
 

(시리즈 글이 5개 있습니다.)
오류 유형: 412. windbg - SOS does not support the current target architecture.
; https://www.sysnet.pe.kr/2/0/11262

오류 유형: 798. WinDbg - Failed to load data access module, 0x80004002
; https://www.sysnet.pe.kr/2/0/12994

디버깅 기술: 184. windbg - 32비트 프로세스의 메모리 덤프인 경우 !peb 명령어로 나타나지 않는 환경 변수
; https://www.sysnet.pe.kr/2/0/13216

디버깅 기술: 185. windbg - 64비트 운영체제에서 작업 관리자로 뜬 32비트 프로세스의 덤프를 sos로 디버깅하는 방법
; https://www.sysnet.pe.kr/2/0/13217

디버깅 기술: 201. WinDbg - sos threads 명령어 실행 시 "Failed to request ThreadStore"
; https://www.sysnet.pe.kr/2/0/13725




windbg - 32비트 프로세스의 메모리 덤프인 경우 !peb 명령어로 나타나지 않는 환경 변수

간단하게 다음의 코드를 작성하고,

using System;

internal class Program
{
    static void Main(string[] args)
    {
        Environment.SetEnvironmentVariable("TEST", "1");
        Console.ReadLine();
    }
}

32비트로 빌드한 다음, 64비트 운영체제에서 실행해 봅니다. 이후 Console.ReadLine에 걸려 있는 프로세스를 "작업 관리자"를 이용해 메모리 덤프를 떠 windbg로 확인하면 다음과 같이 "TEST" 환경 변수가 없습니다.

0:000> !peb
Wow64 PEB32 at d4c000
    ...[생략]...
    Environment:  0000000000000000
       Unable to read Environment string.

Wow64 PEB at 0000000000d4b000
    InheritedAddressSpace:    No
    ...[생략]...
    DllPath:      '< Name not readable >'
    Environment:  00000000010b1300
        ...[생략]...
        TEMP=C:\Users\testusr\AppData\Local\Temp
        ThreadedWaitDialogDpiContext=-4
        ...[생략]...

대신 동일한 32비트 프로세스를 process explorer로 메모리 덤프를 뜨면 이렇게 잘 나옵니다.

0:000> !peb
PEB at 00d4c000
    InheritedAddressSpace:    No
    ...[생략]...
    DllPath:      '< Name not readable >'
    Environment:  0121c730
        ...[생략]...
        TEMP=C:\Users\testusr\AppData\Local\Temp
        TEST=1
        ThreadedWaitDialogDpiContext=-4
        ...[생략]...

결국, 64비트 환경에서 32비트 프로세스에 대해서는 언제나 작업 관리자가 아닌 process explorer를 이용하는 것이 답입니다. ^^

windbg - SOS does not support the current target architecture.
; https://www.sysnet.pe.kr/2/0/11262

WinDbg - Failed to load data access module, 0x80004002
; https://www.sysnet.pe.kr/2/0/12994




비록 작업 관리자가 뜬 메모리 덤프의 해석을 windbg가 혼동하고는 있지만 해당 덤프에는 정상적으로 데이터가 담겨 있다는 사실에는 변함이 없습니다. 따라서, 약간의 단계를 추가하면 (변경된) 환경 변수를 보는 것이 가능합니다.

위의 2개 덤프 기록에서 !peb 명령어의 결과를 보면,

// 작업 관리자로 뜬 x86 프로세스의 덤프

0:000> !peb
Wow64 PEB32 at d4c000
        ...[생략]...

// Process Explorer로 뜬 x86 프로세스의 덤프

0:000> !peb
PEB at 00d4c000
    ...[생략]...

그나마 "Wow64 PEB32"로 출력된 d4c000 주소가 (변경된 환경 변수의 위치를 담고 있는) PEB의 주소와 같다는 것을 확인할 수 있습니다. PEB 구조체는 다음과 같이 정의되고,

// https://theroadtodelphi.com/2012/05/26/getting-the-environment-variables-of-an-external-x86-process/
typedef struct _PEB {
  BYTE                          Reserved1[2];
  BYTE                          BeingDebugged;
  BYTE                          Reserved2[1];
  PVOID                         Reserved3[2];
  PPEB_LDR_DATA                 Ldr;
  PRTL_USER_PROCESS_PARAMETERS  ProcessParameters;
  BYTE                          Reserved4[104];
  PVOID                         Reserved5[52];
  PPS_POST_PROCESS_INIT_ROUTINE PostProcessInitRoutine;
  BYTE                          Reserved6[128];
  PVOID                         Reserved7[1];
  ULONG                         SessionId;
} PEB, *PPEB;

0:000> dt _PEB32
ntdll!_PEB32
   +0x000 InheritedAddressSpace : UChar
   +0x001 ReadImageFileExecOptions : UChar
   +0x002 BeingDebugged    : UChar
   +0x003 BitField         : UChar
   +0x003 ImageUsesLargePages : Pos 0, 1 Bit
   +0x003 IsProtectedProcess : Pos 1, 1 Bit
   +0x003 IsImageDynamicallyRelocated : Pos 2, 1 Bit
   +0x003 SkipPatchingUser32Forwarders : Pos 3, 1 Bit
   +0x003 IsPackagedProcess : Pos 4, 1 Bit
   +0x003 IsAppContainer   : Pos 5, 1 Bit
   +0x003 IsProtectedProcessLight : Pos 6, 1 Bit
   +0x003 IsLongPathAwareProcess : Pos 7, 1 Bit
   +0x004 Mutant           : Uint4B
   +0x008 ImageBaseAddress : Uint4B
   +0x00c Ldr              : Uint4B
   +0x010 ProcessParameters : Uint4B
   +0x014 SubSystemData    : Uint4B
    // ...[생략]...

환경 변수는 "ProcessParameters" 필드가 가리키는 주소에 포함돼 있습니다. 다행히 이 값은 저 구조체를 보고 구하는 것도 가능하지만,

0:000> dd d4c000 + 0x10 L1
00000000`00d4c010  011b69c8

!peb 명령어의 결과에도 나오므로 그 값을 그대로 재활용하면 됩니다.

0:000> !peb
Wow64 PEB32 at d4c000
    InheritedAddressSpace:    No
    ReadImageFileExecOptions: No
    BeingDebugged:            No
    ImageBaseAddress:         0000000000be0000
    NtGlobalFlag:             0
    NtGlobalFlag2:            0
    Ldr                       000000007747cb00
    ***  _PEB_LDR_DATA type was not found...
    *** unable to read Ldr table at 000000007747cb00
    SubSystemData:     0000000000000000
    ProcessHeap:       00000000011b0000
    ProcessParameters: 00000000011b69c8
    ...[생략]...

이렇게 구한 ProcessParameters 구조체는 다음과 같은데,

// https://theroadtodelphi.com/2012/05/26/getting-the-environment-variables-of-an-external-x86-process/
typedef struct _RTL_USER_PROCESS_PARAMETERS
{
     ULONG MaximumLength;
     ULONG Length;
     ULONG Flags;
     ULONG DebugFlags;
     PVOID ConsoleHandle;
     ULONG ConsoleFlags;
     PVOID StandardInput;
     PVOID StandardOutput;
     PVOID StandardError;
     CURDIR CurrentDirectory;
     UNICODE_STRING DllPath;
     UNICODE_STRING ImagePathName;
     UNICODE_STRING CommandLine;
     PVOID Environment;
     ...[생략]...
} RTL_USER_PROCESS_PARAMETERS, *PRTL_USER_PROCESS_PARAMETERS;

아쉽게도 x64 windbg 버전의 dt 명령어로는 32비트 포인터를 사용하지 않으므로 정확한 오프셋을 구할 수는 없으므로, 위의 구조체를 보고 직접 오프셋을 구해야 합니다. 혹은, windbg에서 !wow64exts.sw 명령어로 모드 변경을 한 다음 _RTL_USER_PROCESS_PARAMETERS 구조체를 구하면 다음과 같이 32비트 환경의 오프셋으로 출력됩니다.

0:000> !wow64exts.sw
Switched to Guest (WoW) mode

0:000:x86> dt _RTL_USER_PROCESS_PARAMETERS
ntdll_77350000!_RTL_USER_PROCESS_PARAMETERS
   +0x000 MaximumLength    : Uint4B
   +0x004 Length           : Uint4B
   +0x008 Flags            : Uint4B
   +0x00c DebugFlags       : Uint4B
   +0x010 ConsoleHandle    : Ptr32 Void
   +0x014 ConsoleFlags     : Uint4B
   +0x018 StandardInput    : Ptr32 Void
   +0x01c StandardOutput   : Ptr32 Void
   +0x020 StandardError    : Ptr32 Void
   +0x024 CurrentDirectory : _CURDIR
   +0x030 DllPath          : _UNICODE_STRING
   +0x038 ImagePathName    : _UNICODE_STRING
   +0x040 CommandLine      : _UNICODE_STRING
   +0x048 Environment      : Ptr32 Void
   +0x04c StartingX        : Uint4B
   +0x050 StartingY        : Uint4B
   +0x054 CountX           : Uint4B
   +0x058 CountY           : Uint4B
   +0x05c CountCharsX      : Uint4B
   +0x060 CountCharsY      : Uint4B
   +0x064 FillAttribute    : Uint4B
   +0x068 WindowFlags      : Uint4B
   +0x06c ShowWindowFlags  : Uint4B
   +0x070 WindowTitle      : _UNICODE_STRING
   +0x078 DesktopInfo      : _UNICODE_STRING
   +0x080 ShellInfo        : _UNICODE_STRING
   +0x088 RuntimeData      : _UNICODE_STRING
   +0x090 CurrentDirectores : [32] _RTL_DRIVE_LETTER_CURDIR
   +0x290 EnvironmentSize  : Uint4B
   +0x294 EnvironmentVersion : Uint4B
    // ...[생략]...

이렇게 0x48, 0x290 오프셋 값을 이용해, 최종적으로 다음과 같이 덤프를 하시면 됩니다.

0:000> dd 011b69c8 + 0x48 L1
00000000`011b6a10  0121c730

0:000> dd 011b69c8 + 0x290 L1
00000000`011b6c58  000023f2

0:000> db 121c730 L000023f2
...[생략: 환경 변수 출력]...




정리해 보면, 64비트 운영체제에서 실행되는 32비트 프로세스의 경우 PEB가 2개 버전으로 관리된다는 것인데요, 우선 64비트 PEB에는 프로세스 시작 시점의 환경 변수가 반영되고 이후 Wow64 PEB로 복사되고 나서는 프로세스의 코드에 따른 변경 사항이 Wow64 PEB에서 이뤄진다는 것을 알 수 있습니다.

그렇다면 위와 같은 결과는, 이제 반대로도 생각할 수 있습니다. 64비트 운영체제에서 실행된 32비트 프로세스의 덤프를 Process Explorer로 뜬 경우, 변경된 환경 변수의 버전이 아닌, 초기 프로세스 실행 시점의 환경 변수도 함께 구할 수 있다는 것입니다.

다시 메모리 덤프를 출력한 결과를 볼까요?

// 작업 관리자로 뜬 x86 프로세스의 덤프

0:000> !peb
Wow64 PEB32 at d4c000
    ...[생략]...

Wow64 PEB at 0000000000d4b000
    InheritedAddressSpace:    No
    ...[생략: 프로세스 실행 시점의 환경 변수를 담고 있는 PEB]...

// Process Explorer로 뜬 x86 프로세스의 덤프

0:000> !peb
PEB at 00d4c000
    ...[생략]...

아쉽게도, "Process Explorer로 뜬 x86 프로세스의 덤프"에서는 "Wow64 PEB"의 주소인 0x0d4b000 값을 구할 수 없습니다. 단지, 2개의 메모리 주소가 0x1000 (4KB) 차이가 난다는 것에서 운이 좋다면 PEB 주소에서 그만큼을 빼는 것도 가능할 것입니다. 이후의 과정은 64비트 버전의 _PEB, _RTL_USER_PROCESS_PARAMETERS 구조체 오프셋 연산을 통해 초기 환경 변수의 구성을 구할 수 있습니다. 다시 말하지만... 운이 좋다면! ^^)




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







[최초 등록일: ]
[최종 수정일: 1/12/2023]

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

비밀번호

댓글 작성자
 




... 61  62  63  [64]  65  66  67  68  69  70  71  72  73  74  75  ...
NoWriterDateCnt.TitleFile(s)
12210정성태4/20/202016362.NET Framework: 903. .NET Framework의 Strong-named 어셈블리 바인딩 (1) - app.config을 이용한 바인딩 리디렉션 [1]파일 다운로드1
12209정성태4/13/202013866오류 유형: 614. 리눅스 환경에서 C/C++ 프로그램이 Segmentation fault 에러가 발생한 경우 (2)
12208정성태4/12/202012759Linux: 29. 리눅스 환경에서 C/C++ 프로그램이 Segmentation fault 에러가 발생한 경우
12207정성태4/2/202011842스크립트: 19. Windows PowerShell의 NonInteractive 모드
12206정성태4/2/202014673오류 유형: 613. 파일 잠금이 바로 안 풀린다면? - The process cannot access the file '...' because it is being used by another process.
12205정성태4/2/202011585스크립트: 18. Powershell에서는 cmd.exe의 명령어를 지원하진 않습니다.
12204정성태4/1/202011211스크립트: 17. Powershell 명령어에 ';' (semi-colon) 문자가 포함된 경우
12203정성태3/18/202013813오류 유형: 612. warning: 'C:\ProgramData/Git/config' has a dubious owner: '...'.
12202정성태3/18/202016614개발 환경 구성: 486. .NET Framework 프로젝트를 위한 GitLab CI/CD Runner 구성
12201정성태3/18/202014367오류 유형: 611. git-credential-manager.exe: Using credentials for username "Personal Access Token". [1]
12200정성태3/18/202014434VS.NET IDE: 145. NuGet + Github 라이브러리 디버깅 관련 옵션 3가지 - "Enable Just My Code" / "Enable Source Link support" / "Suppress JIT optimization on module load (Managed only)"
12199정성태3/17/202012191오류 유형: 610. C# - CodeDomProvider 사용 시 Unhandled Exception: System.IO.DirectoryNotFoundException: Could not find a part of the path '...\f2_6uod0.tmp'.
12198정성태3/17/202015374오류 유형: 609. SQL 서버 접속 시 "Cannot open user default database. Login failed."
12197정성태3/17/202014488VS.NET IDE: 144. .NET Core 콘솔 응용 프로그램을 배포(publish) 시 docker image 자동 생성 - 두 번째 이야기 [1]
12196정성태3/17/202012025오류 유형: 608. The ServicedComponent being invoked is not correctly configured (Use regsvcs to re-register).
12195정성태3/16/202014120.NET Framework: 902. C# - 프로세스의 모든 핸들을 열람 - 세 번째 이야기
12194정성태3/16/202016679오류 유형: 607. PostgreSQL - Npgsql.NpgsqlException: sorry, too many clients already
12193정성태3/16/202013251개발 환경 구성: 485. docker - SAP Adaptive Server Enterprise 컨테이너 실행 [1]
12192정성태3/14/202015617개발 환경 구성: 484. docker - Sybase Anywhere 16 컨테이너 실행
12191정성태3/14/202016702개발 환경 구성: 483. docker - OracleXE 컨테이너 실행 [1]
12190정성태3/14/202011604오류 유형: 606. Docker Desktop 업그레이드 시 "The process cannot access the file 'C:\Program Files\Docker\Docker\resources\dockerd.exe' because it is being used by another process."
12189정성태3/13/202017179개발 환경 구성: 482. Facebook OAuth 처리 시 상태 정보 전달 방법과 "유효한 OAuth 리디렉션 URI" 설정 규칙
12188정성태3/13/202020567Windows: 169. 부팅 시점에 실행되는 chkdsk 결과를 확인하는 방법
12187정성태3/12/202011335오류 유형: 605. NtpClient was unable to set a manual peer to use as a time source because of duplicate error on '...'.
12186정성태3/12/202013078오류 유형: 604. The SysVol Permissions for one or more GPOs on this domain controller and not in sync with the permissions for the GPOs on the Baseline domain controller.
12185정성태3/11/202013476오류 유형: 603. The browser service was unable to retrieve a list of servers from the browser master...
... 61  62  63  [64]  65  66  67  68  69  70  71  72  73  74  75  ...