Microsoft MVP성태의 닷넷 이야기
닷넷: 2187. C# - 다른 프로세스의 환경변수 읽는 예제 [링크 복사], [링크+제목 복사],
조회: 4047
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일

(시리즈 글이 3개 있습니다.)
VC++: 63. 다른 프로세스에 환경 변수 설정하는 방법
; https://www.sysnet.pe.kr/2/0/1297

.NET Framework: 366. 다른 프로세스에 환경 변수 설정하는 방법 - 두 번째 이야기
; https://www.sysnet.pe.kr/2/0/1438

닷넷: 2187. C# - 다른 프로세스의 환경변수 읽는 예제
; https://www.sysnet.pe.kr/2/0/13502




C# - 다른 프로세스의 환경변수 읽는 예제

마침 아래의 글이 있군요. ^^

Read Environment Strings of Remote Process
; https://www.codeproject.com/Articles/25647/Read-Environment-Strings-of-Remote-Process

위의 글은 32비트를 대상으로 하는데 64비트도 거의 유사하게 추적할 수 있습니다. 우선, _TEB 주소를 구해야 하는데, 이것은 GS:[0x30]에 위치하고 있습니다.

0:003> dt _TEB
ntdll!_TEB
   +0x000 NtTib            : _NT_TIB
   ...[생략]...

0:003> dt _NT_TIB
ntdll!_NT_TIB
   +0x000 ExceptionList    : Ptr64 _EXCEPTION_REGISTRATION_RECORD
   +0x008 StackBase        : Ptr64 Void
   +0x010 StackLimit       : Ptr64 Void
   +0x018 SubSystemTib     : Ptr64 Void
   +0x020 FiberData        : Ptr64 Void
   +0x020 Version          : Uint4B
   +0x028 ArbitraryUserPointer : Ptr64 Void
   +0x030 Self             : Ptr64 _NT_TIB

이렇게 구한 TEB의 위치에서 PEB를 구하는데 이것은 0x60에 위치합니다.

0:003> dt _TEB
ntdll!_TEB
   +0x000 NtTib            : _NT_TIB
   +0x038 EnvironmentPointer : Ptr64 Void
   +0x040 ClientId         : _CLIENT_ID
   +0x050 ActiveRpcHandle  : Ptr64 Void
   +0x058 ThreadLocalStoragePointer : Ptr64 Void
   +0x060 ProcessEnvironmentBlock : Ptr64 _PEB
   ...[생략]...

PEB를 구했으면 그것의 0x20 위치에 ProcessParameters가 위치하고,

0:003> dt _PEB
ntdll!_PEB
   +0x000 InheritedAddressSpace : UChar
   +0x001 ReadImageFileExecOptions : UChar
   ...[생략]...
   +0x010 ImageBaseAddress : Ptr64 Void
   +0x018 Ldr              : Ptr64 _PEB_LDR_DATA
   +0x020 ProcessParameters : Ptr64 _RTL_USER_PROCESS_PARAMETERS
   ...[생략]...

마지막으로, 0x80 위치에서 환경변수 목록을 구할 수 있습니다.

0:003> dt _RTL_USER_PROCESS_PARAMETERS
ntdll!_RTL_USER_PROCESS_PARAMETERS
   +0x000 MaximumLength    : Uint4B
   ...[생략]...
   +0x050 DllPath          : _UNICODE_STRING
   +0x060 ImagePathName    : _UNICODE_STRING
   +0x070 CommandLine      : _UNICODE_STRING
   +0x080 Environment      : Ptr64 Void
   +0x088 StartingX        : Uint4B

자, 그럼 이 과정을 그대로 C# + P/Invoke 호출을 이용해 구현하면 됩니다. ^^




하지만 실제 소스코드 구현에서는 위의 설명 과정에서 TEB로부터 PEB를 구하는 과정은 생략합니다. 왜냐하면, 처음부터 PEB를 구할 수 있기 때문인데요, "Read Environment Strings of Remote Process" 글의 소스코드에 잘 나와 있습니다. 그리고 아래는 그것을 C#으로 포팅한 예제입니다.

