프로세스는 "프로그램이 실행되기 위해 메모리에 할당된 것"이다

스레드는 프로세스 속에 존재하는 개념으로, 실제로 작업을 처리하는 worker의 개념이다 (Thread와 context?)

프로세스는 스레드를 포함하는 관계이며, 1개의 프로세스에는 1개 이상의 스레드가 존재한다.

---

OS 관점이 아니라 concurrency 관점에서 바라보면, multi-process vs multi-thread가 된다

<multi-process vs multi-thread)

첫번째는 global 변수, dynamic allocation된 메모리와같은 shared data.

multi-process는 모든 데이터를 별도로 가지기 때문에, shared data에 의한 racing이 발생하지 않는다

반면 multi-thread는 stack segment memory만을 별도로 가지기 때문에, shared data를 동시에 write할 때 sync(동기화)를 해야한다

(multi-process > multi-thread)

두번째는 communication.

첫번째와 반대로, multi-process에서는 통신을 위해 IPC를 해야한다. 예를 들면 pipe, signal, socket(주로 network), 세마포어(semaphore), shared memory(C언어의 shm*()), MM I/O

그에 비해 multi-thread는 IPC가 필요없이, shared data들을 통해 간단하게 통신이 가능하다 (sync가 필요하다 하더라도 IPC보다 간단하다)

(multi-process < multi-thread)

세번째는 memory 사용량.

process가 더 많은 메모리를 사용하므로, 메모리 사용량 면에서 비효율적이다

이것은 context switching도 비효율적으로 만든다 (더 많은 메모리를 switching해야하기 때문) (cache hit ratio까지 떨어뜨린다?)

---

process vs thread와 multi-process vs multi-thread를 동일하게 생각하고 있었는데, 서로 다른 레벨의 관점이었다. 

구분해서 기억해두자

RDB 특징(장단점)

 - Table마다 Schema를 정의해야한다

    - data type과 constraint를 통해서, 데이터의 정확성을 보장한다

 - SQL을 통해 요청을 처리한다

 - 성능을 높이려면 H/W를 고성능으로 교체해야 한다 (=scale up)

    - 고성능 H/W는 가격이 매우 비싸다

    - RDB의 성능을 높이기(확장하기) 어렵다는 의미이고, 이것을 보고 RDB의 확장성이 낮다고 한다

NoSQL 특징(장단점)

 - RDB의 확장성 이슈를 해결하기 위해 나온 DB 모델 (등장배경)

 - 분산 컴퓨팅 활용이 목적이고 이것을 통해, 비교적 저렴한 가격으로 DB 성능을 높일수 있다 (=Scale out)

 - NoSQL이 분산 컴퓨팅 가능한 이유? : Table이 여러개가 아닌 등, 자세한 내용은 이후 추가예정 (Sharding?)

 - 그래서 Hadoop과 함께 언급되는 경우가 많다

 - 여러 개의 table이 아닌 Big table 1개만을 사용한다

    - 가장 많이쓰이는 NoSQL은 Key-value 형식으로 데이터를 관리한다

 - SQL을 사용하지 않는다

 - Schema-less

    - 구조 변경이 쉽다

    - 데이터 형식이 다양하고 / 바뀌기 쉽고 / 정확성보다는 데이터량이 중요한 BigData 사용에 적절하다

 - 대표적으로 Redis(Key-value), MongoDB(document-oriented) 등이 있다

In-memory DB 특징(장단점)

 - Memory의 가격이 용량대비 충분히 낮아지면서 빠른 DB 성능을 위해 나왔다 (등장배경)

 - Disk 대신 memory를 사용함으로써 I/O 성능을 높인다 (SSD처럼)

 - 대표적으로 Redis, LMDB 등이 있다

redis를 간략하게 소개하자면, 가장 많이 사용되는 in-memory key-value databse이다

key-value DB는 NoSQL의 한 종류이고, 또한 NoSQL은 SQL을 사용하지 않는 비관계형 database이다

간략한 특징은 아래와 같다.

in-memory이고 hash table을 사용하므로 RDB보다 빠르다

MySQL같은 RDB와 달리 Data organization이 없다 (테이블 스키마가 없다)

단점으로는 일부 value만 읽어올 때는 비효율적이라는 점이 있다

redis에 대한 등장배경 및 자세한 내용은 아래 글을 참조하자

http://codingmania.tistory.com/18

NoSQL에 관한 내용은 아래를 참조하자

http://lazybrain.ikspres.com/nosql1/

https://subokim.wordpress.com/2011/05/20/when-nosql-makes-better-sense/

http://jtoday.tistory.com/12

<redis 설치>

redis는 windows platform을 지원하지 않으므로, docker를 이용하여 설치하기로 했다

https://hub.docker.com/_/redis/

위 사이트에서 docker redis image 및 instance 실행방법이 서술되어 있으며, 이 글은 위 사이트를 기반으로 한다

필자는 windows python redis를 client로 사용할 것이다

docker run --name some-redis -d -p 6379:6379 redis

redis 이미지로부터 redis 컨테이너를 생성 및 실행하고 host의 6379 포트와 연결한다

redis server 실행은 이 한 줄로 끝이다. 이제 파이썬을 통해 테스트해보자

https://pypi.python.org/pypi/redis

위 사이트의 getting started를 기반으로 한 내용이다

windows에서 cmd를 실행한다

pip install redis

아래 코드를 실행한다

import redis

r = redis.StrictRedis(host='192.168.99.100', port=6379, db=0)

r.set('foo', 'bar')

r.get('foo')

host는 win7의 경우 192.168.99.100, win10의 경우 localhost일 것이다

위와 같이 간단하게 redis server를 실행하고 간단하게 python redis를 사용할 수 있다

유저의 입장에서만 보면, FFmpeg이 더 기능이 많다고 참고사이트에 언급되어있다 (필자가 직접 차이를 느껴보지는 못했음)

하지만 특별한 케이스가 아니라면 어느 쪽을 사용하든 상관없을 것이다

두 프로젝트는 분쟁이 생겨 갈라지게 되었다는 것 같다

참고: http://klutzy.nanabi.org/blog/2012/11/16/ffmpeg-libav/

