Shawn's Laboratory (+Popeyed World)

움 대학교 전산망 해킹해서 성적위조하다가 걸렸나 보네요.

요즘에는 취업때 학점을 보기때문에 학점올리는 게 요원했었나 봅니다.

이 기사를 보니 학창 시절이 생각납니다.

한창일때 학생 DB를 액세스해서 성적도 보고, 좋아했던 아가씨 전화번호도 찾아보고 했었는데요
순진해서 성적을 고칠 생각은 못했습니다.

나중에 안 사실이지만, 전산실 아저씨에 따르면 학생성적 은 3중으로 저장하기 때문에 
( 여기서 3중이라고 하면 페이퍼, 테이프, 오프라인 하드디스크를 말합니다. )
DB를 고쳐도 나중에 감사할때 걸린다고  하지 않는게 좋다는 친절한(?) 설명까지 들었었죠.

대학교들 단과대학이 구성원들이 연결되어 있는 구조가 너무 광범위하기 때문에 관리가 잘 안 되는 일이 비일비재한데요.
이번기회를 본보기 삼아 관리에 투자를 좀 했으면 하는 바람입니다.




관련 뉴스

http://news.naver.com/main/read.nhn?mode=LPOD&mid=sec&sid1=001&sid2=140&oid=001&aid=0002933051&isYeonhapFlash=Y

Windows에 있어서는 NtQuerySystemInformation() 하고 NtSetSystemInformation()  함수가
Undocumented Native API 인데  하는 일이 진짜 많다. ...

어떤 어떤 인자를 주고 어떻게 쓰면 프로세스,화일,메모리 ... 정보를 가져올수 있다.. 등등

아래 링크에 들어가보면 자세한 정보를 얻을 수 있다. 근데 어셈블리 분석은 아직 없음, 하지만  찾아보면 어떤 짱구가 해 놨을 거 같음... -_-b

참고는

Inside Windows NT System Data, Dr. Dobb's Journal November 1999
Exploring a mysterious function , By Sven B. Schreiber

http://www.ddj.com/documents/s=897/ddj9911c/9911c.htm

Windows 2003 DDK 인스톨
http://www.microsoft.com/whdc/devtools/ddk/default.mspx

Debuging Tools for Windows 32-bit Version  인스톨
http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx

Windows Symbol Package 인스톨
http://www.microsoft.com/whdc/devtools/debugging/symbolpkg.mspx

