Zero's hobby blog.

sestatus 

명령으로 현재 SELinux 가 실행중인지 확인할 수 있다.

/etc/sysconfig/selinux 

파일에서 

 SELINUX 값을 disabled로 설정한 뒤 재부팅 하면 SELINUX를 사용하지 않는다.

어느 Makefile에서 정의되지 않은 변수 때문에 몇 시간을 헤매다가 GNU사이트에서 해답을 찾았다. 

https://www.gnu.org/software/make/manual/html_node/Implicit-Variables.html

${CC}, ${RM}같은 변수는 재정의 하지 않는 이상, cc, rm 의 명령을 변수로서 바로 사용이 가능하다. 

서버측에서 원격접속 설정이 모두 완료되었는데도 툴에서 접속이 안된다면, 

구 버전의 인증 프로토콜을 사용하도록 Advanced 에서 설정하자. 

웹서버에 모바일 홈페이지를 또 다른 톰캣에 담아 서비스 하던 중,

ssh 연결만 끊으면 404 에러가 뜨는 문제가 생겼다. 원인을 찾아보니 간혈적으로 WAS가 올라간 볼륨의 마운트가 해제되는 문제였다.

모바일 홈페이지는 /home/hanbat 폴더에 위치했다.

df -h 출력

/dev/mapper/tts-root 231214136 175502676  43966388  80% /
none                   2047104       212   2046892   1% /dev
none                   2054268       140   2054128   1% /dev/shm
none                   2054268       136   2054132   1% /var/run
none                   2054268         0   2054268   0% /var/lock
none                   2054268         0   2054268   0% /lib/init/rw
/dev/sda1               233191    105543    115207  48% /boot
/home/hanbat/.Private
                     231214136 175502676  43966388  80% /home/hanbat

보다시피 메인 디스크 볼륨은 / 로 마운트 되어있다.

헌데 맨 마지막줄에도 루트와 똑같은 용량으로 /home/hanbat/.Private 가 /home/hanbat으로 마운트되어 있는 아이러니한 구조다.

이 서버는 단일 디스크로 /home/hanbat 에 마운트된 볼륨과 /는 완전히 동일한 디스크다.

타 업체가 구성한 서버였기에 자세한 내용을 몰라 이리저리 찾아보던중 디스크 암호화 관련 유틸을 찾아냈다.

ubuntu 의  ecryptfs-utils 위 구성은 이 유틸로 /home/hanbat/.Private 라는 폴더를 /home/hanbat 으로 재 마운트 한것이다.

즉, .Private 폴더가 /home/hanbat으로 보이도록 마운트를 재구성 했다고 볼 수 있다.

실제 디스크의 /home/hanbat/.Private 에 가보면 암호화된, 알아볼 수 없는 파일들만 잔뜩 들어있다. 복호화키에의해 이 파일들이 복호화 되면서

/home/hanbat 처럼 보이는 것이다. 그리고 /home/hanbat/.ecryptfs 폴더에 이와 관련된 설정 파일들이 있다. 

hanbat@tts:~/.ecryptfs$ ls
Private.mnt  Private.sig  auto-mount  auto-umount  wrapped-passphrase

5개의 설정 파일이 있는데 이중 auto-mount와 auto-umount는 내용이 빈 파일로 단지 암호화된 디스크의 자동 마운트 및 언마운트 설정용 config다

메뉴얼을 찾아보니 auto-mount 는 로그인할 때 자동으로 마운트하는 옵션이고 auto-umount는 로그아웃할 때 자동으로 언마운트 하는 옵션이다.

이 설정으로 인해서 ssh연결을 끊으면 마운트되어있던 볼륨이 언마운트 되면서 /home/hanbat 으로 둔갑하고 있던 /home/hanbat/.Private 가 사라지고

본래의 /home/hanbat 으로 변하게 된다.

모바일 WAS를 올려둔 것은 홈 폴더로 둔갑했던 /home/hanbat/.Private 이므로 웹 서버가 파일들을 찾을 수 없던 것이다. 

이 디스크 암호화 유틸의 마운트는 /etc/fstab 설정에 전혀 나타나 있지 않다.

인수인계에서 해당 내용을 전달 받지 못했다면, 나중에 꽤나 고생을 해야할지도 모른다. 

마운트가 해제되는 문제는 auto-umount 파일을 삭제함으로써 해결했다.

마켓 플레이스에서 Eclipse Color Theme (코딩 컬러 스키마 모음) &

Eclipse Moonrise UI Theme (이클립스 UI 테마) 설치