이론적인 관점보다는, 프로그래밍 관점에서 살펴보자

sync, async I/O부터 비교해보면 async I/O는 CPU 작업과 I/O 작업을 병렬처리 할수있는 방식이다

대표적인 예제는 서브스레드에서 I/O 작업이 완료되면 callback을 호출하는 형식이다

이렇게 하면 메인스레드에서는 I/O 작업동안 UI 처리와 같은 CPU 작업을 할수있다

반대로 sync I/O의 대표적인 예제는 싱글스레드에서 CPU 작업과 I/O 작업을 모두 처리하는 형식이다

즉 I/O 작업이 끝날 때까지 기다려야 한다

이럴 경우, 유저 입장에서는 프로그램이 멈춘 것처럼 보이게 된다

이러한 이유로 Android Java에서는 메인스레드에서 Network I/O 작업을 할수없다

Network I/O 통신 중이라 하더라도 UI가 멈추지않게 하기 위함이다

그래서 Retrofit2 라이브러리를 메인스레드에서 사용할 때는 async request를 사용한다

결과적으로 async I/O는 I/O 작업과 CPU 작업을 동시에 처리할수 있게 된다

MSDN에서 Async Client/Server Socket을 C# Callback으로 구현한 예제를 제공하고 있다

https://msdn.microsoft.com/ko-kr/library/bew39x2a(v=vs.110).aspx

https://msdn.microsoft.com/ko-kr/library/fx6588te(v=vs.110).aspx

이제 blocking, non-blocking I/O를 비교해보자

이것은 socket에 직접 option을 설정해주는 형식으로 구현된다

blocking일 경우 recv/send/connect/accept system call이 완료될 때까지 blocking되었다가 완료되면 return된다

non-blocking일 경우 반대로 system call이 완료되지 않아도 즉시 return된다 (blocking되지 않는다)

그 결과, non-blocking일 경우 I/O 작업 중간에 CPU 작업을 처리할수 있게된다

async I/O도 마찬가지지만 non-blocking으로 구현할 경우 프로그램 구조가 복잡해진다는 단점이 있다

------

I/O 방식은 대표적으로 멀티클라이언트를 처리하기 위해서 선택되는데, 아래는 멀티클라이언트를 처리하기위한 여러가지 구조에 대한 설명이다

가장 간단한 I/O 구조는 1:1 통신만 가능하다

멀티클라이언트(1:N) I/O를 처리하기 위한 가장 간단한 방법은 멀티스레딩이다

하지만 이것은 메모리 오버헤드가 크게 증가한다는 단점이 있다

Apache 서버가 멀티스레딩 방식인데, 메모리에 의해 최대 동시 연결갯수가 제한된다

그래서 Nginx, Node.js 서버는 멀티스레딩 방식을 사용하지 않는다. 자세한 내용은 async 방식에서 언급한다

메모리 오버헤드를 극복하기 위해, 싱글스레드에서 멀티클라이언트를 처리하기 위한 방법 중 첫번째는 I/O Multiplexing이다

대표적인 것이 select(), poll() system call인데, (시스템 콜: 유저 권한으로 할수없는 작업을 커널에 요청하기 위한 인터페이스) select()를 설명하자면 

blocking된 상태로 fd table (socket table)을 관찰하면서 1개 이상의 socket이 "ready" 상태가 될 경우 reutrn한다 (이 과정을 loop로 반복)

select()는 synchronous I/O multiplexing API이다. 그 내용은 linux select man page에서 확인할 수 있다

select, pselect, FD_CLR, FD_ISSET, FD_SET, FD_ZERO - synchronous I/O multiplexing

select()의 가장 큰 문제점은 클라이언트들이 동시에 접속할 경우, 다른 클라이언트의 처리완료를 기다려야한다는 것이다 (싱글스레드에서 모든 요청과 I/O를 처리하기 때문에)

그래서 select()는 작업단위가 작은 서버에 적합하다

이 외의 단점은 CPU 오버헤드 증가(매 loop마다 fd table을 검사해야 하므로)가 있다

멀티클라이언트 처리에 non-blocking 방식도 사용할수 있다

우선 이 방식은 구조가 복잡하다는 단점이 있다

기존 방식과의 차이점은, socket 생성 후 non-blocking 옵션을 세팅해주는 과정이 추가되고, I/O system call을 1번이 아니라 loop를 통해 여러번 호출하게 된다

I/O 함수가 즉시 리턴되므로 또다른 작업을 할수있게 된다. 즉 blocking되지 않으므로 다른 클라이언트에 대해 I/O를 처리할수 있다는 의미이다

정리하여 non-blocking socket의 단점으로는 복잡한 구조와 CPU 오버헤드 증가 (I/O 작업이 일어나지 않았더라도 계속 loop를 돌며 확인하므로)를 들수 있겠다

마지막으로 async 방식은 곧 callback이라고 생각해도 큰 문제 없을 듯하다

아까 언급했던 Nginx Node.js이 바로 async 방식의 서버로서, I/O 요청 후 작업이 완료되면 callback이 호출된다

그리하여 I/O 작업이 이뤄지는 와중에도 I/O 요청들은 딜레이없이 처리할 수 있게된다

아래 참고사이트들을 살펴보면, Apache 서버와 Node.js 서버를 비교했을 때 스레드를 생성하지 않으므로

훨씬더 많은 클라이언트 요청을 처리할 수 있다고 설명한다 (= 확장성이 뛰어나다)

---

각 I/O 방식의 구조, 장단점을 설명하였고 멀티클라이언트 처리 관점에서 I/O의 다양한 구현들을 설명하였다

async와 non-blocking 개념이 헷갈려서 쓰게 되었고, 이 둘은 굉장히 많이 혼동하는 개념이므로 정확하게 이해해둘 필요가 있다

좀더 쉽게 설명하기 위해 구현 관점에서 설명해보았다

(글을 여러번 수정하면서 장황해졌는데 이후에 다시 간단하게 정리해야겠다)

Threading is about workers; asynchrony is about tasks

참고: 

http://www.tutorialspoint.com/unix_system_calls/_newselect.htm

http://ozt88.tistory.com/20

http://www.nextree.co.kr/p7292/

https://qkraudghgh.github.io/node/2016/10/23/node-async.html

