쿠...sal: hack

레이블이 hack인 게시물을 표시합니다. 모든 게시물 표시

[컴][컴파일러] LLVM 을 Windows Visual Studio Community 2015에서 build

LLVM 을 Windows Visual Studio Community 2015에서 build

여기 내용은 ref. 1의 내용을 직접 해보면서 정리한 내용이다. 정확한 내용은 ref. 1을 보자.

여기서 ref. 1 과 다른 부분은 을 이용해서 표시했다.

LLVM 을 구성하는 3가지 project

LLVM Suite : 다음 것들을 포함한다.

assembler,
disassembler,
bitcode analyzer,
bitcode optimizer
basic regression tests : CLang 과 LLVM tools 의 테스트에 사용할 수 있다.
LLVM 을 사용하는 데 필요한 tools / libraries/ header files

CLang : C, C++, Object-C, Object C++ 의 "소스코드"를 CLang 이 compile 해서 LLVM bitcode 를 만들어 준다.

source code ---> LLVM bitcode 를 하는데, 이것을 위한 tool 이 CLang 이다.
Test Suite : Windows 에서 실행되지 않는다.

directory 구조 / tool chain 등에 대한 추가적인 정보는 ref. 2 에서 알 수 있다.

필요 조건

Visual Studio 2015 가 구동될 수 있는 system.
대략 3GB 이상의 HDD : The LLVM source tree + object files + libraries + executables
Visual Studio 2015 버전 이상의 Visual Studio : 여기선 Visual Studio 2015 Community 를 사용할 것이다.
CMake build system : 아래 "CMake 설치" 참조
LLVM test 를 실행하기 위해서 python 2.7 이상이 필요
GnuWin32 tools
LLVM source tree 의 path 에는 space 가 있으면 안된다.

소스 받기

svn 으로 되어 있다. svn 을 설치하기 귀찮은 관계로 여기서는 git 을 이용한다.

GitHub - llvm-mirror/llvm
GitHub - llvm-mirror/clang : clang source 는 따로 다운받아야 한다.

c:\a\programming\llvm> git clone http://llvm.org/git/llvm.git
c:\a\programming\llvm> cd tools
c:\a\programming\llvm\tools> git clone http://llvm.org/git/clang.git

소스를 받는데에만 약 95분정도가 소요됐다.(llvm source : 60분 / clang source : 35분)
빠르게 하려면 한번에 받아서 unzip 하는 것이 나을 듯 하다.

Visual Studio 2015 실행

Visual C++ toolchain 이 필요해서 미리 한번 실행해서 tool chain 을 설치해야 한다.
12시 51분에 시작

CMake 설치

https://cmake.org/download/ 에서 download 하면 된다. 여기서는

cmake-3.7.1-win64-x64.msi

를 사용했다.

CMake 실행

이제 CMake GUI를 실행해 보자.

c:\Program Files\CMake\bin\cmake-gui.exe

절차

Where is the source code : llvm 을 download 받았던 path, 즉, .git 이 있는 그 folder 를 지정해 준다.
Where to build the binaries : 이것은 CMake 로 만들어질 output file 이 어디에 두느냐 이다. 여기서는 binary 를 만드는 것은 아니고, sln file 등을 만들어준다.

불확실하지만, path 는 llvm source root 안으로 잡아야 한다. 외부로 잡았었는데, *GenRegisterInfo 가 include 되는 곳에서 error 가 발생했다.(그런데 뭔가 필자의 설정 문제 같기도 해서 잘 모르겠다.)
Configure : configure 버튼을 누르면 가운데 화면에 빨간색 바탕으로 변수들이 나온다. 이 변수들의 설정을 원하는대로 변경하고, Generate 버튼을 누르면 .sln + .proj 파일들이 만들어진다. ref. 1 의 이야기로는 default 값으로 generate 해도 별 문제 없다고 한다.

이 때 CLANG_* 변수들이 보인다면, CLANG 에 대한 project 도 같이 만들어진다. 보이지 않는다면, clang source 가 없는 것일 것이다.
CMAKE_INSTALL_PREFIX : 이 값은 LLVM 을 compile 해서 나오는 binary 를 저장할 path 를 지정해 주는 것이다. default 는 그림과 같다.
Generate : 이것을 누르면 .sln + .proj 파일들을 만들어준다.

clang source 없이 llvm source 만 설정했을 때

clang source 를 추가했을 때

LLVM.sln

이제 LLVM.sln 을 열자. "where to build the binaries" 를 "c:\a\programming\llvm\llvm\build\" 로 설정했다면 아래 경로에 LLVM.sln 이 있다.

c:\a\programming\llvm\llvm\build\LLVM.sln

Build

모든 project 를 build 하려면, "ALL_BUILD" 또는 "INSTALL" 을 Build하면 된다.

참고로, clang source 는 llvm 을 이용하기 때문에 2개의 source 가 같은 시점이어야 한다. 내 경우는 llvm 만 먼저 설치후에 나중에 며칠 지나서 clang source 를 받아서 build 했는데, 그랬더니 struct 등이 맞지 않아서 error 가 많이 났다.

INSTALL 은 ALL_BUILD 를 실행하고, libs, header 등도 같이 CMAKE_INSTALL_PREFIX 폴더에 copy 해 준다.

compile 시간

CPU : i3-2100 CPU@3.10GHz
RAM : 8GB
DISK : SATA3(6Gb/s), 7200RPM, 16MB
compile 시간 :

약 65분(CLang 을 제외한 경우),
CLang 을 포함하면 최소 2시간정도

INSTALL

기본적으로 아래 경로에 실행파일이 만들어진다.

<.sln file directory>\Debug\bin

만약 install 을 실행한 경우라면, 위의 path 에서 만들어진 binary file 들은 CMAKE_INSTALL_PREFIX 에 정의한 path 로 복사된다.

c:\Program Files (x86)\LLVM

References

[컴][보안] 서버의 key 관리 어느것이 나을까?

DB 의 field 값 암호화

갑자기 서버가 사용하는 DB 에 user 의 어떤 key 를 저장할 때(예를 들면 특정사이트의 password 같은) 어떤 식으로 저장하는 것이 해킹에 안전할까에 대한 궁금증이 들었다.

그래서 조금 찾아보니 아래에 어느정도 잘 답변해준 자료가 있었다.

key management - Where to store a key for encryption? - Information Security Stack Exchange

여기서 이야기 하려고 하는 것은 당연히 crypt/decrypt 가 되는 암호화를 이야기 하려 한다. hash 같은 방식은 여기서 사용하지 않는다. 왜냐하면 암호화 한 내용을 다시 복호화해서 사용해야 하는 상황이기 때문이다.

여하튼 짧은 보안에 대한 지식을 가지고, 어떤 식으로 key 를 관리하는 것이 좋은 지에 대해 한 번 생각해 보자.

키 관리 key management

symmetric / asymmetirc

개인적으로 symmetric 을 쓰려고 한다. asymmetric 은 key 를 주고받아야 하는 경우가 아니라면 굳이 사용할 이유는 없다고 생각된다. 암호화 수준도 대체로 symmetric 이 우수하다고 하며, key 를 따로 관리해야 하는 것도 부담이다.(혹시 이밖의 의견이 있다면 댓글을 부탁합니다.)

http://i5on9i.blogspot.kr/2015/10/blog-post_2.html

key 관리 key management

결국 이 암호화의 핵심은 key 를 hacker 에게 어떻게 노출시키지 않을 수 있는가 인 듯 하다. 그러기 위해서는 일단 key 를 어디에 숨겨야 한다. 그럼 key 를 숨기기위해 또 암호화를 할까? 그것은 그냥 절차(process)만 길게 만드는 것일 뿐, 보안에 더 도움이 되지 않는다.

보통은 이 key 를 hacker 가 알아내기 힘든 어떤 값으로 정하는 쪽을 택하는 듯 하다.

hacker 가 가져가기 힘든 것

hacker 가 알아내기 힘든 곳이란 것은 자신의 컴퓨터가 hacking 되었을 때를 가정하면 파악할 수 있다.

보통 자신의 server 의 admin 계정이 hacking 당하는 등의 일이 발생하면, hacker 는 계속 그 컴퓨터를 사용하기 보다는 서버의 정보를 자신의 local 로 옮기는 행위를 할 가능성이 크다.

왜냐하면 hacking 이 발각되면, admin 비밀번호를 당연히 바꿀 것이고, 다시 hacking 을 해서 정보를 가져오려면 또 오랜 수고가 필요할 테니 말이다.

그래서 결국 여기서 "hacker 가 알아내기 힘든 곳"이란 결국 hacker 가 가져갈 수 없는 어떤 것이 된다. 대부분은 network를 통해 가져갈 수 있으니, 그 이외의 것을 고려하면 된다.

Hardware

그래서 가장 좋은 것은 encryption key 로 h/w 정보를 이용하는 것이다. 물론 쉽게 알아낼 수 있는 것은 좋은 생각이 아니다.(예를 들면 mac address)

그래서 ref. 1 에서 이야기하는 것처럼 외부에 장착된 security module 같은 것은 더없이 좋다. 아니면 TPM chip 같은 것을 이용하는 것도 좋다.

물론 여기에도 한계는 있을 수 있다. hacker 들이 이것을 이미 알고 들어왔다면, security module 을 hacking 하는 시도를 하던지 TPM chip 의 정보등은 해킹을 시도할 수 있다.

login 정보

