2011년 10월 24일 월요일

finally

finally 블록은 try-catch문 수행한 후에 반드시 수행해야 할 코드들을 위한 영역
try 블록에서 예외가 발생하거나 발생하지 않더라도 finally 블록은 항상 수행되기 때문에 반드시 실행해야할 코드들이 오게 되며 주로 사용한 자원을 반환하는데 사용
finally 블록은 catch 블록 뒤에 위치하며, catch 블록이 없을 경우에는 try 블록 뒤에 위치
try 블록이 존재하지 않을 경우에는 catch 블록과 finally 블록 둘 다 선언될 수 없음
예외가 발생할 경우의 finally 블록
try 블록에서 예외가 발생했을 경우에는 try 블록 내의 나머지 코드들은 실행되지 않고 해당 예외에 대한 catch 블록을 실행한 후 finally 블록 내의 코드를 실행. 예외를 처리할 catch 블록이 없을 경우에는 try 블록에서 finally 블록으로 바로 제어가 넘어가며 이 경우 해당예외는 계속해서 유효하며 메소드에 throws문이 존재 않는 다면 프로그램은 비정상적으로 종료
몇 가지의 예외를[System.exit()] 제외하고 try 블록이나 catch 블록에 return 문이 선언되어 있더라도 finally 블록 내의 코드가 먼저 실행된 다음에 return문이 실행
System.exit()try 블록이나 catch 블록에서 호출되면 프로그램은 그 즉시 종료
예외가 발생 하지 않을 경우
try 블록에서 예외가 발생하지 않았을 경우에는 try 블록 내의 코드를 모두 실행할 후 finally 블록을 실행. try 블록 내에 return 문이 선언되어 있지 않을 경우에는 finally 블록 내의 코드를 실행한 후 finally 블록 다음 코드들 실행. return 문이 선어 되어 있을 경우에는 finally 블록 내의 코드를 실행한 후 return 문을 실행하게 되므로 finally 블록 다음의 코드들은 실행되지 않음

p1) 윈리

뭔가 강의가 쓰면서 틀이 잡혀지는 느낌이네요. 글자 포인트도 보는 제가 너무 작아서 좀 키웠씁니다.

사실 전 건 10년간 바이러스에 안걸려 봤어요. 내용인 즉슨,

뭐 와레즈나 야 사이트 들어 갈 때는 vmware나 virtual box등으로 웹서핑을 해서 그런지 걸려도 날려버리고 copy떠논
이미지를 다시 불러오면 되니까요. 딱히 다른 사람의 USB를 받은 적도 없습니다. 그리고 가끔 저도 저의 비번을 까먹지만
비번을 자주 바꾸거든요. 특정한 패턴이라 잊어버리면 나름 추측이 가능합니다. 그리고 카스퍼스키를 썼었습니다.
세계에서 가장 안전한 이름은 안철수가 아니라 가장 안정한 백신인거죠. 안철수 네임벨류가 워낙 높으니까 안랩이 자꾸
안철수 이야기를 하는데... V3 깔아서 정말 피 본적 많습니다. 해외 사이트 돌아다니다가 ㅡㅡ;
그런데 지금은 V3를 씁니다. 왜냐구요? 안철수씨 빠돌이가 되어 버렸어요. 대선 나오면 뽑을 겁니다. ^^
우리나라 소프트웨어기도 하긍. ㅋㅋ.

가상 머신으로 웹서핑을 한다는 것, 그 때 그 때 최고의 안티바이러스 프로그램을 썼었다는 점(노턴 때부터 괜찮은 것을
골라서 쭉 써왔죠)이 사실 바이러스를 걸렸지만 금방 탐지하고 삭제할 수 있는 계기가 되었습니다. 그리고 안티 바이러스
프로그램들은 대부분 시그니처 검색을 하는데 안티 바이러스 프로그램 끼리 서로 탐지하는 사태가 발생할 수도 있습니다.
탐지하려면 시그니처를 저장하고 있을텐데 서로는 다른 회사꺼니까 공유가 안되서 바이러스로 인식하는 거죠.
그런데 가끔 궁합이 맞는 녀석들이 있어요. 알약같은... 일단 궁합이 맞다 싶으면 같이 깔아서 썼습니다.

그리고 인터넷 공유 사이트에 돌아다니는 파일 중에 대부분은 바이러스를 심어놓은 것이 많습니다. 바이러스가 아니더라도
트로이 목마를 심어서 배포를 하죠. 인터넷으로 받는 윈도우7 들도 MBR 영역에 바이러스를 심고 배포를 합니다.
세상에 믿을 놈 정말 없죠? ^^; 한 명이 그러면 다른 착한 공유(?) 정신을 가진 사람들은 그들의 의견과는 다르게 바이러스를
유포하게 되는 겁니다. 그래서 전 정품을 꽤 오래전부터 사서 썼습니다. 뭐, SW 개발자기도 하니까. 내가 돈 안 내는데
누가 내 밥줄을 위해 돈을 내겠어요 ^^ ㅋㅋ

그런데 리눅스는 바이러스가 없냐? 컹 왜 없겠습니까. 커널 소스까지 있는데 만들면 더 심각하게 만들죠. 그런데 왜 리눅스
바이러스 이야기는 못 들어봣을까요? 아닙니다. 있어요. 상용 백신까지 있는 판국에. 그런데 사람들은 별 관심이 없죠.
리눅스 바이러스 만드는 사람도 적고(왜냐면 지식은 리눅스에서 많이 얻었을테니까...) 쓰는 사람도 그리 많지 않아서 입니다.

사족으로 세상이 참 웃긴게 상대적으로 잘난 사람들에게는 시기와 질투가 생기는 법입니다. 이상하죠. 부자들도 똑같은 인간인데 겁나
미워하죠. 윈도도 그래여. 참 우리를 편하게 해 주지만 잘 나가면 짜증 나는 사람도 자연히 생기고 악한 마음으로 괴롭히는 사람들이 많죠. 진짜 주변에 컴 모르는 사람들은 악성코드 때문에 얼마나 고생을 하는지 원... 윈도야 다시 깔면 되지만 보관해둔 자료를 모아 둔 사람은 정말 ㅠㅠ

최고의 보안은 랜선 뽑고 정품만 쓰는 겁니다. 랜선이 뽑여 있는데(무선랜도 off) 어느 누가 네트워크 해킹을 시도 하겠습니까?
정품을 사용하는데 누가 악성코드를 CD안에 박아 놨을까요? 그게 아니라면 조심을 해야 하는데...
.
.
.
사실 전 이렇게 피곤하게 안 살고 있습니다. 주민번호 누출되었다고 뭐라뭐라 하는데. 뭐 나만 유출되는게 아니고 다 같이 유출되는 거니까 굉장히 심각하게 나만 피해를 보는 것은 아닙니다. 싸이렌인가? 요샌 어떤 서비스에 가입하면 아예 그 민번으로는 회원 가입이 안 되도록 하게 한곳도 있던데. 그거야 신용정보평가원인가요? 믓튼 민번 관리 하는데 연결이 된 사이트만 그렇지. 소소한 쇼핑몰 같은 사이트에서는 그런데 가입이 안되서 걍 다른 사람 민번으로도 가입이 됩니다.
설사 민번이 노출되고 이래저래 신상 털린다고 해도 나만 떳떳이 살고, 통장에 돈 관리만 빠짝 신경만 쓰면 제가 피해를 볼건 별로 없거든요. 그리고 자료 같은 경우 주기적으로 백업을 합니다. 지금 하드 3테라 지만 실재적으로 제가 백업을 하는건 10기가도 안됩니다. 저의 추억들이 담긴 사진들이 대부분이죠. 뭐, 업체 소스, 유틸리티, 필수 S/W 등등... 인터넷에서 다 구할 수 있습니다.
구할 수 없으면 저한테 필요없는 것들이구요. 저 역시 데이터 센터를 구축해서 이 자료들 정말 중요하다고 생각한 적도 있고, 영화같은 엔터테인 자료들도 모아봤습니다. 그런데 생각해보니 내가 새로운 것을 안 받아 들이고 저장해논 자료만 여가 시간에 봐도 다 못볼건데... 왜 못볼 자료들을 보관하고 있는지 의아해 지더군요. 뭐 예전처럼 팔아서 돈 되는 것도 아니고. 설사 그걸 돈으로 만든다고 해도 내가 지금 버는 base가 위협을 받지, 더 도움이 될 것 같진 않더라구요.

사람마다 life style 이 있는데, 자료를 비정상적으로 긁어 모으는 것은 좀 아닌 것 같아요. 자기 공부에 필요한 것만~