추가 플러그인으로 설치된 Color Theme 에서 코드 컬러 스키마 설정

튜닝 끝.

토비의 스프링 3.1 p.670의 내용을 진행한뒤 테스트를 돌려보면 EmbeddedDatabase 에서 에러가 발생해 테스트의 일부가 실패한다.

에러의 원인은 중복 스크립트 실행이다. (테이블이 이미 있는데 또 다시 생성 스크립트 실행)

원인을 파악하기 위해 학습테스트를 여럿 만들고 테스트 소스를 여기저기 수정해가며 파악해 봤다.

 @DirtiesContext 가 문제의 원인이었다.

이 애노테이션은 빈의 DI설정을 변경할경우 다음 테스트를 실행할 때 새로운 컨텍스트를 생성케 한다

문제는, 이 애노테이션으로 생성되는 컨텍스트는 완전히 새로운 컨텍스트가 아니라는 것이다.

컨텍스트가 빈을 다시 생성할 때 내장형 데이터베이스 역시 새로운 메모리에 생성해서 돌려주어야 하는데, 이 애노테이션으로 생성된 컨텍스트는

기존에 생성됐던 내장형 데이터베이스에 다시 작업을 진행한다.

이 과정에서 이미 테이블까지 완성시킨 내장 데이터베이스에 다시 한 번 테이블 스크립트를 실행하고 SQL익셉션을 내뱉는 것이다.

왜 이렇게 작동하는지는 아직 정확한 이유를 알 수 없다.

한가지 알 수 있는것은 @DirtiesContext 는 컨텍스트를 완전히 새로 생성하는 것이 아니라는 것이다.

DI의 정보가 수정된 빈만 새로생성해서 돌려주거나 하는 특수한 작업을 하는 것으로 추측된다.

Junit 테스트는 컨텍스트 생성에 실패하고 다음 테스트에 다시 한 번 완전히 새로운 컨텍스트를 생성해 진행하게 된다.

(이 부분은 온전히 새로운 컨텍스트이기에 내장형 데이터베이스도 새로 생성되며 스크립트의 중복실행 또한 없다.)

결과적으로 @DirtiesContext 이후에 새로생성된 불완전한 컨텍스트로인해

@DirtiesContext이 붙은 테스트 바로 다음에 실행되는 테스트는 컨텍스트를 생성하는 과정에서 스크립트 중복실행으로 테스트가 실패하는 것이다.

@DirtiesContext 이 빈을 재생성할 때 어떤 작업을 하길래 이러한 문제가 발생하는지 해결 방법은 없는지

언젠가 스프링의 소스코드를 분석하게되면 찾아봐야겠다.

언팩완료.  클리어

내 수리능력이 참으로 원망스러웠던 문제..

고길님의 문서를 보고 마지막의 EAX와 EBX를 구해서 제일 처음의 EAX와 EBX로 만들고 언팩했다.

원본 파일에 트랩이 있어서 삽질을 조금. ..

오리지날 파일이 왜 제공됐는가 의문이었는데 원본 메모리를 뜯어보니 문서와 똑같이 따라하면 실패하도록 트랩이 설치되어있었다. -_-

goodluck ....

가장 처음의 EAX와 EBX를 구하는 소스코드 

#include <stdio.h>


int main(void)
{
    unsigned int prev = 0x726ee12b, ofst = 0x20c1085a, check = 0;
    unsigned char bhChk=0;
    unsigned int reEbx = 0x????????; 

// 가장 마지막의 Ebx값을 reEbx에 넣어주면 된다. 이 값을 적고 프로그램을 돌리면 바로 답이 나오기에 이 값은 블라인드 처리..

    _asm{
        push ebx
            push eax
            push edx
            push ecx
            xor ecx,ecx
            xor edx,edx
            xor ebx,ebx
            xor eax,eax
    }


    for(unsigned char i=0; i<=0xFF; i++){
        _asm{
            mov eax,ofst
                mov cl, i
                rol eax, cl
                xor eax, prev
                mov check, eax
                mov ebx, check
                mov bhChk, bh
                mov eax, prev
                mov cl, al
                ror ebx, cl
                mov check, ebx
        }
        if(bhChk == i)
        {
            printf("BH : %x, EBX : %x\n", i, check);
        }

        if(i == 0xFF){
            break;
        }
    }

    _asm{
    }

    for(unsigned int i=5; i<=0x1000; i++){
        _asm{
                mov ebx, reEbx
                mov eax, prev
                sub ebx, eax
                mov cl, bh
                rol eax, cl
                xor eax, ebx
                mov cl, al
                ror ebx, cl
                mov reEbx, ebx
                mov prev, eax
        }
    }



    _asm{
            pop ebx
            pop eax
            pop edx
            pop ecx
    }

    printf("prev EAX...EBX %x, %x\n", prev,reEbx);

    return 0;
}