( 위의 스타트 페이지,  http://www.microsoft.com/whdc/devtools/debugging/debugstart.mspx )

각각 설치 한다음에
시스템 환경 설정에 _NT_SYMBOL_PATH 추가하고 "C:WINNT" 값을 적어준다.
( 심볼화일이 C:WINNTSymbols 에 설치된다는 가정하에 )

한편, 위에서 symbols 받기가 귀찮으면 c:winntonline_symbols 디렉토리를 만들고
WinDbg 에서 symbols file 설정하는 곳에
SRV*c:winntonline_symbols*http://msdl.microsoft.com/download/symbols
이런식으로 온라인 symbols을 사용할 수 있다.

만일 :
post modern 방식 크래쉬 한담에 덤프를 분석하는 방법을 사용할 것이라면,
시스템 환경설정 -> 고급 -> 성능 -> 가상메모리를 물리 메모리의 약 2배정도로 늘려 잡는다.
시스템 환경설정 -> 고급 -> 시작및 복구 -> 시스템 오류 "전체메모리 복"구 로 설정
크래쉬 덤프는 크래쉬가 난 시점에 메모리 페이지에 값을 기록하고 다음 부팅시에 이를 화일로 덤프한다.
C:WINNTMEMORY.DMP 를 WinDBG 에서 로드하면 됨


참고는 Undocumented Windows 2000 Secrets, "Setting up a debugging environment" 에서

 
System Service Dispatcher

ntdll.dll -->
        eax, 인덱스
        edx, 리턴값
        int 2Eh
                  --> ntoskrnl.exe

ntdll.dll Zw* Nt* 함수가 있으면
ntoskrnl.exe Zw* Nt* 함수가 존재한다.

ntdll.dll 은 단순히 인터페이스이고, ntdll.Zw* ntdll.Nt* 함수가 같은 주소를 사용하는 동일함수이다.
ntoskrnl.exe 에 ntoskrnl.Nt* 함수가 진짜 함수 ...

 

Service Descriptor Tables (SST)

ntoskrnl , win32k 두개의 시스템 서비스 테이블을 가지고 있고
이는 각각 KiServiceTable, KiArgumentTable
W32pServiceTable , W32pArgumentTable 이라는 테이블을 가지고 있다.

이 테이블들은 각각 함수의 주소와 인자의 갯수를 가진 배열구조체 이다.

int 2Eh 는 바로 위 테이블을 참조해서 KiSystemService() 로 진입하고 쓰레드는
global SDT를 사용하지 않고 KeServiceDescriptorTable 을 사용하지 않고 자체의 포인터로
KiServiceTable 와 KiArgumentTable을 참조한다.

ntdll.dll 과 ntoskrnl.exe 가 가진 함수는

C runtime library ( memcpy , sprintf .. )
Extended runtime library ( Rtl* ...)
Floating-point emulator ( _eFLD .. )

그리고 기타 프리픽스에 따라
Ki : 커널 인터럽트 핸들러
Ke : 커널 루틴
Ldr : 이미지 로더
Ps : 프로세스 서포트
Nt : Native NT API
Hal : 하드웨어 추상레이어 함수  ...

자주사용되는 데이터 타입은

문자열의 경우 UNICODE_STRING 이고
Length, MaximumLength, Buffer ... 세가지로 이루어진 구조체인데
이를 다룰려면 RtlCreateUnicodeString , RtlInitUnicodeString , RtlCopyUnicodeString 등 함수를 사용해야됨...

Native API 에 접근하기 위해서는 ntdll.lib 을 사용하고
커스터마이징 헤더를 사용하면 됨...

참고는 Undocumented Windows 2000 Secrets, "The Windows 2000 Runtime Library" 편에서...

Windows에서 커널디버깅을 통해 프로세스와 쓰레드를 손으로 찾아가며 확인하는 방법입니다. 
사용된 PC는 Windows 2003 서버버젼 입니다.

kd> dt -b nt!_EPROCESS
+0x000 Pcb              : _KPROCESS
+0x000 Header           : _DISPATCHER_HEADER
+0x010 ProfileListHead  : _LIST_ENTRY
   +0x000 Flink            : Ptr32
   +0x004 Blink            : Ptr32
     +0x018 DirectoryTableBase : Uint4B // CR3 레지스터가 저장되어 있다
+0x020 LdtDescriptor    : _KGDTENTRY
....
+0x048 SwapListEntry    : _SINGLE_LIST_ENTRY
   +0x000 Next             : Ptr32
+0x04c VdmTrapcHandler  : Ptr32
     +0x050 ThreadListHead   : _LIST_ENTRY // 쓰레드 리스트의 헤드
  +0x000 Flink            : Ptr32
  +0x004 Blink            : Ptr32
      +0x058 ProcessLock      : Uint4B
+0x05c Affinity         : Uint4B
+0x060 AutoAlignment    : Pos 0, 1 Bit
+0x060 DisableBoost     : Pos 1, 1 Bit
...
+0x090 RundownProtect   : _EX_RUNDOWN_REF
+0x000 Count            : Uint4B
+0x000 Ptr              : Ptr32
   +0x094 UniqueProcessId  : Ptr32 // 프로세스 아이디
+0x098 ActiveProcessLinks : _LIST_ENTRY // 모든 프로세스 목록 관리 리스트
+0x000 Flink            : Ptr32
+0x004 Blink            : Ptr32
   +0x0a0 QuotaUsage       : Uint4B
...
+0x0cc DebugPort        : Ptr32
+0x0d0 ExceptionPort    : Ptr32
   +0x0d4 ObjectTable      : Ptr32  // 문제의 오브젝트 핸들테이블
   +0x0d8 Token            : _EX_FAST_REF
...
+0x14c Spare0           : Ptr32
+0x158 PageDirectoryPte : _HARDWARE_PTE
+0x158 Filler           : Uint8B
+0x160 Session          : Ptr32
   +0x164 ImageFileName    : UChar // 프로세스의 이름
   +0x174 JobLinks         : _LIST_ENTRY
+0x000 Flink            : Ptr32
+0x004 Blink            : Ptr32
+0x17c LockedPagesList  : Ptr32
+0x180 ThreadListHead   : _LIST_ENTRY
+0x000 Flink            : Ptr32
+0x004 Blink            : Ptr32
...
 +0x1e8 Vm               : _MMSUPPORT
      +0x000 WorkingSetExpansionLinks : _LIST_ENTRY
    +0x000 Flink            : Ptr32
    +0x004 Blink            : Ptr32
+0x008 LastTrimTime     : _LARGE_INTEGER
    +0x000 LowPart          : Uint4B
    +0x004 HighPart         : Int4B
    +0x000 u                : __unnamed
       +0x000 LowPart          : Uint4B
       +0x004 HighPart         : Int4B
    +0x000 QuadPart         : Int8B
+0x010 Flags            : _MMSUPPORT_FLAGS
+0x014 PageFaultCount   : Uint4B
...
+0x030 NextEstimationSlot : Uint4B
+0x034 NextAgingSlot    : Uint4B
+0x038 EstimatedAvailable : Uint4B
    +0x03c WorkingSetSize   : Uint4B // 프로세스 워킹셋 사이즈
      +0x040 WorkingSetMutex  : _EX_PUSH_LOCK
   +0x000 Locked           : Pos 0, 1 Bit
   +0x000 Waiting          : Pos 1, 1 Bit
   +0x000 Waking           : Pos 2, 1 Bit
   +0x000 MultipleShared   : Pos 3, 1 Bit
   +0x000 Shared           : Pos 4, 28 Bits
   +0x000 Value            : Uint4B
   +0x000 Ptr              : Ptr32
+0x230 MmProcessLinks   : _LIST_ENTRY
+0x000 Flink            : Ptr32
+0x004 Blink            : Ptr32
+0x238 ModifiedPageCount : Uint4B
+0x23c JobStatus        : Uint4B
+0x240 Flags            : Uint4B
+0x240 CreateReported   : Pos 0, 1 Bit
...
+0x24a SubSystemMinorVersion : UChar
+0x24b SubSystemMajorVersion : UChar
+0x24a SubSystemVersion : Uint2B
+0x24c PriorityClass    : UChar
   +0x250 VadRoot          : _MM_AVL_TABLE // 유저영역의 모든 메모리 설명
   +0x270 Cookie           : Uint4B

 

커널 레이어에서 EPROCESS 얻기

PEPROCESS PsGetCurrentProcess()
현재 프로세스의 EPROCESS을 얻어올수 있음

NTSTATUS PsLookupProcessByProcessId(IN ULONG ProcessID, OUT PVOID *EProcess )
다른 프로세스의 EPROCESS를 얻어올수 있음

프로세스를 구성하는 요소

각 프로세스의 독립적 메모리 공간의 사용은 Intel x86의 페이징 시스템을 그대로 사용함
위의 CR3 저장공간에 따라 실제 물리공간 결정 어드레스 오프셋은 물리매핑을 위한 각
페이지 디렉토리, 페이지 테이블 등의 오프셋

유저 메모리 영역 관리

kd> !process 85e3b8a8
PROCESS 85e3b8a8  SessionId: 0  Cid: 0aa8    Peb: 7ffdf000  ParentCid: 01b4
DirBase: 1e7f5000  ObjectTable: e217d008  HandleCount:  55.
Image: uedit32.exe
VadRoot 85331468 Vads 85 Clone 0 Private 740. Modified 2. Locked 0.
DeviceMap e206f720
Token                             e260f938
ElapsedTime                       00:07:44.406
UserTime                          00:00:00.000
KernelTime                        00:00:00.000
QuotaPoolUsage[PagedPool]         39256
QuotaPoolUsage[NonPagedPool]      3592
Working Set Sizes (now,min,max)  (2064, 50, 345) (8256KB, 200KB, 1380KB)
PeakWorkingSetSize                2064
VirtualSize                       41 Mb
PeakVirtualSize                   42 Mb
PageFaultCount                    2983
MemoryPriority                    BACKGROUND
BasePriority                      8
CommitCharge                      1035
  THREAD 85e3b638  Cid 0aa8.05f0  Teb: 7ffde000 Win32Thread: e126a4e0 WAIT: (Unknown) UserMode Non-Alertable
      85334ff0  SynchronizationEvent
  Not impersonating
  DeviceMap                 e206f720
  Owning Process            85e3b8a8       Image:         uedit32.exe
  Wait Start TickCount      227979         Ticks: 6558 (0:00:01:42.468)
  Context Switch Count      1298                 LargeStack
  UserTime                  00:00:00.0406
  KernelTime                00:00:00.0281
  Start Address kernel32!BaseProcessStartThunk (0x77e6b5c7)
  Win32 Start Address 0x0050cec5
  Stack Init f5664000 Current f5663bc4 Base f5664000 Limit f5661000 Call 0
  Priority 10 BasePriority 8 PriorityDecrement 0
  Kernel stack not resident.
  ChildEBP RetAddr 
  f5663bdc 80820128 nt!KiSwapContext+0x25 (FPO: [Uses EBP] [0,0,4])
...
  f5663d4c 7c82ed54 nt!KiFastCallEntry+0xf8 (FPO: [0,0] TrapFrame @ f5663d64)
  0012fed4 00000000 ntdll!KiFastSystemCallRet (FPO: [0,0,0])
  THREAD 853cf020  Cid 0aa8.0af4  Teb: 7ffdd000 Win32Thread: e290a8b8 WAIT: (Unknown) UserMode Non-Alertable
      8533a2a0  Semaphore Limit 0x7fffffff
  Not impersonating
  DeviceMap                 e206f720
  Owning Process            85e3b8a8       Image:         uedit32.exe
  Wait Start TickCount      264026      
  Context Switch Count      15                 LargeStack
  UserTime                  00:00:00.0000
  KernelTime                00:00:00.0000
  Start Address kernel32!BaseThreadStartThunk (0x77e6b5bb)
  LPC Server thread working on message Id 442d
  Stack Init f53f4000 Current f53f3c24 Base f53f4000 Limit f53f1000 Call 0
  Priority 9 BasePriority 8 PriorityDecrement 0
  Kernel stack not resident.
  ChildEBP RetAddr 
  f53f3c3c 80820128 nt!KiSwapContext+0x25 (FPO: [Uses EBP] [0,0,4])
...
  0158fe18 0003f1bb ntdll!KiFastSystemCallRet (FPO: [0,0,0])
WARNING: Frame IP not in any known module. Following frames may be wrong.
  0158ff84 00015360 0x3f1bb
  00000000 00000000 0x15360

kd> !vad 85331468
VAD     level      start      end    commit
857ac690 ( 6)         10       10         1 Private      READWRITE
853b6280 ( 5)         20       20         1 Private      READWRITE
...
853a51d8 ( 6)       1410     1420         0 Mapped       READONLY
85e47320 ( 7)       1430     1477        72 Private      READWRITE
85e42c20 ( 3)       1480     1481         0 Mapped       READONLY
85333b98 ( 5)       1690     16d7        72 Private      READWRITE
Total VADs:    46  average level:    5  maximum depth: 7

핸들테이블

Windows 객체 관리자는 핸들 숫자값을 핸들 테이블의 색인 정보로 활용해서 참조하고자 하는 커널 객체에 접근

kd> !handle 07fc
processor number 0, process 85e36020
PROCESS 85e36020  SessionId: 0  Cid: 05c0    Peb: 7ffdc000  ParentCid: 0ad8
DirBase: 183e5000  ObjectTable: e2879988  HandleCount: 249.
Image: windbg.exe
New version of handle table at e2e92000 with 249 Entries in use
07fc: Object: e1006d08  GrantedAccess: 00000003
Object: e1006d08  Type: (85f92900) KeyedEvent
ObjectHeader: e1006cf0
  HandleCount: 30  PointerCount: 31
  Directory Object: e1001668  Name: CritSecOutOfMemoryEvent

e1006d08 은 핸들 테이블에 존재하며 이는 3단계로 분해되서 색인처리 됨
위를 분해하면 커널 객체 포인터를 찾을 수 있음

[31..26][25..18][17..10][9..2][1..0]
         i 256     j 256     k 256

x 를 핸들이라고 하면

x 가 가르키는 테이블 의 i 인덱스
x2 = *x[i]

x2 이 가르키는 테이블의 j 인덱스
x3 = *x2[j]

x3 가 가르키는 테이블의 k 인덱스
p_kobj = *x3[k]

p_kobj 는 커널 객체의 Object 포인터 이다...

한편, 위의 [31..26] 은 Audit on Close , Protect from close, Inheritable 플래그로 사용,
[1..0] 은 Lock Flag 으로 사용한다는 전설이 내려온다구 한다...

이렇게 쓰는 이유는 에너지절약 차원...
프로세스가 가지는 핸들의 테이블 메모리를 최대한 줄일 수 있음

정리하면서 무엇보다 이거 보면서 솔루션 만드느라
조낸 고생하신 올드드래곤 옹 생각이 난다...
-_-;;;

참고는 Windows 구조와 원리 그리고 Codes , 정덕영, "프로세스와 쓰레드"편

Sysinternals 의 LiveKD라는 실시간 커널 디버깅 어시스턴트를 사용해서 실서버의 커널을 디버깅하는 방법입니다.



WinDbg 를 언제 어디서나 빠르고 편하게 사용할 수 있도록
sysinternals 에서 livekd 라는 유틸리티를 제공해 준다.

이를 사용하면 별도로 커널을 크래쉬하거나
리모트 디버깅환경을 만들지 않아도 현제 PC 에서 커널 디버깅을 수행할 수 있다. 

likvekd.sys 가 무슨 파일 드라이버 역할을 하는 것 같다.
실제 windbg는 c:windowssystem32livekd.dmp 를 읽고 있다.

사용법도 간단하다.. Debugging Tools for Windows 를 깔아 놓고 , livekd 를 설치한다음
livekd -w 하면 됨

심볼도 알아서 설치해 준다.
ㅠㅠ... 넘 편하다.



다운로드는
LiveKD, http://www.sysinternals.com/utilities/livekd.html

Remote Debugging using VMWare  http://www.catch22.net/tuts/vmware.asp 의 내용을 정리한 것입니다.

vmware 에 있는 커널 디버깅 하는 방법 설명한거...

windbg 헬프 보기 싫어서 걍 이거 참조함

1. 타켓에 Serial 포트하나 만들어 놓고 "This end is the Server" , "The other end is an application" 선택하고 Yeild on CPU poll" 선택

2. boot.ini 에 마지막 라인의 옵션에 /debugport=com1 /baudrate=11520 추가하고

2. 사용자 디버거에서
windbg -b -k com:pipe,port=\.pipecom_1,resets=0 

로 접속하면 됨

소스 디버깅을 하려면,
WinDbg 의 Symbol File Path ... 에 해당 드라이버의 pdb 가 있는 디렉토리를,
Source File Path .. 에 해당 소스 디렉토리를 정해주면 된다.

타겟 머신에서 드라이버를 설치하고,

x driver!*

심볼들을 찾아내서

bp driver!MyOpen

이런식으로 걸고 외부에서 Windbg 를 실행하면 됩니다.

Inside Microsoft Windows 2000 에서 정리한 내용입니다. 



 
부팅 (booting)

Bios 가 boot sector 를 읽음
ntldr 가 부트 섹터에 위치함

Ntldr :

16 리얼 모드 -> 32 보호모드로 전환
메모리 페이징을 시작
boot.ini 를 읽어와서 부트옵션을 적용 ( SCSI 나 특별한 장치를 위해 ntbootdd.sys 를 로드)
Ntdetect.com을 실행 시스템 정보를 모음 ( HKLMHARDWAREDESCRIPTION 에 정보가 취합됨 )
Ntoskrnl.exe 를 메모리에 로드, Bootvid.dll , Hal.dll 을 로드하고, boot-start 디바이스 드라이버를 초기화함

 ( HKLMSYSTEMCurrentControlSetServices안에 드라이버가 있음 )
CPU를 Ntoskrnl.exe 를 위해 준비하고 Ntoskrnl.exe 시작점으로 제어를 넘김

Ntoskrnl.exe :

 각종 서브시스템을 초기화, 실행하고
system-start 디바이스 드라이버를 초기화
native app 인 smss.exe ( 세션 서브시스템) 을 실행

 자세히 :

 스텝 0 : 인터럽트를 중단시키고
KiSystemStartup -> HalInitializeprocessor , Ki1InitializeKernel  ; 초기의 커널 자료구조를 생성함  Ki1InitializeKernel 은 ExpInitializeExecutive() 호출하고 이는 각각
메모리관리자, 개체관리자, 보안참조 모니터, 프로세스관리자, 플러그엔 플러그 0 단계 초기화를 한다.

 스텝 1 :

  인터럽트 준비, 전원관리자, 시스템 시간 초기화 , 개체관리자가 링크됨, 커널 스케쥴러 초기화, ntdll.dll 매핑,
구성관리자가 Registry 복원, I/O 관리자 초기화
보안참조 모니터 호출 후
Native app 인 Smss.exe 를 실행시킨다.

Smss.exe:

 Windows 서브 시스템 win32k.sys 를 로드하고,
Csrss ( client/server runtime 서브시스템) 실행, winlogon 을 로드

자세히 :

LPC 포트 개체 생성
알려진 dll 을 열고
추가적 페이징 생성

레지스트리 초기화
시스템 환경변수 생성
Win32k .sys 로드
csrss 시작
Winloon 시작

Winlogon:

 SCM(서비스 컨트롤 매니져), LSASS(로칼 보안 인증 서브시스템) 를 로드하고 사용자 로긴 다이얼로그를 띄움

SCM:

 SCM 에 있는 자동시작 드라이버들을 로드

 

"Inside microsoft windows 2000" ,
David A.Solomon & Mark E. Russinovich

 

최근, 아마존의 명작 Kindle 2 (이-북리더)에 대한 해킹이슈가 올라왔네요.

아마존과 Sprint 사와의 일련의 계약에 의해 이루어진 Whispernet 기능을 우회할 수 있는 해킹입니다.

원래는 Kindle의 경우 미국내에서 아마존이 제공하는 이-북스토어를 Sprint 사의 무선 데이터망을 이용해서만 접근이 가능하다고 합니다. 그런데, Jess Vincent 라는 사람이 Kindle 2에 USB 디버깅 케이블을 달아 디버깅모드로 자신의 PC에 연결시키고 Kindle2에 아이피를 할당해서이 북스토어를 외국에서도 사용할 수 있게 한다는 내용입니다.

 

오 그렇다면, 세계 어디서나 Kindle 2를 사용할 수 있겠내요. 실제 Kindle 2에는 귀여운 ARM Linux box가 들어 있어서 rootshell 을 가질 수도 있다고 합니다. 메모리는 128메가...

하지만, 아마존에서 GPS 정보나 Kindle 2의 시리얼 정보를 가지고 있기 때문에 조심하라는 ....

아무튼 Kindle 을 가지고 있는 사람에겐 재미있는 일이 아닐 수 없습니다.

 

http://arstechnica.com/gadgets/news/2009/03/kindle-2-hacks-bypassing-whi...

 

여기는 Kindle 해킹 전문가  Igor Skochinsky 의 페이지

http://igorsk.blogspot.com/2007/12/hacking-kindle-part-3-root-shell-and....

 

그리고 이곳이 실제 Jess가 의 Howto 가 나와있는 곳입니다.

http://blog.fsck.com/2009/03/tethering-your-kindle.html

게임에 대한 해킹으로부터 고객회사를 지켜준다는 솔루션인, 게임 가드의 문제점은 태생이 외부 솔루션이라서 게임상의 메모리 보호를 못 하거나, 패턴대응이 늦어서 신종 툴이 나올때는 패턴 업데이트가 늦어 게임들이 버젓히 뚫리는 경우가 많았습니다. 
그래서 게임자체에서 메모리나 코드보호를 해야할 필요가 있습니다. 바로 메모리셔플링이라고 하는 거인데요, 예전에 각 게임사에서 게임보안 솔루션을 자체로 만들려고 했던 이유이기도 합니다.

아래 동영상은 MoonLite Engine 이라는 툴이 나와서 한창 돌아다닐때의 일인데요, 요즘은 게임가드 제작사인 잉카에서 새버젼이 나오면 열심히 업데이트한다고 합니다. 그렇다고 해도, 근본적인 문제가 해결되는 것은 아니고 다만, 관리적인 문제로 답을 구한다?는 느낌입니다.

(아래 계속...)