그리고 시기/질투 이야기 나와서 말인데...
아.. 제가 정말 좋아하는 자수성가 연예인 최진실씨 죽고난 뒤에는 세상 누구든지 잘나서 밉다는 생각은 안하기로 했습니다. 잠시 묵념 ㅠㅠ. 사실 조성민같은 자식은 죽이고 싶었지만. 왜냐면 사고 방식을 알거든요. 뭐 남자야 육봉 휘둘러서 애 만들면 되는거고, 여자는 배 아파서 낳아야 하니까. 당연 자식한테 마음가는거고. 그리고 어릴 때부터 운동하면서 컸으면 세상이 자기 마음대로 되는 듯하게 살았을거고 그래서 최진실 주팬거고 죽고 나서도 재산 탐내다가 막상 너무 많은 사람들이 반대하니까 남은 여생 편할 것 같지 않아서 접은 거죠. 그런데 늙으면 후회가 될거고 자식들은 커면 옛날이 후회가 될건데. 뭐 그것도 다른 사람 만들어 놓고 사랑으로 사람을 잊고 자기 잘났다는 가치관 세우고 자식 거부하면서 살면 됩니다. 그러다가 자식이 아비 보고 싶어서 찾아 가면... 아 역시 내가 아비니까 찾아 오는가보다 하면서 그래도 헛되게 안 살았다고 어줍잖은 철학으로 위로하면 되는거고.

흠냥... 술이 좀 되어서 그런지 감상에 빠졌군요 ^^;; 조씨가 조서 쓸 때도 술 먹었다고 햇을까요? 물론, 주변에 법을 잘 아는 사람도 잇었을 테니까 대충은 짐작이 됩니다만. 뭐, 믓튼 그런 부류(저도 포함)는 그런 부류대로 놔두고 한걸음 더 나아가 봅시다~

아 그리고 리버싱 이야기도 잠깐 하겠는데요. 리눅스 플랫폼은 소스가 대부분 있다고 말씀드렸어요. 그럼 리버싱이 필요 할까요? 최고의 리버싱 작품은 삼바 입니다. 지금은 구글로 가셨나요? 삼바는 윈도우의 netbios, netbeui와 완전히 다른 메커니즘으로 동작합니다. 사실 윈도우 소스를 볼 수 도 없으니까 그걸 알수도 없죠. 그런데 어떻게 윈도우 에서 리눅스 공유 폴더로 접속이 되는거냐?

http://samba.org/ftp/tridge/misc/french_cafe.txt

문서를 보면... 삼바는 프로토콜 역공학으로 만들어 졌다는 것을 알 수 있습니다.

12년 이상이나 해서리...

간단히 설명하자면 여러분이 말을 모르는 오지로 가서 그 쪽 말(프로토콜)을 아는 것이 목적이라면.
우선 가만히 듣고 있으면서 그들의 말의 어떤 패턴을 찾는 것이 방법일수도 있습니다. 아니면 말도 안되는
말들을 해서 그들의 반응을 살펴보고 그들을 말을 배울수도 있죠. 실재 프로토콜은 대상이 되는 서버랑 반응을
살피는 것이니 정형화된 패킷을 하나 캡춰해서 그 패킷을 내용을 조금씩 바꾸어서 계속해서 날려보고 서버의
반응을 보는 것입니다. 그리고 가상 서버를 만들어서 실재 서버의 반응과 가상 서버의 반응의 차이를 보고 또
그 프로토콜을 알수도 있는거죠.

아 정말 노가다 인가요? ^^;; 그런데 역공학은 대부분 노가다가 많습니다.

노가다하면서 정이 좀 가는게... 노가다를 하면 반복학습이 되기 때문에 학습효율이 높습니다. 그리고 비슷한
것들을 계속해서 따라가기 때문에 연관성이 있어서 자동으로 마인드맵 학습이 가능한거죠. 대부분 잘 안되는
경우지만 해결되었을 때 그 충격은! 그래서 충격 학습법도 같이 작동합니다.
그래서 재미가 좀 있어요. 그렇게 쌓여진 실력은 안 사라지니까.

흠냥 잡소리가 많았네요.

잠깐 리버싱 이야기를 대충 해 보면, (강좌 인기 떨어질까봐)

우선 툴을 준비 합니다. 올리디버거 버전별로, 구할 수 있는데로 다. 패킹된거 DRX버전(이건 어떤 사용자가 커스터 마이징 한거죠)
최신버전 등등... 그리고 IDA와 헥사 워크샵을 구합니다. 그리고 분석하는 거여여.

리버싱 1단계는 걍 점프하는 곳만 바꿔주는 겁니다. 첨부 그림처럼 IDA로 보면 그래프가 나오는데 점프 구문만 바꿔주면 되죠?
1단계에서 조금 나아가면 팝업이나 특정 문구가 없는 파일을 디버깅 하는 것입니다.
리버싱 2단계는 프로그램을 분석하는 것입니다. 구조를 보고 암호키의 생성 방식을 알아 내는 것이 있겠네요.
리버싱 3단계는 언패킹 입니다. 실행 압축이 걸린 파일의 OEP를 찾는거라고 할 수 있겠네요. PE포멧 스터디도 여기서 종결 짓는거죠.
리버싱 4단계는 1~3과 같으나 칩에서 내용을 뽑는 겁니다. 하드웨어에 걍 JTAG를 꼽는 것도 방법이고,
하드웨어 구조를 보고 메모리를 찾아서 그 메모리에 올라가는 내용들을 리버싱하는거죠.

흠.. 강좌 하나가 좀 길어졌는데 한가지 책에서 본 에피소드를 말씀드리면... 책 제목이 생각은 안나는데.

지금처럼 칩이 BGA타입(핀이 안으로 다 들어가있는)이 아닐 때에는 칩을 기계에서 분리할수가 있었습니다.
카`지노 기계를 하나 사서 거기들어 있는 칩을 뺀 다음 안에 들어있는 기계어를 분석해서 랜덤함수 알고리즘을
분석했데요. 그 랜덤 함수의 약점이 특정 시간에는 꼭 특정 숫자가 나오는 거였는데 그 시간을 시계를 들고가
계속해서 맞춰서 카`지노 가서 계속해서 대박을 터뜨렸다능... 뭐 일단 특정 패턴이 나올 때까지 돌리다가
특정 패턴(OEP엔트리 포인트기도 하죠)이 나오면 거기서 부터 타이머를 돌려서 특정 타임틱마다 기계의
stop을 누르는거죠. 흠.. 쓰고보니 좀 어렵게 쓴 감이 있네요. 믓튼, 해킹 관련 에피소드 서적도 좀 보시구요.
나름 잼나요. 기술적인 내용도 들어감... 아는 만큼 보이죠. 모.

아 너무 늦었네. 전 이만 총총.
[Reference] : 쿨러, 「리눅스 개발 - 윈리 야그 8 - 10년간 바이러스 걸리지 않은 이야기.」 http://coolsoft2.com/?mid=linux_dev&document_srl=895628.