http://la-stranger.tistory.com/m/entry/understanding-node-js-event-loop

https://stackoverflow.com/questions/34680985/what-is-the-difference-between-asynchronous-programming-and-multithreading

FFmpeg은 라이브 스트리밍 프로젝트를 진행하면서 처음 접하게 되었다
ARM Cortex Board에 FFmpeg을 사용하는 프로그램을 개발하기 위하여 cross-compile하여 shared library를 보드에 설치하였었다
프로젝트의 구체적인 내용은 WebCam, Mic Device로부터 video, audio를 각각 읽어와 HTTP 프로토콜을 통해 live streaming하는 것이었다
FFmpeg, cross-compile 등을 처음 접하면서 헤맸던 경험을 바탕으로 하여,
FFmpeg으로 Device에서 stream을 읽어오는 프로젝트를 진행하기 위한 이상적인 진행순서를 작성한다.
물론 개인적인 기준이다.

최종 구현은 아래와 같다
cross-compile -> ARM Linux에서 Device -> streaming
cross-compile보다는 streaming을 하는 프로그램 코딩이 더 우선순위가 높아야한다. cross-compile하기전에 코딩을 먼저 진행해야 한다는 의미이다
이것이 가능한 이유는 FFmpeg의 사용법이 Windows나 Linux나 차이가 없기 때문이다
video stream의 container format이 Windows는 dshow이고, Linux는 v4l2라는 것 외에는 동일한 코드를 사용한다
즉 Windows에서 FFmpeg 프로그램을 먼저 코딩해 보라는 것이 첫번째

Windows에서 FFmpeg 코딩을 해보려고 해도, 카메라가 없을 수 있다. 하지만 그것은 문제가 되지 않았다
input으로 카메라가 아닌 동영상 파일을 사용하면 된다
이것 또한 format, codec의 차이 뿐 큰 맥락에서는 거의 동일하다
카메라를 읽어오기 전에 동영상 파일부터 읽어보라는 것이 두번째
(참고로 FFmpeg에서 AVIO 함수들은 카메라에 사용할수 없었다)

필자는 FFmpeg이 Windows와 Linux에서 어떤 차이가 있는지, device와 video file을 읽어오는데에 있어서 어떤 차이가 있는지, container format이 무엇이고 codec이 무엇인지 아는것이 전무했기 때문에 많이 헤매었고,
위 내용은 그 과정에서 알게된 것들이다

요약하자면
Windows에서 동영상 파일을 읽어보고,
카메라 스트림을 읽어보고, 스트리밍을 해보고,
마지막에 cross-compile하여 ARM Linux Board에서 구현해놓은 프로그램을 실행해보는
순서가 이상적이라고 생각한다

다음에 비슷한 프로젝트를 진행할 때 참고하면 시간을 효율적으로 관리할 수 있을것 같다

공식 사이트의 아래 페이지를 기반으로 작성하였다

https://caffe2.ai/docs/getting-started.html?platform=windows&configuration=docker

Windows 7 64bit

2017-11-07 기준 최신 버전

Windows에서는 GPU mode를 지원하지 않으므로, CPU mode + full option 이미지를 다운받았다

docker는 설치했다고 가정한다

# docker pull <repo/repo:tag>

docker pull caffe2ai/caffe2:c2v0.8.1.cpu.full.ubuntu14.04

docker image를 다운(pull)받는다

# to test

docker run -it caffe2ai/caffe2:c2v0.8.1.cpu.full.ubuntu14.04 python -m caffe2.python.operator_test.relu_op_test

docker image로부터 container를 생성한다

python을 실행하여 test해본다

# jupyter from docker

docker run --name mycaffe2 -p 80:8888 caffe2ai/caffe2:c2v0.8.1.cpu.full.ubuntu14.04 bash -c "jupyter notebook --no-browser --ip 0.0.0.0 --allow-root /caffe2/caffe2/python"

docker image로부터 container를 생성한다

container name을 mycaffe2로 설정한다

host port 80을 container port 8888과 연결한다

jupyter를 실행한다

이제 host에서 docker의 jupyter에 접속할수 있게 되었고, token은 docker에 출력된 것을 사용하면 된다

windows 10은 localhost:80로 접속이 됐던 것 같은데, windows 7은 192.168.99.100:80로 접속해야 한다

(본인의 경우 windows 7 docker는 virtualbox 설치필요, vim key mapping 문제, localhost not working 등 불편한 점이 많았다)

# list container

docker ps -a

이 명령어로 생성되었던 container들을 확인할 수 있다

# start container

docker start mycaffe2

재부팅 등의 이유로 container가 exited된 경우, 이 명령어로 container를 다시 시작한다

---

<쉘 실행하기>

docker exec -it -u 0 mycaffe2 bash

docker terminal에서 위의 커맨드로 bash 쉘을 실행할 수 있다. -u 0는 uid=0(root) 옵션이다

또는 jupyter 우측 상단에 New-Terminal을 통해, 웹쉘에 접근할 수 있다

웹쉘은 docker terminal과 달리 vim key mapping 문제가 발생하지 않으므로, 유용하게 사용할 수 있다

---

vim key mapping issue는 docker for windows의 버그인듯하다

고칠수가 없네

cp /usr/share/vim/vim74/vimrc_example.vim ~/.vimrc

위 커맨드를 사용하면 된다

결국 set term=cygwin로 해결된건데, 이거 때문에 몇시간을 버린건지.

참조: https://superuser.com/questions/843876/cygwin-terminal-backspace-and-arrow-keys-not-working

티스토리 블로그를 네이버 웹마스터 도구에 연동해도(주소를 등록해도)

신디케이션을 적용해도

수집요청을 해도

티스토리 블로그가 네이버 검색에 노출되는 것은 불가능한 것 같습니다.

되는 경우도 있긴 하던데.. 전 안되네요

무슨 이유인지는 네이버에서 알려주지 않네요(구글은 알려준다는데)

ssaemo.tistory.com 는 수집이 성공하지만

ssaemo.tistory.com/1 처럼 개별 게시글은 수집이 되지 않습니다.

신디케이션 핑도 가지 않습니다 검증실패