using System.Diagnostics;
using System.Runtime.InteropServices;
using static ConsoleApp1.NativeMethods;

namespace ConsoleApp1;

internal class Program
{
    static void Main(string[] args)
    {
        int pid = 52436;

        foreach (var item in GetRemoteEnvironmentVariables(pid))
        {
            Console.WriteLine($"{item.Key}={item.Value}");
        }
    }

    public unsafe static Dictionary<string, string> GetRemoteEnvironmentVariables(int pid)
    {
        Dictionary<string, string> envVariables = new Dictionary<string, string>();

        PROCESS_BASIC_INFORMATION processInformation = new PROCESS_BASIC_INFORMATION();
        IntPtr processHandle = Process.GetProcessById(pid).Handle;
        int requireLength = 0;

        int pbiSize = Marshal.SizeOf<PROCESS_BASIC_INFORMATION>();
        int ntStatus = NtQueryInformationProcess(processHandle, PROCESSINFOCLASS.BasicInformation, ref processInformation, pbiSize, ref requireLength);
        if (ntStatus != 0)
        {
            Console.WriteLine("failed to get PEB address");
            return envVariables;
        }

        byte[] buffer = new byte[pbiSize];
        ulong readLength = 0;
        ReadProcessMemory(processHandle, processInformation.PebBaseAddress, buffer, pbiSize, &readLength);
        if (readLength == 0)
        {
            Console.WriteLine("failed to read PEB");
            return envVariables;
        }

        IntPtr pProcessParameters;
        // read int64 from buffer at offset 0x20
        fixed (byte* p = buffer)
        {
            pProcessParameters = Marshal.ReadIntPtr(new IntPtr(p + 0x20));
            if (pProcessParameters == IntPtr.Zero)
            {
                Console.WriteLine("failed to get _RTL_USER_PROCESS_PARAMETERS address");
                return envVariables;
            }
        }

        buffer = new byte[0x80 + 8];
        ReadProcessMemory(processHandle, pProcessParameters, buffer, buffer.Length, &readLength);
        if (readLength == 0)
        {
            Console.WriteLine("failed to read _RTL_USER_PROCESS_PARAMETERS");
            return envVariables;
        }

        IntPtr pEnvironment;
        fixed (byte* p = buffer)
        {
            pEnvironment = Marshal.ReadIntPtr(new IntPtr(p + 0x80));
            if (pEnvironment == IntPtr.Zero)
            {
                Console.WriteLine("failed to get environment address");
                return envVariables;
            }
        }

        int envSize = GetRegionSize(processHandle, pEnvironment);
        buffer = new byte[envSize];
        ReadProcessMemory(processHandle, pEnvironment, buffer, envSize, &readLength);
        if (readLength == 0)
        {
            Console.WriteLine("failed to read environment");
            return envVariables;
        }

        fixed (byte* p = buffer)
        {
            char* pEnv = (char*)p;

            while (true)
            {
                if (*pEnv == '\0') // double null terminated
                {
                    break;
                }

                string text = new string(pEnv);

                pEnv = pEnv + text.Length;
                if (*pEnv != '\0') // must be '\0';
                {
                    break;
                }

                pEnv++;

                string [] nameValue = text.Split('=');
                if (nameValue.Length < 2)
                {
                    continue;
                }

                envVariables.Add(nameValue[0], nameValue[1]);
            }
        }

        return envVariables;
    }

    static int GetRegionSize(IntPtr hProcess, IntPtr pAddress)
    {
        _MEMORY_BASIC_INFORMATION64 mbi = new _MEMORY_BASIC_INFORMATION64();
        uint mbiSize = (uint)Marshal.SizeOf<_MEMORY_BASIC_INFORMATION64>();
        int readBytes = NativeMethods.VirtualQueryEx(hProcess, pAddress, ref mbi, mbiSize);

        if (mbi.Protect == PAGE_NOACCESS ||
            mbi.Protect == PAGE_EXECUTE)
        {
            return 0;
        }

        if (readBytes != mbiSize)
        {
            return 0;
        }

        ulong diff = (ulong)pAddress - (ulong)mbi.BaseAddress;

        return (int)mbi.RegionSize - (int)diff;
    }
}