조성민 - 최진실 폭행파문낙서장
2005/07/11 14:56
최진실,일방적 구타..
“이혼은 좀 더 생각해 보겠다.”탤런트 최진실이 2일 오후 2시 서울 강남구 신사동 안정형외과에서 기자회견을 열고 남편 조성민..
조성민,이혼하면 끝..
“이혼만 해달라.”2일 오후 최진실의 공식 기자회견 내용을 전해들은 조성민은 의외로 담담해 했다. 조성민은 최진실이 기자회견..
최진실 병상 인터뷰
2일 오전까지 말을 할 수도 없을 정도로 정신적 충격을 받았다는 최진실이 병실에서 기자들을 만났다.. 연합뉴스
최진영,먼저 맞고 멱살잡아
“누가 저들을 보고 부부라고 할 수 있겠냐.”최진실의 동생 최진영은 최진실의 기자회견에 이어... 스포츠투데이
최진실 "1시간동안 공포에 떨어야 했다"
2일 오전 2시 서울 강남의 모 정형외과에 입원치료 중인 최진실이 기자들과 만나 당시 사건에 대한 정황과 심경 등을 털어놨다. 최진실은.. 뉴시스
[사진] 정형외과에 입원중인 최진영
뉴시스
최진실 잠원동 자택 부서진 가구로 '아수라장'
거실에는 평화가, 그러나…. 최진실의 90평짜리 서울 잠원동 빌라는 사건 발생 하루가 지났지만 당시의.. 스포츠조선
이혼결심? 최진실 불가입장 철회
이혼만 해달라’(조성민) vs ‘좀더 생각해보겠다’(최진실).탤런트 최진실이 2일 기자회견을 열고 남편.. 스포츠투데이
최진실측 반응
"만취 조성민 일방적 폭행" 1
최진실 인터뷰 "조성민에 생명 위협까지 느껴" 1
'모든 상황이 너무 기가 막힐 뿐' 1
"너무 맞아서 정신 잃었다" 1
최진실"쌍방폭행? 애들한테 물어보라" 1
조성민측 반응
"서로다퉈…나도 피해자" 1
조성민, 입원실 문 잠근 채 두문불출 1
"그쪽에서 고소하면 맞대응" 1
조성민,이혼하면 끝날일 1
주변반응
네티즌 "이제 그만 좀 했으면.." 1
일본신문 대대적 보도 '세계적 망신' 1
'조-최 부부사건'팬시선 따갑다 1
최진실-조성민 파경까지
신고에서 연행까지 1
최진실 "조성민에 접근금지가처분 신청할 것" 연합뉴스 8.2(월)
최진실, "이혼하겠다" 심경변화..."양육권은 포기 못해" 스포츠조선 8.2(월)
최진실 곧 기자회견…‘폭탄선언’ 관심 스포츠투데이 8.2(월)
[최진실-조성민 폭행파문] 조성민 ‘서로다퉈…나도 피해자’ 스포츠투데이 8.2(월)
최진실-조성민, 새벽 '폭행' 사건 진실게임 굿데이 8.2(월)
[최진실-조성민 폭행파문] 최진영 척추·목뼈 통증 X-레이 촬영 스포츠투데이 8.2(월)
최진실, "감금폭행"-조성민, "쌍방폭행"...양측 주장 맞서 스포츠조선 8.2(월)

2011년 10월 22일 토요일

P1) 윈도우즈 파기 위하여

5부터는 리눅스와 윈도우즈 이야기로 갑니다.

그림도 없고 딱딱한 글들이라 쉽게 읽혀 지지 않는데다가 사실 내용에 공감하시는 분들은 저처럼 좀 geek 한 분들 말고는
없을 것도 같아서요. 엄청 기초적인 것들을 말하다가도 전체적으로 보기도 하고. 사실 완전 초보는 책을 봐야 하기 때문에.....
왜냐면 영어 단어 하나도 모르는데 문법을 설명할 수는 없잖아요 ^^;;

사실 강좌를 쓰는 건 큰 의미가 없습니다. 돈이 없는 것도 아니고 프로젝트 하면서 꽤 돈이 들어오니까 책을 내는 것이 아니라면
네임벨류나 자신한테 크게 도움이 되는 것도 없습니다. 그리고 큰 회사에 있는 곳에 정리하는 편이 저의 딕셔너리를 만드는 데에도
더 도움이 되요. 뭐 쓴 글은 제 블로그에 저장하고는 있지만 사실 포스팅하는 것보다는 혼자서 집에 쌓여진 책이라도 좀 읽는게
도움이 됩니다. 그런데 왜 쓰느냐? 간만에 휴일인데 마눌님은 주무시고 혼자 영화 하나 다보고 철권5 캐릭터 2개 엔딩보고 심지어
나중에 애 키울거 대비해서 삼각함수 EBS 동영상까지 보고, 사업하신다는 분 홈피도 뚝딱 만들고(요샌 정말 편하더군요) 그래도
시간이 남는데다가 잠까지 안오는 겁니다!! 된장, 된장, 된장 ㅠㅠ 여기 좋고 운영자님이 맘에 들어서 뭔가 써주어야 겟다고 생각해서
광고 하나 클릭 하고 (광고 클릭하는데 안 힘듭니다. 들어오셔서 컨트롤 누르고 살짝 눌러주시면 눌린 표시도 안나여) 글도 하나
써 봅니다.

하지만 혹시나 저랑 비슷한 생각을 가지신 분이나 공부 하시는데 갈팡질팡 하시는 분들을 위해서 강좌를 시작한거고.
생각해보니 다른 게시판은 저랑 성격이 안 맞을수도 있고, 다른 분들이 잘 정리하는 강좌에 누가 될지도 모른다고 해서. 이쪽에
적으려고 합니다. 그런데 리눅스는 이용만 당하지 실재로 큰 인기는 없습니다. 저희가 안드로이드 폰을 쓰고 접속하는 서버 대부분
이 리눅스기는 해도 크게 보기 보다는 협소하게 보는게 정신 건강에도 좋고 행복한거죠.

다만 리눅스에서 시작하는 이유는 참 지식은 공유와 나눔에 있는건데 리눅스는 그런 정신을 잘 계승하기 때문입니다. 그런데
늘 밥만 먹고 살 수는 없듯이 라면도 먹어줘야 하는데 전 그게 윈도우라고 생각해요. 물론, 지식의 입장에서.

하나는 완전 공개, 하나는 돈 못벌게 하는 부분은 비공개된 운영체제 사이에서 리버스 엔지니어링은 발전 합니다.
그래도 밑에 금광이 있다고 분명히 알고 파는 거랑 모르는데 파는 거랑은 천지 차이거든요.

오늘은 프로세스에 대해서 이야기 해 보려고 합니다.

사실 디스크 구조도 들어가면 좋겠지만 디스크 구조에 대해서 공부하면 공부할수록 머리가 잘 안 돌아가고 파일 시스템 올려진
상태에서는 뭐 딱히 할것도 없는게 지론입니다. 가끔 목만 축이는 정도로...

프로세스라 함은 프로그램이 메모리에 올려진 상태를 말합니다. 리눅스의 경우에는 ELF가 통산 쓰이는 거고 윈도우의 경우에는
PE 포멧이라는게 있죠. 둘 다 COFF에서 나온거라서 비슷합니다. 사실 더 좋은 파일 포멧이 여러 학회나 학교에서 연구될 수도 있겠지만
겁나 좋으면 뭐하나요. 컨셉카처럼 걍 스쳐지나가면서 한번 볼까 말까 하는거죠. 많이 쓰는게 대세인거죠.
그리고 win7까지도 PE로 나갔으니 win8에서 바뀔리도 없고, 충분히 검증된거라. 향 후 7년 이상 잘 쓰여질 거라고 봅니다.
사실 몇십년 동안 별 탐구할 생각도 없었다가 향 후 비전을 보니 PE를 파야 겠더라구요 ^^;;

ELF의 경우에는 동작중에도 프로그램을 끼울 수가 있는 구조 입니다. 절대번지가 없는거죠. 그런데 리눅스만 그런데 아닙니다.
PE 포멧도 그래요. 정확한 주소는 윈도우즈 로더가 적어주고 메모리에 올려줍니다.

파일(PE, ELF) -> 로더(리눅스 커널, 윈도우 로더) -> 메모리

요렇게 올려주는 거죠.

리버싱 때 사용되는 IDA PRO 같은 경우에는 윈도우 기준으로 실행되지 않은 PE 파일을 분석한다고 보시면 되구요.
우리의 영웅 올리디버거 같은 경우에는 퍄일을 불러서 실행도 되고 실행중인 프로세스에 어태치도 되는 것 입니다.

그럼 메모리에 파일이 올라간다면 다시 파일로 만드는 것도 가능하겠네요? 당근 입니다.

울산 모 대학에서 프로그램을 만들었었는데(저 말고 누군가) 메모리에 올라간 것을 다시 PE 파일로 만들어 주는 유틸리티 였습니다.
물론, 엄청 복잡한거는 안되는데요. 파일을 복사하는게 아니라 진짜 메모리에서 가져와서 파일을 만들더라구요.
어차피 파일이 있어야 메모리에 올리니까 별 쓸모 있다고는 생각 안했지만 정말 신기했습죵. 논문이나 대회나 그런데 사골 우거지
곰탕처럼 우려 먹을 수 있다고나 할까요?

ㅋㅋ

아 마눌님께서 기지개를 펴시네요. 담달 결혼식인데 ^^ 청첩장이 남아 돌아요 슬퍼...

이만 쓸께여.

그리고 제 철학을 말하자면 코드만 하면서 칙칙하게 사는건 싫어요. 다만 이 세상도 하나의 큰 게임, 아니면 큰 코드와도 같아서
참 알수가 없는데 리버싱이라는 것은 세상을 역분석하는 학문이라고도 생각이 듭니다.

물론 방식은 다르지만요.

그럼, 즐거우 주말 되세요~

2011년 10월 21일 금요일

p1) api hooking 관련

출처 : http://lain32.egloos.com/4805054