os 의 login 정보를 key 로 이용할 수 있다. 하지만 이것은 linux 에서 어떤 식으로 가능한지는 잘 모르겠다. windows 는 이런 API 를 제공한다. 이것을 활용한 예는 chrome 에서 볼 수 있다. 아래 글을 참고하자.

How Secure are Your Saved Chrome Browser Passwords?

server 시작시 key 입력

개인적으로는 이녀석이 쉽게 구현해서 사용할 수 있고 꽤 괜찮은 안전 수준을 제공해 줄 듯 하다. ref. 1 에서 memory dump 로 가져갈 수 있다고 하지만, 입력한 key 의 hash 값을 사용한다면 더욱 안전한 상태가 가능할 듯 싶다.

하지만 관리자가 계속 머리에 key를 가지고 있어야 하는 것은 부담이다.

다른 서버에 저장

개인적으로 이것도 나쁜 생각은 아니라고 생각된다. 하지만, 그 key 를 저장하는 서버가 충분히 secure 할 필요는 있다. 쉽게 뚤리는 곳이라면 hacking 도 쉽게 이뤄질 수 있으니, 순간적으로 key 가 탈취당하지 않았다고 생각할 수 있지만, 바로 hacking 해서 가져갈 수도 있다.

하지만 일단 또다른 hacking 을 해야 한다는 부담감이 있어서 단념하게 될 가능성도 크다.

같은 서버에 다른 곳에 저장

가장 쉽게 생각할 수 있는 부분인 듯 하다. 그저 network 로 정보만 가져가는 경우라면 다행이겠지만, admin 계정등을 해킹해서 들어온 경우라면, 큰 의미없는 보관이 될 듯 하다.

개인적은 결론

일단 개인적으로 자금이나 machine 의 상황으로 h/w 를 이용하는 것은 쉬운일이 아니라고 생각된다. 그런면에서는 조금 번거롭지만, 암호를 잘 기억해서 server 를 띄울때 typing 하는 것이 가장 합리적인 방법이 아닐까 생각된다.

References

key management - Where to store a key for encryption? - Information Security Stack Exchange

[컴] Visual Studio 2015 Community 개인적인 단축키 세팅

이글은 그냥 개인적으로 필요한 세팅을 정리해 놓는다.

Visual Studio 2015 를 python 의 debugger 로 쓰려고 하는데, 단축키가 달라서 개인적으로 몇가지를 조정했다.

Shortcuts

Ctrl+Q( Quick launch) 에서 keyboard 를 치면
Options > Environment > Keyboard 로 갈 수 있다. 거기서 아래 부분을 수정했다.
이탤릭체는 그냥 적어놓는 기능이다.

Edit.FindNext : F4
Edit.FindNextSelected : Shift + F4 (cursor 가 있는 곳의 symbol 을 찾기)
Edit.FindPrevious : F3
Edit.FindPreviousSelected : Shift + F3 (cursor 가 있는 곳의 symbol 을 찾기)
Edit.FindAllReferences : alt + F7 (reference 된 곳들을 찾아준다.)
Edit.QuickFindSymbol : (정의 된 곳들을 solution 내 에서 찾아준다.)
Edit.GoToDefinition : ctrl + b
View.ClassViewGoToSearchCombo : ctrl + R (file 내의 symbol 을 찾기에 좋다.)
View.NavigateBackward : alt + 왼쪽화살표
View.NavigateForward : Text Editor / alt + 오른쪽화살표
Windows.SolutionExplorerSearch : ctrl + p (solution 내 모든 파일)
Edit.CommentSelection : ctrl + /
Edit.UncommentSelection : ctrl + shift + /
Edit.NextBookmarkInDocument : F2
Edit.PreviousBookmarkInDocument : Shift + F2
Edit.ToggleBookmark : ctrl + F2

여러 단어 한번에 선택하기, multi selection

sublime text 등에서 ctrl + d 를 이용하면 같은 단어를 select 해준다. 이것을 가능하게 해주는 extension 이다. 설치하고 Visual Studio 를 restart 하면 된다.

MixEdit extension

한번에 여러 line 선택, vertial selection

alt 를 누르고, 마우스를 drag 해서 여러 line 을 한번에 선택할 수 있다. 하지만 이 extension 으로 multi selection 을 안된다. 이녀석은 MixEdit 를 설치했다면 굳이 설치 하지 않아도 좋을 듯 하다.

MultiEditing extension

메인 메뉴 숨기기

그리고 메인메뉴(main menu bar)를 안보이게 하고 싶어서 아래 plug in 을 설치했다. plugin 을 설치하고 restart 를 하면 된다.

Hide Main Menu extension

[컴][웹][보안] HTML5 Canvas fingerprinting

HTML5 Canvas fingerprinting 원리 / 캔버스 지문채취 원리 / 브라우저에서 트래킹하는 방법/ 이미지 픽셀로 컴퓨터 구분하는 방법

HTML5 Canvas fingerprinting

우리가 인터넷을 사용할 때마다 우리를 tracking 하는 기술들이 많이 있다. 이 post 에서는 canvas fingerprinting(캔버스 지문채취) 라는 기술에 대해서 간략히 알아보자.

ref. 1 에 가면 현재 자신의 browser 로 fingerprinting 을 한 내용을 보여줄 것이다. 그리고 이것이 어떻게 동작하는 지를 알려준다.

ref.1 에서 설명을 잘해 주고 있어서 ref.1 의 내용 중 일부를 번역했다.

아래의 글은 ref.1 의 내용을 번역한 것이다.

Canvas 2D context 를 사용한다면, 특히 WebGL profiling 을 사용한다면 비디오 adapter 를 구분할 수 있다. 일반적인 font 를 rendering 할 때 그래픽 카드 드라이버마다 다른 영향을 준다.
이렇게 만든 화면은 memory 상에 있게 되는데, 이 화면을 toDataURL() 함수를 이용해서 추출한다. toDataURL() 함수가 binary image 파일을 base64-encoding 된 문자열로 변환해서 보여준다.
그래서 이 string 을 MD5 hashing 을 할 수도 있고, PNG file 마지막에서부터 16 ~12 byte 에 있는 IDAT chunk 로 부터 CRC checksum을 추출할 수도 있다.
이것이 Canvas Fingerprint 가 된다고 한다.

실제로 구현된 모습은 ref. 1 에서 확인할 수 있다. 아래는 javascript code 이다.

// Text with lowercase/uppercase/punctuation symbols
var txt = "BrowserLeaks,com <canvas> 1.0";
ctx.textBaseline = "top";
// The most common type
ctx.font = "14px 'Arial'";
ctx.textBaseline = "alphabetic";
ctx.fillStyle = "#f60";
ctx.fillRect(125,1,62,20);
// Some tricks for color mixing to increase the difference in rendering
ctx.fillStyle = "#069";
ctx.fillText(txt, 2, 15);
ctx.fillStyle = "rgba(102, 204, 0, 0.7)";
ctx.fillText(txt, 4, 17);

converse 를 이용해서 video 카드 특성을 알아보는 법

ref. 2 에 보면 html 의 canvas 와 js 를 이용해서 어떤 식으로 video 카드의 특징을 파악하는 지 알 수 있다.

ref.2 에서는 font-smoothing 기능을 지원하는지 여부를 알아보는 함수를 보여주는데, 원리는 간단하다.

canvas 2D context 를 이용해서 그 안에 검정색의 문자를 하나 넣는다. 그러면 video card 가 그것을 rendering 할 텐데, 이 rendering 된 결과의 pixel 들을 확인하는 것이다. 그래서 검은색이 이외의 색(예를 들면 회색) 이 있다면, 이것은 font-smoothing 이 적용돼서 흐릿한 색이 들어간 것일 테니, 이런 경우라면, graphic card 가 font-smoothing 을 사용한다고 보는 것이다.

기타

이외에도 browser 를 통해 많은 정보를 가져갈 수 있는데 이런 방법들은 아래 source 에서 확인할 수 있다. 대략 보면 DOM 의 navigator 정보를 많이 이용하는 듯 하다.

https://github.com/Valve/fingerprintjs2

Reference

HTML5 Canvas Fingerprinting : further reading 에서 더 많은 자료를 확인할 수 있다.
How to Detect Font-Smoothing Using JavaScript

[컴][그래픽] Bitmap 포맷 정보

비트맵 분석 / 비트맵 정보 / 비트맵 포맷

Bitmap format

1 pixel 의 검은색 bit map(24bit) 에 대한 hex code

42 4D 3A 00 00 00 00 00 00 00 36 00 00 00 28 00
00 00 01 00 00 00 01 00 00 00 01 00 18 00 00 00
00 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00

ㅁ file size
ㅁ reserved(not used yet)
ㅁ file 의 시작위치에서부터 실제data 위치
-----------------
ㅁ bitmap header size – 각 bitmap variants 마다 size가 다르다. 제공하는 기능이 다르기 때문이다. Windows는 40byte의 size를 쓴다. Bitmap header size 는 지금 이 header size 를 포함해서 40-byte 이다. 즉, 위 그림에서 0x 28 00 00 00 부터 40-byte이다.
ㅁ width in pixels
ㅁ height in pixels
-----------------
ㅁ planes
ㅁ bits per pixel
ㅁ compression
-----------------
ㅁ bitmap data size
ㅁ hresolution (pixel per meter)
ㅁ vresolution (pixel per meter)
-----------------
ㅁ colors
ㅁ important colors
-----------------
ㅁ 실제 data, 한 pixel 당 3-byte(24bit) 사용.

Bitmap data 분석시

Bitmap 의 저장은 빨간색으로 표시된 왼쪽 아래에서부터 한 줄씩 저장하게 된다.

