2. 메인 메뉴에서Wipe선택 > 우측 하단의Format Data선택 >yes입력 후 키보드 우측 하단의체크 버튼선택
(무결성 검증 때문에 필수)
3. adb push /Magisk-v20.3.zip /sdcard 후 install 설치
4. 리커버리 및 Magisk 설치 후 기기 내 Magisk.apk 설치
- 참고
오딘으로 TWRP를 설치하고 부팅을 하면 순정리커버리로 복원됩니다. TWRP를 설치할때 오딘에서 Auto Reboot에 체크를 해제하라는게 이것때문이지요. 오딘에서 Auto Reboot에 체크를 해제해도 바로 부팅을 시켜버리면 순정리커버리로 복원되어버립니다. 오딘에서 TWRP를 올린후 바로 리커버리로 진입하세요. 잘못해서 부팅되버리면 도루묵입니다. 이게 어렵다 싶으시다면 CAF Auto Root로 루팅을 먼저 하신후 Flashify 앱으로 리커버리를 설치하는 방법도 있습니다.
mysql > SELECT id FROM test WHERE id='admin' limit 0,1 procedure analyse(extractvalue(1, concat(0x3a, (if(mid(version(),1,1) like 5, sleep(5),1))), 1);
CORS(Cross Origin Resource Sharing)는 브라우저가 XHR(XMLHttpRequest)을 이용해 Cross-Origin 요청이 가능하여, 서로 다른 도메인(사이트) 간 자원을 공유할 수 있게 해주며, 특정 조건들이 만족할 경우동일 출처 정책(SOP : Same Origin Policy)에 의한 제한을 완화하는 데 사용될 수 있습니다.
동일 출처 정책(SOP : Same Origin Policy)은 보안 상의 이유로, 브라우저들의 스크립트 내에서 초기화되는cross-origin HTTP요청을 제한하는 것으로 다른 웹페이지에서 접근할 때는 동일한 출처, 즉 프로토콜, 호스트명, 포트가 같은 웹페이지에만 접근이 가능합니다. 예를 들면, XMLHttpRequest는 동일 출처 정책을 따르기에, XMLHttpRequest을 사용하는 웹 애플리케이션은 자신과 동일한 도메인으로 HTTP 요청을 보내는 것만 가능합니다. 즉, 웹페이지의 스크립트는 그 페이지와 같은 서버에 있는 주소만 ajax 요청을 할 수 있습니다.
먼저Scheme은 http://나 https://나 ftp://와 같은 URI의 맨 앞에 붙는 문자열을 의미합니다.
이는 클라이언트에서 이를 처리하는 방식을 지정해줍니다. http가 붙으면 해당 프로토콜로 작동하는 것처럼요.
다음으로Host는 "www.tistory.com"이나 "www.google.com"과 같은 도메인을 의미합니다.
이 뒤에 붙는 /index.html과 같은 PATH는 Host에 포함되지 않습니다.
마지막으로Port는 말 그대로 포트입니다. 도메인은 IP와 대응되고, 이 뒤에 포트를 지정해 줄 수 있죠.
"www.tistory.com:8081"과 같이 도메인 뒤에 붙여 접속할 포트번호를 지정할 수 있습니다.
아래는 이와 관련된 예제입니다. 이를 보시면 쉽게 이해하실 수 있습니다.
기본 출처 : http://kookhh.ml (80포트)
1번 : http://kookhh.ml/some_dir/index.php -> O
2번 : https://kookhh.ml -> X (Scheme이 다름)
3번 : http://google.com -> X (Host가 다름)
4번 : http://kookhh.ml:4301 -> X (Port가 다름)
kookhh.ml에서 www.naver.com로 요청해도 응답 안줌!
CORS(Cross Orgin Resource Sharing) policy 때문에 XMLHttpRequest가 차단되었다는 메세지입니다.
API같은걸 만드는 개발자 입장에서는 이를 해결하기 위해서는 위의 에러 메세지에 적힌 것과 같이 Access-Control-Allow-Origin 헤더를 보내서, 접근을 허용하는 Origin을 정해주면 됩니다.
또는 JSONP를 이용하거나, 서브도메인 간의 접근을 위해서는 document.domain을 이용하는 방법도 있습니다.
그냥 요청만 보내는 것은 SOP에서 막지 않기 때문이에요, 게시글 수정, 삭제, 비밀번호 변경 등의 요청은 이 정책에 구애받지 않고 할수 있어요.
하지만 CSRF 토큰을 이용해서 막아뒀다거나, 다른사이트의 쿠키값같은걸 들고오고 싶다면(DOM에 접근하고 싶다면) 당연히 SOP를 우회해서 공격해야 합니다.
여기서 보통 일반적으로 생각할 수 있는 방법이 DNS Rebinding 공격입니다.
DNS Rebinding Attack 악의적인 사이트의 도메인에 할당된 IP를 잠재적인 희생자가 사이트에 들어와있는 동안 공격하고자 하는 사이트의 IP로 바꾸어 Same Origin Policy를 우회하는 방법
이 공격을 하기 위해서는 악의적인 DNS 서버를 하나 파서,
낮은 주기의 TTL로 A라는 도메인에 할당된 아이피가 a라는 IP와 b라는 IP 사이를 왔다갔다 해야합니다.
간단한 공격 순서도
위 사진이 공격 순서입니다.
먼저 희생자(Victim)이Domain A로 연결합니다. 브라우저는 이 Domain A의 IP를 얻기 위해 DNS 서버에 요청을 보냅니다.
그러면 악의적인 DNS 서버에서 이에 대한 IP가 111.111.111.111이라고 알려줍니다.
이 IP는 우리가 만든 악의적인 스크립트가 심어진 악의적인 페이지입니다.
여기서 잠시 뒤에 스크립트가 실행됩니다. 이 스크립트는Domain A로 요청을 보내고, 응답을 읽어들입니다.
하지만 Domain A에 대한 ttl이 낮아서, 다시한번 브라우저는 IP를 얻기 위해 DNS 서버에 요청을 보냅니다.
이번에는 악의적인 DNS 서버에서 이 도메인의 IP가 222.222.222.222라고 알려줍니다.
이제 브라우저가 스크립트를 실행시키는데,Domain A의 IP가 222.222.222.222로 바뀌었기 때문에 실제로 요청은 희생양이 될 사이트로 보내지게 됩니다.
브라우저 입장에서는 Domain은 A로 똑같기 때문에, Same Origin Policy에 위배되지 않는다고 생각하고 응답을 읽어들일 수 있도록 허용해줍니다. scheme이나 port는 당연히 똑같이 맞춰줘야겠죠.
이렇게 해서 희생자가 사이트에 들어가는 순간의 Domain A에 할당된 IP가 111.111.111.111,
악성 스크립트가 동작하는 순간의 Domain A의 IP가 222.222.222.222로 브라우저에게 인식된다면 공격 성공입니다.
DNS Rebinding Attack을 위한 DNS Server 소개 whonow, rbndr
이제 이걸 배웠으니 실습을 해보고 싶은데 dns 서버를 직접 파는것은 굉장히 귀찮은 일입니다.
그래서 이미 똑똑한 사람들이 이 공격을 쉽게 할 수 있도록 dns 서버를 만들어 놨습니다.
사용법도 굉장히 간단합니다.
먼저whonow입니다.
# respond to DNS queries for this domain with 34.192.228.43 the first time
# it is requested and then 192.168.1.1 every time after that
A.34.192.228.43.1time.192.168.1.1.forever.rebind.network
# respond first with 34.192.228.43, then 192.168.1.1 the next five times,
# and then start all over again (1, then 5, forever...)
A.34.192.228.43.1time.192.168.1.1.5times.repeat.rebind.network
LLVM 프로젝트는 모듈러와 재이용 가능한 컴파일러와 툴 체인 기술의 집합이다. 이 이름에도 불구하고 LLVM은 기존 VM과는 거의 관계가 없다. LLVM이라는 이름은 머리 글자를 딴 것이 아니라 프로젝트 이름이다.
LLVM은 모던하고 SSA 베이스한 임의의 프로그래밍 언어의 정적 컴파일과 동적 컴파일을 모두 지원할 수 있는 컴파일 전략을 제공하는 것을 목적으로 한 일리노이 대학의 연구 프로젝트에서 시작되었다. 그 뒤 LLVM은 몇 개의 서브 프로젝트로 구성되는 umbrella project로 성장했다. 대부분은 학술 연구는 물론 폭넓은 분야의 상업 용이나 오픈 소스 프로젝트에 의한 프로덕션에서 사용되고 있다. LLVM 프로젝트의 소스 코드는 “UIUC” BSD-Style 라이선스이다.
LLVM의 주요 서브 프로젝트
LLVM Core 라이브러리 source 나 target 이라는 독립한 현대적인 옵티마이저와 많은 일반적인 CPU(일반적이 아닌 것도 있다)의 코드 생성을 지원한다. 이들 라이브러리는 LLVM intermediate representation(LLVM IR)라고 알려진 잘 정의된 코드 표현을 중심으로 구성된다. LLVM Core 라이브러리는 잘 문서화되어 있으므로 당신 자신이 언어를 작성(또는 기존의 컴파일러를 가져와서), 옵티마이저, 코드 생성기로 LLVM을 사용하는 것은 특히 간단한다.
Clang LLVM 네이티브인 C/C++/Objective-C 컴파일러로 놀라울 만큼 빠른 컴파일을 제공하는 것을 목적으로 하고 있다.
LLDB project LLVM과 Clang에 의해서 제공된 라이브러리 상에서 네이티브한 디버거를 제공한다.
ibc++ and libc++ ABI projects C++ 표준 라이브러리의 표준 준수와 고성능한 구현을 제공한다.
compiler-rt project
OpenMP subproject
polly project
libclc project
klee project
SAFECode project
lld project
Features
LLVM Features
C와 C++ 컴파일러의 이야기.
Strengths of the LLVM System
LLVM은 심플한 저 수준 언어를 사용한다.
LLVM에는 C와 C++용 프론트엔드가 포함된다. Java, Scheme, 기타 언어 프론트엔드는 개발 중이다.
LLVM에는 굉장히 옵티마이저가 포함된다.
LLVM은 life-long compilation model을 지원한다.
LLVM은 accurate garbage collection을 완전 지원한다.
LLVM code generator 라는 것이 있다.
이후에는 기능적인 이야기가 없어서 생략.
프론트엔드가 각 프로그램 언어를 해석하는 부분, 중간에 있는 옵티마이저가 “LLVM Core 라이브러리”, 백엔드가 각 프로세서용 기계 코드를 출력하는 부분이다. “LLVM Core 라이브러리”의 설명에도 있었던 source와 target은 아마 이 프론트엔드와 백엔드로 말하는 것이다.
LLVM Audience
이 장은 LLVM이 누구 전용인지 쓰고 있다.
컴파일러 연구자
VM 연구자
아키텍처 연구자
보안 연구자
컴파일러의 프로토 타입에 관심이 있는 강사나 개발자
퍼포먼스를 추구하고 싶은 최종 사용자
질문답
Q1. LLVM은 컴파일러 기반라고 하는데 컴파일러 기반은 뭐죠? A1. 임의의 프로그래밍 언어에서 임의의 프로세서의 기계 코드로 컴파일할 수 있는 기반이라고 생각한다. LLVM을 이용함으로써 중간 언어의 최적화 처리와 다양한 아키텍쳐에 대응한 기계어 코드 생성 처리를 재활용 할 수 있는 것이 장점이 된다고 생각한다.
Q2. LLVM은 컴파일러 기반이며 VM이 없다고 하지만 LLVM에 포함되는 JIT 컴파일러는 VM과 다른가? A2. (이것은 LLVM의 설명에 쓰인 건 아니지만)VM은 프로세서를 에뮬레이트 하는 것에 대해서, JIT 컴파일러는 기계 언어로 컴파일하고 실행한다는 점이 다르지 않을까 생각한다. 예를 들어 JVM(Java 가상 머신)는 JIT 컴파일러를 이용하여 실행하고 있으면서 VM으로 불리니 LLVM도 JIT컴파일러 이면서 MV가 아니라는 표현이 꼭 올바르지는 않은듯.