상용 DRM솔루션에 대한 이해 1부 - 화면캡쳐방지는 어떻게 구현될까? 리버스 엔지니어링 by lain32 2010/07/31 13:05 lain32.egloos.com/4805054 덧글수 : 9


거의 1년동안 포스팅이 뜸하다가 요즘들어 다시 포스팅을 시작하고 있습니다.

예전엔 너무 무거운 주제로 얘기를 하다보니 글이 별로 안 올라왔던 것 같아서 요즘에는 가벼운 주제인 델파이같은

어플리케이션 개발과 관련 된 사소한 부분들에 대해서도 올리고 있습니다. ( 델파이가 사소하다는게 아닙니다. -_- )



그러다가 제 블로그에 찾아오시는 분들이 거의 시스템쪽을 좋아하시는 분들이 많으시다보니 요즘 올리는 주제가 좀

제 블로그 형태에 벗어나는 것 같아서 다시 한 번 좀 더 무거운 주제로 깊이 있는 글을 써볼까 합니다.-_-



우선 시작부터는 좀 그러니 가벼운 주제로 화면캡쳐방지에 대해서 알아보도록 하겠습니다.

시작합니다.~





몇 년전부터 화면캡쳐방지를 해주는 솔루션들이 등장하기 시작했습니다.

어떻게보면 좀 오래된 분야지만 아직까지도 완벽하게 화면캡쳐방지를 막는 것은 사실상 불가능합니다.

그래도 어차피 100% 다 막을 수가 없기 때문에 적어도 99%정도는 막는다라는 취지에서 이러한 솔루션들이 등장하고 있습니다.



화면캡쳐방지에 대해 거론하기 전에 우선 화면캡쳐를 어떻게 하는지 당연히 알고 있어야 합니다.

방어를 할려면 공격방법을 먼저 알아야 되죠. 그래서 해킹보다 보안이라는것이 더 어려운 경우가 많습니다.



화면캡쳐에 기본적인 주요 API는 3가지로 구현됩니다.

GetDC, BitBlt, ReleaseDC



화면캡쳐 프로그램들은 보통 이 3가지 API를 이용하여 화면캡쳐를 합니다.

다음은 오픈캡쳐에서 사용하는 전체화면 캡쳐 방식입니다.



procedure TCaptureEngine.ScreenCapture;

const

// ** 윈도우 2000 이상에서 반투명화 된 윈도우를 캡쳐 할 수 있는 비트 플래그 ** //

// ** BitBlt 함수에서 OR 연산자를 통해서 사용한다 ** //

CAPTUREBLT = $40000000;

var

CursorInfo: TCursorInfo;

piconinfo: TIconInfo;

DC: HDC;

scrRect: TRect;

CAPTUREBIT: Integer;

begin

DC := GetDC(0);



scrRect := Screen.DesktopRect;

FBackBuffer.SetSize(scrRect.Right - scrRect.Left, scrRect.Bottom - scrRect.Top);



CAPTUREBIT := 0;



if FTransparentCapture = True then

CAPTUREBIT := CAPTUREBLT;



with FBackBuffer do

BitBlt(FBackBuffer.Canvas.Handle, 0, 0, FBackBuffer.Width,

FBackBuffer.Height, DC, scrRect.Left, scrRect.Top,

SRCCOPY or CAPTUREBIT);



if FCaptureCursor = True then

begin

CursorInfo := CaptureCursor;

GetIconInfo(CursorInfo.hCursor, piconinfo);



CursorInfo.ptScreenPos := DesktopCoordinateToOriginCoordinate(CursorInfo.ptScreenPos);



DrawIcon(FBackBuffer.Canvas.Handle,

CursorInfo.ptScreenPos.X - piconinfo.xHotspot,

CursorInfo.ptScreenPos.Y - piconinfo.yHotspot, CursorInfo.hCursor);

end;



FCaptureRect := Rect(0, 0, FBackBuffer.Width, FBackBuffer.Height);



ReleaseDC(0, DC);

end;



GetDC(0);을 호출하게 되면 전체화면에 대한 디바이스 컨텍스트 핸들을 흭득하게 됩니다. ( 듀얼모니터 포함 )

그리고 BitBlt을 통해서 실제 화면DC에 있는 데이터를 비트맵인 FBackBuffer에 DC로 옮깁니다.

그리고 마지막으로 ReleaseDC(0, DC);를 호출하여 할당한 디바이스 컨텍스트 자원을 해제하게 됩니다.



위에서 보앗듯이 화면캡쳐는 이게 전부입니다. 추가적으로 구현되는 부분도 있겠지만 기본 베이스는 이게 끝입니다.

화면캡쳐하는 방법에 대해서 알았으니 이제 화면캡쳐방지는 어떻게 구현해야 할지 생각해볼 차례입니다.



우선적으로 떠오로는 것은 API Hooking이 필요하다라는것을 느낄것입니다.

그리고 화면캡쳐방지에 대한 3가지 주요함수에 대해서 후킹에 필요성이 느껴질것입니다.



그렇다면 어떠한 API를 후킹해야 할지 결정할 차례입니다.

일단 ReleaseDC는 제외됩니다. 단순히 자원을 해제하게 되기 때문입니다.



두 번째로 GetDC와 BitBlt이 있는데 이 함수를 다 후킹해야할지 하나만 후킹해야할지를 결정해야 합니다.

보통 화면캡쳐방지를 만들려고 하면 실수하는 부분이 GetDC를 고려한다는 점인데 실제로 GetDC는 고려할 필요조차

없습니다. 만약에 GetDC를 후킹한다면 결과적으로 그 DC를 얻을 때 마다 DC를 관리하는 리스트에 다 추가를 해줘야

되겠고 BitBlt이 호출되면 이 때 리스트에 대한 정보를 검색하여 이전에 GetDC를 이용하여 화면캡쳐를 시도하려는 DC였다면

BitBlt을 실패시키겠죠. 그리고 ReleaseDC도 덩달아 후킹을 해야 합니다. 왜냐하면 자원이 해제되는 것을 체크하여 DC를

관리하는 리스트에서 제거를 해주어야 하기 때문입니다.



우선 왜 실수로 GetDC를 고려할려고 하였는지 생각해봐야 합니다.

GetDC를 고려하는 이유는 BitBlt 함수가 호출 될 때 이게 화면캡쳐를 하기 위해 BitBlt를 하였는지 아니면 그냥 단순히

비트맵 복사를 할려고 하였는지 알수가 없기 때문입니다.



그렇다면 오로지 BitBlt만 후킹해서 함수를 호출한 프로그램이 화면을 캡쳐하려는것인지 비트맵을 복사하려고 하는것인지

알아낼 수 있는 방법이 있는지를 찾아내야 합니다.

그리고 실제로 상용 화면캡쳐 방지 솔루션에 경우에는 오로지 BitBlt 후킹만으로 화면캡쳐방지를 구현합니다.



이것을 체크하기 위해 윈도우즈 API인 GetObjectType 함수를 이용할수 있습니다.

이 함수는 인자로 받는 매개변수가 GDIObject로써 DC도 GDIObject에 포함되기 때문에

당연히 매개변수로 받을 수 있습니다. 그리고 이 함수가 리턴값들 중에 가장 중요한 리턴값은

OBJ_DC로 MSDN에 보면 이것은 Device context 를 의미합니다.



즉, BitBlt를 후킹한 루틴에서는 넘어온 srcDC ( SourceDC ) 에 대해 GetObjectType으로 해당 DC에 타입을

조사하여 OBJ_DC일 경우 원본 API를 호출하지 않으면 됩니다.



다음과 같이 소스로 구현될것입니다.



BOOL WINAPI MyBitBlt(

HDC hdcDest, // handle to destination DC

int nXDest, // x-coord of destination upper-left corner

int nYDest, // y-coord of destination upper-left corner

int nWidth, // width of destination rectangle

int nHeight, // height of destination rectangle

HDC hdcSrc, // handle to source DC

int nXSrc, // x-coordinate of source upper-left corner

int nYSrc, // y-coordinate of source upper-left corner

DWORD dwRop // raster operation code

)

{

if (GetObjectType(hdcSrc) == OBJ_DC)

{

return TRUE;

}

BOOL Result = 0;



RestoreAPI(g_hInst, "gdi32.dll", "BitBlt", OldBitBltCode);



// ** 그리고 원래의 API 함수를 호출 ** //

//if (hWnd == 0)

Result = BitBlt(hdcDest, nXDest, nYDest, nWidth, nHeight, hdcSrc, nXSrc, nYSrc, dwRop);



// ** 다시 코드를 변경한다. ** //

InterceptAPI(g_hInst, "gdi32.dll", "BitBlt", (DWORD)MyBitBlt, OldBitBltCode);



return Result;

}