구글 웹마스터 도구 Search Console은 다음 포스팅에서 다루기로 !

***** ***** ***** 추가 ***** ***** *****

라고 생각했는데 네이버에서도 블로그 탭에 검색 노출이 되는 것을 확인했습니다.

일단 수집 요청은 실패합니다.(수집이 이미 되었든, 안되었든 모두 실패) [1]

그리고 네이버는 ssaemo 검색 시 주소에 ssaemo가 포함되어도 검색이 되지 않습니다. [2] 즉, 글 제목과 내용에서 검색합니다. 메타 태그 description, keywords는 좀 더 알아봐야겠지만.

마지막으로, 오래된 글이든 아니든 기간에 상관없이 일부 글만 수집됩니다.

맨 처음에 쓴 글은 수집되지 않고, 어제 쓴 글은 수집이 되네요.(이 글)[3]

좀더 알아내면 적겠습니다..

필자는 용어를 굳이 명확하게 구분하는 것을 좋아한다.

그리고 최대한 정의만 간단히 하여 쉽게 이해하는 것을 좋아한다.

그래서 정리해보았다.

그러나, Platform과 Framework의 경계선은 애매하다. 명확하게 구분되지 않는다. 이것이 필자의 결론이다.

그래도 일단 알아보자.

Platform : 소프트웨어SW를 실행해주는 환경. Windows, Linux 등의 OS가 예이다.

Framework : Software Framework. 클래스와 라이브러리들의 집합이라고 생각하자. 여기에서 라이브러리랑은 뭐가 달라요?라는 의문이 생긴다.

LIbrary는 개발자가 프로그램의 흐름을 제어한다. 주가 개발자이다.

그러나, Framework는 그 반대이다. 프레임워크의 실행 흐름 내에서 개발자가 일부분을 개발한다. 

정확한 예인지는 모르겠지만, 프레임워크는 '웹 개발' 프레임워크처럼 웹 개발 틀이 만들어져 있고, 라이브러리는 그런 것이 없고 사용하기 나름이다.

프레임워크의 예로 .NET Framework(닷넷 프레임워크)는 MS의 윈도우 프로그램 개발/실행 환경이라고 위키디피아에서 소개한다. 가상머신 CLR에서 작동한다.

프로그램/소프트웨어의 '실행' 부분에서 플랫폼은 필수다. 프레임워크도 필요한 경우에는 필수다. 이런 점에서 뭐가 달라?라는 의문이 생기는 모양이다. 하지만 '개발' 부분에서는 프레임워크와 라이브러리가 비교 대상이다.

틀린 부분이 있다면 태클/피드백 주시길.

Character Set.

Encode. Encoding.

인코딩의 종류는 너무나도 많다. 그걸 한 번 정리해보자.

Reference : 

https://kldp.org/node/129659

UNICODE

유니코드. 인코딩이라기보다는 개념이다.

문자열을 숫자로 표현하기 위하여, 문자 하나와 숫자 하나를 각각 매핑한 것이 바로 유니코드이다.

매핑은 한글로 하면 사상인데, 쉽게 연결이라고 생각하자.

예를 들어 A는 U+0041에 매핑되어있고, '가'는 U+AC00에 매핑되어있다.

그리고, 이 유니코드를 저장하는 방법에는 다양한 방법이 있다. UTF-8, UTF-16 등, 살펴보자!

 - UTF-8

컴퓨터를 다루면서 자주 보았을 UTF-8은 유니코드 인코딩 중에 하나로, 문자열을 8-bit 기반으로 저장한다. ANSI 문자(영어 포함)는 그대로(1 바이트로) 아시아 문자는 3 바이트로 가변 표기하는 인코딩 방식이다.

https://ko.wikipedia.org/wiki/UTF-8

위키에 잘 설명되어있다.

'가'를 UTF-8로 표기하려면

범위상 1110xxxx 10xxxxxx 10xxxxxx에 해당하고

'가'가 매핑된 U+AC00은

0xAC00 = 44,032 = 10101100 00000000 이고

이제 x 표시한 부분에 순서대로 넣어주면 된다. 보기 편하게 색깔을 넣어줬다.

11101010 10110000 10000000

234       176        128

EA        B0          80

이런 식으로 UTF-8이 완성된다.

A는 그냥 U+0041 -> 0x41이다. 이제 한글이 왜 3 바이트인지 이해가 되는가?

이런 점에서 UTF-8로 영어 문서를 작성할 경우, 문서의 용량을 줄일 수 있다. 게다가 ANSI와 호환도 된다는 장점이 있다.

여담이지만, URL의 %41도 UTF-8이다.

URL Encode, Percent Encode는 %를 붙인 UTF-8 인코딩이라고 할 수 있다.

 - UTF-16

https://ko.wikipedia.org/wiki/UTF-16

UTF-8이 8-bit 기반이듯 UTF-16은 16-bit 기반으로 문자열을 저장한다.

그래서 UTF-16은 모든 문자를 2 바이트로 저장한다는 이야기가 있는데

그것은 미신이다. 위키에서도 설명하듯, BMP의 문자들은 2 바이트 그대로 인코딩되고, 그 이상의 문자는 특별한 방식으로 4 바이트 인코딩된다. BMP는 UCS-2에서 설명하겠다.

즉, UTF-16도 엄연한 가변 표기 인코딩이라는 것이다. 알아만 두자.

UTF-16에서 중요한 것은, 16-bit 기반으로 문자를 저장함으로써 한글 또한 2 바이트로 저장할 수 있다는 것이다.

이를 통해 한글 문서의 용량을 줄일 수 있을 것이다. 그 외에 영어+한글 처리 시 크기가 모두 2 바이트이므로 UTF-8보다 편리한 경우도 있겠다.

그러나 ANSI와 호환이 안될 뿐더러, 2 바이트이기 때문에 리틀엔디안, 빅엔디안이 필요하다는 단점이 생긴다.

< 윈도우즈 메모장notepad에서 텍스트 파일 저장 시, 유니코드, 유니코드(big endian)이 바로 UTF-16에 해당한다. >

 - UCS-2

https://ko.wikipedia.org/wiki/유니코드

위 링크에서 확인할 수 있는 유니코드 목록을 보면, 기본 다국어 평면 BMP(Basic Multilingual Plane) 부분이 있다.