위에서, 재미있는 부분이 하나 있다면, 환경변수 주소를 가져온 다음 그 영역을 읽어내는 것입니다. 사실, _RTL_USER_PROCESS_PARAMETERS 구조체에는 환경변수 주소만 있고 그 크기에 대한 정보가 없습니다.

"Read Environment Strings of Remote Process" 글에서는 이 부분을 VirtualQueryEx를 통해 해결하고 있는데요,

BOOL CProcessEnvReader::HasReadAccess( HANDLE hProcess,
                                        void* pAddress, int& nSize )
{
    MEMORY_BASIC_INFORMATION memInfo;
    __try
    {
        VirtualQueryEx( hProcess, pAddress,&memInfo,sizeof(memInfo));
        if( PAGE_NOACCESS == memInfo.Protect ||
        PAGE_EXECUTE == memInfo.Protect )
        {
            nSize = 0;
            return FALSE;
        }
        nSize = memInfo.RegionSize;
        return TRUE;
    }
    __except( SHOW_ERR_DLG( _T("Failed to query memory access")))
    {
    }
    return FALSE;
} 

전에 저도 이 함수를 이용해 스택 메모리의 상태 출력을 한 적이 있습니다.

C# - VMMap처럼 스택 메모리의 reserve/guard/commit 상태 출력
; https://www.sysnet.pe.kr/2/0/13174

그런데, 위의 소스 코드에는 문제가 하나 있습니다. 환경변수를 가리키는 pAddress로 전달한 주소가 해당 Region의 시작 주소와 일치하지 않기 때문에 전체 RegionSize를 반환해 버리면 저 영역을 넘어선 부분까지 읽기 시도를 할 수가 있습니다.

아마도 저 소스코드는 32비트에서 테스트해서 운이 좋게 다음 Region도 commit 영역이었을 확률이 높지만 x64의 광활한 메모리 공간에서는 오류 확률이 매우 높게 됩니다.

따라서, BaseAddress로부터 pAddress가 떨어진 만큼의 크기를 RegionSize에서 빼서 반환하는 보정을 거쳐야 합니다.

static int GetRegionSize(IntPtr hProcess, IntPtr pAddress)
{
    _MEMORY_BASIC_INFORMATION64 mbi = new _MEMORY_BASIC_INFORMATION64();
    uint mbiSize = (uint)Marshal.SizeOf<_MEMORY_BASIC_INFORMATION64>();
    int readBytes = NativeMethods.VirtualQueryEx(hProcess, pAddress, ref mbi, mbiSize);

    if (mbi.Protect == PAGE_NOACCESS ||
        mbi.Protect == PAGE_EXECUTE)
    {
        return 0;
    }

    if (readBytes != mbiSize)
    {
        return 0;
    }

    ulong diff = (ulong)pAddress - (ulong)mbi.BaseAddress;8
    return (int)mbi.RegionSize - (int)diff;
}

(첨부 파일은 이 글의 예제 코드를 포함합니다.)

참고로, PEB, _RTL_USER_PROCESS_PARAMETERS의 offset 위치가 운영체제/패치마다 다를 수도 있습니다. 아마도 환경변수 영역은 거의 변하지 않을 거라 예상은 하지만 그래도 안전하게 하고 싶다면 "KernelStructOffset" 등의 도움을 받으면 됩니다.




보통, TEB를 가져오기 위한 용도로 (x64의 경우) GS 세그먼트를 사용한 연산을 합니다. 일례로, Visual C++의 __readgsqword 함수를 사용하면 이렇게 TEB를 가져올 수 있는데요,

unsigned __int64 fsSelf = __readgsqword(0x30);

기계어로는 다음과 같이 번역됩니다.

mov         rax,qword ptr gs:[30h]  
mov         qword ptr [fsReg],rax 

그런데 재미있는 건, 0x30h의 값이 바로 TEB 자신의 주솟값이라는 것입니다.