위에서 RestoreAPI는 후킹된 함수를 원래대로 되돌려주며 InterceptAPI는 다시 후킹을 하는 함수입니다.

그리고 이러한 방식은 멀티 스레드에 매우 위험한 방법으로 실제 상용DRM에서는 이렇게 허접하게 만들면 안됩니다.-_-

지금은 단순히 예제를 보여주기 위해 이렇게 코드가 작성되었다라고 이해해주시면 감사하겠습니다.

( Detour 라이브러리를 쓰는것이 좋습니다. 그러나 API Hooking하는것 자체도 설명을 같이 할것이기 때문에 나중에

이 부분은 다시 설명하겠습니다. )



후킹을 하고 해제하는 함수는 다음과 같이 구현되어 있습니다.



BOOL InterceptAPI(HMODULE hLocalModule, const char* c_szDllName, const char* c_szApiName, DWORD dwReplaced, char *OldCode)

{

DWORD dwOldProtect;

// 해당 함수의 시작 주소를 얻는다. ** //

DWORD dwAddressToIntercept = (DWORD)GetProcAddress(

GetModuleHandle((char*)c_szDllName), (char*)c_szApiName);



if (dwAddressToIntercept == 0)

{

// OutputDebugString("에러");

return FALSE;

}



BYTE *pbTargetCode = (BYTE *) dwAddressToIntercept;



BYTE *pbReplaced = (BYTE *) dwReplaced;



// ** 메모리의 권한을 변경 ** //

VirtualProtect((void *) dwAddressToIntercept, 5, PAGE_WRITECOPY, &dwOldProtect);



// ** 원래의 코드를 백업한다. ** //

memcpy(OldCode, pbTargetCode, 5);



// ** 점프 코드를 삽입한다. ** //

*pbTargetCode++ = 0xE9; // jump rel32



// ** 주소는 내가 설정한 함수 주소 ** //

*((unsigned int *)(pbTargetCode)) = pbReplaced - (pbTargetCode +4);

VirtualProtect((void *) dwAddressToIntercept, 5, PAGE_EXECUTE, &dwOldProtect);

FlushInstructionCache(GetCurrentProcess(), NULL, NULL);



OutputDebugString("InterceptAPI 완료");



return TRUE;

}



BOOL RestoreAPI(HMODULE hLocalModule, const char* c_szDllName, const char* c_szApiName, char *OldCode)

{

DWORD dwOldProtect;

DWORD dwAddressToIntercept = (DWORD)GetProcAddress(

GetModuleHandle((char*)c_szDllName), (char*)c_szApiName);



if (dwAddressToIntercept == 0)

{

return FALSE;

}



BYTE *pbTargetCode = (BYTE *) dwAddressToIntercept;



VirtualProtect((void *) dwAddressToIntercept, 5, PAGE_WRITECOPY, &dwOldProtect);



// ** 원래의 코드를 복구한다. ** //

memcpy(pbTargetCode, OldCode, 5);



VirtualProtect((void *) dwAddressToIntercept, 5, PAGE_EXECUTE, &dwOldProtect);

FlushInstructionCache(GetCurrentProcess(), NULL, NULL);



OutputDebugString("RestoreAPI 완료");;

return TRUE;

}



그리고 후킹용 DLL이 로드 될 때

InterceptAPI(g_hInst, "gdi32.dll", "BitBlt",(DWORD)MyBitBlt, OldBitBltCode);

해제 될 때,

RestoreAPI(g_hInst, "gdi32.dll", "BitBlt", OldBitBltCode);

를 해주어야 합니다.



위와 같은 예제를 통해서 DLL을 만들어 인젝션을 시킨 후에 오픈캡쳐로 화면캡쳐를 시도하려고 하면

그냥 흰색으로 나오거나 검은색나올것입니다. BitBlt 함수자체가 동작하지 않기 때문에 아예 복사자체가 안되기 때문입니다.



이정도면 제가 보기엔 안정성을 제외하고서는 기능적으로 보았을때에는 거의 상용과 동일한 수준이라고 생각됩니다.

그러나 추가적으로 하나의 API를 더 후킹해야 할 필요가 있습니다.

일부 상용 DRM 솔루션은 바보같게도 WIndows XP에서 추가 된 새로운 API인 PrintWindow를 후킹하지 않는 바람에

이 함수를 써서 우회가 가능하더군요.



PrintWindow 함수는 화면상에 보이지 않고 가려져 있는 윈도우에 대해서도 화면을 캡쳐할 수 있는 매우 막강한 함수입니다.

그냥 후킹해서 return TRUE; 해버리면 이것도 당연히 막히겠죠.



추가적으로 상용 화면캡쳐방지 솔루션은 단순히 화면캡쳐만 막는게 아니라 화면캡쳐에 대한 영역을 보안하는 기능이 있습니다.

즉, 전체화면에 대한 캡쳐가 안되는것이 아니라 보호하고 있는 대상이 웹브라우저라면 그 웹브라우저에 대한 부분만 캡쳐가

안되도록 막는 기능입니다. 이거는 후킹하는 루틴에서 원본 함수를 호출 후 좌표계산을 통해 웹브라우저가 속한 영역에 대

해 화면캡쳐를 하지 말라는 경고그림이라던지(-_-) 그런거를 그려넣으면 되겠죠.



이전에도 말씀드렷다시피 지금 알려드린 예제는 안정성이 떨어지기 때문에 마이크로소프트사에서 만든

API Hooking용 라이브러리를 쓰는 것이 좋습니다.

http://research.microsoft.com/en-us/projects/detours/

만약에 델파이를 사용하신다면 매드훅 라이브러리를 쓰면 됩니다.

http://help.madshi.net/ApiCodeHooking.htm



Detour 라이브러리에 경우에는 인터넷에 관련 글들이 많이 있고 매드훅 라이브러리는 상용 라이브러리이기 때문에

제가 사용을 해보질 않아서 이 두 라이브러리에 대한 내용은 생략하겠습니다.



그렇다면 이걸로 끝일까요?

그렇지 않습니다. 단순히 API를 후킹했다고 해서 끝나지 않습니다.

화면캡쳐를 하는 방식은 무궁무진하기 때문에 저 두 API만 후킹한다고 해서 끝나지 않습니다.

다이렉트X를 이용한 화면캡쳐라던지 윈도우즈 미디어 API를 이용한 화면캡쳐등 여러가지가 있습니다.

이 모든 것을 막을 수 없기 때문에 추가적으로 요구되는 사항이 바로 블랙리스트 개념입니다.



블랙리스트 방식은 화면캡쳐와 관련 된 프로그램에 대한 식별할 수 있는 시그내쳐를 모두 모아서

이 시그내쳐와 맞는 프로세스가 발견되면 즉시 강제 종료시키는 방식입니다.



이러한 시그내쳐중에 단순히 윈도우에 타이틀바 캡션정보를 이용하여 식별하는 방법이 있는데 허접하게 보일지 몰라도

의외로 강력하며 최후에 수단이라고 보여집니다.-_-

왜냐하면 일반 사용자는 직접 소스코딩을 할 수가 없기 때문에 프로그래머가 아닌 일반 사용자에 대해서는 좋은 방어

수단이 될수가 있기 때문입니다. 물론 완벽하지는 않겠지만요.



여기까지 화면캡쳐방지에 대한 글은 마치겠습니다.

지금까지 설명한 내용은 실제로 상용으로 판매되고 있는 화면캡쳐방지 기법에 대한 기본 베이스입니다.

더 이상 설명하다가는 보안종사하시는 분들이 화를 내기 때문에 이쯤에서 글을 줄입니다.



태그 : 화면캡쳐방지, 리버스엔지니어링, DRM포스트 메타 정보

퍼블리싱 및 추천내보내기

밸리 : IT 2010/07/31 13:05

태그 : 화면캡쳐방지, 리버스엔지니어링, DRM

2011년 10월 19일 수요일

p1) IAT 테이블 2

now, let's start this over but look in it more in detail. 일단 시작하고 더 자세히 들여다 보자.
 First of all : when an executable is first loaded, 우선 실행가능한 (파일)이 처음으로 로드 될 때