https://ko.wikipedia.org/wiki/국제_문자_세트

위키에 UCS는 국제 문자 세트(UCS, Universal Character Set, 범용 문자 집합)라고 소개되어있다.

쉽게 설명하자면

UCS-2 인코딩은 U+0000 ~ U+FFFF 영역만을 표기할 수 있다.

그리고 모든 문자는 UTF-16과 같이 2 바이트로 표기된다.(그래서 UCS-2)

이게 전부다.

ANSI code(=ASCII)

ASCII(American Standard Code for Information Interchange)

ANSI code와 ASCII 둘 다 같은 말이라고 생각하면 된다.

ASCII table을 기준으로 인코딩 한 것이 ANSI encoding이라는 것이 필자의 추측.

ANSI로 표현가능한 문자들은 asciitable.com에서 확인가능하다.

유니코드 중 0x00~0x7f에 해당한다.

그런데, ASCII table에는 한글이 없는데

메모장에서 ANSI 인코딩은 어떻게 한글을 저장해요?

'가'는 B0 A1 로 저장되던데.

이에 대한 답은 다음 인코딩에 있다.

EUC-KR

한글 Windows의 메모장에서 이야기하는 ANSI 인코딩이란, EUC-KR을 말하는 것이다.

(틀린 부분이 있어 수정합니다. 댓글 감사합니다.)

한글 Windows의 메모장에서 이야기하는 ANSI 인코딩이란, CP949 (Code Page 949)을 말하는 것이다.

CP949는 EUC-KR의 확장이며, 하위 호환성이 있다.

EUC-KR이 뭐에요?

ANSI를 한국에서 확장한 것이다. 일본은 EUC-JP라고 한다.

EUC-KR 코드표를 확인해보면 B0 A1에 '가'가 매핑되어있는 것을 확인할 수 있다.

너무 많다 싶으면 UTF-8과 유니코드의 개념에 대해서만 제대로 알아두면 거뜬할 것이다.

8-bit 기반이라는 점만 기억해두자.

은근 복잡복잡.

rogue AP를 만들어보자.

일명 가짜 Access Point. Fake AP. 리눅스에서 무선 랜카드가 실제 AP인 것처럼 만드는 것이다.

일반적인 통신은 Client->AP->ISP 식으로 이루어지지만

Rogue AP를 통한 통신은 Client->Rogue AP->AP->ISP 식으로 이루어진다.

Rogue AP를 만드는 Linux는 두 개의 NIC를 통해 하나는 Rogue AP를 위하여, 다른 하나는 일반적인 NIC처럼 실제 AP에 연결한다.

이를 통해 AP처럼 인터넷을 공유하거나 MITM 공격을 시도할 수 있다.

다음 실습에서는 eth0가 일반적인 NIC가 되고, wlan0이 rogue ap가 될 것이다.

환경 : 가상머신 ubuntu 14.04

네트워크 어댑터 eth0는 NAT든 Bridged든 상관없다.

실습은 NAT에서 진행했다.

<use root>

sudo su

<package install>

apt-get install hostapd isc-dhcp-server -y

<Wireless NIC Connect>

무선 랜 카드 컴퓨터or노트북에 연결

iwconfig

잘 연결되었는지 확인

NIC driver명은 wlan0로 가정함.

<hostapd configure>

hostapd는 rogue ap를 만들어 줄 패키지이다.

vi /etc/hostapd/hostapd.conf

hostapd 설정은 http://melpin.tistory.com/?page=2 참조. 그대로 복붙해서 사용해도 무방.

ssid과 channel만 필요에 따라 수정. channel이 같은 AP가 존재할 경우 간섭이 발생할 수 있다.

<isc-dhcp-server configure>

isc-dhcp-server는 rogue ap에 연결된 victim(피해자)들에게 실제 AP처럼 DHCP 서비스를 해줄 패키지이다.

backtrack의 dhcp3-server 서비스와 동일하다.

vi /etc/default/isc-dhcp-server

#은 주석이므로 있으나없으나 동일

주석 부분 하이라이팅이 안될 경우 vim 패키지 설치.

아래와 같이 수정

INTERFACES="wlan0" # 스크린샷 상에는 eth0가 포함되어 있으나, 없어도 될 것이다.

vi /etc/dhcp/dhcpd.conf

ddns-update-style none;

option domain-name-servers 8.8.8.8; #Google DNS server

option routers 192.168.54.1; #rogue_ap의  IP Address

option subnet-mask 255.255.255.0;

default-lease-time 600;

max-lease-time 7200;

subnet 192.168.54.0 netmask 255.255.255.0 #network 

{

        range 192.168.54.2 192.168.54.254; #IP 할당 range

}

log-facility local7;

서브넷마스크상 192.168.54는 네트워크 부분. 그 뒤는 호스트 부분.

이해하는 한도 내에서 자유롭게 수정 가능하다. 게이트웨이 아이피든(option routers) 네트워크든(192.168.54)

이 실습에서는 rogue ap의 IP(Gateway)가 192.168.54.1라고 가정한다.

<NIC configure>

ifconfig

현재 상태

wlan0을 켜보자.

ifconfig wlan0 up

그런데 오류 발생.

RF-kill이 필요하다.

rfkill list

무선랜이 block 되어있다.(막혀있다)

풀어주자.

rfkill unblock wlan

rfkill list

block이 해제된 것을 확인.

wlan0 up 재시도

ifconfig wlan0 up

wlan0을 켰다.

wlan0은 rogue ap가 될 NIC이므로, static IP(고정. 정적 IP)를 할당해주자.

ifconfig wlan0 192.168.54.1 netmask 255.255.255.0

잘 설정되었다.

이제 hostapd와 isc-dhcp-server 패키지를 실행해보자.

<service start>

/etc/init.d/isc-dhcp-server restart

동일한 명령어로 

initctl restart isc-dhcp-server

service isc-dhcp-server restart

가 있으나, 해당 환경에서는 제대로 작동하지 않거나 성공/실패 여부를 보여주지 않았다.

서비스를 시작한 적이 없으니 stop은 당연히 fail이지만

start가 fail 되었다. 출력문을 따라서 syslog를 참조해보자.