Null-byte padding

한 line 이 4-byte 로 나누어 떨어지지 않으면, 4의 배수로 맞추기 위해 null-byte를 추가한다.
예를 들면,
가로 5-pixel 의 bitmap 을 24-bit로 저장한다면,
가로줄 하나는

FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

이렇게 된다. 이러면 가로줄 하나는 15-byte 가 된다. 그럼 4-byte로 나누어 떨어지지 않는다. 그래서bitmap 으로 저장하게 되면

FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 00

이렇게 00(null-byte) 을 붙여서 4-byte로 나누어 떨어지게 한다.
If the number of bytes matching a horizontal line in the image is not divisible by 4, the line is padded with null-bytes.

Reference

[컴][용어] Proof-of-work 란?

일의 증명 / what is proof of work

Proof-of-work 가 무엇일까? bit coin 문서를 보면 proof-of-work 의 이야기가 많이 나온다. 그래서 proof-of-work 에 대한 정의에 대해 살펴보자. 대부분 ref. 1 을 보고 필자가 이해한 바를 정리한 내용이다.

Proof-of-work system

proof-of-work 는 핵심은 비대칭성이다.[ref. 1] 이것은 한쪽은 시간이 오래 걸리고, 다른쪽은 시간이 별로 안걸리는 것을 이야기 한다.

쉬운 예로 어떤 왕이 "저 산을 이쪽에서 저쪽으로 옮겨라"라고 지시했다고 하자. 이 경우에 산을 옮기기 위해 신하들은 엄청나게 오랫동안 일을 하지만, 왕은 산이 옮겨진 것을 확인하는 것으로 간단하게 신하들이 고생했다는 것을 파악할 수 있다.

proof-of-work 에서 client

proof-of-work 시스템을 번역하면 "일의 증명" 시스템이라고 할 수 있겠다. ref. 1 에서 Proof-of-work 의 예로 CAPTCHA 를 들고 있다. (CAPTCHA 에 대한 설명은 생략한다.)

우리도 이 CAPTCHA 를 가지고 proof-of-work 가 어떤 역할을 하는지 보자.

CAPTCHA 의 대표적인 예로 "이미지로된 영문자"가 있다. CAPTCHA의 "이미지로 된 영문자"는 정상적인 모양이 아니라 조금 비틀어져 있다.

이렇게 조금 비틀어진 이미지로 된 영문자는 컴퓨터의 입장에서 바로 인식할 수 없다. 흔히 이야기하는 image processing 을 해서 비로서 컴퓨터 입장에서 "문자"로 인식한다. 이 분야를 OCR(optical character recognition) 이라 하는데 이 OCR 이라는 것이 그렇게 훌륭하지 않아서 조금만 정자(正字) 에서 벗어나면 인식률이 크게 떨어진다. 결국 이 CAPTCHA 를 컴퓨터가 제대로 읽어드리기 위해서는 이런 비틀어진 이미지에 대한 처리를 해줘야 하는데, 이것은 작업이 빠르게 되지 않는다. 비틀어진 글자들이 어떤 pattern 을 가지고 있는지도 알 수 없으며, pattern 이 없기 때문에 여러가지 경우를 고려해야만 한다. 여하튼 이런 이유로 CAPTCHA 의 글씨는 사람은 빠르게 처리할 수 있지만, 컴퓨터는 시간이 오래걸리게 된다.

만약에 login 과정에 CAPTCHA 를 사용하는 시스템이 있다고 하자. 이 때 만약 누군가가(컴퓨터이든, 사람이든) CAPTCHA 를 통과해서 시스템에 들어오면, 이 통과해서 들어온 녀석은 무조건 login 을 정상적으로 했다고 인정해 준다.

사람이 아닌 컴퓨터가 통과하는 것은 해킹이기 때문에 허락하면 안되는 것 아니냐라고 생각할 수 있다. 하지만 컴퓨터로 통과하려면 이 CAPTCHA 를 처리하는 작업을 하고 들어와야 하는데, 이 CAPTCHA 를 처리하는 시간이,장비나 알고리즘마다 틀릴 수 있지만, 몇시간이상 걸릴 것이다. 이것이 한번의 login 시도만 할 경우에는 해볼만 할 지 모르겠지만, 해커의 입장에서는 비용이 많이 든다. 고작 login 시도 한 번을 위해 몇시간을 투입할 수는 없다. 이것을 병렬로 돌린다고 해도, 여러대의 컴퓨터를 소유해야 하고, 전기도 사용해야 해서 비용 대비 효율이 떨어진다.

즉 "login 시도"를 컴퓨터로 자동화 해도, 원하는 만큼의 속도를 얻기가 힘들다는 이야기다. 보통 컴퓨터로 자동화 하는 이유가 빠르게 여러 번 시도해서 login 을 성공하려는 것인데, 그런 일을 어렵게 한다는 것이다.

이러한 판단을 해커가 하게 된다면, 해커는 굳이 CAPTCHA 를 뚫으려 하지 않는다. 차라리 그 시간에 CAPTCHA 가 없는 곳을 공격하거나, 아니면 사람을 사용해서 일일이 시도하거나, CAPTCHA 를 우회할 방법을 고민할 가능성이 크다.

이렇게 해커에게 이 시스템을 공격하는 것은 돈도, 시간도 많이 드는 작업이라는 것을 알려서, 대부분의 해커가 포기하게 만드는 것이 Proof-of-work 의 목적이다.

proof-of-work 의 server

다시 CAPTCHA 로 돌아가자. server 쪽에서 이 녀석이 CAPTCHA 의 인증을 할 땐 간단히 확인해 줄 수 있다. 자신이 제시한 이미지가 어떤 값을 가지고 있는지 미리 알기 때문에 client 에서 입력한 값과 자신이 입력한 값을 비교해 주기만 하면 된다. 즉 server 는 매우 빠르게 증명해 줄 수 있어서 비용이 거의 들지 않는다.

이래서 server 쪽은 큰 부담없이 CAPTCHA 를 사용할 수 있다.

protocol 종류

이 proof-of-work 의 protocol 에는 2가지 종류가 있다.[ref. 1] 이 protocol 은 ref. 1 의 variants 에 있는 그림을 확인하자.

Challenge-response protocol : CAPTCHA 처럼,

요청자(requester)가 문제(challenge) 를 요구하고,
제공자(provider)가 문제를 골라서 주면,
요청자가 문제를 풀고 수신자에게 주면,
수신자가 그 문제를 확인해서 증명하는 방법

Solution-verification protocol : bitcoin 등에서 처럼 요청자가 문제를 요구하는 것이 아니라, 이미 나와 있는 문제들을 푸는 것이다. 이 때 제공자는 어떤 문제를 풀었는지도 확인하고, 답도 확인해야 한다. 이런 scheme 중 하나가 bitcoin 등의 unbounded probabilistic iterative procedures 이다.

비트코인의 작업 증명

실제적으로는 검사하기는 쉬우나, 풀어내기는 어려운 것을 PoW라 한다.
이것을 이용해서 bitcoin 에서는 하나의 어려운 문제에 대한 해답을 얻으면(CPU 능력을 소모) , 블록체인 원장(ledger)에 새로운 block을 더할 수 있도록 한다.
네트워크안의 모든 node(컴퓨터들)가 문제를 풀게 된다.
이 때 가장 빨리 풀어낸 node 가 코인으로 보상을 받게 된다. 이과정을 채굴(mining) 이라고 한다.
이것이 consensus mechanism 이 된다. 즉, 이녀석이 많은 작업증명을 해결했다는 것은 곧 CPU 자원을 가장많이 사용한 녀석이기 때문에 이녀석의 ledger 를 채용한다는 동의를 해준다.(컨센서스 알고리즘 참고 자료 : Raft 알고리즘)
이렇게 cpu 의 소모가 많아서 쉽게 조작하지 못한다. 대체로 악의적인 유저가 cpu 를 소모해서 ledger의 내용을 고치는 것보다는 mining 을 하는 것이 cpu 소모가 적다. 이것이 blockchain 이 pow 를 이용하는 이유 중 하나다.

Reference

[컴][웹] ssl 에서 공격

ssl attack / 보안 공격 / 해커 공격 / https 공격 방법

SSL 공격 과 관련된 자료

https 를 사용하는데, 그래서 해킹관련 자료를 조금 찾아봤다. 1번째 자료가 개괄적으로 설명을 잘 해놓은 듯 하다. 2번째 자료는 그림자료가 있어 이해하는 데 도움이 된다.

오픈웹 관련: SSL과 관련된 공격들…

MITM
SSL Strip
IDN

MITM 에 대한 방법, 그림 : http://kimdongwook.tistory.com/entry/SSL-MITM

https 를 http로 연결해서 공격

공격 중에 http 가 같이 열려 있는 경우에 대한 공격들이 있다. http 가 열려있는 경우 강제로 https를 http 로 연결 시키는 공격이 있다. 여기를 참고하자. 동영상을 볼 수 있다.

[컴][보안] 패스워드 보안 - password hash function

패스워드 해쉬 함수 /

password hash function

패스워드 관련 암호화 자료를 찾다가 좋은 자료를 찾았다. 아래에 password hash function 과 관련된 전반적이고 자세한 이야기, 이슈등을 정리해서 잘 알려주고 있다.

appsec - How to securely hash passwords? - Information Security Stack Exchange

결론

결론적으로 위의 글에서 추천하는 방법은 아래 2가지 이다.

bcrypt
PBKDF2