the Windows loader is responsible for reading in the files PE structure 윈도우 로더는 PE파일 구조를 읽고 and loading the executable image into memory. 실행가능한 이미지를 메모리로 로드해야 한다. One of the other steps it takes is to load all of the dlls 그리고 다음으로 다른 모든 dll들을 로드하는데 that the application uses 어플리케이션에서 쓰는 것들이다.
and map them into the process address space. 프로세스 주소 공간에 있는 맵 또한 로드한다.
The executable also 실행가능한 것(파일)은 또한
lists all of the functions 모든 함수들을 보여준다.
it will require from each dll. 그것들은 다른 dll에서 요구될 것이다.
Because the function addresses are not static, 왜냐면 함수 주소는 고정된게 아니기 때문이다.
a mechanism was developed that 메카니즘은 다음과 같이 개발되어졌다.
allows for these variables to be changed without needing to alter all of the compiled code at runtime. 실행시간에 컴파일된 코드들이 고쳐지지 않고 이 변수들이 바뀌는게 가능하도록
This was accomplished through the use of an import address table (IAT). 이것은 IAT를 통해서 완성되었다. This is a table of function pointers filled in by the windows loader  이것은 윈도우 로더에 의해 채워진 펑션 포인터들의 테이블이다.
as the dlls are loaded.  dll이 로드될 때 When the application was first compiled, 어플이 처음 컴파일 될 때 it was designed 그것은 디자인 된다.
so that none of the API calls use direct hardcoded addresses 그래서 어떤 코드도 주소가 바로 고정되어 사용되지 않는다.
but rather work through a function pointer. 그래서 함수 포인터를 이용한다.Conventially this pointer table can be accessed in several ways. 몇가지 방법으로 이 포인터 테이블은 액세스 될 수 있다.
Either directly by a call[pointer address] or via a jmp thunk table. By using the pointer table, the loader does not 직접 호출이나 점프 테이블을 통해서. 포인터 테이블을 이용할 때 윈도우즈 로더는 need to fixup all of the places in the code that want to use the api call, all it has to do is add the pointer to a 코드 위치를 모두 고쳐 API호출을 할 필요가 있다.  single place in a table and its work is done. 모든 추가된 포인트는 테이블의 한곳을 나타내고 제대로 동작한다.

p1) PE의 IAT 테이블

There are different Microsoft Windows operating systems, 윈도우즈 운영체제는 여러 종류가 있습니다.


(XP, win7..., server, ....)

and they all have different addresses for their API functions, 그리고 구조가 달라서 API 함수들의 주소도 다릅니다.

because of different structured DLL's. When an application starts, 어플이 시작될 때

it has a list of all functions that aren't originally a part of the application. 어플의 가상 주소의 리스트를 가지고

있습니다. These functions, called imports, 이 함수들은 imports 라고 불리고

are located in the operating systems DLL's 운영체제의 시스템 DLL에 위치합니다.

but the application doesn't know where. 그런데 어플은 그게 어딨는지 모르죠.

Every win32 executable application has an Import Address Table (IAT) 모든 윈32 실행가능한 어플은 IAT라는 놈을

residing inside the program. 가지고 있습니다.

The IAT is used as a lookup table API function. IAT는 API 함수를 찾는데 쓰이죠.

So before starting, the windows loader has to find each address of each API that the program wants to call and


"constructs" an IAT with them. 그래서 시작될 때 윈도우 로더는 각각 다른 API에서 주소를 찾습니다. 프로그램은 그 주소로

When the program is running and it wants to call an API, 호출하고 고걸로 IAT 테이블을 구성하는거죠.

it simply looks in the IAT and thus finds immediately the address IAT 테이블 보고 주소를 찾는건 쉽습니다.

it needs to go in the DLL! 찾는건 DLL로 가는게 필요합니다. When an executable has been packed or protected the reverse


engineer must recover the original executable file 팩이 되어 있거나 방어되어 있으면 리버서는 실재 파일을 복구해야 합니


다. because a lot of packers/protectors destroy the IAT 왜냐면 IAT를 망가뜨려버리거든요.

(while taking care of findidng the API's for the program). 프로그램의 API를 찾는 동안

The import address table needs to be either rebuilt or fixed to allow for the executable to run properly. Import


rebuilding is the 임포트된 주소테이블은 재생성되어야 하거나 제대로 실행되도록 고쳐져야 합니다.reconstruction of the


Import address table(IAT). 임포트된 재생성물은 다시 만들어진 IAT테이블 입니다.

So far a short overview of the problem. 지금까지 짧은 개요의 요지는

To understand all better and to be able to rebuild the IAT, IAT 테이블을 다시 만드는 것을 이해하는 겁니다.

it will be necessary dig a little deeper in the theory. 이론은 좀 더 깊게 팔 필요가 있습니다.

However, 그러나

I will only tell you 우리랑 관계없는건 다 빼고 이해하기 위해 정말 뭐가 필요한지만 말하겠습니다.here what's really


necessary to understand and I'll skip those parts that are of no concern for us.

2011년 10월 18일 화요일

p3) 다른 사이트 버리기.

흠... 앞으로 내가 놀 놀이터를 찾고 있었는데 쿨 소프트가 적격일 것 같다.

사실 온라인 상으로 여러 사이트와 여러 사람들과 관계를 맺고 있지만 오래가는 사이트가
별로 없더라.

많이 아쉬웠는데 쿨 소프트 운영자랑 이야기를 해 보니 오래 갈 것 같았다.

우선, 혼자서 개발하는 곳은 오래가게 되어 있다. 나머지는 개인적인 사항이라 블로그에는 적기 그렇고 믓튼, 오래 간다는 것이다.

회사 생활을 접을 생각은 없어서 전업이 아닌 취미로 하는 거지만.

지식을 좋아하고 컴퓨터를 정말 좋아하는 사람들 속에서 지내는 것은 행복한 일이라는 걸

회사 생활 하면서 알았다.

정말 컴퓨터를 좋아하는 사람보다는 컴퓨터로 돈을 벌 수 밖에 없어서 좋아하는 사람들이

많아서.

뭐 돈 없이는 나도 결혼도 못할거고 주변 사람한테 베풀수도 없겠지만. 지금껏 그런 마인드는
아니었기에 편하게 스트레스 안받고 살 수 있었던 것 같다.

ㅋㅋㅋ 그래도 혹시 모르니 내가 쓰는 글들은 여기 백업 해놔야지.

life) PDP가 LED보다 전기를 적게 먹다니...

나도 잘못 들었네.


제가 5개월전에 교수님께 듣기로는 LED가 전기는 적게 먹지만 한번 쏘면 LED 전체를 ON해야돼고 PDP TV는 쓸모 없는 불을 OFF할 수 있다고 합니다. 그래서 결과적으로 볼때 PDP TV가 전기세가 더적게 먹는다고 합니다.




하지만 제가 삼성 LED TV 설명하는 여직원한테 교수님한테 들어던 말을 말하니까 삼성전자 여직원말은 이상하게 말합니다. 최신기술이라 세계1위라고 하면서 더적게 들어간다고 말하고 이론적으로 설명은 전혀 못합니다.



최신기술이 어떤지 LED TV가 전기가 더적게 먹는지? 아니면 삼성전자여직원에 허풍인지 궁금합니다



님이 말하는 부분은 맞는 말입니다. PDP는 PIXCEL 하나하나를 ON,OFF하기 때문에 화면에 따라 소비전력이 수시로 변합니다. 가령 50인치정도로 보면 어두운 화면에서는 약 180~220W정도를 왔가 갔다 하고, 밝은 해변가에서는 260~300W를 왔가 갔다 합니다. 반면에 CCFL LCD경우 화면전체의 밝기를 어둡게 하거나, 밝게 하면 소비전력이 줄지만 화면에 따라서는 소비전력차는 거의 없습니다. 다만 밝기를 비슷하게 해놓고 볼때는 LCD 쪽이 소비전력이 적습니다. 다만 그차이는 일반인이 생각하는 만큼 그렇게 차이가 나는 것은 아니지만



분명 같은 인치에 같은 밝기에 같은 영화를 본다면 LCD쪽이 소비전력이 작습니다.



순간적인 소비전력은 비교를 할수 없지만 누적전력량으로 비교하면 얼마든지 비교가 가능하죠. 가령 같은 영화 한편을 보는데, 사용되는 전력량으로 비교해 보면 되니까요.







여기서 또한가지 차이는 삼성 LED TV는 LED를 EDGE(모서리)에 설치하고, 반사판을 이용해 BACKLIGHT를 합니다. 따라서 부분 밝기제어가 안됩니다. 반면에 LG LED방식은 직접 BACKLIGH방식입니다. 따라서 앞의 LCD화면에 동기화시켜 밝기제어를 하므로 이부분에 대해서는 LG방식이 다소 유리합니다.