lkd> dt _TEB
nt!_TEB
   +0x000 NtTib            : _NT_TIB
   +0x038 EnvironmentPointer : Ptr64 Void
   +0x040 ClientId         : _CLIENT_ID
   +0x050 ActiveRpcHandle  : Ptr64 Void
...[생략]...

lkd> dt _NT_TIB
nt!_NT_TIB
   +0x000 ExceptionList    : Ptr64 _EXCEPTION_REGISTRATION_RECORD
   +0x008 StackBase        : Ptr64 Void
   +0x010 StackLimit       : Ptr64 Void
   +0x018 SubSystemTib     : Ptr64 Void
   +0x020 FiberData        : Ptr64 Void
   +0x020 Version          : Uint4B
   +0x028 ArbitraryUserPointer : Ptr64 Void
   +0x030 Self             : Ptr64 _NT_TIB

재미있지 않나요? ^^ 그냥 gs 레지스터가 가리키는 값을 가져오면 될 텐데, 왜 굳이 gs:[0x30]으로 가는 방식으로 정해서 구조체에까지 영향을 주는 식으로 정의를 했을까요?

사실 GS는 일반적인 레지스터가 아닌 세그먼트 레지스터라서 그것 자체의 값은 주소가 아닙니다.

0:007> r gs
gs=002b

그리고 저 Selector에 해당하는 정보를 구하면,

0:007> dg gs
                                                    P Si Gr Pr Lo
Sel        Base              Limit          Type    l ze an es ng Flags
---- ----------------- ----------------- ---------- - -- -- -- -- --------
002B 00000000`00000000 00000000`ffffffff Data RW Ac 3 Bg Pg P  Nl 00000cf3

의외로 Base 주솟값이 00000000`00000000으로 나옵니다. 아니, 그렇다면 gs:[0x30]은 결국 0x30 가상 주소를 가리키는 것과 같을 텐데요, 당연히 이 영역은 null 주소에 가까운 페이지라서 커밋이 안 돼 있는 영역입니다.

0:007> dd 0x30 L4
00000000`00000030  ???????? ???????? ???????? ????????

이게 가능한 이유는,

windbg - Why does the GS register resolve to offset 0x0?
; https://reverseengineering.stackexchange.com/questions/21033/windbg-why-does-the-gs-register-resolve-to-offset-0x0

특별히, gs의 경우에는 MSR(Model Specific Registers)에 보관된 값을 base address로 사용하기 때문이라고 합니다.

SWAPGS
; https://wiki.osdev.org/SWAPGS

위의 문서에 보면,

(IA32_FS_BASE) FSBase is MSR 0xC0000100, 
(IA32_GS_BASE) GSBase is 0xC0000101, 
(IA32_KERNEL_GS_BASE) and KernelGSBase is 0xC0000102.

// 그 외, IA32_DS_AREA, IA32_L-STAR, IA32_SYSENTER_EIP, IA32_SYSENTER_ESP

MSR에서 GS가 참조하는 주솟값이 나옵니다.




마지막으로, 다음과 같이 코딩을 하면,

; gs_register.asm
; MASM - "ml64.exe /c /nologo /Zi /Fo"x64\Debug\gs_register.obj" /W3 /errorReport:prompt  /Tags_register.asm"

    .code

get_gs_addr proc
    mov rax, ds:[20]    
    ret

get_gs_addr endp

end

"error A2202: illegal use of segment register" 오류가 발생합니다. 검색해 보면, 64비트 모드에서 CS/DS/ES/SS를 오버라이드할 수는 있지만 실제로는 무시되기 때문에 MASM의 경우에는 아예 지정하지 못하게 막았고, 다른 어셈블러들은 허용했다고 합니다. 그래도 이게 아주 쓸모없지는 않은 게, CS/DS/ES/SS로 지정함으로써 명령어 길이를 늘려 메모리 정렬을 맞추기 위한 패딩 용도로 쓴다고 합니다.

반면, 원래 이 글에서 우리가 원했던 표현은,

mov rax, gs:0 // error A2027: operand must be a memory expression