(잘 실행되었으면 pass)

--pass--

파일을 열 수가 없다는 에러 로그.

그렇다. 필자는 다른 터미널에서 서비스를 실행하느라 root 권한이 아니었다. 이상한 데에서 시간 허비했다. (...)

엄한 데에서 헤맸다.

echo > '/var/lib/dhcp3/dhcpd.leases' # 해당 파일을 초기화한다. 수행하지 않아도 무방하다.

--pass--

dhcp 서버 실행 후

root 권한으로.. 

hostapd /etc/hostapd/hostapd.conf

아까 생성한 hostapd.conf 파일의 설정대로 hostapd를 실행했다.

가끔 이 부분에서 에러가 발생하는 경우가 있는데

nmcli nm wifi off

rfkill list

혹시 wlan이 block되어있는 지 확인하자.

hostapd까지 잘 실행되었다면, 와이파이가 만들어진 것이다.

또다른 무선 랜카드나 스마트폰 등으로 와이파이를 확인해보자.

필자는 ssid가 ssaemo_free인 와이파이가 생겨있었고, 해당 와이파이로 접속하면

IP 할당까지 완료되어 잘 연결되었다.

하지만 인터넷은 되지 않는다.

이제 wlan0에서 받은 패킷을 eth0로 리다이렉션해줘야할 차례이다.

커널 레벨에서의 IP 포워딩도 필요하다.

어떤 상태인지 궁금하다면 wireshark를 통해 wlan0과 eth0를 확인해보자.

<Packet Relay/Redirection>

IP 포워딩부터 하자. hostapd는 끄지않고 진행해도 된다.

echo 1 > /proc/sys/net/ipv4/ip_forward

또는

sysctl net.ipv4.ip_forward=1

이것은 OS 종료 전까지의 임시 세팅이다. 기본값은 여전히 0이므로, 부팅 시마다 이 값은 1이 아닌 0으로 세팅된다.

패킷을 리다이렉션 해주기 위해 iptables에서 설정을 해주자.

iptables -t nat -L : nat 테이블을 확인하는 명령어

iptables -L : default 테이블인 filter 테이블을 확인하는 명령어

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

iptables -P FORWARD ACCEPT

-t nat : nat 테이블

-A POSTROUTING : POSTROUTING 체인에 추가

-o eth0 : output NIC 설정

-j MASQUERADE : -j 옵션은 동작 설정. MASQUERADE는 SNAT와 같은 동작으로, 패킷을 리다이렉션하는 동작이다.

-P : Policy. 기본 정책. 설정이 없는 패킷에 대한 처리. filter 테이블의 FORWARD 체인의 기본 정책을 ACCEPT(허용)으로 바꾼다. 아무 설정이 없으므로 모든 패킷은 ACCEPT 된다.

여기까지 설정했다면 인터넷이 이제 잘 될 것이다.

리눅스 외 다른 기기에서(스마트폰) 와이파이를 연결하고, 인터넷을 연결해보자.

필자는 엄청 느리긴 하지만, 인터넷 연결이 가능했다!

다음 글은 aircrack-ng를 통해 rogue ap를 만들어보겠다. 아직 성공 못함.

1. 도킹 스테이션 구매 계획

2. 다나와->11번가 이동

3. 11번가 로그인

4. 휴면계정 해제 필요

5. 아이핀 인증 시도

6. Active X 설치 필요

7. IE가 추가 기능 실행 막음

8. 설치 안해도 로그인 되긴 함.

9. 아이핀 로그인 성공

10. 아이핀 사용 중지 상태.(?) 홈페이지에서 해제 필요

11. g-pin 홈페이지에서 중지 해제 시도

12. 해제하려면 공인인증서 필요

13. 공인인증서 쓰려면 Active X 설치 필요

14. IE가 추가 기능 실행 막음

15. 추가 기능 실행이 안돼서 해제 불가능

16. Active X가 한 두개가 아니라서 사용자 계정 컨트롤 때문에 화면 계속 깜빡거림(예/아니요)

17. 보안 모두 최하로 낮춤

18. 설정 적용하려면 재부팅 필요

19. 재부팅 후 Active X 모두 설치

20. 아이핀 중지 해제

21. 아이핀 로그인 성공

22. 패스워드에 특수문자가 있으니 패스워드 변경 후 사용바람

아니 패스워드 설정할 때는 특수문자 포함하라며

23. 안할란다 욕나온다

요약 : 윈도우는 보안 전부 최하로 낮추고 사용해야 제맛;

kimyuna is a south korean figure skater. 

she is the olympic champion in ladies singles the world champion the four continents champion a three time grand prix final champion the world junior champion the junior grand prix final champion anda four time south korean national champion kim is the first south korean figure skater to win a medal atanisu junior or senior grand prix event isuchampionshipandtheolympicgamessheisthefirstfemaleskatertowintheolympicgamestheworldchampionshipsthefourcontinentschampionshipsandthegrandprixfinalsheisoneofthemosthighlyrecognizedathletesandmediafiguresinsouthkoreaasofaprilthisyearsheisrankedsecondintheworldbytheinternationalskatingunionsheisthecurrentrecordholderforladiesintheshortprogramthefreeskatingandthecombinedtotalundertheisujudgingsystemsheisalsothefirstfemaleskatertosurpassthetwohudreadpointmarkundertheisujudgingsystemshehasneverbeenplacedoffthepodiuminherentirecareer

Corelan Exploit Tutorial : Corelan 팀에서 작성한 문서로, 공격 코드를 작성하는 방법에 대하여 서술되어있다.(문서 제목이 공격 코드 작성하기 튜토리얼이다.) Crelan 팀은 유명한 외국의 해킹 팀이다.

해당 문서에서 배운 내용을 좀더 쉽게 풀어써보고자 이 글을 쓴다.

Wargame에서는 Linux BOF 밖에 공부할 수가 없으니, Windows BOF를 공부하기에는 이 문서가 최고인 것 같다.

필요한 프로그램 : Easy RM to MP3 Converter, Immunity Debugger, WinDbg, python 