참그리고 제품뒷면에 적힌 소비전력및 소비전류는 대부분 최대값을 표시합니다.



제품에 있어 소비전력은 그 제품을 전선이나 콘센트에 연결함에 있어 전선및 콘센트의 전류,전력용량을 정하는데 기준을 주기 위해서입니다. 즉 500W라고 적혀 있는 것은 실제 소비전력이라기 보다 이제품은 순간적이나마 500W까지 소비할수도 있으므로 전선이나 콘센트의 경우 500W이상 견디는 제품을 사용하란 의미이지 그것이 실제 소비전력은 아닙니다. PDP의 경우 화면밝기에 따라 달라지므로 평균적으로 보면 이보다 훨씬 소비전력이 작지만 가장 밝은화면(백색)에서 최대 전력값으로 표시해야 하므로 이런면에서는 매우 불리하죠.



네이버 지식 발췌.

http://kin.naver.com/qna/detail.nhn?d1id=11&dirId=1118&docId=59178733&qb=TEVEIFRWIOyghOq4sOyalOq4iA==&enc=utf8§ion=kin&rank=6&search_sort=0&spq=0&sp=1&pid=gpzNd35Y7uwssbeTeowssc--026424&sid=TpzaNQG2nE4AAD9fLSM

p5) 리눅스 정리 프로젝트 2

리버싱이 주이다. 보니 네트워크 관련해서 쭉 쓰려고 했는데요.
사실 다음이 소켓 프로그래밍이었죠. 초급 강좌를 쓰면서 리눅스를 배워 보려고 하시는 분들에게
무거운 내용이 아닐까 하여 다시 리눅스 이야기로 돌아 왔습니다. 사실 소켓 프로그램 하나 올려놓고
이러이러 하다고 이야기하는건 C 공부 밖에 안되서리 ^^;;

제가 앞에서 설명해 드린 여러 부분들은 리눅스를 전체적으로 봤을 때 별 다를게 없다는 것입니다.
담배피는 사람이야 그게 디스든 에세든 켄트등... 중요하지가 않죠. 뭐, 물론 이것저것 다 펴보았을 때의
이야기 입니다. 사족으로 한마디 하자면 담배는 하나만 계속 피는게 좋아요. 여러가지 펴 보니 원래의
맛을 잃고 다 그 담배가 그 담배 같아 보입니다. 맛을 잃는거죠 ㅠㅠ. 그래서 저도 리눅스 윈도우 다 써보는
것은 좋은데 리눅스가 아쉬운 것이 공부하기는 좋은데 너무나도 내용이 많다는 것입니다.
윈도우는 드라이버단만 좀 해도 잘한다는 소릴 듣는데 리눅스는 고수가 너무 많음...

잡소리는 그만하고 시작하겠습니다. 온라인 교재를 하나 도입했는데요.


Understanding the Linux Kernel
Understandig the LINUX KERNEL by Daniel P. Bovert & Marco Cesati의 책 내용인데요. 유명한 책인데 지금은 접속되지 않는 블로그에서 퍼놨던 거예요. 사실 외서든 번역본 이든 다 딱딱해서 내용 알기가 쉽지가 않죠. 옆길로 너무 새는 것 같아. 그냥 갈께요.

-> 메모리 어드레싱 부분 갑니다. 여러분들 램 사서 컴퓨터에 꽂죠? 리버싱 할 때 PE 파일에서 읽어오면 PC(프로그램카운터)라는 곳이 그 위치를 기억하고 IR(인스트럭트 레지스터)를 거쳐서 ALU(시퓨 코어죵)에 가면 거기서 처리한 연산 결과가 레지스터나 메모리 내용을 변화 시킵니다. 뭐, 플래그들도요. CPU와 메모리는 상당히 중요한 녀석인데 운영체제가 고 녀석들을 관리해줘요. 올리 디버거도 운영체제가 관리하는 메모리 영역(운영체제가 나눈 메모리 영역)을 이용하는 프로그램인거죠.


-> 일단 저장하고 수정해야지... 날아갈라....


Chapter 2. Memory Addressing


차례

Introduction

Memory Address
Segmentation in Hardware
->이 세그먼트란 녀석은 자주 나옵니다. 근래에는 별로 신경을 안 써도 되지만 그래도 어떤 녀석인지는 알아야 겠죠?
8bit, 16bit 시절 메모리 주소 지정이 어려울 때 나온 녀석입니다. 가령 서울에 사는 사람이 편지를 쓸 때 압구정동만 써도
서울이란 걸 다른 사람들은 알수가 있죠? 적절한 비유는 아니지만 그 서울에 해당하는 녀석이 세그먼트란 것입니다.
어떤 기준점이라고만 생각하시면 되요. -생각해보니 정말 적절한 비유는 아니지만 기준점임은 확실합니다.

Segmentation in Linux
Paging in Hardware

-> 페이징이란 녀석도 자주 나오는데 얘는 말 그대로 책에서 페이지 입니다. 메모리를 나누는 단위죠.

Paging in Linux


Introduction

물리적으로 연결되어 있는 메모리에 번지지정을 하는 일반적인 IA(Intel Architecture)의 하드웨어구조와 이를 운영체제에서 사용하는 방법을 살펴본다.

즉, segment와 paging이 적용된 system에서 logical address -> linear address -> physicall address의 변환과정을 살펴본다.


-> 실재적으로 저희가 쓰는 메모리는 physical 메모리 입니다.(교재에 오타가 있네여) 말 그대로 물리 메모리죠. 리니어 라는 건 일자 메모리라는 건데요. 저희가 쓰는 스택이라고 부르는 녀석도 실재적으로는 리니어 메모리 안의 한 부분입니다. 여러분들이 램은 2개를 꽂던 4개를 꼳던 리니어 어드레스 에서는 하나의 메모리로 인식을 한다는 것이죠. 그 하나의 메모리로 보는건 메인보드 단에서 일어나는 현상이구요. 운영체제가 그 리니어한 메모리를 힙, 스택 등 로지컬한 메모리로 변환시킵니다.


Memory Address

일반적인 IA에서 사용하는 3가지 address의 정의
-> IA는 인텔 명령어를 쓰는 녀석이라고 생각하시면 되요.
Logical adderss penrand와 instruction을 정의하는 machine language instructions.

16-bit segment selector와 32-bit offset으로 구성.

-> 세그먼트에서 또 얼마나 떨어졌는지 보는게 오프셋입니다.

Linear address

232bit로 표현되는 4GB까지 지정할수 있는 번지.
-> 32비트라 4GB까지 밖에 못써요. 32비트면 0이나 1이 32개 까지 있을 수 있는데
0 ~ 11111111111111111111111111111111 32개 이게 최대 숫자죠.

16진수로 표현하면
0x00000000 - 0xffffffff

그런데 세그먼트는 왜 있느냐? 세그먼트는 단순히 10을 곱한 겁니다.
가령 세그먼트가 1이면 오프셋으로 10으로 보시면 되구요.
세그먼트가 10이면 오프셋 100으로 보시면 됩니다.
그럼 세그먼트 오프셋 방식에서
0001:0001 하면
실재적으로는 11번지가 되는거죠. 적은 숫자로 많은 메모리 단위를 표현할 수 있기
때문에 세그먼트 오프셋이 나온겁니다. 64비트로 가고 있는 근래엔 필요없는 개념이죠.



Physical address -> 그냥 꽂은 메모리 애들 자체를 말합니다.실제 메모리칩에 포함된 메머리 cell을 지정하기 위해 사용되는 번지.

Ref)figure 2-1 Logical address translation(36p)

Ref)Intel Architecture Software Developer's Manual Volume 3

IA 4가지 동작 모드
-> 이건 CPU에 지정되어 있는 모드에요. 사실 어셈블리에서 말하는 기계어 라는 것은

CPU가 가지고 있는 명령set 입니다. 그럼 CPU마다 명령어가 다른가요?
네 그렇습니다. CPU마다 명령어가 다릅니다. 그런데 어떻게 운영체제를 깔 수 있냐고요?
당연히 운영체제에서는 해당 CPU에 패치를 하기 때문이죠. 패치란 건 해당 운영체제의
명령어들이 다 들어 가는 거예용.

Protected mode

Real-address mode

System mangement mode

Virtual-8086 mode

다음의 모든 내용은 protected mode에서의 동작을 설명한다.

Segmentation in Hardware

Segmentation provides a mechanism of isolating individual code, data, and stack modules so that multiple programs(or tasks) can run on the same processor without interfering with one another.

먼저 시스템에 reset이나 power on을 하면 real-address mode로 동작을 하고 bootstraping 과정을 거친후 protected mode로 진입한다.