1차 시도 : 15/02/27

PEB에서 비롯되는 Ldr, Heap 안티 디버깅을 지나  OEP 도달. 

scanf 로 입력을 받고 난 뒤 ZwQueryInformationProcess API를 사용하는 안티 디버깅에 걸려서 실패 . 

오늘은 여기까지.

2차시도 : 15/02/28 

2차시도 4시간 30분만에 클리어. 

내용이 너무 방대해 자세한 내용은 나중에 쓸까 말까 고민중입니다. .

간략히 설명하자면

처음엔 1차시도에서 확인한 PEB 관련(Ldr, HeapFlag ) 안티디버깅이 3회 출몰합니다. 

그리고는 이제 Main만 분석하면 될것처럼 OEP가 등장하고 

scanf로 입력을 받다가 뜬금없이

ZwQueryInformationProcess native API로 2회 안티디버깅이 나옵니다. 

이제 정말 끝이겠지 하고 분석을 하던 도중 GetThreadContext로 디버그 레지스터에서 하드웨어 브레이크가 있는지 없는지 검사합니다.(분석하면서 하드웨어 브레이크를 사용할 일이 없었기에 무사히 넘어갔습니다.)

여기까지 지나면 드디어 내가 입력한 값들이 어떤 연산으로 분기되는지 나옵니다. 

그리고 대망의 비교루틴에서도 한 두번씩 페이크가 나옵니다 - -. 

1번째 문자에대한 페이크와 몇번째인지 기억은 안나는데 예, 예, 예 버튼 막 누르던 도중에 예 버튼자리에 아니오가 온 느낌이랄까요. 

그런느낌으로 엄한데로 점프 시켜버립니다 --. 

다행히 점프하기전의 스택으로 돌려놓고 origin 바꿔서 되돌아 오긴했습니다만.. 인내심을 시험받은 듯한 느낌이 드네요..

일단 여기까지

파일 디스크립트 문제, UPX 실행 압축과 매우 긴 쓰레기 코드로 리버싱을 방해한다.

중요 부분만 빠르게 체크하자

먼저 쓰레기 코드를 건너 뛰기 위해 printf 함수에 BP를 걸어 실행한다.

그러면 위와같은 파일관련 함수 호출이 연이어 등장하는 루틴을 발견할 수 있다.

401000 CALL 명령은 리버싱을 방해하는 쓰레기 코드이니 무시하자

내가 입력한 문자열을 순서대로 한개씩 돌려가면서 복호화 키로 사용하고 있다.

그리고 마지막 즈음에 파일 전체에 XOR EDX,0FF 명령으로 다시 한번 복호화를 진행한다.

암호화 루틴은 매우 간단하다.  내가 입력한 문자열을 순서대로 하나씩 뽑아서 암호화 하고, 다시 0xFF로 전체 파일을 암호화 한것이다.

그럼, 전체 파일을 0xFF로 한번 복호화 하고

일반적인 PE 실행파일에서 공통적으로 등장하는 부분을 0~0xFF 모든 경우로 다시 복호화해서 비교해보면 되겠다.

나는 도스 스텁 코드로 나오는 is program cannot 을 대상으로 복호화를 진행했고 복호화 키값을 얻어낼 수 있었다.

(간단한 프로그램을 짜서 is program cannot 스텁 부분의 문자열을 무차별 복호화 한 값하고 비교해보면 간단히 나온다.)

복호화 키값으로 원본 파일을 복호화 해보면 키값을 출력하는 프로그램이 나온다. 

복호화에 사용된 소스 :

#include "stdafx.h"
#include <string.h>

char sig[100];
char cksig[100];

int _tmain(int argc, _TCHAR* argv[])
{
    char chk;
    FILE* file = fopen("file", "r+b");


    strcpy(cksig, "is program cannot");

    rewind(file);
    fseek(file,0x50,SEEK_SET);

    for(int j=0; j<100; j++){
        sig[j] = fgetc(file);
        sig[j] ^= 0xFF;
        for(int i=0; i<=0xFF; i++){
            chk = sig[j] ^ i;

            if(chk == cksig[j]){
                printf("%c", i);
                break;
            }
        }
    }


    fclose(file);


    return 0;
}