Category

    level3

    level3

    바로 시작해 보자. level3의 힌트는 아래와 같다. 소스코드를 유심히 보자. 조건문에 인자가 2개가 아니라면 프로그램이 종료 됨을 확인할 수 있다. 만약 2개의 인자가 들어오게 된다면, 첫 번째 인자는 프로그램의 실행 프로그램명을 의미할테고, 두번째 들어오는 놈을 cmd char형 배열에 붙여 넣는다. 마지막에 system 함수로 실행하게 된다. cmd를 확인해 보면 "dig@ 입력되는놈 version.bind chaos txt" 이란 명령이 system 함수에 들어간다. 다음 힌트를 보면 동시에 여러 명령어를 사용하려면? 문자열 형태로 명령어를 전달하려면? 이란 힌트가 있다. system 함수에 명령이 하나가 아닌 두개가 들어가서 실행이 된다면? 그럼 password를 바로 알 수 있지 않을까? 한..

    Level 2

    Level 2

    Level 2로 넘어가서 힌트부터 확인하자. 텍스트 파일 편집 중 쉘의 명령어를 실행 시킬 수 있다는데... 정말 쌩뚱 맞다. 처음에 이 힌트를 보고 굉장히 당황 했지만, 하나하나 뒤져 나가기로 했다. SUID가 설정되어 있고, 소유 권한이 level3인 파일을 찾아 봤다. 아래와 같은 editor라는 파일을 찾을 수 있었다. editor 라니? vi 에디터를 말하는 건가? ls 명령어를 이용해서 editor 파일과 기존에 제공되는 vim 파일을 비교해 보면 editor 파일은 소유권한이 level3이고 그룹권한은 level2 인 파일이고 vim 파일은 둘다 root 권한인 파일 임을 확인할 수 있다. editor파일을 실행하면 vim 에디터 파일 실행과 동일하게 실행된다. 이 상태에서 권한이 level..

    Level1

    Level1

    먼저 level1 의 디렉토리에 무엇이 있는지 확인하고, hint라는 파일안의 내용을 확인하면 아래와 같은 문구가 나온다. level2 권한에 setuid가 걸린 파일을 찾는다. 라는 힌트 문구가 보인다. 실행 퍼미션에는 setuid와 setgid라는 특별한 퍼미션이 있다. setuid는 심볼릭 모드로 's'로 표현되고 8진수 모드로는 4000 으로 표현된다. setuid 퍼미션이 설정되어 있는 실행 파일은 실행되는 동안에는 그 파일의 소유자 권한을 가지게 된다. 이러한 이유때문에 root 소유의 setuid 퍼미션이 포함되어 있는 파일은 아주 신중히 관리를 해야 된다. setgid 퍼미션이 포함되어 있는 실행 파일은 실행되는 동안은 그 파일의 소유 그룹의 권한을 가지는 것 빼고는 setuid와 같다. ..

    find 옵션

    find 찾는 명령어 find / (root부터 시작) -name "log"(이름이 log 인 파일) 그 외는 너무 많이 떠서 생략 // * find 사용자가 지정한 특정파일을 찾는 명령 사용법 find [시작 디렉토리] [각종 문법] 주어진 디렉토리에 [각종 문법]에 해당하는 내용과 일치하는 파일을 찾아 보여준다. 부모 디렉토리에서부터 시작해서 하위 디렉토리에 있는 모든 파일들에 대해서 검색하며, 시스템 내의 모든 파일들에 대해 찾고자 할때는 [시작 디렉토리[를 ‘/’(root)로 지정한다.-name “문자열” : 파일이름이 문자열과 일치하는 파일을 찾는다. “log” : 파일이름이 log인 파일 “*log” : 마지막 문자열아 log로 끝나는 모든 파일 “log*” : log로 시작하는 파일 “?lo..

    WAIT_FOR_CONCURRENT_GC ??

    사용자 코드가 명시적으로 GC ()를 호출하고 GC가 이미 진행 중인 상황코드를 할당 할 시도하지만 요청을 수용 할 수있는 메모리의 실제 공간이없고, GC가 이미 진행 중일 때. 각각의 경우에, 요청을 수행하기 위해, 다른 스레드에서 GC를 사용하고 있어 해당 스레드에서 GC 작업을 기다리는 것입니다.

    죽지 않는 서비스 등록(알람 이용)

    안드로이드는 사정에 따라 서비스를 죽이기도 하며 나중에 다시 살리기도 한다.만일 항상 떠있는 서비스를 구현하고자 하는 경우에는 이런 일이 발생하는것에 대해 아주 당황할것이다.이럴경우 서비스를 죽지 않도록 하고자 할것인데.이런 경우 알람서비스를 이용하여 서비스가 죽으면 다시 살리는 방법이 있다.많은 경우 이런 방식을 이용하는것으로 보인다. PersistentService가 죽지 않아야 할 서비스이다. 아래 예제에서 보면 onCreate시 기존 알람이 있으면 제거하고 onDestroy시 알람을 기동한다. 알람은 일정시간이 지나면 PendingIntent를 날리는 알람이며 이 인텐트를 받을 수 있는 BroadcastReceiver가 있게 된다. 여기서는 RestartService receiver가 해당 인텐트..