Segmentation registers

logical address의 구성은 다음과 같다.

logical address = identifier or segment selector(16-bit) + offset(32bit)

segmentatiin register는 필요한 segment를 빠르게 검색하기 위해 segment selector와cs(code segment register), ss(stack segment register), ds(data segnebt register), es, fs, gs(additional data segment or gernerl purpose register)가 있고 cs register는 cpu의 Current Privilege Level(CPL)를 규정하는 2-bit를 포함하고 있다.

-> 뭐, 여기까지 질문있으시면 댓글을 이용해 주세요. 별로 설명할 내용이 없네요.
CPU는 몇가지 모드를 가지고 있고 FLAG 세팅으로 그 모드들을 바꿀 수 있습니다.
보호모드로 안 바꾸면 DOS 시절처럼 한 프로그램이 다른 프로그램의 메모리를 넘어갈 수 있습니다.
그럼 Flag만 바꾸면 무적이 되지 않느냐? 당근 운영체제가 막고 있죠 ^^ 하지만 운영체제가 다른 프로그램을 침범해도 되게 해놓은 것이! 윈도우에서는 DLL injection이고, 리눅스에서는 디바이스 드라이버죠(디바이스 드라이버를 쓰게 되면 커널모드에서 동작할 수 있습니다)

리눅스에서는 0:User-Mode 3:Kernel-Mode를 사용한다.

Segment Descriptor

Segment descriptor는 processor에게 size, segment의 위치, access control,status 를 제공하는 GDT(Global Descriptor Table)나 LDT(Local Descriptor Table)에 있는 data structure.

GDT와 LDT의 address는 gdtr,ltdr register에 저장되어있다.

Segment Descriptor의 구성 (8-byte)

Base field(32-bit): linear address이내의 segment의 0-byte의 위치.

G flag : segment limit filed를 scaling.

Limit field(20-bit): segment의 size. G flag에 영향을 받음.

G=0 -> 1byte ~ 4MB

G=1 -> 4KB ~ 4GB

S flag: segment가 system segment 인지 code,data segment인지를 표시.

Type field(4bit): 접근권한과 segment type의 여러가지 서로다른 특성을 규정.(CS, DS, TSS, LDTD, Call-gate, Trap-gate, Interrupt-gate..등등에 따라 서로 다른 특성을 규정.

DPL(2-bit):Descripor privilege level. segment에 접근할수 있는 권한을 표시.(CPL level에 의해서 접근권한이 주어진다.)

P flag: segment가 메모리에 있는지 없는지를 표시.

D/B flag: code,data segment에 따라 segment offset을 16-bit or 32-bit로 사용하는지를 표시.

AVL: OS에 따라 임의로 사용 (linux 무시)

Segment Selectors

Segment Selector의 구성(16-bit)

Index(3:15):GDT나 LDT의 8K의 entry중 하나를 지정.

TI flag:GDT나 LDT중 어느 table을 사용하는지를 정의.

RPL(Requestor Privileage level)(2-bit):selector의 level을 정의 (CPL,DPL과 관계있음).

GDT의 첫번째 entry는 항상 0으로 set (null segment selector)

GDT의 최대 entry는 (2^13)-1=8191

Segmentaion Unit

segment selector의 T1 조사 (GDT or LDT를 선택)

segment selector의 INDEX를 추출 gdtr or ldtr의 address를 합쳐 segment descriptor의 address를 결정.

segment descriptor의 BASE field와 logical adress의 offset을 합쳐 linear address를 얻는다.

Ref)figure 2-4. translating a logical address

Segmentation in Linux

리눅스에서는 아주 제한적인 segment를 사용하고 paging 사용을 더 선호한다.즉 protected flat model을 사용한다.사실 IA에는 segment 기능을 disable 할수가 없다.

paging을 선호하는 이유:

모든 processes가 같은 linear address를 이용할때 같은 segment register를 이용하기 때문에 메로리 관리가 쉬워진다.

segment의 극히 작기 때문에 모든 segment descriptor는 GDT만을 사용한다.

arch/i386/kerel/head.S 다음과 같이 정의되어 있다.


ENTRY(gdt_table) .quad 0x0000000000000000 /* NULL descriptor */ .quad 0x0000000000000000 /* not used */ .quad 0x00cf9a000000ffff /* 0x10 kernel 4GB code at 0x00000000 */ .quad 0x00cf92000000ffff /* 0x18 kernel 4GB data at 0x00000000 */ .quad 0x00cffa000000ffff /* 0x23 user 4GB code at 0x00000000 */ .quad 0x00cff2000000ffff /* 0x2b user 4GB data at 0x00000000 */ .quad 0x0000000000000000 /* not used */ .quad 0x0000000000000000 /* not used */
Paging in Hardware

Paging provides a mechanism for implementing a conventional demand-paged, virtual-memory system where section of a program's execution environment are maped into physical memory as need.

page table : linear address를 physical adress로 맴핑한 data structure.

Paging에 사용되는 flags

cr0 register의 PG flag : 0 -> linear address=physical address, 1 -> paging enable.

cr4 register의 PSE (page size extension)flag : large page size(2Mbyte,4Mbyte)

cr4 register의 PAE (physical address extention)flag: 36-bit의 physical size address가능하게 한다.

Regular Paging

4kB의 page을 갖는 방법.

구성 directory (10-bit) + table(10-bit) + offset(12-bit)

page-directory entry

page-table entry

Ref) Figure 3-14

Extended paging

4MB의 page를 갖는 방법

Three-level paginag

64-bit system에서 사용.

리눅스 ststem에서도 사용.

Hardware cache

locality principle을 이용한 hardware cache.

TLB (translation Lookaside Buffers)

linear address 변환을 빠르게 하기 위해 한번 변환된 physical address를 저장.

Paging in Linux

리눅스는 기본적으로 Three-level paging을 사용한다.

Global_dir + Middle_dir + Table + Offset 구성된다.

하지만 IA 시스템에서는 Middle dir을 사용하지 않는다.

Middle dir의 entry에 1을 넣으므로써 Global Dir과 Middle_dir을 Mapping 시킨다.

The Linear Address Fields

Page Table Handling

Reserved Page Frames

Kernel's code and data structure는 reserved page frames에 저장된다

일반적으로 Linux kernel은 물리주소 0x0010_0000부터 RAM상에 저장된다. 1MB이하 영역은 PC architecture상 BIOS에서 사용되기 때문.

Process Page Tables

linear address space는 다음 2부분으로 나뉜다.

0x0000_0000 ~ PAGE_OFFSET -1 process가 User Mode or Kernel Mode에 있을 때 사용된다.

PAGE_OFFSET ~ 0xffff_ffff process가 Kernel Mode에 있을 때 사용된다.

일반적으로 PAGE_OFFSET은 0xc000_0000(3GB)

Kernel Page Tables

다음은 kernel 자신의 page talbes을 초기화 하는 방밥에 대해 알아 본다.

Provisional kernel page tables

real mode와 protected mode 둘다 쉽게 번지 지정을 하기 위해 4MB의 paging을 한다.

Kernel은linear address 0x0000_0000 ~ 0x003f_ffff 와 PAGE_OFFSET ~ PAGE_OFFSET+0x3f_ffff둘다 physicall address 0x0000_0000 ~ 0x003f_ffff에 mapping 한다.

startup_32() assembly function에 의해 paging unit이 enable된다.

Final kernel page table

paging_init()실행.

처음 4MB의 linear와 physicall의 mapping을 제거.

User Mode process는 이 4MB의 linear address 공간을 사용할수 있게 된다.

PAGE_OFFSET상위 linear address는 User/Supervisor flag 값이 0가 되므로 User mode process가 Kernel address space접근을 거부


-> 뒤의 내용들은 그냥 한번 읽고만 가야 하는 내용들이네요. 사실 다 까먹거든요. 하지만 한번 읽어두는 것은 중요합니다. 왜냐면 한번은 읽어놔야 나중에 찾을 수가 있거든요. 사실 출근전이라 급하게 적은 감이 없잖아 있습니다만. 그 동안 뭐가 뭔지 긴가 민가 하시는 분들에게 나름 어줍잖은 지식에 대한 혼자만의 결단으로 이해를 도운 부분이 있을 것 같습니다.

bootcamp 지우기

맥북 프로 레티나 터치바 diskutility 에서 bootcamp 파티션 삭제하면 검은색에서 회색으로 바뀐다(APFS로 지정) 파틴션 아이콘 클릭하여 - 버튼을 이용하여 삭제하면 끝.