'Ver 1.0/역 어셈블링'에 해당되는 글 7건
- 2009.08.09 SQl injection 예제 동영상
- 2007.01.09 Hacker Disassembling Uncovered / 리눅스 커널 구조
- 2007.01.07 [도서] CRACK 크랙 2
- 2007.01.07 어셈블리어 강좌
- 2006.12.19 에디터 / 디버거
- 2006.12.02 PC 어셈블러 가이드북
- 2006.11.29 Reverse Engineering은 합법이다?
SQl injection 예제 동영상
보면 asp.net으로 짜여진 페이지고, 디버그 에러가 잔뜩 나온다.
그걸 이용해서 정보를 찾고 찾은 정보를 이용해서 어떤 페이지에서 sql을 생성해 내는데 뭔 내용인지는 화면이 보이지 않아서 잘 모르겠다.
외국 넘들은 저렇게 정보를 모아 놔서 각 설정에 맞게 sql까지 생성해 주는 웹페이지 까지 만들어 놓고 운영하나보다.
멋진 넘들. 일단 영어 공부 많이 해 놓자.
SecureState_SQL_Injection.flvHacker Disassembling Uncovered / 리눅스 커널 구조
진짜 당장 다 때려 치우고 1년간 영어만 죽어라 공부하는 계획으로 바꿔야 하나?
지금 전공 따라가기도 숨가빠서 머리가 터질 지경인데, 영어야 어차피 해야 하지만 이거 벌써부터 은근히 스트레스 많이 받네.
일단 번역의 땀 방울이 진하게 묻어나 보이는 한글문서 부터 보도록 하자.
invalid-file[도서] CRACK 크랙
| [도서] CRACK 크랙 : 역어셈블링을 이용한 코드 해킹 (CD 1) |
이 책 2틀동안 읽어 봤는데, 정말 나에겐 쓰레기였다.
이런 책을 출판 했다는것 자체가 나에겐 참으로 의아한 일이다.
파워북이란 출판사. 정신이 있는건지 없는건지? 이런 쓰레기를 출판 할 생각을 하다니?
뭐 지극히 개인적인 판단이지만 내가 이 책을 읽고 느꼈던 배신감의 충격은 컸다.
검색해 보니까 파워북이란 출판사는 망했는지 나오지도 않고 도메인도 다른 사이트가 나온다.
내가 이 책에서 원했던 내용은 물고기를 잡는 방법이었다.
왜 물고기를 잡아야 하는지, 어떤 물고기를 잡아야 하는지, 물고기는 어떤 종류가 있는지 등등
하지만 이 책은 실망 스럽게도 자기가 잡은 물고기 자랑만을 늘어 놓는다. 그리고 잡는 모습을 사진으로 몇방 찍어서 붙여 넣었다. 그리고는 자만심에 넘쳐서 자기 자랑을 늘어 놓는다. 책 중간에 "나는 천재인것 같다"라는 식의 표현이 나온다. 참으로 어의가 없다. 개인 석상의 자리도 아니고, 그렇다고 자신의 블로그같은 웹상의 자유로운 자리도 아니고, 정식으로 출판 하는 책에서 이런 개인적인 표현을 쓰다니? 그리고 그걸 그대로 출판한 출판사까지? 참으로 어의가 있을수가 없었다.
이런 내용들은 전문 잡지의 시리즈류의 기사로 실었어야 알맞은 내용이다.
처음 이론은 단 10장도 안된다. 그런 상황에서 프로그램을 하나 놓고 툴을 이용해서 그림을 넣어가면서 설명을 하는데. 이건 딱 잡지 기사 형식이 아니던가.
좋다. 그럼 잡지기사 형식과 책의 차이는 무엇일까? 정답은 유효기간에 있다. 이런 내용들은 그때만 잠깐 쓸모있는 내용들이다. 유효기간이 짧기 때문에 책으로 출간하지 않는다. 만약 책으로 출간 하려 했다면 깊게, 그리고 심도있게 들어갔어야 할 것이다. 이런식의 내용이 책으로 출간 된다면 개나 소나 다 책내겠다.
정말 내 시간만 잡아 먹어 버린 쓰레기 같은 책이었다.
어셈블리어 강좌
|
[어셈블리어] Win32 API Assembly 강좌
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
에디터 / 디버거
invalid-filePC 어셈블러 가이드북
Reverse Engineering은 합법이다?
개정 컴퓨터프로그램 보호법, 그 미비점
- 최재원(경희대 국제법무대학원 지적재산권법무학과 석사과정)
- [월간 마이크로소프트웨어 1996년 4월호 게재문]
- 출처: http://my.dreamwiz.com/saro/copyla04.html
리버스엔지니어링의 명시적 허용규정을 두어야리버스엔지니어링(reverse engineering;분석프로그래밍)이란 타 제품을 분석해
서 그로부터 기술을 알아내는 행위이고, 산업발전에 있어서는 필수적인 호환성을
유지하기 위한 필수적인 행위이다. 그러므로 기술보호법인 특허법, 실용신안법,
의장법, 반도체배치설계법은 명문으로 이를 인정하고 있다. 리버스엔지니어링은
통상 옵젝트 코드에서 소스코드로 거슬러 올라가는 과정으로 기존 프로그램을 복
제하거나 번역하는 행위가 불가피하다. 때문에 이를 허용되지 아니한다거나 인정
에 있어 신중론을 펴는 견해가 없지 않다.
그러나 명문의 규정이 없더라도 종래의 관행으로 인정되어온 리버스엔지니어링
은 허용되어야 할 것이며, 이를 명문으로 인정함이 타당할 것이라는 견해가 있으
며(송영식.이상정.황종환, 앞의책, 1111면), 필자도 이를 지지한다. 왜냐하면 EU
지침("컴퓨터프로그램의 법적 보호에 관한 지침 제6조", 1991.4.17.), 미국의 최
근판례를 통해서도 리버스엔지니어링을 허용하고 있고, 소프트웨어산업의 최대 유
력사인 미국 마이크로소프트사도 관련법규에서 명시적으로 허용된 제한적인 범위
에서 이를 허용하고 있는 점 등을 고려할 때 명시적으로 이를 인정하는 규정을 둘
필요가 있기때문이다.
참고로 미국판례를 보면, 첫째, Accolade사건(Sega Enterprises Ltd. v.
Accolade Inc., 977 F.2d 1510(9th Cir. 1992))에서 "호환성이 있는 프로그램을
개발하기 위해 타사 프로그램의 설계사상이나 기능에 관한 개념을 이해할 필요가
있고 '다른 대안이 없을 때'에는 복제행위를 수반하는 리버스엔지니어링을 행하더
라도 저작권법위반이 아니라고 하였다." 둘째, Atari사건(Atari Games Corp. v.
Nintendo of Am. Inc., 975 F.2d 832, 843 (Fed. Cir. 1992))에서 "프로그램의 복
제를 부정한 수단으로 입수하지 않았고 프로그램을 이해하기 위하여 행한 리버스
엔지니어링이라면 공정한 사용(Fair Use)이라고 볼 수 있을 것이다"라고 하였다
(정완, 앞의책, 84면이하).
이제 시작 해보자.