- 접기 WinDbg : WDK(Windows Driver Kit)에 포함되어 있는 것으로, MS에서 제작한 윈도우 디버거이다.WDK를 꼭 다운받아야 하는 건 아니고, standalone으로 다운 받을 수 있다.python : 스크립트 언어 중 하나. 간단한 문법으로 금방금방 코드를 짤 수 있는 것이 특징.

Easy RM to MP3 Converter 프로그램은 오버플로우 취약점을 가지고 있다.

오버플로우를 일으킬 파일을 파이썬으로 만들어보자.

실습 환경 : VMware - Windows XP

Python IDLE을 열고, New File로 새 파일을 만들어 다음 코드를 입력하고 저장 후 실행.

f=open('exploit1.m3u','w')

buf="A"*30000

f.write(buf)

f.close()

exploit.m3u라는 파일을 열어(없으면 생성하여) 파일에 A를 50,000개 입력 후 저장하는 코드다.

이제 프로그램을 실행하고 exploit1.m3u 파일을 열어보자.

Drag&Drop으로 열 수도 있고, Load 버튼을 통해 열 수도 있다.

Drag&Drop 시에는 가끔 Load가 아니라 Purchase 버튼이 눌리기도 하니 주의.

exploit1.m3u 파일을 Load하면 아무 응답 없이 파일이 꺼지는 것을 확인할 수 있다!

프로그램에서 crash가 발생한 모습 자세한 정보를 보려면 여기를 클릭하십시오를 클릭했을 때

2번째 캡처에서 Offset: 41414141을 확인할 수 있다.

이는 EIP를 의미하는 것으로, 이 EIP가 41414141(AAAA)로 Overwrite 되었기 때문에 위와 같은 Crash가 발생한 것이다.

WinDbg로 메모리 덤프를 확인하기 위해 WInDbg를 포스트모템 디버거로 설정해보자.

포스트모템 디버거 : 프로세스가 크래시crash 날 때마다 윈도우가 디버거를 이용해 덤프 파일을 생성하게 하는 메커니즘

Reference : http://www.slideshare.net/ohyecloudy/13-2247006

콘솔창을 띄우고 다음 명령어를 입력해보자.

cd C:\Program Files\Debugging Tools for Windows (x86)

windbg -i

windbg 디렉토리로 이동하여 windbg를 포스트모템 디버거로 변경하는 명령어이다.

Crash 발생 시 Windbg가 실행된다.

이제 EIP를 우리가 원하는대로 조종해보자.

그러려먼 정확히 dummy 값이 얼만큼 들어가야 하는 지 정확히 알 필요가 있다.(dummy=쓰레기 값)

그것을 위하여 해당 문서에서는 메타스플로잇Metasploit의 pattern_create.rb 툴을 사용했다.

칼리 리눅스에서 pattern_create.rb를 사용해보자.

필자는 칼리 리눅스 2를 사용했다.

/usr/share/metasploit-framework/tools/exploit/pattern_create.rb 5000

5000 바이트짜리 패턴 문자열을 생성한 것이다.

이제 XP로 돌아가서 파일에 A를 20,000개와 패턴 5000바이트를 입력하고 컨버터 프로그램에서 실행해보자.

사실 파이썬이 아니라, 텍스트 파일에 A 20000개와 패턴 문자열을 입력 후 m3u로 확장자를 변경해도 같은 파일이 생성된다.

파이썬 코드로 입력.

Crash가 발생하지 않은 모습. 프로그램 내에서 오류 처리.

A를 25,000개 입력하고 패턴 문자열을 넣어보자.

Crash 발생! 패턴 문자열 중 일부로 EIP가 Overwrite 되었다.

이제 EIP에 덮어씌워진 문자열을 메타스플로잇에 입력해보자.

./pattern_offset.rb 0x42346a42

그러면 EIP의 위치가 1062라는 것을 알 수 있다.(문서에서는 오프셋이 1072인데, 필자는 1062가 나왔다.)

즉, 우리는 dummy를 26062 bytes 입력하면 다음 4 바이트로 EIP를 마음대로 입력할 수 있다는 것이다.

eip 위치에 ssae를 주었더니 eip가 65617373으로 바뀌었다. ssae를 헥스값으로 바꿨더니 73716165가 나왔다.

즉, eip에 'eass'가 입력된 것이다. 왜 거꾸로 입력 되었을까?

그것은 리틀 엔디안 방식이기 때문이다.

리틀엔디안이 뭐지? <-- 포스팅 예정

그러므로 우리가 'ssae'를 eip에 입력하고 싶으면, 'eass'라고 입력해야함을 알 수 있다.

자, 이제 우리는 eip를 덮어씌웠으니, 또다른 레지스터인 esp를 덮어씌울 차례이다.

esp는 또 뭐여 <-- 포스팅 예정

프로그램의 흐름과 레지스터 <-- 포스팅 예정

eip가 덮어씌워지는 자리 뒤가 바로 esp의 위치임을 우리는 알고 있다.

eip 뒤에 문자열을 추가로 입력해보자.

d esp를 입력하면 esp가 가리키는 메모리 영역을 볼 수 있다.

우리는 esp를 0123456789로 입력하려는 생각이었으나, 실제로 보니 0123을 지나 4를 esp가 가리키고 있다.

이유는 무엇일까? 

그리하여, 우리는 eip와 esp 사이에 4바이트의 더미를 둬야한다는 것을 알 수 있다.

문서에서 덮어씌워지는 원리에 대해 설명해놓은 것을, 필자는 다른 글에서 쓰도록 하겠다. (링크 걸어놓음)

원리를 이해하면서 넘어가보자.

eip는 프로그램 실행 흐름을 변경하기 위해 덮어씌웠다. 그런데 esp는 왜 덮어씌웠느냐?

esp에 우리가 원하는 코드를 삽입하고, eip를 통해 실행 흐름을 esp로 돌려서, esp에서 원하는 코드를 실행하기 위함이다.

고로, 우리는 esp에 입력할 페이로드가 필요하다. 이제 다시 메타스플로잇을 사용해보자.

우리는 프로그램의 흐름을 변경하여 계산기를 실행하도록 유도할 것이다.

msfvenom -a x86 --platform Windows -p windows/exec CMD=calc.exe -e x86/shikata_ga_nai -b '\x00' -i 3 -f python