안드로이드에서 PBKDF2 사용

Using Cryptography to Store Credentials Safely > Even more security 참고

Asymmetric < symmetric

Asymmetric 암호화보다는 symmetric 암호화가 훨씬 secure 하다고 한다.

http://stackoverflow.com/a/3649787

[컴] 공유캐쉬

shared cache /

예전에 잡다한 것들을 정리했던 empas 블로그가 있었는데, 이녀석이 자꾸 인수되면서 내 계정을 찾는 기간을 놓쳐 버렸다. ㅜ.ㅜ 현재 zum 에 있는데, 계정은 찾아줄 수 없고, 삭제는 가능하다고 한다. 그래서 조금씩 글들을 옮겨 놓으려 하고 있다.

작성일 : 2008-04-26

공유캐쉬

false sharing 에 관한 글(http://minjang.egloos.com/1094099)을 보다가 참조사이트를 따라 갔더니 multi-core system 에서 공유 캐쉬를 잘 활용하는 방법에 대한 글이였다. 그저 개인적인 호기심에 한 번 보기 시작하고 정리를 했더니 번역이 되어 버린 듯 하네.

내가 정리한 내용은 그다지 충실하지 않으니 관심이 있으시면 아래 링크를 가서 보는 것이 좋을 듯 하다.

software techniques for shared-cache multi-core system

Software Techniques for Shared-Cache Multi-Core Systems

프로그램적으로 multicore processor 를 잘 사용하는 법.

processor affinity

이것은 어떤 core에 어떤 thread 를 할당할 것인가에 관한 얘기다.

data의 공유없이 그저 각자의 일을 하는 thread들은 (contention-only threads) cache 를 share하지 않는 core에 넣어야 하고, 어떤 data를 공유하는 thread 들(data-sharing threads) 은 cache를 share 하는 곳에 넣어야 한다.

만약 정말 밀접하게 연관되어 있는 thread 들이라면(closely tied to each other) 같은 core 안에 놓는 것이 data를 공유할 때 cache miss 가 적게 발생해 훨씬 빠르다.

cache blocking technique. (data tiling)

하나의 data set 이 있고, 이것의 size가 cache 의 size 보다 크고 이 data set을 사용하는 loop 이 있다. 이 때 A라는 작업(operation)에서 data set 을 전부 한 번씩 처리하고 나서,
다시 처음부터 data set을 처음부터 건드리면서 B라는 작업을 한다면 계속해서 cache miss가 날 것이다. 이것을 줄이기 위해 일단 cache size 만큼 data를 불러서 A, B operation 을 끝내고, 그 다음 data를 불러서 다시 A, B operation 을 하는 방식을 하면 cache miss를 줄일 수 있다. 이것이 cache blocking technique의 한 방법이다.

예제 : ref. 1 의 example

Hold approach

이것은 shared L2 cache에서 shared data 를 L2 cache에 계속 업데이트 하는 것을 낭비라 생각하고 이를 필요할 때만 update를 하는 식으로 바꾸는 것을 말한다.

이것을 구현하는 방법중 하나는 modified data가 shared copy에 update가 될 때까지 tracking 을 위한 private data copy를 갖고 있는 것이다.

이것의 실질적인 사용은 OpenMP* reduction clause(http://blog.empas.com/i5on9i/25398368) 를 이용하는 것이다.

예제 : ref. 1 의 example

Delayed approach

만약 Thread 0 가 사용한 data를 Thread 1 에서 사용하는 routine을 가진 program이 있다고 하자.
Thread 0 은 core 0 에서 사용되고, Thread 1 은 core 1 에서 동작하고 있다.
그러면,

Thread 0 가 data를 memory에서 L1 cache로 받아와서 data를 수정한다.
Thread 0 가 일을 끝내고 나서 data를 건드려도 좋다고 Thread 1 한테 신호를 보낸 것이다.
Thread 1은 L2 cache를 뒤져볼 것이다. 근데 아직 data가 L1 cache에서 L2 cache로 안넘어갔다.
그러면 core 1에서는 cache miss 가 발생하고나서 data가 L2 cache 로 evicted 될 것이다.
Thread 1 이 L2 cache에서 data를 가져올 것이다.

이 과정에서 data가 L2 cache로 evicted 될 때까지 signal 을 보내는 것을 늦추는 것이다.

그러면 Thread 1 이 signal 을 받는 순간에 이미 data가 L2 cache로 넘어왔기 때문에
cache miss 가 아닌 cache hit가 될 것이다.

예제 : ref. 1 의 example

false sharing

이것은 cache-coherency protocol 로 인해 발생한다.

cache는 보통 block 단위로 data를 가져오는데 이것을 cache-line이라고 한다.

우연하게 이 block 에 thread 0 에서 쓰는 data도 있고, thread 1 에서 쓰는 data도 있다면
양쪽의 L1 cache 는 서로 같은 내용의 cache-line을 가지고 있다.
이 때 한쪽에서 data를 고치게 되면 cache-line 전체가 고쳐진것으로 인식하고,
다른 한 쪽의 cache-line이 이제 쓸모없음을 알려서 cache-coherency를 유지한다.

이런 cache-coherency 때문에 공유되지 않는 data지만 같은 block 안에 묶여서
계속 cache miss가 발생한다. 이것이 false sharing 이다. 보다 자세한 내용은 "art.oriented : 정답: 다음 코드의 문제점은 false sharing" 를 보자.

예제 : how to avoid false sharing

Trackback

CPU Shared Cache를 잘 사용하는 방법

Reference

software techniques for shared-cache multi-core system

[컴][자바] 소스 deobfuscating

난독화 / 역난독화 / reverse obfuscated code / dex decompiler / 안드로이드 코드 난독화

DeObfuscating

요새 안드로이드 project 가 gradle 로 넘어간 덕분인지, obfuscate 한 code 들이 많이 보인다. 이런 code 들은 아무래도 분석하기가 어려워 진다.
이런 녀석들에 대해 deobfuscating tool 들이 존재한다. 물론 이 녀석들이 정확히 obfuscated 이름을 원래대로 돌려주지는 못하지만, 아주 좋은 hint 를 주고 JDO 같은 경우는 원하는 이름으로 변화해 준다.

JDO

가장 대표적인 tool 로 JDO 가 있다. 간단하고, class 이름을 원하는 이름으로 바꿀 수 있는 기능을 제공한다. gui 가 그리 화려하지는 않지만 가장 필요한 기능을 가지고 있는 듯 하다.

그냥 모든 class 를 load 해서 Deobfuscate 버튼을 누르면, a, b 등으로 되어 있는 녀석 앞에 prefix 로 class, var 등을 붙여준다.

Decompiler

이제 deobfuscated 된 class 를 가지고 기존의 decompiler 를 이용하면 된다. 개인적으로 jd-gui 를 많이 활용했는데, 더이상 update 가 안되는 느낌이었고, 간혹 decompile 이 안되는 녀석들이 있었는데, stackoverflow 에서 아래 decompiler 를 새로 찾았다.

mstrobel / Procyon / wiki / Java Decompiler — Bitbucket

위의 site 에서 procyon 을 사용하는 gui 몇개를 소개해 주고 있다. 대체로 나쁘지 않지만, 개인적으로 jd-gui 가 제일 편한 느낌이다.

deathmarine/Luyten · GitHub : 간단하지만 viewer 수준이라 크게 많은 기능을 가지고 있지 않다. gui 는 jd-gui 와 제일 닮았다.
Java Decompiler - The Free Java Decompiler for Everyone : navigation 이 좋다. jd-gui 와 비슷한 느낌이다.
Konloch/bytecode-viewer · GitHub : 개인적으로는 제일 괜찮다. bytecode 도 같이 보여주며, 조금 번거롭긴 하지만, navigation 하는 것도 큰 무리는 없다.

개인적인 의견

JDO 를 사용하고, 그것을 jd-gui 로 열어서 보는 등의 방법을 사용하면 될 듯 하다.

추가로, jd-gui 에서 src 를 저장할 수 있게 해주는데, 이녀석을 저장해서 IDE 에서 열어서 봐도 좋을 듯 하다.

리눅스 소스 검색

리눅스 코드를 인터넷에서 뒤져볼려고 찾다보니, 아주 좋은 방법을 소개해준 post 가 있었다.

Searching the Linux Source Tree in 0.5 Seconds

local 에서 search 하는 법에서 부터 github 에 이르기 까지 다양한 방법을 이야기 해 준다.

github

개인적으로 web 에서 보고 싶어 하기 때문에 github 에서 해주는 것이 마음에 든다. github 를 들락날락하면서도 linux source 가 여기에 있는지는 처음알았다. ^^;;;

torvalds/linux · GitHub

LXR

개인적으로 LXR 로 된 녀석을 좋아하는데, 아래 사이트에서 찾을 수 있다.

http://lxr.free-electrons.com/source

상단 오른쪽에 잘 보면 검색 메뉴도 있다.

안드로이드 소스 검색

LXR

http://androidxref.com/

[컴][해킹] 정찰, Reconnaissance

아래글은 ref.1 의 내용을 정리 한 것이다.

정찰(reconnaissance)

reconnaissance 는 최대한 많은 정보를 모으는 것이 목적이다. 공개된 정보의 빈틈없는 검색. 이렇게 얻은 정보를 잘 정리해서 공격가능한 IP 주소 리스트(a list of attackable IP addresses)를 만든다.

이런 정찰(reconnaissance) 의 종류는 2가지가 있다. 아래에서 확인하자.

Active reconnaissance : target 과 직접적으로 interacting 한다. 이때 target 은 우리의 ip 나 행동을 기록하게 된다.
Passive reconnaissance : web 에 있는 정보를 이용한다.

Active reconnaissance

대부분의 경우 가장 처음으로 해야할 일은 target 의 web site 가 어디에 위치해 있는지를 아는 것이다.

HTTrack : website copying tool, web site 를 copy 해서 off-liine 에서도 사용할 수 있도록 해주는 프로그램

웹사이트를 보면서 수집해야 할 항목

physical address and locations
phone numbers
email addresses
영업시간(hour or operation)
파트너쉽(business relationships)
employee names
social media connections
공개된 토막뉴스거리 : public tidbits
M&A 자료 : M&A 등으로 인해 기업의 내부사항이 공개된다.
open job posting : 기업에서 사용한 기술에 대한 자료를 찾아 볼 수 있다.

target의 website 를 테스트하면서 우리는

target 이 누구고,
그들이 무슨 일을 하고,
어디에 위치했는지

에 대한 깊은 이해를 할 수 있어야 한다.

Passive reconnaissance

검색엔진

web 을 검색해서 정보를 얻어내는 작업이다. 이 작업에 가장 적합한 도구가 google 이다. 그러므로 google 을 잘 다루는 것이 효과적인 passive reconnaissance 를 하는 방법이다. 아래 페이지가 도움이 될 것이다.

Google Search Operators - Google Guide

그리고 다양한 search engine 을 활용하도록 하자. 각 검색엔진마다 결과가 다르기 때문에 여러 검색엔진을 사용하는 것이 좀 더 빈틈없는 검색을 하는데에 도움이 된다.

게시판

UseGroup 이나 게시판등을 뒤져보자. 이곳에서도 개발자들이 문의를 위해서 자세한 글들을 올려놓는다.

specific software version
hardware models
current confiuration information
and the like about internal systems

SNS

회사 직원의 posting 에서 나오는 기술적인 이야기들에서 정보를 얻을 수도 있다.

Reference

The Basics of Hacking and Penetration Testing

[컴][해킹] 해킹에 대한 간략한 이해

Penetration Test

우리가 흔히 생각하는 hacking 이랑 같은 개념이라고 보면 된다. 하지만 조금 다른 것은 요새 우리가 착한 해커들을 "화이트 해커" 라고 부르는데 그 "화이트 해커"랑 같은 개념위에 있는 것이라고 보면 된다.

쉽게 얘기하면 해커가 하는 행동을 "hacking" 이라고 한다면, 화이트 해커가 하는 행위를 "Penetration Test" 라고 할 수 있겠다. 이밖에도 white hacking 등 여러가지 이야기로 불려 진다. 여기서는 이해하기 쉽게 penetration test 도 hacking 이라고 부르도록 하겠다.

자세한 이야기는 아래 글을 참고하자.

The Basics of Hacking and Penetration Testing > setting the stage

Penetration Testing 에 필요한 유용한 tools

Kali Linux : 예전에 Backtrack Linux 라고 불렸던 녀석이다. penetration testing 에 필요한 tool들이 설치된 상태로 배포된다고 한다.

VMware 에 Kali Linux 설치

Complete Guide On How To Install Kali Linux In VMware, Lewis Encarnacion
한글설치 : 처음에 영어로 설치하고 나서 한글을 설치하자. 한글을 택하면 기본적으로 한글 폰트가 나오지 않아서 글자를 볼 수 없다.

repository 설정 : install 시에 mirror-site 사용을 no 로 하면, repository 설정 관련해서는 아래 link 를 참고하자.

칼리리눅스 Repository

Kali Linux setting

network 활성화 하기

eth0 를 활성화(activate) 하기

ifconfig eth0 up

DHCP 를 사용하는 경우

dhclient eth0

poweroff 나 reboot command 로 linux 를 종료하게 되면 자동으로 설정이 기억된다.

Hacking lab

hacking 연습실 정도로 보면 된다. hacking 을 공개적으로 할 수 없다. 잘못하다가는 잡혀간다. 그래서 이런 hacking 기술을 연습할 곳이 필요하다.

네트워크 고립(isolation of the network)

실수로(ip 를 잘못 치는 등의) 외부로 hacking 하라는 명령어가 전달되면 큰일난다. vm 같은 것을 이용해서 공격할 대상을 하나 만들고, 내 자신의 computer 를 internet 에서 끊는 것 만으로 간단하게 만들 수 있다.

VM

vm 을 만들때 원하는 설정을 모두 하고난 후에 복사본을 만들어 놓자. 왜냐하면 hacking 을 하고나서 시스템이 망가지는 경우가 있을 때 빠르게 복구 시킬 수 있기 때문이다.

Hacking 절차

정보수집(reconnaissance / information gathering)
스캔(scanning)

port scanning
vulnerability scanning

exploitation : 이 exploitation 의 최종 목적은 관리자 권한의 획득이다.(administrative access) exploitation 를 위해서는 scanning 을 통해 아래사항등을 파악해야 한다.

어느 port 가 열려있는지,
열려진 port 에서 구동되는 service 는 무엇인지,
그 service 들과 관련된 취약점은 무엇인지

maintaining Access : 지속적으로 이 시스템에 침투하기 위해서는 backdoor 를 열어놔야 한다. admin 권한을 가지고 backdoor program 이 언제나 살아있도록 해야 한다.(심지어 reboot 을 한다고 해도.)
정보지우기(hiding/removing evidence)

References

The Basics of Hacking and Penetration Testing, 2011-08

[컴] BIOS 동작

인터럽트 / interrupt / boot sequence / booting / 부팅 과정 / bootstrap program

updated

아마 아래와 같은 해킹을 막기 위해 Microsoft 에서 Secure Boot policy 같은 것들을 이용한 듯 하다. 그런데 이 policy 말고, debug policy 가 있었는데, 이녀석이 유출됐다고 한다. 그것도 MS 가 실수로 같이 배포한 듯 하다. 여하튼 그래서 Secure Boot policy 를 없애고, 새로운 policy 를 깔아서 windows 이외의 os 를 loading 할 수 있는 여건이 됐다고 하는 듯 하다. 자세한 것은 아래 글을 참고하자.

Bungling Microsoft singlehandedly proves that golden backdoor keys are a terrible idea • The Register

--------------------

우리가 잘 알고 있는 러시아 보안회사 카스퍼스키랩이 2월 16일에 Equation group 이라는 해커단체의 방법을 분석해서 뿌렸다. 아래 블로그에 그 내용이 간략하게 나와있다.

국제 해커 단체 19년 만에 덜미…NSA 연관설도

그래서 어떻게 HDD 의 firmware 를 호출하게 되는지 궁금해 져서 찾다가 결국 BIOS 까지 왔다. 예전에 boot loader 을 올리는 짓(?)을 해본 기억은 있는데, 역시나 오래된 일이라 잘 기억도 나지 않고, 적어놓은 얘기도 없어서 다시 적는다. 자세한 내용은 ref. 1 을 보도록 하자. 여기글은 ref.1 을 보고 필자가 이해하기 좋게 편집했다. 참고로 ref.1 의 내용은 2003년에 작성된 글이니 현재의 시스템과 조금 차이가 있을 수도 있음을 고려하자.

일단 그전에 HDD의 firmware 는 아마도 BIOS 가 실행될 때 사용할 수 있는 상태가 돼야 할 듯 하다.

pc 에 전원을 넣은 후 os 의 kernel 이 load 되기 까지

pc 에 전원을 넣게 되면, BIOS 가 실행된다.(BIOS 가 실행되는 routine 은 정확히 모른다.) 이 BIOS 가 실행되면 PC 의 장치들을 구동할 수 있는지에 대한 간단한 test 를 하게 되고(POST, Power-On Self Test) 이 test 가 완료된 후 setup menu 로 들어갈 수 있는 기회가 잠깐 생긴다(흔히, 컴퓨터 첫화면서 <f2> 나 <del> 키등을 누르고 들어갈 수 있다. 이 때가 이미 POST 가 끝난 상태라고 보면 되겠다.)

BIOS 가 초기화되고 나서 다른 하드웨어가 초기화 된다. 그리고 그 하드웨어들의 firmware 가 메모리로 load 된다.

이제 BIOS 는 setup 에 정해진 boot sequence 에 맞게 device(usb, hdd, ssd 등) 에 접근하게 된다. 처음에 접근한 device 의 첫 sector 를 접근해서 RAM 의 주소 0x0000~0x7C00 으로 가져오고 PC(program counter) 를 0x0000 으로 변경하게 된다.

이 때 device 의 첫 sector 가 우리가 아는 MBR 이 되고, 이렇게 가져온 프로그램이 boot sector program(boot loader) 이 된다. 참고로 각 partition 의 첫 sector 를 boot sector라 부르기 때문에 위에서 프로그램을 boot sector program 이라 칭한다.

boot sector 를 load 한 것이 BIOS 의 마지막 일이라고 보면 된다. boot sector program이 하게 된다.

보통 os 가 한개만 깔린 상태라면 boot sector program(boot loader) 이 kernel 을 바로 메모리로 load 하거나 second stage boot loader 를 먼저 memory 로 load 한 후에 second stage boot loader 가 kernel 을 load 하게 된다.

여기서 의문점이 생기게 된다. 어떻게 boot sector program 이 kernel 이나 second stage boot loader 가 disk 의 어느위치에 있는지 알수 있을까?

이것은 우리가 boot sector program(boot loader) 을 MBR 에 write 할 때 정해진다. 보통 booting 이 가능한 device 를 만들기 위해 우리가 MBR 에 작업을 하게 되는데, 이 때 이런 작업을 해주는 프로그램들을 이용한다. (MBRwiz 같은...)

이런 녀석들이 boot loader installer 라고 보면 되는데, 이 boot loader가 MBR 에 second stage boot loader 의 위치를 알려주거나(보통 segment 번호로 알려준다고 한다.) kernel 의 위치등을 알려주게 된다.(자세한 것은 아래를 참고하자.)

UEFI(UnifiedExtensibleFirmwareInterface)

UEFI 는 하나의 완전한 boot manager 를 갖고 있고, 그래서 여러 stage 를 갖는 BIOS boot process 보다 빠르다.

--------------------------------

아래의 대부분의 내용은 ref. 1 의 내용을 번역한 것이다.

BIOS

BIOS 는 PC 메인보드의 ROM 에 들어 있는 firmware 이다.(요새 android 를 자꾸 보다보니 ROM 의 의미가 헷갈렸는데, 혹시 나같은 사람이 있을 듯 해서 자세하게 말하자면, 여기서는 Read Only Memory 를 뜻하는 보드에 붙어있는 하드웨어 ROM 을 이야기한다.)

우리가 PC 를 켜면 가장먼저 실행되는 녀석이다. 많이들 봤겠지만, <F2> 나 <del> 키를 눌러서 bios 의 setup menu 로 들어갈 수 있는 것도 BIOS 가 실행된 상태이기 때문이다.
BIOS 는 4가지부분으로 되어 있다.

POST(Power On Self Test) : 우리가 pc 를 켰을 때 나오는 memory 가 몇 byte 인지 보여주는 화면등이 이런 전원을 켤때 자기 점검(POST) 하는 것 중에 하나다.
Setup Menu : 여기서 boot sequence 등을 정할 수 있다.
boot sector loader
BIOS interrupts : 프로그램들이 화면, 키보드, disk 에 접근하기 위한 간단한 device driver 들이다. 대부분 os 들은 이용하지 않는다.

BIOS는 다른 ROM (이 ROM 을 extension ROM 이라 한다.)을 실행시킬 수 있다. 이런 extension ROM 은 VGA card, SCSI host adapter, Ethernet card 등에 있을 수 있다.

이런 확장 ROM 을 이용한 예가, 우리가 알고 있는 "네트워크로 부팅하기" 이다. 이 기능을 위해 Ethernet card 에 EPROM 을 추가하고, 이 EPROM 을 BIOS 가 실행하게 해서 hdd 에서 가져오던 data 대신에 network 로 부터 필요한 data 를 가지고 와서 부팅을 시킬 수 있는 것이다.

load the Boot sector to RAM

PC BIOS 가 다른 computer system 들에 비해서는 비교적 원시적인 녀석이라고 한다. 여하튼 그래서 PC BIOS 는 disk 에 대해서 가능한 것이라고는 "첫 512-byte 섹터" 를 메모리(RAM) load 하는 방법뿐이다.

디스켓의 첫 섹터(흔히 MBR 이라 부르는 부분)는 RAM 의 주소 0x0000 ~ 주소 0x7C00 에 load 된다. 이 디스켓의 첫 섹터의 마지막 2 byte 는 0x55 와 0xAA 여야 한다. BIOS 는 마지막 2byte 의 값으로 sanity check 를 하는데 이 마지막 2 byte 가 0x55 와 0xAA이면 된다. sanity check 를 통과하면 BIOS 는 RAM 의 주소 0x0000~0x7C00 으로 jump 한다.
CD-ROM 부팅에선 좀 다르게 동작하는데, CD-ROM 부팅에선 CD-ROM 의 특정 파일을 diskette image 로 생각해서 다루게 된다. 그러면 이 diskette image 의 첫 sector 를 RAM 의 0x0000~0x7C00 으로 load 하고 BIOS 가 이 주소로 jump 하게 된다.

real mode

여하튼 이렇게 boot sector 가 RAM 에 load 되고 나면, CPU 는 real mode 에 있게 된다. real mode 는 x86 architecture 에 있는데, 32-bit protected mode 보다 좀 더 제한된 mode 이다. (참고 : [컴][디버그] INT 3 의 동작분석)

예를 들면, 이 real mode 에서는 64k segment 밖의 data 는 segment register 를 바꿔야만 접근이 가능하고, 주소공간(address space)의 첫 1MB 의 밖에 있는 data 는 전혀 접근이 불가능하다.

gcc 같은 compiler 는 이 real mode 에 대해 모르기 때문에 대부분의 boot loader 들(GRUB 을 제외한)이 assembly 로 짜여져 있다. boot sector 에 들어있는 program 들은 전부 assembly 로 되어 있다.

BIOS interrupts

BIOS interrupts 는 INT instruction 을 통해 호출할 수 있는 sub routine 인데 boot loader 가 이 녀석을 사용할 수 있다.(참고 : [컴][디버그] INT 3 의 동작분석) 이 BIOS interrupts 들은 real mode 에서만 동작한다. 대부분의 boot loader 에서는 아래 routine 들이 사용된다.

INT 0x10 : 화면 output
INT 0x16 : 키보드 input
INT 0x13 : disk I/O
INT 0x15 : 모든 BIOS 함수들을 위한 잡동사니통(catch-all)

boot sector program

boot sector program 이 BIOS 의 boot loader 에 의해서 RAM 의 0x0000 ~ 0x7C00 부분으로 load 가 되면 BIOS 는 이 boot sector program 을 실행하게 된다. 이 때 여기서 boot sector program 이 second stage boot loader 를 호출하게 된다.

boot sector program 은 이론상 최대 512 byte 가 되지만, 실제로는 불가능하다. 일단 마지막 2byte 가 sanity check 용으로 사용되고, boot sector program 이 저장되는 MBR은 partition table 도 가지고 있는데, 이 partition table 이 64 bytes 가 된다. 그래서 실제로 사용가능한 용량은 446 bytes 이다.

이렇게 용량이 적은 관계로 우리가 생각하는 boot loader 의 기능들을 이 boot sector program 에서 전부 구현할 수 없다. 그래서 대체로 이 프로그램은 아래 일들을 한다.

다른 boot sector 를 load 한다. : 하드디스크의 MBR 에 있는 프로그램이 대부분 이런 일을 한다. 선택된 active partition 의 첫 sector(boot sector) 를 찾고 그것을 chain load(아래 참고) 한다.
MBR 프로그램은 boot time 에 active partition 을 바꾸는 일은 할 수 없다. 그래서 LILO 의 MBR program 같은 경우는 유저가 partition 을 선택하는 메뉴를 보여준다.
second stage boot loader 를 load 한다.
boot sector program 으로는 특정 이름의 file 에 접근하기 위해 directory 를 들여다 보고 그것을 memory 로 load 하는 등의 행동을 할 수 없다.(단 예외는 있다. 적어도 DOS file system 들에서는 예외가 있다.)
대부분의 boot sector program 은 파일이름이 아니라 sector 번호로 second stage boot loader 를 찾는다. sector 번호는 boot loader installer 에 의해 boot sector 에 적히게 된다.(밑에 boot loader installer 참고.)
직접 kernel 을 load 한다.
보통 second stage boot loader 보다는 kernel 의 size 가 크다.

Linux kernel 에 있는 boot sector program 은 second stage boot loader 의 도움없이 kernel 을 memory 로 직접 load 한다. 커널이 디스켓에서 boot sector program 의 sector 의 다음 sector 에 존재한다면 굳이 file system 데이터 구조를 접근하지 않아도 된다. 그러나 bZimage 커널들을 위해서는 boot sector program 은 꼼수를 사용한다. 이 커널은 커널의 나머지 부분을 memory 로 load 하기 위해서 kernel 의 setup 부분에서 sub-routine 을 호출한다.

The boot loader e2boot fits into the first 1kB block of an ext2 partition (it is twice as big as a boot sector program), but with some tricks it finds both the kernel and the RAM disk by name on an ext2 partition and loads them into memory.

Also the boot sector on a DOS disk does not utilize a second stage boot loader to load the MS-DOS kernel files IO.SYS and MSDOS.SYS. The structure of an MSDOS file system is simple enough to find a file with a specific name in the root directory and load it into memory, at least part of it.

second stage boot loader

이녀석이 실제 boot 를 해주는 프로그램이다. 이 second stage boot loader(2차 부트로더) 는 아래 2가지를 가지고 있다.

UI : os 가 2개 이상 깔린 경우 선택하는 화면이 나오는데, 그 때의 화면이 이 second stage boot loader 가 보여주는 것이다. 그리고 윈도우의 경우에 비정상 종료가 된 경우에도 여러가지 선택옵션을 가진 선택화면을 보여주는데 이 화면도 이 second stage boot loader 에서 보여주는 것이라고 생각하면 되겠다.
kernel loader : os 를 memory 로 load 하고 그 os 를 실행하는 역할을 한다. 다른 os 와 관계된 boot loader 를 load 하고 그것을 실행할 수도 있다. 이렇게 다른 os 와 관계된 boot loader 를 load 하는 것을 chain loading 이라고 한다.

second stage boot loader 예

윈도우 비스타/7/8의 second stage boot loader :BOOTMGR 윈도우 XP : NTLDR 2차 부트로더는 파일의 형식으로 부팅 파티션의 루트경로에 존재합니다.
이녀석의 size 는 크게 상관없다. LILO 는 6.6KB 이고, GRUB 은 100KB 이다.

boot loader installer

이녀석은 말 그대로 boot loader 설치 프로그램이다. 이 녀석을 실행하면 MBR 에 boot sector program 을 copy 해 넣고, boot sector program 에 boot sector program 이 호출할 second stage boot loader 의 정보를 써주게 된다. 그리고 second stage boot loader에는 second stage boot loader 가 필요한 커널의 위치등도 적어준다.

References

How Boot Loaders Work
디지누리 - [만능 USB를 만들어 보자!] 2편 - 부트로더란?
멀티부팅시 부트로더 설치에 대한 이해..
Diving into Secure Boot – Dubai Security Blog
Operating System Concepts 10th edition

[컴][네트워크] hostname restrictions

dns record 이름 / reg / 제한 / dns 이름 문법 / dns 이름 제한 / dns 이름에서 사용하지 말아야 할 문자 / cname restriction / cname rule / dns record rules

Hostname 과 관련해서 naming rule 에 대한 자료

Restrictions on valid host names, Wikipedia

출처 : RFC952 : http://tools.ietf.org/html/rfc952

ASSUMPTIONS

   1. A "name" (Net, Host, Gateway, or Domain name) is a text string up
   to 24 characters drawn from the alphabet (A-Z), digits (0-9), minus
   sign (-), and period (.).  Note that periods are only allowed when
   they serve to delimit components of "domain style names". (See
   RFC-921, "Domain Name System Implementation Schedule", for
   background).  No blank or space characters are permitted as part of a
   name. No distinction is made between upper and lower case.  The first
   character must be an alpha character.  The last character must not be
   a minus sign or period.  A host which serves as a GATEWAY should have
   "-GATEWAY" or "-GW" as part of its name.  Hosts which do not serve as
   Internet gateways should not use "-GATEWAY" and "-GW" as part of
   their names. A host which is a TAC should have "-TAC" as the last
   part of its host name, if it is a DoD host.  Single character names
   or nicknames are not allowed.

출처 : RFC1123 : http://tools.ietf.org/html/rfc1123#page-13

 2.1  Host Names and Numbers

      The syntax of a legal Internet host name was specified in RFC-952
      [DNS:4].  One aspect of host name syntax is hereby changed: the
      restriction on the first character is relaxed to allow either a
      letter or a digit.  Host software MUST support this more liberal
      syntax.

      Host software MUST handle host names of up to 63 characters and
      SHOULD handle host names of up to 255 characters.

      Whenever a user inputs the identity of an Internet host, it SHOULD
      be possible to enter either (1) a host domain name or (2) an IP
      address in dotted-decimal ("#.#.#.#") form.  The host SHOULD check
      the string syntactically for a dotted-decimal number before
      looking it up in the Domain Name System.

DNS 관련 name syntax

RFC 2181 - Clarifications to the DNS Specification > 11. Name syntax
RFC 1123 - Requirements for Internet Hosts - Application and Support > 6.1.3.5 Extensibility

여기보면 DNS 의 이름의 제한은 거의 없다. 길이제한정도인듯 하다. 그러나 각자 환경에 필요한 restriction 을 추가해서 사용한다고 한다. 그래서 Internet 에서는 위에 제시한 "Hostname 과 관련해서 naming rule 에 대한 자료" 를 사용하면 되는 듯 하다.

[컴][안드로이드] Android NDK FFmpeg 컴파일

Android NDK 설치

설치환경

os : ubuntu 64bit

ndk package

Android NDK | Android Developers

에서 download 하자.

android-ndk-r10d-linux-x86_64.bin 를 다운로드하고 설치하자. 대략 3.6GB 가 필요하다. 파일에 실행권한을 주고, 실행하면, 그 폴더 안에서 압축이 풀린다.
여기서는

/home/namh/android/ndk/android-ndk-r10d

에 설치되었다.

참고로, 현재(2015년 1월) 는 아래버전이 ndk 의 최신버전이다.

Android NDK, Revision 10d (December 2014)

ffmpeg 설치 및 빌드

FFmpeg

여기에 가서 FFmpeg 의 소스를 다운로드 하자. 그리고 ndk folder 안에 sources 에 소스를 풀어놓자.

/home/namh/android/ndk/android-ndk-r10d/sources/ffmpeg-2.5.3

현재(2015-01-25) stable version 이 2.5.3 이다. 이것을 사용하자.

configure file

ffmpeg 의 configure file 을 열자. 경로는 아래와 같다.

d:\Program Files\Android\ndk\android-ndk-r10d\sources\ffmpeg-2.5.3\configure

그리고 아래 # 부분을 수정해 주자. 저부분이 compile 후에 나오는 .so 파일의 이름을 정해준다.[ref. 1]

# SLIBNAME_WITH_MAJOR='$(SLIBNAME).$(LIBMAJOR)'
# LIB_INSTALL_EXTRA_CMD='$$(RANLIB) "$(LIBDIR)/$(LIBNAME)"'
# SLIB_INSTALL_NAME='$(SLIBNAME_WITH_VERSION)'
# SLIB_INSTALL_LINKS='$(SLIBNAME_WITH_MAJOR) $(SLIBNAME)'
SLIBNAME_WITH_MAJOR='$(SLIBPREF)$(FULLNAME)-$(LIBMAJOR)$(SLIBSUF)'
LIB_INSTALL_EXTRA_CMD='$$(RANLIB) "$(LIBDIR)/$(LIBNAME)"'
SLIB_INSTALL_NAME='$(SLIBNAME_WITH_MAJOR)'
SLIB_INSTALL_LINKS='$(SLIBNAME)'

Build ffmpeg

ref. 1 에서 build_android.sh 를 가져오자.
그리고 거기서 아래처럼 NDK path 만 다시 설정해 주자.

NDK=$HOME/android/ndk/android-ndk-r10d
SYSROOT=$NDK/platforms/android-9/arch-arm/
TOOLCHAIN=$NDK/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64

그리고 configure file 이 있는 곳으로 가서 실행하자. 20분은 안걸린다.(vm 에서 cpu core 2 개, i3 2100 인 경우)

그러면 아래 경로에서 결과 file 을 찾을 수 있다.

$NDK/sources/ffmpeg-2.0.1/android

jni 빌드

ndk-build 를 위해 필요한 파일

Android.mk / Application.mk / jnitest.c
$NDK/sources/ffmpeg-2.5.3/android/arm/Android.mk

예제 소스는 아래 Example Source 를 참고하자.

$NDK/sources/ffmpeg-2.5.3/android/arm/Android.mk

$NDK/sources/ffmpeg-2.5.3/android/arm/Android.mk

를 추가한다. 참고로 LOCAL_SRC_FILES 의 이름은

$NDK/sources/ffmpeg-2.5.3/android/arm/lib

에 있는 .so 파일의 이름과 같아야 한다.

Android.mk

LOCAL_PATH:= $(call my-dir)
 
include $(CLEAR_VARS)
LOCAL_MODULE:= libavcodec
LOCAL_SRC_FILES:= lib/libavcodec-56.so
LOCAL_EXPORT_C_INCLUDES := $(LOCAL_PATH)/include
include $(PREBUILT_SHARED_LIBRARY)
 
include $(CLEAR_VARS)
LOCAL_MODULE:= libavformat
LOCAL_SRC_FILES:= lib/libavformat-56.so
LOCAL_EXPORT_C_INCLUDES := $(LOCAL_PATH)/include
include $(PREBUILT_SHARED_LIBRARY)
 
include $(CLEAR_VARS)
LOCAL_MODULE:= libswscale
LOCAL_SRC_FILES:= lib/libswscale-3.so
LOCAL_EXPORT_C_INCLUDES := $(LOCAL_PATH)/include
include $(PREBUILT_SHARED_LIBRARY)
 
include $(CLEAR_VARS)
LOCAL_MODULE:= libavutil
LOCAL_SRC_FILES:= lib/libavutil-54.so
LOCAL_EXPORT_C_INCLUDES := $(LOCAL_PATH)/include
include $(PREBUILT_SHARED_LIBRARY)
 
include $(CLEAR_VARS)
LOCAL_MODULE:= libavfilter
LOCAL_SRC_FILES:= lib/libavfilter-5.so
LOCAL_EXPORT_C_INCLUDES := $(LOCAL_PATH)/include
include $(PREBUILT_SHARED_LIBRARY)
 
include $(CLEAR_VARS)
LOCAL_MODULE:= libwsresample
LOCAL_SRC_FILES:= lib/libswresample-1.so
LOCAL_EXPORT_C_INCLUDES := $(LOCAL_PATH)/include
include $(PREBUILT_SHARED_LIBRARY)

이렇게 하고, jni 라는 이름의 folder 를 하나 만들고,
.c file + Android.mk + Applicaiton.mk 파일들을 만들어 그 안에 놓자.

Android.mk

LOCAL_PATH := $(call my-dir)

include $(CLEAR_VARS)

LOCAL_MODULE    := tutorial01
LOCAL_SRC_FILES := tutorial01.c
LOCAL_LDLIBS := -llog -ljnigraphics -lz 
LOCAL_SHARED_LIBRARIES := libavformat libavcodec libswscale libavutil

include $(BUILD_SHARED_LIBRARY)
$(call import-module,ffmpeg-2.5.3/android/arm)

Application.mk

APP_ABI := armeabi
#APP_ABI := armeabi-v7a
APP_PLATFORM := android-10

이제 ndk-build 를 실행하면, .c file 이 compile 된다. 그리고 필요한 lib 들이 copy 된다.

여기서 ./libs 와 ./jni 부분을 android project 로 가져오면 된다.

Example source

https://github.com/roman10/android-ffmpeg-tutorial

windows + cygwin

아래 page 에서 windows 에서 cygwin 을 사용해서 compile 하는 방법이 나와있다.

Android NDK FFmpeg 컴파일 강좌 (1/4) 남은그루터기, 2011.07.10 08:12:05
Android NDK FFmpeg 컴파일 강좌 (2/4) 남은그루터기, 2011.07.10 18:51:03
Android NDK FFmpeg 컴파일 강좌 (3/4) 남은그루터기, 2011.07.11 05:02:12
Android NDK FFmpeg 컴파일 강좌 (4/4) 남은그루터기, 2011.07.11 05:20:38

References

How to Build ffmpeg with NDK r9 | roman10

[컴] Windows 에서 BIND 설치

Windows 에서 BIND 설치

download 및 설치
<BIND_path>\bin> rndc-confgen -a
rndc-confgen > ..\etc\rndc.conf
named.conf
..\bin> named-checkconf.exe ..\etc\named.conf
ftp://ftp.rs.internic.net/domain 에서 named.root download 하기
named.root 의 이름을 named.ca 로 변경
localhost.zone 파일 생성
<BIND_path>\bin>named-checkzone.exe localhost ..\etc\localhost.zone
named.local 파일 생성
named-checkzone.exe named.local ..\etc\named.local
example.com.zone 파일 생성
<BIND_path>\bin>named-checkzone.exe example.com example.com.zone

원래는 rndc-confgen > ..\etc\rndc.conf 를 해서 conf 를 만들고, 여기서 key 부분만 copy 해서 rndc.key 를 만들면 된다.
여기선 key format 을 좀 더 명확히 보여주기 위해서 이런 방법을 택한 듯 하다.
여하튼 결과적으로 .conf 와 .key 의 key 값이 일치하면 된다.

named.conf

options {
  directory "c:\Program Files (x86)\ISC BIND 9\etc";  // NS Zone file path  
};

controls{
  inet 127.0.0.1 allow{localhost;}keys{rndc-key;};
}; // "named" deamon is controlled at the localhost with rndc-key

// required zone for recursive queries
zone "." {
  type hint;
  file "named.ca";
};  // root domain '.' is in the named.ca file, the path in options.directory is used 

// required local host domain
zone "localhost" in{
  type master;
  file "localhost.zone";
  allow-update{none;};
};

// localhost reverse map
zone "0.0.127.in-addr.arpa" in{
  type master;
  file "named.local";
  allow-update{none;};
};

include "c:\Program Files (x86)\ISC BIND 9\etc\rndc.key";

zone "example.com" in{
  type master;
  file "example.com.zone";
  allow-update{key "rndc-key";};
};

localhost.zone

$TTL 86400
@    IN    SOA    @    root (
     42         ; serial (d. adams)
     3H         ; refresh
     15M        ; retry
     1W         ; expiry
     1D )       ; minimum

     IN    NS     @
     IN    A      127.0.0.1

example.com.zone

$TTL 43200
@    IN    SOA    ns.example.com.    root.example.com. (
                        2007042710  ; 시리얼 값 (년월일시간)으로 대부분 셋팅
                        3H              ; 2차 네임서버가 1차 네임서버에 접속하는 시간
                        15M            ; 접속 실패 시 다시 시도할 시간 간격
                        1W              ; 1차 네임서버에서 데이터가 없다면 1주 이후에 지워진다.
                        1D )            ; 위에서 설정한 TTL 값과 같은 의미
;
; Name Server
      IN     NS      ns.example.com. ; 도메인을 소유한 DNS의 도메인
      IN     MX 10  mail.example.com. ; 메일을 보낼 도메인 또는 주소
      IN     A         211.207.71.151  ; 도메인이 찾아갈 IP 주소
;
; Host name
ns   IN    A         211.207.71.151  ;
;
; Virtual Host
www    IN    A   211.207.71.151  ; www.도메인이 찾아갈 IP주소
mail     IN    A   211.207.71.151  ; 메일서버 아이피
ftp        IN    A   211.207.71.151  ; FTP서버 아이피
*          IN    A   211.207.71.151  ; 모든 서브 도메인이 찾아갈 서버 ip 주소

References

Windows 에서 BIND 설치

[컴][브라우저] Where the Chrome desktop application is installed

크롬 데스크탑 앱이 설치되는 곳 / 크롬 데스크탑 설치 폴더 /

Let's check where these chrome desktop applications are located in my hard drive.
이 chrome 의 application 이 어느 디렉토리(folder) 에 저장되는지 살펴봤다.

Application name is replaced with some keys, which looks like hash key. These keys are used as an app-id.
어플리케이션의 이름 대신에 특별한 key 값을 app-id 로 사용하고 있다.

If you can see the shortcut of the chrome application, you can see this key is used as the app-id.
크롬 어플리케이션의 바로가기를 보면, 이 key 값이 app-id 로 사용되고 있는 것을 볼 수 있다.

Content Path
c:\Users\<user-name>\AppData\Local\Google\Chrome\User Data\Default\Extensions\

Application icon path
c:\Users\<user-name>\AppData\Local\Google\Chrome\User Data\Default\Web Applications\

at the shortcut
"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --profile-directory=Default --app-id=mjcnijlhddpbdemagnpefmlkjdagkogk

Shortcut for Chrome applications
"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --show-app-list

Screenshots

모듈 설치

flow.py 를 실행하기 위해서는 아래의 과정이 필요하다.

graphviz-2.32.msi 를 설치
pyparsing 1.5.7 설치
pydot 을 설치.

error : GraphViz\'s executables not found

'GraphViz\'s executables not found' 에러는 ref. 4 을 보면 해결 할 수 있다. pydot.py 에 path 가 다르게 설정돼서 그런 것이니, 그 부분만 맞춰주면 된다.

error : Couldn't import dot_parser, loading of dot files will not be possible

이것은 ref. 5 에 따르면 pyparsing 의 버전 문제라고 한다. 이전버전을 없애고 1.5.7 버전을 깔면 된다.

error : python 27 directory 를 못 찾는다.

windows 7 64 bit 에서

pyparsing-1.5.7.win32-py2.7.exe (md5)

를 실행시켰더니 python 2.7 directory 를 못 찾는다. 그래서 그냥 .zip 을 다운받아서

setup.py install

로 설치했다.

flow.py 실행

이제 flow. py 를 실행 해 보자.

d:\project\smali\android\annotation\SuppressLint.smali

에 있는 smali 파일을 이용한다고 하자.

c:\>flow.py -c "d:\project\smali\android\annotation\SuppressLint.smali"

이러면 class 를 분석한 _flow.png 그래프가 생성된다

References

Graphviz - Graph Visualization Software : http://www.graphviz.org/Download_windows.php
pydot download : https://code.google.com/p/pydot/downloads/list
pyparsing 1.5.7 download : https://pypi.python.org/pypi/pyparsing/1.5.7
pydot Issue 65: GraphViz's executables not found on Windows 7 64-bit
pydot and graphviz error: Couldn't import dot_parser, loading of dot files will not be possible

[컴][안드로이드] 안드로이드 분석에 도움되는 사이트들

유용한 사이트를 정리해 놓은 사이트가 있어 소개한다.

Android Security related tools : http://ashishb.net/security/android-security-related-tools/

Online Analyzers
Static Analysis Tools

Smali CFG generator : http://i5on9i.blogspot.kr/2013/09/smali-smali-flow.html

Dynamic Analysis Tools
Reverse Engineering
Misc Tools/Readings

위와 같이 다양한 분야의 유용한 사이트를 정리 해 놓았다.

LLVM 을 Windows Visual Studio Community 2015에서 build

LLVM 을 구성하는 3가지 project

소스 받기

Visual Studio 2015 실행

CMake 설치

CMake 실행

절차

LLVM.sln

Build

compile 시간

INSTALL

See Also

References

DB 의 field 값 암호화

키 관리 key management

symmetric / asymmetirc

key 관리 key management

hacker 가 가져가기 힘든 것

Hardware

login 정보

server 시작시 key 입력

다른 서버에 저장

같은 서버에 다른 곳에 저장

개인적은 결론

References

Shortcuts

여러 단어 한번에 선택하기, multi selection

한번에 여러 line 선택, vertial selection

메인 메뉴 숨기기

HTML5 Canvas fingerprinting

converse 를 이용해서 video 카드 특성을 알아보는 법

기타

Reference

Bitmap format

Bitmap data 분석시

Null-byte padding

Reference

Proof-of-work system

proof-of-work 에서 client

proof-of-work 의 server

protocol 종류

비트코인의 작업 증명

Reference

SSL 공격 과 관련된 자료

https 를 http로 연결해서 공격

password hash function

결론

안드로이드에서 PBKDF2 사용

Asymmetric < symmetric

공유캐쉬

Software Techniques for Shared-Cache Multi-Core Systems

processor affinity

cache blocking technique. (data tiling)

Hold approach

Delayed approach

false sharing

Trackback

Reference

DeObfuscating

JDO

Decompiler

개인적인 의견

See Also

리눅스 소스 검색

github

LXR

안드로이드 소스 검색

LXR

정찰(reconnaissance)

Active reconnaissance

Passive reconnaissance

검색엔진

게시판

SNS

Reference

Penetration Test

Penetration Testing 에 필요한 유용한 tools

VMware 에 Kali Linux 설치

Kali Linux setting

network 활성화 하기