GS가 명시된 경우 오퍼랜드로 가능한 것은 반드시 메모리 (주솟값 자체가 아닌) 참조만 가능하다고 합니다. 만약 저 표현이 가능했다면 "mov rax, gs:[0x30]" 코드는 필요 없었을 것입니다.




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







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

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)
13558정성태2/18/20243479닷넷: 2217. C# - 최댓값이 1인 SemaphoreSlim 보다 Mutex 또는 lock(obj)를 선택하는 것이 나은 이유
13557정성태2/18/20243196Windows: 258. Task Scheduler의 Author 속성 값을 변경하는 방법
13556정성태2/17/20243296Windows: 257. Windows - Symbolic (hard/soft) Link 및 Junction 차이점
13555정성태2/15/20243585닷넷: 2216. C# - SemaphoreSlim 사용 시 주의점
13554정성태2/15/20243174VS.NET IDE: 189. Visual Studio - 닷넷 소스코드 디컴파일 찾기가 안 될 때
13553정성태2/14/20243228닷넷: 2215. windbg - thin/fat lock 없이 동작하는 Monitor.Wait + Pulse
13552정성태2/13/20243257닷넷: 2214. windbg - Monitor.Enter의 thin lock과 fat lock
13551정성태2/12/20243618닷넷: 2213. ASP.NET/Core 웹 응용 프로그램 - 2차 스레드의 예외로 인한 비정상 종료
13550정성태2/11/20243837Windows: 256. C# - Server socket이 닫히면 Accept 시켰던 자식 소켓이 닫힐까요?
13549정성태2/3/20244087개발 환경 구성: 706. C# - 컨테이너에서 실행하기 위한 (소켓) 콘솔 프로젝트 구성
13548정성태2/1/20243780개발 환경 구성: 705. "Docker Desktop for Windows" - ASP.NET Core 응용 프로그램의 소켓 주소 바인딩(IPv4/IPv6 loopback, Any)
13547정성태1/31/20243525개발 환경 구성: 704. Visual Studio - .NET 8 프로젝트부터 dockerfile에 추가된 "USER app" 설정
13546정성태1/30/20243279Windows: 255. (디버거의 영향 등으로) 대상 프로세스가 멈추면 Socket KeepAlive로 연결이 끊길까요?
13545정성태1/30/20243063닷넷: 2212. ASP.NET Core - 우선순위에 따른 HTTP/HTTPS 호스트:포트 바인딩 방법
13544정성태1/30/20243183오류 유형: 894. Microsoft.Data.SqlClient - Could not load file or assembly 'System.Security.Permissions, ...'
13543정성태1/30/20243250Windows: 254. Windows - 기본 사용 중인 5357 포트 비활성화는 방법
13542정성태1/30/20243117오류 유형: 893. Visual Studio - Web Application을 실행하지 못하는 IISExpress - 두 번째 이야기
13541정성태1/29/20243345VS.NET IDE: 188. launchSettings.json의 useSSL 옵션
13540정성태1/29/20243517Linux: 69. 리눅스 - "Docker Desktop for Windows" Container 환경에서 IPv6 Loopback Address 바인딩 오류
13539정성태1/26/20243453개발 환경 구성: 703. Visual Studio - launchSettings.json을 이용한 HTTP/HTTPS 포트 바인딩
13538정성태1/25/20243798닷넷: 2211. C# - NonGC(FOH) 영역에 .NET 개체를 생성파일 다운로드1
13537정성태1/24/20243913닷넷: 2210. C# - Native 메모리에 .NET 개체를 생성파일 다운로드1
13536정성태1/23/20243898닷넷: 2209. .NET 8 - NonGC Heap / FOH (Frozen Object Heap) [1]
13535정성태1/22/20243875닷넷: 2208. C# - GCHandle 구조체의 메모리 분석
13534정성태1/21/20243682닷넷: 2207. C# - SQL Server DB를 bacpac으로 Export/Import파일 다운로드1
13533정성태1/18/20243781닷넷: 2206. C# - TCP KeepAlive의 서버 측 구현파일 다운로드1
1  2  3  4  5  [6]  7  8  9  10  11  12  13  14  15  ...