무슨 명령어인지 궁금하다면 다음을 참고하자.

메타스플로잇 명령어 정리 <-- 포스팅 예정

다음과 같이 출력되면, 파이썬 코드로 옮겨서 사용하면 된다.

페이로드는 다음과 같이 얻었으니, 이제 eip에 esp의 주소를 입력하면

우리의 예상대로라면 esp에 입력되어있는 계산기를 실행하는 코드가 실행될 것이다.

우리는 windbg에서 esp의 주소를 확인할 수 있었다.(d esp)

esp의 주소는 0x000ffd38이었다.

페이로드가 사라졌다?(계산기를 실행하는)

위 캡처에서 우리는 eip를 esp의 주소로 잘 바꿨다는 것을 알 수 있다.

파이썬 코드에서는 \xff 형식을 통해 바이너리 형태로 입력하였고, 리틀엔디안에 의해 거꾸로 입력해주었다.

헌데, esp에 입력했던 계산기 실행 페이로드가 사라진 것을 확인할 수 있다. 그래서 계산기가 실행되는 것이 아니라 crash가 여전히 발생한다.

사실은, 사라진 것이 아니라, 입력이 안된 것이다. 입력이 왜 안되었느냐?

esp의 주소 중 \x00이 있었는데, 이 바이트가 NULL을 의미하여, 문자열 입력이 해당 부분에서 종료된 것이다.

테스트용 코드를 이용해 확인해보자.

ABCD 중 A 뒤에 \x00를 주었을 때, A까지만 입력이 되는 것을 확인할 수 있다.

자, 그러면 eip를 esp의 주소로 덮어씌우는 것은 불가능하다. 그럼 어떻게 해야할까?

jmp esp를 통해 eip를 esp의 주소로 덮어쓰는 것이다. jmp가 뭐지? 이 부분에 대해서는 다음 장에서 자세하게 다룬다.

우리가 실패한 방법은 위 그림에서 첫 번째 그림이고, 우리가 새롭게 시도하려는 방법은 두 번째 그림이다.

이를 위해서, 우리는 JMP ESP의 주소를 알아야한다.

그러려면 JMP ESP가 어디있는 지 찾아야한다. 이것은 windbg 또는 findjmp라는 프로그램에서 가능하다.

여기서는 windbg를 통해서 찾아보겠다.

eip를 esp로 덮어쓴 파일을 실행하여 crash가 발생시킨 후 windbg가 실행되었던 지점까지 가보자.

eip는 esp와 같은 곳을 가리키고 있는 상태이어야 한다. 아니면 아래 명령어가 조금 바뀌어야 할 것이다.

그리고 다음과 같이 입력하자.

a

jmp esp

엔터

u esp

a는 어셈블 모드를 시작

jmp esp는 기계어 입력

엔터는 어셈블 모드 종료

u esp는 esp부터 언어셈블(디스어셈블)하는 명령이다.

만약, a를 입력했을 때, 현재 eip가 출력된다. 출력된 주소가 esp와 다르다면, u 다음에 esp가 아니라 해당 주소를 입력해줘야 한다.

위와 같이 jmp esp의 기계어가 ff e4라는 것을 확인할 수 있다.

그렇다면, jmp esp의 바이너리 즉 ff e4를 dll 파일에서 찾아보자.

dll이 뭐지? <-- 포스팅 예정

windbg가 실행되었을 때 나오는 dll 파일들 중

ModLoad: 019c0000 01e8d000   C:\Program Files\Easy RM to MP3 Converter\MSRMCcodec02.dll

라는 줄이 있다. 필자는 MSRMCcodec02.dll이라는 dll 파일에서 ff e4라는 기계어를 찾아볼 것이다.

다른 dll파일에서 찾아도 상관 없을 것이다.

단, 이 때 페이로드를 넣어야한다. 파일의 내용 길이에 따라 주소가 변경되기 때문이다.

s 019c0000 01e8d000 ff e4

windbg 명령어 정리 <-- 포스팅 예정

다음과 같이 ff e4들을 찾아낸 것을 알 수 있다.

(캡처는 문서상에서 나와있는 명령어 s 019c0000 l 01e8d000 ff e4를 그대로 친 것인데, 01e8d000을 넘어간 영역이 검색되어버린다.  가운데 l(L)을 빼준 s 019c0000 01e8d000 ff e4는 해당 범위만 정확히 검색이 된다. l을 빼고 사용하도록 하자.)

좌측에는 ff e4의 주소들이 있는데, esp와 마찬가지로 \x00을 포함하고 있다면 사용이 불가능하다.

필자는 01b7f23a라는 주소를 사용할 것이다.

리틀엔디안으로 하면 \x3a\xf2\xb7\x01이다.

이때, 페이로드 앞에 NOP을 적당히 넣어줘야 한다. POP/PUSH 연산에 의해 페이로드가 덮어씌워지는 것을 방지하기 위해서다.

이 부분에 대해 잘 설명된 글이 있어서 링크를 걸어둔다.

링크 글의 내용에 대해 나중에 개인적으로 포스팅 할 예정이다.

Reference : http://orang.tistory.com/2

ESP와 Payload(Shellcode) <-- 포스팅 예정

성공적으로 계산기가 실행됐다!

여기까지가 1장의 내용이다. NULL BYTE 때문에(ESP의 주소 중 \x00) JMP ESP의 가젯을 찾아 EIP를 해당 가젯의 주소로 변조하고, NOP SLED를 사용하는 등의 고생을 했다.

워게임을 통해 리눅스 BOF를 먼저 공부하고 이 문서를 보는 게 좋을 것 같다는 생각이 든다.

그리고 쉬운 시스템 워게임은 해커스쿨 것이 많이 있고 매우 좋다.

(FTZ->LOB Redhat->이 문서 읽기 순)

아무튼 이 문서에서 얻어야할 것은 '계산기를 띄우는 방법'이 아니라 '계산기가 띄워지는 원리'이므로, 링크되어 있는 포스트들의 내용을 모두 이해하는 것이 좋을 것이다. 구글신님과 함께.(추후 링크&포스팅 예정..)

링크걸 글들을 모두 포스팅하고 2장 쉘코드로 점프를 포스팅하겠다!