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

[컴][웹] firefox 에서 보안설정 간편하게 하기

firefox 보안 / 파폭 설치 후  / 파이어폭스

firefox 에서 보안설정 간편하게 하기

user.js 를 이용해서 설정을 간단하게 할 수 있다.

user.js

주의할 점은 user.js 에 설정된 값은 firefox 내에서 수정해도, firefox 를 껐다켜면 다시 값을 user.js 로 복구시킨다.
  • profile folder:
    • Windows: %APPDATA%\Mozilla\Firefox\Profiles\
    • Linux: /home/<USRNAME>/.mozilla/random.default.
    • Android: /data/data/org.mozilla.firefox/files/mozilla/xxxxxxxx.default/
  • profile folder 에 user.js 를 copy 해 놓으면 된다. 그러면 firefox 가 시작할 때 user.js 의 내용을 prefs.js 로 내용을 copy 한다.(참고: User.js file - MozillaZine Knowledge Base)
  • backup : 혹시 모르니 prefs.js 를 backup 해 놓자.
  • firefox 를 닫고 나서 작업을 하고 다시 켜자.(android 에서는 '강제종료'를 하고 하자.)

example

아래 예제는 ref.2 에서 가져와서, 몇개를 수정했다.
// Heimdallr -- Added -- Privacy Enhanced
// Disable Telemetry
user_pref("browser.urlbar.trimURLs","false");  
user_pref("browser.newtabpage.activity-stream.feeds.telemetry","false");
user_pref("browser.newtabpage.activity-stream.telemetry","false");
user_pref("browser.pingcentre.telemetry","false");
user_pref("devtools.onboarding.telemetry-logged","false");
user_pref("media.wmf.deblacklisting-for-telemetry-in-gpu-process","false");
user_pref("toolkit.telemetry.archive.enabled","false");
user_pref("toolkit.telemetry.bhrping.enabled","false");
user_pref("toolkit.telemetry.firstshutdownping.enabled","false");
user_pref("toolkit.telemetry.hybridcontent.enabled","false");
user_pref("toolkit.telemetry.newprofileping.enabled","false");
user_pref("toolkit.telemetry.unified","false");
user_pref("toolkit.telemetry.updateping.enabled","false");
user_pref("toolkit.telemetry.shutdownpingsender.enabled","false");

// Disable Plugin Scanning
user_pref("plugin.scan.plid.all","false");

// Disable Geolocation
user_pref("geo.enabled","false");

// Disable all disk caching PERIOD
user_pref("browser.cache.disk.enable","false");
user_pref("browser.cache.disk_cache_ssl","false");
user_pref("browser.cache.memory.enable","false");
user_pref("browser.cache.offline.enable","false");
user_pref("browser.cache.insecure.enable","false");

// Disable formfill
user_pref("browser.formfill.enable","false");

// Disable Zero Round Trip Time Resumption
user_pref("security.tls.enable_0rtt_data","false");

// Use only TLS 1.2 and 1.3
user_pref("security.tls.version.min","3");

// Disable Triple DES cipher
user_pref("security.ssl3.rsa_des_ede3_sha","false");

// Use strongest cipher
user_pref("security.ssl3.dhe_rsa_aes_128_sha", false);
user_pref("security.ssl3.ecdhe_ecdsa_aes_128_gcm_sha256", false);
user_pref("security.ssl3.ecdhe_ecdsa_aes_128_sha", false);
user_pref("security.ssl3.ecdhe_rsa_aes_128_gcm_sha256", false);
user_pref("security.ssl3.ecdhe_rsa_aes_128_sha", false);
user_pref("security.ssl3.rsa_aes_128_sha", false);

// Evade Finger printing
user_pref("privacy.resistfingerprinting","true");

// Disable the HORRIBLE webRTC
user_pref("media.peerconnection.enabled","false");

// Disable Prefetching
user_pref("network.dns.disablePrefetch","true");
user_pref("network.prefetch-next","false");

// Disable Referrer Headers (WHY is this is a thing)
user_pref("network.http.sendRefererHeader","0");

// Disable direct GPU access (WEBGL)
user_pref("webgl.disabled","true");

// Disable battery life check
user_pref("dom.battery.enabled","false");

// Disable session identifier
user_pref("security.ssl.disable_session_identifiers","true")

// Make requests only to site being visited
user_pref("privacy.firstparty.isolate","true")

// Disable auth fast starts 
user_pref("security.ssl.enable_false_start","false")

// Disable new tab privacy concerns
user_pref("accessibility.force_disabled", 1);
user_pref("browser.newtabpage.activity-stream.asrouter.userprefs.cfr.addons", false);
user_pref("browser.newtabpage.activity-stream.asrouter.userprefs.cfr.features", false);
user_pref("browser.newtabpage.activity-stream.feeds.section.highlights", false);
user_pref("browser.newtabpage.activity-stream.feeds.section.topstories", false);
user_pref("browser.newtabpage.activity-stream.feeds.section.topstories.rec.impressions", "{\"50465\":1576448311544,\"50504\":1576448311544,\"50513\":1576448311544}");
user_pref("browser.newtabpage.activity-stream.feeds.section.topstories.spoc.impressions", "{\"2323\":[1576448311615,1576448311641,1576448317243]}");
user_pref("browser.newtabpage.activity-stream.feeds.snippets", false);
user_pref("browser.newtabpage.activity-stream.feeds.telemetry", false);
user_pref("browser.newtabpage.activity-stream.feeds.topsites", false);
user_pref("browser.newtabpage.activity-stream.impressionId", "{bc349b2a-4696-4afa-bf4f-48d1fd919fe0}");
user_pref("browser.newtabpage.activity-stream.improvesearch.topSiteSearchShortcuts.havePinned", "google,amazon");
user_pref("browser.newtabpage.activity-stream.prerender", false);
user_pref("browser.newtabpage.activity-stream.section.highlights.includeBookmarks", false);
user_pref("browser.newtabpage.activity-stream.section.highlights.includeDownloads", false);
user_pref("browser.newtabpage.activity-stream.section.highlights.includePocket", false);
user_pref("browser.newtabpage.activity-stream.section.highlights.includeVisited", false);
user_pref("browser.newtabpage.activity-stream.showSearch", false);
user_pref("browser.newtabpage.activity-stream.showSponsored", false);
user_pref("browser.newtabpage.enabled", false);
user_pref("browser.newtabpage.storageVersion", 1);

// Disable spell check and enable clear on shutdown
user_pref("layout.spellcheckDefault", 0);
user_pref("network.cookie.cookieBehavior", 4);
user_pref("network.cookie.lifetimePolicy", 2);
user_pref("network.http.speculative-parallel-limit", 0);
user_pref("network.trr.mode", 2);
user_pref("pdfjs.enabledCache.state", true);
user_pref("pdfjs.migrationVersion", 2);

// Correct Permissions
user_pref("permissions.default.camera", 2);
user_pref("permissions.default.desktop-notification", 2);
user_pref("permissions.default.geo", 2);
user_pref("permissions.default.microphone", 2);

// Enable privacy sanitization and disable PDF full page
user_pref("plugin.disable_full_page_plugin_for_types", "application/pdf");
user_pref("pref.privacy.disable_button.cookie_exceptions", false);
user_pref("privacy.clearOnShutdown.downloads", true);
user_pref("privacy.clearOnShutdown.formdata", true);
user_pref("privacy.clearOnShutdown.history", true);
user_pref("privacy.clearOnShutdown.offlineApps", true);
user_pref("privacy.clearOnShutdown.sessions", true);
user_pref("privacy.clearOnShutdown.siteSettings", true);
user_pref("privacy.donottrackheader.enabled", true);
user_pref("privacy.history.custom", true);
user_pref("privacy.resistFingerprinting", true);
user_pref("privacy.sanitize.pending", "[]");
user_pref("privacy.sanitize.sanitizeOnShutdown", true);
user_pref("privacy.trackingprotection.cryptomining.enabled", true);
user_pref("privacy.trackingprotection.enabled", true);
user_pref("privacy.trackingprotection.fingerprinting.enabled", true);
user_pref("toolkit.telemetry.reportingpolicy.firstRun", false);
user_pref("trailhead.firstrun.didSeeAboutWelcome", true);

Reference

  1. Profiles - Where Firefox stores your bookmarks, passwords and other user data | Firefox Help
  2. Firefox Hardening Tips 2019 - Wikis & How-to Guides - Level1Techs Forums, 2019-01-18
  3. Guide: Hardening Mozilla Firefox For Privacy & Security 2016 | Cyber Security Wiki | Viking VPN Service

[컴][폰] tfp0 patch


tfp0 patch 가 뭐지? patch 

tfp0 patch

task_for_pid

XNU 커널에서 task_for_pid는 privileged process가 동일한 host에 있는 다른 process의 task port를 가져 오도록하는 기능.

  • 커널 task (프로세스 ID 0)는 가져올 수 없다.

tfp0 패치

tfp0 패치 (또는 task_for_pid (0) 패치)는 이 제한(kernel task 를 가져올 수 없는 제한)을 제거한다.

  • 그래서 "root로 실행중인 모든 실행 파일"이 pid 0 (따라서 이름)에 대해 task_for_pid를 호출 하고, vm_read 및 vm_write를 사용하여 커널 VM 영역을 수정하는 것이 가능해 진다.
  • AMFI(AppleMobileFileIntegrity - The iPhone Wiki)를 만족 시키려면 get-task-allow 자격과 task_for_pid-allow 자격(entitlement)이 필요.

Reference

[컴][네트워크] 라우팅 프로토콜

routing protocol / router / 라우팅 프로토콜  / 어떻게 패킷이 가는가 / 네트워크 알고리즘


라우팅 프로토콜

routing protocol은 3가지 형식으로 분류할 수 있다.
  1. routing table 을 누가 만드느냐에 따라 분류
  2. 내부 network에서 routing을 담당하느냐에 따른 분류
  3. routing table을 어떻게 만드느냐에 따른 분류

routing table 을 누가 만드느냐에 따라 분류

스태틱 라우팅 프로토콜(static routing protocol)

  • 사람이 직접 손으로 routing table(라우팅 테이블)을 만드는 것이다.
  • 경로에 문제가 발생하면, 다시 사람이 고쳐주지 않는 한 문제를 해결하지 못한다.

다이나믹 라우팅 프로토콜(dynamic routing protocol)

  • 라우터가 알아서 routing table을 만들어 준다.
  • 경로 이상 시 알아서 다른 경로를 설정할 수 있다.
  • 하지만 라우터의 부담이 가중된다.
  • RIP, IGRP, OSPF, EIGRP 등이 있다.

내부 network에서 routing 을 담당하느냐에 따라

  • IGP(Interior Gateway Protocol)
  • EGP(Exterior Gateway Protocol) 로 나눌 수 있다.
같은 관리자의 관리 하에 있는 라우터의 집합을 AS(Autonomous System)라고 하는데,
Autonomous System 내에서 사용되는 router 의 protocol 이 IGP이다. RIP, IGRP, EIGRP, OSPF 이 여기에 속한다.
그리고 AS와 다른 AS 사이에서 사용되는 router의 protocol이 EGP이다. BGP, EGP 이 여기에 속한다.


routing table을 어떻게 관리하는 가에 따라

  • 디스턴스 벡터 알고리즘(Distance Vector Algorithm)을 사용하는 프로토콜,
  • 링크 스테이트 알고리즘(Ling State Algorithm)을 사용하는 프로토콜
DVA 는 routing table 에 목적지까지 가는데 필요한 거리와 방향만을 기록. RIP와 IGRP가 대표적이다
LSA 는 라우터가 목적지까지 가는 경로를 SPF(Shortest-Path-First) 알고리즘이란 것을 통해 routing table에 기록. OSPF가 대표적이다.



[컴][자바] java 의 G1 collector

자바 / 가비지 컬렉터 /

G1 collector

  • server-style garbage collector
  • multi-processor machines 를 target 으로 한다.
  • 높은 처리량(througput)을 달성하면서 높은 확률로 garbage collection pause time 목표를 충족시키다.
  • Oracle JDK 7 update 4 부터 지원시작
  • 다음과 같은 어플리케이션을 위해 디자인 됐다.
    • CMS collector 와 같은 응용 프로그램 스레드와 동시에 작동 할 수는 application.
    • pause time 을 유발하는 긴 GC가 없이 여유 공간을 compact 하는 application
    • 더 예측 가능한 GC pause durations가 필요한 application
    • 많은 throughput performance 를 희생하고 싶지 않은 application.
    • 훨씬 더 큰 Java 힙이 필요하지 않는 application.
G1은 CMS (Concurrent Mark-Sweep Collector)의 장기 교체 계획이다. G1과 CMS를 비교해서, G1의 더 나은 점은
  • G1이 compacting collector
    • G1 은 충분히 압축한다
      • allocation을 위한 fine-grained free list 들의 사용을 완전하게 피하고, 대신에 region 들에 의존하기 위해서 --> 연속된 메모리로 옮겨놓는 것, 이로 인해 분산되어있는 것들에 대한 접근을위해 리스트를 traverse 해야 하지만, 한곳에 모아놓으면 traverse time 을 줄이는 것 같다.
      • 이는 collector의 일부를 상당히 단순화하고 잠재적 인 fragmentation 문제를 대부분 제거한다
  • 또한 G1은 CMS collector 보다 좀 더 예측 가능한 garbage collection pauses를 제공하며 사용자가 원하는 desired pause 목표를 지정할 수 있다.

G1 동작 overview

오래된 garbage collectors (직렬, 병렬, CMS)는 모두 heap을 fixed memory size의
  • young generation
  • old generation
  • permanent generation
의 세 섹션으로 구성한다.

모든 메모리 객체는 이 세 섹션 중 하나에 들어간다.

G1 수집기는 다른 접근 방식을 취한다.

heap은 equal-sized heap regions 의 집합으로 나뉜다. 각각의 region은 virtual memroy 의 연속된 범위이다.
heap  ---> heap region
      |
      +---> heap region
      |
      +---> heap region

특정 region 집합에는 이전 collector와 동일한 역할 (eden, survivor, old)이 할당되지만 정의된 fixed size 는 없다. 이것이 메모리 사용에 있어서 더 큰 유연성을 제공한다.


marking phase

garbage collections 을 수행 할 때 G1은 CMS collector(Concurrent Mark-Sweep Collector)와 유사한 방식으로 작동한다.

G1은 동시 전역 마킹 단계(concurrent global marking phase)를 수행하여 heap 전체에서 객체의 liveness 를 결정한다.

마크 단계가 완료되면 G1은 어느 region이 많이 비어 있는지 알게 된다. 이 region에서 먼저 collect하여 일반적으로 많은 양의 여유 공간을 생성한다. 이러한 garbage collection 방법이 Garbage-First 라고 불리는 이유이다.

reclaimable heap region

이름에서 알 수 있듯이 G1은 회수 가능한(reclaimable) object들, 즉 garbage로 가득 찬 heap region에 수집 및 압축 활동(collection and compaction activity)을 집중시킨다.

G1은 pause prediction model(정지 예측 모델)을 사용하여 user-defined pause time target(유저가 정의한 정지 시간 목표)를 충족시키고 지정된 pause time target를 기반해서 "수집 할 영역(region)의 수"를 선택합니다.

evacuation

G1 이 reclamation 을 할 만큼 오래(ripe)됐다고 판단한 region은 evacuation(방출) 을 사용하여 garbage collect 가 된다.

G1은 "힙의 하나 이상의 region"에서 "힙의 단일 region"으로 객체를 복사하고 프로세스에서 둘 영역 모두의 메모리를 압축하고 해제한다. --> 여러개로 흩어진 region 을 하나의 연속된 공간으로 모으고, 이것을 하나의 region 으로 처리한다?

이러한 evacuation은 multi processors 에서 병렬로 수행되어 pause times을 줄이고 처리량을 증가시킨다.

따라서 G1은 각각의 garbage collection에서 지속적으로 동작하여 단편화를 줄이고 user-defined pause times 내에서 작업한다.

이것은 이전의 두 가지 방법으로는 불가능하다. CMS (Concurrent Mark Sweep) garbage collector 는 압축(compact)을 수행하지 않는다. ParallelOld garbage collection은 전체 힙 압축(whole-heap compaction) 만 수행하므로 상당한 pause times이 발생한다.

G1은 real-time collector가 아니다. 즉, real-time os 처럼 time critical 하지 않다. 높은 확률로 pause time target를 충족하지만, 절대적으로 확신할 수 있는 것은 아니다.

이전 collection 의 데이터를 기반으로 G1은 사용자가 지정한 target time 내에 collect 할 수있는 "region의 수"를 추정한다.

따라서 collector 는 region을 수집하는 비용에 대해 reasonably accurate model(합리적으로 정확한 모델)을 갖고있고, 이 모델을 사용하여 pause time target 내에 어느 region 을 collect 할지 얼마나 많은 region 을 collect 할 지를 결정한다.

참고 : G1에는 concurrent (애플리케이션 스레드와 함께 실행 (예 : refinement, marking, cleanup))와 parallel (멀티 스레드, 예를 들어 세계 중지) 단계가 있다. full garbage collection은 여전히 ​​단일 스레드이지만, 잘 tuning 하면 애플리케이션이 full GC를 피할 수 있다.

G1 발자국

ParallelOldGC 또는 CMS collector에서 G1으로 마이그레이션하면 JVM 프로세스 크기더 커질 수 있다. 이것은 Remembered Sets 및 Collection Sets과 같은 "accounting" data structures 때문이다.

RSets

  • Remembered Sets(RSets)는 특정 region 에 대한 obejct referece 들을 추적한다.
  • heap에는 region 당 하나의 RSet이 있다.
  • RSet을 사용해서 region의 병렬 및 독립 collection이 가능하게 한다.
  • RSets의 전체 foot printing 영향은 5 % 미만이다.

CSets

  • Collection Sets(CSets) GC에서 collect 될 region 들의 집합.
  • CSet의 모든 라이브 데이터는 GC 중에 evacuated 된다.(copied / moved).
  • regions 의 집합은 Eden, survivor 및 / 또는 old generation 이 될 수 있다.
  • CSets는 JVM 크기에 1 % 미만의 영향을 미친다.

G1의 권장 사용 사례

G1의 첫 번째 초점은 limited GC latency time큰 heap이 필요한 애플리케이션을 실행하는 사용자에게 솔루션을 제공하는 것이다.

약 6GB 이상의 힙 크기와 0.5 초 미만의 안정적이고 예측 가능한 pause time 을 의미한다.

CMS 또는 ParallelOldGC garbage collector로 실행중인 응용 프로그램 중 G1로 전환하는 것이 좋은 경우(다음중 하나에 해당하면 G1 을 사용하는 것이 좋다.)
  • Full GC duration이 너무 길거나 너무 자주 일어난다.
  • object allocation rate 의 비율 또는 object promotion 비율이 크게 다르다.
  • 원하지 않는 긴 garbage collection 또는 compaction pauses (0.5-1 초 이상)
참고 :
  • CMS 또는 ParallelOldGC를 사용하고 있고 응용 프로그램에 garbage collection pauses가 길지 않으면 현재 collector를 유지하는 것이 좋다.
  • 최신 JDK를 사용해도 G1 collector 를 꼭 사용하지 않아도 된다.

See Also


  1. JEP 345: NUMA-Aware Memory Allocation for G1

Reference

  1. Getting Started with the G1 Garbage Collector

[컴][네트워크] DDos(distributed denial of service) 공격

DDOS attack / 디도스 / ddos / distributed denial of service

DDos(distributed denial of service) 공격

디도스 공격의 목적

  • 대상(온라인 리소스)을 느리게 만든다.
  • 대상을 응답이 없게 만든다.

3가지 유형의 디도스 공격

  1. 볼륨 기반 공격
    • 대량의 가짜 트래픽을 이용
    • 웹 사이트나 서버 등의 리소스의 용량을 초과한다.
    • 여기에는 ICMP, UDP, SPF(Spoofed-Packet Flood) 공격 등이 포함
    • 측정: 초당 비트 수(Bits Per Second, BPS)로 측정.
  2. 특정 layer 를 공격
    1. 프로토콜 또는 네트워크 layer 디도스 공격
      • 다수의 패킷을 표적화된 네트워크 인프라인프라 관리 툴로 전송
      • 공격 방법
        • SYN 플러드
        • 스머프 디도스 등
      • 측정: 초당 패킷 수(Packets Per Second, PPS)로 측정.
    2. 애플리케이션 layer 공격
      • 애플리케이션에 악의적인 요청을 무작위로 전송하여 수행.
      • 측정: 초당 요구 수(Requests Per Second, RPS)로 측정.

대규모 공격 예

  • 2016년 10월, 인터넷 인프라 서비스 제공 기업인 딘 DNS(현 오라클DYN)
    • DNS 쿼리를 수천만 개의 IP 주소로부터 받았다.
    • 이로 인해 시스템이 마비됐다.
    • 이 공격은 미라이 봇넷을 통해 수행됐다.
    • IP 카메라와 프린터를 포함하여 10만 개 이상의 IoT 기기를 감염시킨 것으로 보도
    • 최고조일 때 미라이는 40만 개의 봇에 달했다.
    • 아마존, 넷플릭스, 레딧, 스포티파이, 텀블러, 트위터 등의 서비스가 마비.
  • 2018년 초, 2월 28일, github
    • 초당 1.35TB의 트래픽
    • 기트허브는 간헐적으로 차단
    • 20분 만에 해당 공격을 물리쳤다.
    • 해당 공격에 사용된 기술에 관한 분석
      • MemCached 를 사용하는 서버를 이용.
      • 작은 get 으로 큰 사이즈의 response를 가져다 준다.
      • 요청자의 ip address 를 변경해서 요청하면, 특정 ip address 로 대량의 response 가 가게 된다.

봇넷을 활용한 공격

  • 깃허브 이후, 미국의 한 service provider 에 대한 미라이 봇 공격
    • MemCached 기반 공격
    • 초당 1.7TB 공격
    • 취약한 IoT 기기를 활용.
  • 아카마이, 클라우드플레어, 플래시포인트, 구글, 리스크IQ, 팀 사임루 내부의 보안팀들이 수행한 조사에서 유사한 규모의 와이어X라는 봇넷이 발견
    • 100개국에서 해킹된 10만 개의 안드로이드 기기로 구성
  • 토리
    • 일련의 IoT 기기를 장악할 수 있으며 미라이보다 더욱 일관되고 위험한 것으로 여겨지고 있다.
  • 데몬봇
    • 하둡 클러스터를 장악하여 더 큰 연산 능력을 얻는다.
  • 0x-booter 같은 새로운 디도스 실행 플랫폼의 등장
    • 미라이의 변종인 “부시도(Bushido) 악성코드”에 감염된 약 1만 6,000개의 IoT 기기를 이용

디도스 트렌드

  • 봇넷의 임대
    • 디도스 공격자는 봇넷에 의존
    • 이런 봇넷을 임대해서 사용
  • APDoS(Advanced Persistent Denial-of-Service)
    • 단일 공격 안에서 다수의 공격 벡터를 사용하는 APDoS(Advanced Persistent Denial-of-Service)
    • 포함하는 공격
      • 데이터베이스
      • 애플리케이션
      • 서버에 대한 직접적인 공격 등 애플리케이션 계층이 포함
  • ISP 와 클라우드를 타겟으로
    • 피해자를 직접 표적으로 삼지 않는 대신에 그들이 의존하는 ISP와 클라우드 제공자 등의 조직을 표적으로 삼는 경우가 많다.
    • 자사와 협업하는 여러 비즈니스 파트너, 벤더, 공급자에 대한 공격도 우려

github 의 ddos 공격 자료

References

  1. 디도스 공격은 어떻게 발전하고 있나 - CIO Korea

[컴][통신] windows 에서 특정 program 에 대한 방화벽 설정 방법

V3 Lite 를 설치 후 해야 할일 / 안랩 업데이트 / 통신 라이트 / v3 라이트 차단 / 방화벽 설정 방법 / 방화벽 command  / command line firewall netsh how to set advfirewall /




windows 에서 특정 program 에 대한 방화벽 설정 방법

ASDSvc 의 TCP 통신을 제한

V3 Lite - 나무위키의 이야기는 P2P 로 업데이트 하는 방식을 사용한다고 한다.

그래서 이부분을 조금 제한 하려 한다. 현재로서는 이렇게 했을 때 update 가 될지 안될지 확인을 해보지는 못했다.

대략적인 절차

  • 제어판 --> windows 방화벽 –> 고급설정 
  • --> 아웃바운드 규칙 
  • –> 새규칙 
  • –> 규칙종류, ‘프로그램’
  • –> %ProgramFiles%\AhnLab\V3Lite40\ASDSvc.exe
  • –> 연결차단

CLI command

위처럼 gui 를 통해서 해도 되고, 간단하게 아래 command 를 사용해도 된다. (관리자 권한의 cmd 를 열어야 한다.)

netsh advfirewall firewall add rule name="ASDSvc - my conf" dir=out action=block program="%ProgramFiles%\AhnLab\V3Lite40\ASDSvc.exe" enable=yes profile=ANY


ASDSvc 가 1755 port 도 계속 이용하는 듯 하다. 1755 는 MS-streaming 관련 port 라서 port 자체를 막는 것은 좋지 않아 보인다. 일단 위의 프로그램 관련 통신만 차단해도 ASDSvc 가 1755 에서 통신을 하지는 않는 듯 보인다.

See Also


  1. Port 1755 (tcp/udp) :: SpeedGuide

Reference


  1. How to use the "netsh advfirewall firewall" context instead of the "netsh firewall" context to control Windows Firewall behavior in Windows Server 2008 and in Windows Vista
  2. Netsh AdvFirewall Firewall Commands






[컴] windows cmd 에서 alias 설정

alias 설정 / 단축키 설정 / .bashrc 설정 / 자동으로 설정 / bash function /


windows cmd 에서 alias 설정

regedit 를 이용해서 아래 처럼 설정하면 된다.

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Command Processor]
"AutoRun"="%USERPROFILE%\\alias.cmd"


위 같이 설정하면, cmd 를 실행할 때마다. %USERPROFILE%\\alias.cmd 를 한번 실행해 주게 된다.

그리고 나서 %UserProfile% 에 alias.cmd 를 아래처럼 작성하면 된다.
@echo off

DOSKEY ls=dir /b
DOSKEY ac=c:\a\envs\$1\Scripts\activate.bat $*
$* : 나머지 모든 parameter


References

  1. alias - Aliases in Windows command prompt - Stack Overflow, 2019-09-30

[컴][웹] firefox 에서 banner_ 로 시작하는 class 이름

파이어폭스 / 광고 / 배너 / 배너이미지 / 광고 이미지 / 광고 차단 방법

Firefox 에서 banner_ class 사용시 주의사항

firefox 를 사용하는데, class name 을 banner_image 로 설정했다. 그랬더니 firefox 에서 보이지 않게 됐다. 그래서 다른 class name (banner 가 들어가지 않은) 으로 변경하였다.
  • 사용한 firefox version : 7.1.0 64 bit

See Also

[컴][웹] AWS 트래픽 줄이는 방법

aws 에서 비용 줄이는 방법 / aws traffic 감소 / 아마존 웹 서비스 트래픽 감소 / 트래픽 줄이는 방법 / 아마존 저렴하게 이용하는 방법 / 감소 방법 / 감소시키는 방법

AWS 트래픽 줄이는 방법

ref. 1 의 gameanaytics 라는 곳에서 자신들이 aws 의 traffic 을 줄인 방법을 소개했다. 여기서는 대략적인 내용만 적으려 한다. 자세한 이야기는 ref. 1을 읽어보도록 하자.
  1. http header 크기 줄이기

    // 줄이기전 header
    HTTP/1.1 200 OK
    Connection: Keep-Alive
    Content-Length: 15
    Content-Type: application/json
    accept-encoding: gzip
    Access-Control-Allow-Origin: *
    X-GA-Service: collect
    Access-Control-Allow-Methods: GET, POST, OPTIONS
    Access-Control-Allow-Headers: Authorization, X-Requested-With, Content-Type, Content-Encoding
    
    // 줄인 후 header
    HTTP/1.1 200 OK
    Connection: Keep-Alive
    Content-Length: 15
    Content-Type: application/json
    

  2. TLS handshake 횟수를 줄이기
    • TLS handshake 에서 가장 큰 크기는 certificate 의 trust chain 이었다.
    • 만약 client 가 2번째 service 에 접속하는 거면, server 에게 이전에 사용한 TLS session 을 요청한다.
    • 그래서 AWS Load balancer 에서 cache size 등을 조절해 보려했지만, 못찾았다.
    • 그래서 close connection 하는 시간을 10분으로 늘렸다.(기본 세팅은 60초)
  3. 인증서(certificate) 의 크기 줄이기
    • 인증서가 TLS handshake 할 때 certificate 교환을 하기에, certificate size 가 작아야 유리.
    • AWS 에서 무료로 제공하는 certificate 에는 trust chain 에는 intermediate certificate 이 3개나 있어서, size 가 더 컸다.
    • root certificate 만 있으면 되기에, Digicert 에서 따로 구매해서 사용했다.

References

  1. Three ways to reduce the costs of your HTTP(S) API on AWS - GameAnalytics, 2019-12-13

[컴][안드로이드] rootbeer 피하기

rootbeer / rootbeerfresh / root beer



Rootbeer 피하기

updated

이 방식으로는 어려운 듯 하다. 다만 여기 좋은 글이 있다.

Magisk Hide detection

Magisk Hide 에 대한 감지 방법(detection) 으로 32-digit Unix Domain Socket 을 이용한다.

Magisk Hide 가 기존의 32-digit UDS 를 랜덤한 32 character string 으로 변경하는데 그것을 이용해서 detection 을 한다.

자세한 내용은 아래를 참고하자

Magisk Hide detection 피하기

그래서 간단하게 /proc/net/unix 에 접근하지 못하게 막는다. 그외에 다양한 이야기들을 아래 링크에서 확인할 수 있다.
su -c chmod 440 /proc/net/unix


Busybox uninstaller




[컴][js] AdonisJS v3 ---> v4 에서 Encryption 문제

암호화 문제 / 마이그레이션 / encryption / simple encrypt /

Encryption (AdonisJS v3.x --> AdonisJS v4.x migration)

최신버전의 Adonis Encryption/index.js 에서 보면 아래처럼 Encryptor 를 호출할 때 object 를 parameter 로 보낸다.

하지만 옛버전의 Adonis Encryption/index.js 를 보면 그냥 string 을 parameter 로 넘긴다.

// latest version
// <root>\node_modules\@adonisjs\framework\src\Encryption\index.js
const Encryptor = require('simple-encryptor')
...
class Encryption {
  constructor (appKey, options) {
    /**
     * Throw exception when app key doesn't exists.
     */
    if (!appKey) {
      throw GE.RuntimeException.missingAppKey('Encryption')
    }
    this.appKey = appKey
    this.encryptor = Encryptor(Object.assign({ key: appKey }, options))
  }
  ...
// old version
// <root>\node_modules\@adonisjs\framework\src\Encryption\index.js
const Encryptor = require('simple-encryptor')
...
class Encryption {
  constructor (Config) {
    const appKey = Config.get('app.appKey')

    /**
     * Throw exception when app key doesn't exists.
     */
    if (!appKey) {
      throw GE.RuntimeException.missingAppKey('Encryption')
    }

    this.encryptor = Encryptor(appKey)
  }
  ...

simple-encryptor 의 option 이 변경된다.

이로 인해 발생하는 문제는 simple-encryptor 의 default option 이 변경된다.
// simple-encryptor
module.exports = function(opts) {
  if( typeof(opts) == 'string' ) {
    opts = {
      key: opts,
      hmac: true,
      debug: false
    };
  }
  var key = opts.key;
  var verifyHmac = opts.hmac;
  var debug = opts.debug;
  var reviver = opts.reviver;
  ...

해결책

그래서 혹시 이전의 option 을 사용하려 한다면 자신의 AppProvider 를 만들어서 사용해야 할 듯 하다. 아래 소스를 참고하자.
그리고 app.js 에 등록만 해주면 된다. 아래 글을 참고하면 된다.

[컴][nodejs] nodejs 의 crypto module 사용시 주의점



nodejs 의 crypto module 사용시 주의점

nodejs version 과 openssl


대략적으로 NodeJS 는 자체적으로 OpenSSL 을 포함하고 있다.(code)

아래 링크를 가면, nodejs version 에 따른 openssl 버전을 확인할 수 있다.

crypto module 사용시 주의점

How to use the crypto module | Node.js 를 보면 crypto 모듈은 openssl 를 이용한다. 그래서 openssl version 의 특별한 변화가 생기면, nodejs 의 openssl 도 영향을 받는다.

md5 --> sha256,  openssl version 1.1.0

openssl version 이 1.1.0 으로 올라가면서 기본 digest algorithm 이 md5 에서 sha256 으로 변경됐다.

nodejs 에서 openssl version 을 1.1.x 로 옮긴 것은 nodejs 의 version 이 10.0.0 이 된 순간이다.(참고)

그러므로, v10 미만을 사용할 때와 v10 이상을 사용할 때 만약 crypto module 을 사용하고 있다면 주의가 필요하다.

error

OpenSSL 1.0.x 버전에서 얻은 값을 OpenSSL 1.1.x 로 decrypt 를 시도하면 아래와 같은 error 가 발생한다.

error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt

알고리즘 선택

아래 처럼 algorithm 을 명시해주는 것이 나을 수 있다.
var cryptoKey = crypto.createHash('sha256').update(key).digest();



[컴][js] redux-saga 동작 분석




redux-saga 동작 분석

위의 예제로 분석할 것이다.

// saga.js
import { put, takeEvery, all  } from 'redux-saga/effects'

const delay = (ms) => new Promise(res => setTimeout(res, ms))


export function* helloSaga() {
  console.log('Hello Sagas!')
}


// ...

// Our worker Saga: will perform the async increment task
export function* incrementAsync() {
  yield delay(1000)
  yield put({ type: 'INCREMENT' })
}

// Our watcher Saga: spawn a new incrementAsync task on each INCREMENT_ASYNC
export function* watchIncrementAsync() {
  yield takeEvery('INCREMENT_ASYNC', incrementAsync)
}



// notice how we now only export the rootSaga
// single entry point to start all Sagas at once
export default function* rootSaga() {
  yield all([
    helloSaga(),
    watchIncrementAsync()
  ])
}


// main.js
import "babel-polyfill"

import React from 'react'
import ReactDOM from 'react-dom'
import { createStore, applyMiddleware } from 'redux'

import Counter from './Counter'
import reducer from './reducers'
//// default export 인 sagaMiddlewareFactory 를 createSagaMiddleware 에 assign 한 것
import createSagaMiddleware from 'redux-saga'
// import { rootSaga } from './sagas'
import rootSaga from './sagas'

// const store = createStore(reducer)
const sagaMiddleware = createSagaMiddleware()
const store = createStore(
  reducer,
  applyMiddleware(sagaMiddleware)
)
sagaMiddleware.run(rootSaga)

const action = type => store.dispatch({type})

function render() {
  ReactDOM.render(
    <Counter
      value={store.getState()}
      onIncrement={() => action('INCREMENT')}
      onDecrement={() => action('DECREMENT')}
      onIncrementAsync={() => action('INCREMENT_ASYNC')} />,
    document.getElementById('root')
  )
}

render()
store.subscribe(render)

createSagaMiddleware()

createSagaMiddleware() --> sagaMiddlewareFactory() 가 호출된다. sagaMiddlewareFactory 를 확인해보면 대체로 이전버전의 사용법에 대한 error 를 던져주기 위한 용도인듯 하다. 그외에는 sagaMiddleware 라는 function 을 만들어서 return 해준다.

sagaMiddleware() 를 호출할 때 runSaga 에 첫번째 argument 를 assign 해준다.(이것이 boundRunSaga) 그리고 sagaMiddleware.run 을 하면,  이 boundRunSaga  를 호출한다.


createStore() / applyMiddleware()

applyMiddleware() 는 단순하다. 기존의 createStore() 를 실행하고, 그 이외에 다른 동작을 하기 위한 함수라고 보면 된다. python 의 decorator 같은 역할이다.

물론 로직은 좀 더 복잡하게 짜여있다. applyMiddleware() 를 직접실행시키는 것이 아니라createStore 내에서 applyMiddleware() 가 decorator 처럼 동작해야 해서 createStore 내에서 다시 호출(call)한다. 그런 이유로 applyMiddleware() 가 function 을 return 한다. 말이 복잡하다. source code 를 확인하자.

export default function applyMiddleware(...middlewares) {
  return createStore => (...args) => { // pass the createStore as an argument
    const store = createStore(...args)
    let dispatch = () => {
      throw new Error(
        'Dispatching while constructing your middleware is not allowed. ' +
          'Other middleware would not be applied to this dispatch.'
      )
    }

    const middlewareAPI = {
      getState: store.getState,
      dispatch: (...args) => dispatch(...args)
    }
   // 기존의 dispatch 에 middleware 를 추가해서 dispatch 를 새롭게 만든다.
    const chain = middlewares.map(middleware => middleware(middlewareAPI))
    dispatch = compose(...chain)(store.dispatch)

    return {
      ...store,
      dispatch
    }
  }
}
...
export default function createStore(reducer, preloadedState, enhancer) {
  ...
  if (typeof enhancer !== 'undefined') {
    if (typeof enhancer !== 'function') {
      throw new Error('Expected the enhancer to be a function.')
    }

    return enhancer(createStore)(reducer, preloadedState)
  }
  ...
}


sagaMiddleware.run(rootSaga)

sagaMiddleware.run(rootSaga) 를 하면 runSaga() 가 호출된다. runSaga() 에서는 필요한 설정들에 대한 값들을 set 하고(sagaMonitor 같은) proc() 를 호출한다.(proc.js)
proc(env, iterator, context, effectId, getMetaInfo(saga), /* isRoot */ true, noop)

proc 에서 stdChannel 를 생성하는데, 이녀석은 약간의 경고문구만 추가한 eventChannel 이다. 이녀석은 createSagaMiddleware 를 할 때 생성된다.

proc 에서 next() 를 호출하고, next 는 iterator.next() 를 호출한다. iterator 를 이용해서 all() 로 묶인 task 들을 한번에 처리한다.


// saga.js
export default function* rootSaga() {
  yield all([
    helloSaga(),
    watchIncrementAsync()
  ])
}
...

// runSaga.js
function runSaga(_ref, saga) {
  ...

  var iterator = saga.apply(void 0, args);
  ...
  return immediately(function () {
    var task = proc(env, iterator, context, effectId, __chunk_1.getMetaInfo(saga),
    /* isRoot */
    true, __chunk_1.noop);

    if (sagaMonitor) {
      sagaMonitor.effectResolved(effectId, task);
    }

    return task;
  });
}

function proc(env, iterator, parentContext, parentEffectId, meta, isRoot, cont) {
  if (iterator[__chunk_1.asyncIteratorSymbol]) {
    throw new Error("redux-saga doesn't support async generators, please use only regular ones");
  }
  ...
  next(); // then return the task descriptor to the caller
  
  return task;
  /**
   * This is the generator driver
   * It's a recursive async/continuation function which calls itself
   * until the generator terminates or throws
   * @param {internal commands(TASK_CANCEL | TERMINATE) | any} arg - value, generator will be resumed with.
   * @param {boolean} isErr - the flag shows if effect finished with an error
   *
   * receives either (command | effect result, false) or (any thrown thing, true)
   */

  function next(arg, isErr) {
    try {
      var result;
      
      if (isErr) {
        result = iterator.throw(arg); // user handled the error, we can clear bookkept values
        clear();
      } else if (__chunk_1.shouldCancel(arg)) {
        /**
          getting TASK_CANCEL automatically cancels the main task
          We can get this value here
           - By cancelling the parent task manually
          - By joining a Cancelled task
        **/
        ...
      } else if (__chunk_1.shouldTerminate(arg)) {
        // We get TERMINATE flag, i.e. by taking from a channel that ended using `take` (and not `takem` used to trap End of channels)
        ...
      } else {
        result = iterator.next(arg);
      }

      ...
    } catch (error) {
      if (mainTask.status === CANCELLED) {
        throw error;
      }

      mainTask.status = ABORTED;
      mainTask.cont(error, true);
    }
  }
  ...
}


redux-saga 사용

redux-saga 는 특정 이벤트가 끝날때에 대한 작업을 미리 등록해 놓을 수 있다.(saga.js)

그래서 원래라면,

  1. 특정 이벤트가 발생하고, 
  2. 그 작업을 수행한 후(event handler)에 
  3. 우리가 원하는 작업을 실행하기 위해서 우리의 code를 추가해야 한다.(callback) 
하지만 redux-saga 는 그부분의 대한 구현에 관계없이 구현을 하면 된다.

redux-saga 를 이용해서 event 가 끝나는 시점에 호출되는 대신에,

  1. 먼저 특정 event 를 기다리는 code 를 실행하고 
  2. event 가 발생할 때 까지 control 을 다른 곳에 넘겨준다. 그리고 event 가 발생하면 다시 control 을 받아온다.(yield)

  yield takeEvery('INCREMENT_ASYNC', incrementAsync)

아래 글을 읽으면 자세한 이야기를 알 수 있다.








[컴][웹][js] v8 Scanner



from: https://v8.dev/blog/scanner

v8 Scanner

v8 이 소스를 파싱해서 AST 로 만든다.abstract syntax tree (AST)
이걸로 프로그램 구조를 표현한다.

v8은 complile 해야 프로그램을 실행할 수 있다.
v8 parser 은 scanner 에서 만들어놓은 token 을 소모한다.

이때 scanner 가 사용하는 character stream의 encoding 은 utf16만 지원한다.
scanner 에 input 으로 제공하기 전에 이전에 모든 encoding 을 utf16으로 convert 하는 과정을 거친다.

scanner는 이 utf16을 decode 해서 unicode 로 만들어서 사용한다.
이 decoded character 들을 이제 가져다 scanner 가 token 을 만든다.



Whitespace

2개의 token 사이에 whitespace 가 있으면 거기에 ;(semicolon)을 넣는다.(ECMAScript® 2020 Language Specification > Auto semicolon insertion)

다음 token 을 scan 하기 전까지 모든 whitespace는 skip 된다.(newline 이 발생하는지 추적하면서)

real world 에서는 대체로 js 들이 minified 돼서 여러개의 whitespace 가 연속해서 나타나는 경우가 드물다.

그래서 V8 은 whitespace 도 하나의 token 으로 취급한다. (Token::WHITESPACE) 그래서 '//' 같이 comment 가 오는 경우에도 Token::WHITESPACE 를 return 해 버린다.  그러면 paring 하는 loop 에서 다른 Token이 나올때 까지 계속 scan 을 이어나갈 수 있게 된다.

(역주: 다시 말하면, // 가 나와서 이것을 다른 token 으로 정의(Token::COMMENT) 등으로 정의해서 사용하게 되면, loop 을 한번 벗어난 후에 다시 parsing 을 시작해야 하지만, 이것을 whitespace 와 같은 속성으로 취급해 버리면, 이 overhead 를 없앨 수 있게 되는 것이다.)



V8_INLINE Token::Value Scanner::ScanSingleToken() {
  Token::Value token;
  do {
    next().location.beg_pos = source_pos();

    if (V8_LIKELY(static_cast<unsigned>(c0_) <= kMaxAscii)) {
      token = one_char_tokens[c0_];

      switch (token) {
        ...
        
        case Token::DIV:
          // /  // /* /=
          Advance();
          if (c0_ == '/') {
            uc32 c = Peek();
            if (c == '#' || c == '@') {
              Advance();
              Advance();
              token = SkipSourceURLComment();
              continue;
            }
            token = SkipSingleLineComment();
            continue;
          }
          if (c0_ == '*') {
            token = SkipMultiLineComment();
            continue;
          }
          if (c0_ == '=') return Select(Token::ASSIGN_DIV);
          return Token::DIV;
          
        ...

        case Token::WHITESPACE:
          token = SkipWhiteSpace();
          continue;

        case Token::NUMBER:
          return ScanNumber(false);

        case Token::IDENTIFIER:
          return ScanIdentifierOrKeyword();

        default:
          UNREACHABLE();
      }
    }

    if (IsIdentifierStart(c0_) ||
        (CombineSurrogatePair() && IsIdentifierStart(c0_))) {
      return ScanIdentifierOrKeyword();
    }
    if (c0_ == kEndOfInput) {
      return source_->has_parser_error() ? Token::ILLEGAL : Token::EOS;
    }
    token = SkipWhiteSpace();

    // Continue scanning for tokens as long as we're just skipping whitespace.
  } while (token == Token::WHITESPACE);

  return token;
}




Identifier scanning
Internalizing minified identifiers
Keywords
Surrogate pairs
AdvanceUntil


See Also


  1. V8 관련 글들



[컴] 썬더클랩 Thunderclap

썬더볼트 취약점 /


paper : http://thunderclap.io/thunderclap-paper-ndss2019.pdf

썬더클랩(Thunderclap)

  • 이 취약점은 물리적인 접근을 한 공격자에게 Thunderbolt(썬더볼트) 포트를 이용해서 해당기계를 위험하게 한다.
  • 공격자가 가장높은 권한으로 임의의 코드를 실행시킬 수 있게 해준다. 그래서 잠재적으로 암호, 은행 로그인, 암화화 키, 개인파일등에 접근할 수 있게 해준다.
  • 또한, 공격자가 이 취약점을 이용하면 겉으로 무해해 보이는 충전기, 프로젝터 같은 주변기기가 충전이나, 영상을 쏘아 주는 사이에 "host 머신"을 위험하게 할 수 있다.(이러면, 우리가 제3자의 충전기도 마음대로 사용하기 힘들어진다. 마치 공용 wifi 같이)

동작

네트워크 카드의 동작

  1. OS 가 network interface card(NIC) 에 packet 을 보내라고 요청할 때
  2. OS 는 NIC에 보낼 data 에 대한 address 를 제공해 준다.
  3. 그러면 NIC 의 payload 함수는 plaintext data를 찾으려고 memory 근처를 검색할 것이다.


Thunderclap 방법

When an IOMMU is in operation, the most obvious way touse it for protection requires some changes to ring buffer usage. 
  • First,  packet  data  must  be  allocated  from  a  pool  of  physical memory  that  allows  exposure  to  devices  (some  memory  maybe  inaccessible  due  to  hardware  limitations).  
  • Second,  before a data  block  is  placed  in  the  ring  buffer  for  transmission,  a window must be opened for it to be accessible by the device. This involves creating a mapping for the block in the IOMMU page table.
  • Third, the address written into the ring buffer is now the I/O virtual address of the mapping, rather than the physical address. 
  • Finally, when the device is finished with the data, the operating system should close the window again, revoking the mapping from the IOMMU page table and IOTLB.




How do the Thunderclap vulnerabilities work?

The Thunderclap vulnerabilities stem from the fact that computer peripherals such as network cards and GPUs have traditionally been trusted parts of a computer system: they have direct memory access (DMA), which allows them to read and write all of system memory without operating system oversight. DMA allows peripherals to bypass operating system security policies, and DMA attacks abusing this access have been widely employed by hackers and the intelligence community to take control of and exfiltrate sensitive data from target machines. This means passwords, banking logins, private files and browser activity are all exposed, and an attacker can inject any code they wish onto your machine.

Current systems feature input-output memory management units (IOMMUs), protection mechanisms that allow the operating system to restrict peripheral-device memory access. With IOMMU usage enabled, operating systems can protect against DMA attacks by restricting memory access to peripherals that perform legitimate functions and only allowing access to non-sensitive regions of memory. Unfortunately, IOMMU protection is turned off by default in many systems.

Our work leverages vulnerabilities in operating system IOMMU usage to compromise a target system via DMA, even in the presence of an IOMMU that is enabled and configured to defend against DMA attacks. The novel Thunderclap security evaluation platform, built on field-programmable gate array (FPGA) hardware, mimics the functionality of a legitimate peripheral device to convince a target operating system to grant it access to regions of memory. It then examines those regions of memory to find a rich and nuanced attack surface of vulnerable structures that can be exploited to take control of the system.

The rise of hardware interconnects like Thunderbolt 3 over USB-C that combine power input, video output, and peripheral device DMA over the same port greatly increases the real-world applicability of Thunderclap vulnerabilities. Thunderbolt can allow potentially malicious devices to hotplug into a running machine and obtain direct memory access, which makes DMA attacks against temporarily unattended targets feasible. Furthermore, the confusion of power, video, and DMA facilitates the creation of malicious charging stations or projectors that take control of connected machines.

Additionally, our work shows that the Thunderclap vulnerabilities can also be exploited by compromised firmware on existing PCI Express devices, for example network cards or baseboard management controllers (BMCs) integrated into servers. A firmware compromise might be introduced via a firmware vulnerability or a compromise in the device supply chain or factory.


How does this work differ from earlier DMA attacks such as Inception?

Early DMA attacks relied on the absence of an IOMMU. They involved scanning all of a system’s memory for sensitive data from devices that did not appear to the system as legitimate peripherals. These attacks were addressed by the introduction of IOMMUs, which block all memory access from unrecognized devices.

Some previous DMA attacks have taken advantage of weaknesses in IOMMU configuration or setup to disable IOMMU protections. Thunderclap explores serious vulnerabilities that are present even once the IOMMU is configured correctly.

Technical details of the Thunderclap platform

The Thunderclap platform consists of an FPGA that runs the Thunderclap application. The FPGA then plugs into a computer via PCI Express or Thunderbolt. The Thunderclap application makes the FPGA behave to the computer like a genuine Ethernet card (the Intel 82574L network interface card or NIC). The operating system will identify the ethernet peripheral, load drivers, allow the device to access memory (via DMA and an IOMMU if enabled), and ask it to send and receive packets.

With this deep interaction with the operating system, Thunderclap’s device model provides hooks that allow payload functions to be added to device behavior. For example, when the operating system asks the NIC to send a packet, it provides the NIC with the address of the data to send. A payload function might search nearby memory looking for plaintext data that was intended for a different network device.

The Thunderclap application runs on Intel/Altera FPGA boards:
  1. Intel Arria 10 SoC Development Kit ($4500) with Samtec HDR-181157-01-PCIEC cable (available from Samtec direct) - currently recommended
  2. Enclustra Mercury+ AA1 module (ME-AA1-270-3E4-D11E) on PE1 carrier board (~EUR 800) - work in progress
  3. Terasic DE5-Net board (Stratix V) with BERI soft-CPU - no longer supported
  4. As far as we can ascertain, Xilinx, Lattice and Intel Cyclone FPGAs don’t allow us to replace the vendor-supplied implementation of configuration registers with our own (Intel calls it ‘config bypass’ mode) which we require.
It is composed of several pieces:
  1. The underlying FPGA bitfile, containing the hardware that receives PCIe packets (TLPs) and delivers them to software. The FPGA contains an Arm Cortex A9 CPU (hard processor system or HPS) to run our software stack. GitHub repo
  2. The Ubuntu 16.04 operating system running on the on the Arm, including kernel, device tree and u-boot bootloader (which also loads the FPGA bitfile at boot time). Automated build scripts (work in progress): GitHub repo
  3. The Thunderclap application, which is a substantially cut down version of QEMU, based on its e1000e device. This runs in Ubuntu on the ARM core and connects directly to the PCIe queues provided by the hardware. GitHub repo





[컴] iOS 보안-시스템 보안

iOS 부팅 절차 / boot time / booting process / enclave


ref. 1 의 System Security 의 일부를 번역했다. 자세한 내용은 ref. 1을 보도록 하자.

iOS 보안-시스템 보안

기기암호화(device encryption) 는 기본적으로 설정되어 있으며, 설정을 변경할 수 없다.

Secure Boot Chain

  1. iOS 켜기
  2. --> AP 가 Boot ROM 의 code실행
    1. the hardware root of trust 라고 알려져 있다.
    2. the chain of trust 의 첫번째 단계(first step) 이다.
    3. 이 code 는 변경불가능(immutable code)
    4. 칩제조(chip fabrication) 때 만들어 진다.
    5. implicitly trusted
    6. Apple Root CA public key 를 가지고 있다.
      1. 이 public key 는 iBoot bootloader 가 load 되기 전에 Apple 에 의해 서명(sign) 됐다는 것을 확인(verify) 하는데 사용된다.(아래 boot-time verification 참고.)
  3. Boot ROM 에 의해 추가적인 Low-Level Bootloader(LLB) stage 가 load 되고, 확인(verify) 된다.
    1. A9를 포함한 A9 이전의 A시리즈 processor 에만 존재.
  4. 만약 Boot ROM 이 LLB 또는 iBoot 을 load 하는 것을 실패하면,  기기는 DFU mode (Device Firmware Upgrade)로 들어가게 된다.
    1. 오래된 기기들에서 LLB 를 load 하는 것을 실패 하거나,
    2. 새로운 기기들에서 iBoot 을 load 하는 것을 실패하는 것
  5. LLB 나 iBoot 이 다음 작업(next step) 을 load 하거나 verify 하는 것을 실패하는 경우
    1. startup 은 멈춰지고(halt) iTunes 에 접속하라는 화면이 보여진다. 
    2. --> recovery mode 이다.
  6. DFU mode 로 가거나, recovery mode 로 들어가면, USB 를 이용해서 iTunes 에 접속해서 "공장 기본 세팅(factory default settings)" 로 복구되어 져야만 한다.
  7. 기기가 Recovery Mode 와 DFU Mode 로 들어가기 전에 The Boot Progress Register (BPR) 가 update 된다. 이 update 된 값을 보고 Secure Enclave 가 user data 에 대한 접근제한을 하게 된다.
    1. Recovery Mode
      1. A10, S2 그리고 최신의 SoCs 를 가진 기기에서 iBoot 에 의해 BPR 이 set.
    2. DFU Mode : A12 SoC 를 가진 기기에서 Boot ROM 에 의해 BPR 이 set.
  8. --> iBoot 이 일들을 마치면
  9. --> iBoot 은 iOS kernel 을 확인(verify) 하고, 실행한다.

baseband subsystem 또한 이것과 비슷한 자신의 secure booting 을 이용한다.
Secure Enclave coprocessor 또한 secure boot process 를 이용하고, 그로인해 그것의 분리되 소프트웨어가 verified and signed by Apple 되었다는 것을 확신시켜준다.
secure boot



시스템 소프트웨어 권한부여(System Software Authorization)

만약 과거버전의 iOS의 설치가 가능하다면 해커는 과거버전의 iOS를 깔고 권한을 가져올 수 있다. 이것을 막기 위해서 iOS는 System Software Authorization 을 이용한다. Secure Enclave 도 이것을 이용한다.


iOS update

iOS update 는 2가지 방식(iTunes, OTA) 으로 가능하다.
  • iTunes 로 업데이트를 할 때
    • iOS image 전체를 download 
    • Content Caching 옵션을 켠 macOS High Sierra 를 돌리는(run) Mac 을 사용한다면, 미리 cache 되어서, iOS 의 update 를 바로 할 수 있게 해준다.
  • OTA 로 할 때: patch 를 할 내용만 다운로드한다. 

installation authorization server

iOS update 할때 기기는 Apple 의 installation authorization server 에 접근한다.
그리고 다음 3가지를 확인 한다.
  1. bundle의 measurements: 설치될 installation bundle들에 대한 암호화된 measurements(측정)
    • installation bundle : iBoot, kernel, iOS Image
  2. nonce : signed data 를 가져다 다른 기기에 쓰는 것을 막아주고, system software 를 변경하지 못하게 막는다.
  3. ECID: 기기의 고유한  ECID(Exclusive Chip Identification) 를 서버로 보내게 된다.

installation authorization server 에서 하는일

서버에서는  이 installation bundle 의 버전들이 맞는 구성인지를 확인한다. 예를 들면 특정버전의 iBoot 은 특정 version 의 kernel 을 써야만 하는식이다. 이렇게 버전이 맞으면 이 measurement 에 ECID 를 더해서 sign 을 하고 이 sign 된 data 를 기기에 보내준다.
sign(measurment + ECID) ---> device

boot-time verification

위에 설명한 startup process 가 "Apple 이 sign 한 code" 만 기기에 설치되는 것을 보장해 준다.
  • Apple 의 signature : boot time 에 일어나는 chain-of-trust evaluation 은 Apple 의 signature 를 verify 한다.
  • disk 에서 load 되는 item 의 measurement: "disk 에서 load 되는 item 의 measurement (기기의 ECID를 이용해서 만들어져 있다.)"와 "signature 에 의해 감싸진 measurement(위의 installation authorization server 에서 받은)"가 맞는지를 verify 한다.
이 절차들이 특정기기에 대한 authorization 을 해주고, 기기에서 옛 iOS버전이 다른 곳으로 copy 안되도록 한다.

Secure Enclave

  • Secure Enclave 는 보조 프로세서이다. 
  • SoC 안에 들어있다.(fabricated)
  • 암호화된 메모리를 사용
  • 하드웨어 난수발생기(random number generator) 를 포함.
  • Secure Enclave Boot ROM
    • application processor Boot ROM 과 비슷하게, Secure Enclave Boot ROM 은 변경이 불가능한 code (immutable code) 이다. Secure Enclave 를 위한 "하드웨어 root of trust" 를 확립한다.(establish)
    • device 가 시작될 때, Secure Enclave Boot ROM 이 수명이 짧은 메모리 보호 키(ephemeral memory protection key)를 만든다. 
  • Secure Enclave 는 데이터 보호 키 관리에게 (Data Protection key management) 모든 암호화 기능(cryptographic operations)들을 제공
  • 심지어 커널이 허락한 상태에도(kernel has been compromised) Data Protection 의 integrity (데이터가 변경, 파괴되지 않은 상태)을 유지.
  • AP(Application processor) 와 Secure Enclave 사이의 통신은 interrupt-driven mailbox 와 shared memory data buffer 들과 분리되어 있다.
  • Secure Enclave OS 를 실행
    • Secure Enclave OS
      • "L4 마이크로 커널의 Apple-customized version" 에 기초해서 만들어진 OS
      • Apple 에 의해 sign 된다.
      • Secure Enclave Boot ROM 가 verify
      • 개인의 소프트웨어 업데이트 프로세스를 통해 update 된다.
  • device 가 시작될 때, Secure Enclave Boot ROM 이 수명이 짧은 메모리 보호 키(ephemeral memory protection key)를 만든다. 
    • 이 키(memory protection key)는 기기의 UID 와 얽히게 만들고(entangle), 기기의 memory space 의 "Secure Enclave 부분"을 암호화 할 때 사용된다.
    • 예외적으로 Apple 의 A7 에선, Secure Enclave memory "memory protection key" 로도 인증(authenticated) 이 가능하다. A11과 A11 이후 그리고 S4 SoC 들에서는 "memory protection key" 와 on-chip SRAM 에 저장된 nonce 들에 의해 인증된다.(authenticated)
    • 그리고, A11과 A11 이후 그리고 S4 SoC 들에서 integrity tree 는 보안이 중요한 Secure Enclave memory 의 replay 를 막기위해 사용되어진다.
    Secure Enclave 에 의해 file system 에 저장된 data 는 UID 와 entangled 된 key와 anti-replay counter 로 암호화되어 진다. anti-replay counter 는 dedicated 비휘발성 메모리 IC 안에 저장되어 있다.

    A12 와 S4 SoC 들이 있는 기기들에서, Secure Enclave 는 anti-replay counter storage 를 위해 secure storage IC 와 짝을 이룬다. secure storage IC 는 immutable ROM code, 하드웨어 random number generator, 암호화엔진들, physical tamper detection(물리적인 조작 감지) 과 함께 디자인됐다. counter 들을 읽고 업데이트 하기 위해서, Secure Enclave 와 storage IC 는 counter 들에게 exclusive access 를 보장하는 '안전한 protocol '를 사용한다.

    Secure Enclave 의 "anti-replay 서비스"들은 event 에 사용된 data 의 철회(revocation of data over events)를 위해 사용되어진다.

    이 이벤트들은 anti-replay 의 경계들(boundaries)을 표시 해 준다.
    이벤트는 다음것들을 포함한다. 하지만 제한되진 않는다.
    • Passcode change
    • Touch ID or Face ID enable/disable
    • Fingerprint add/delete
    • Face ID reset
    • Apple Pay card add/remove
    • Erase All Content and Settings
    Secure Enclave 는 또한 지문을 처리하고, Touch ID 와 Face ID 센서들로 부터 오는 얼굴데이터를 처리하는 책임도 진다. 그리고 맞는지 여부를 결정하고, 그리고나서, 유저를 대신해서 access 또는 구매를 가능하게 한다.

    Reference

    1. https://www.apple.com/business/site/docs/iOS_Security_Guide.pdf

    [컴][웹] 간단하게 주기적으로 message 를 수신하는 web page

    EventSource / cors / jsonp / different host / subscribe model /


    tornado

    EventSource object | Javascript


    EventSource object 로 server 에 연결(subscribe) 을 해서 주기적으로 event 를 받을 수 있다. 자세한 동작은 일단 생략한다. ref. 2 에서 어느정도 설명을 해준다.


    different domain

    domain 이 다른 곳에 event 를 날려주는 server 가 있어도 무리없이 사용할 수 있다. 보통 html(javascript) 에서 다른 domain 인 경우는 보안을 이유로 ajax 요청이 되지 않는다. 그래서 jsonp 등(일반적으로 Cross-Origin Resource Sharing 이라고 이야기하는 방법)을 이용한다.

    하지만 이 EventSource 는 그런 것의 제약을 받지 않는다. [ref. 1]

    아래처럼 다른 domain 인 경우에는 다른 domain 을 uri 로 적어주면 된다.

    var evtSource = new EventSource("//api.example.com/ssedemo.php", { withCredentials: true } );

    evtSource.addEventListener("ping", function(e) {
      var newElement = document.createElement("li");
     
      var obj = JSON.parse(e.data);
      newElement.innerHTML = "ping at " + obj.time;
      eventList.appendChild(newElement);
    }, false);


    이렇게 다른 domain 에 대한 제약이 없어서 좋은 점은 기존의 web server 와 관계없이 새로운 event 처리를 하는 server 를 사용할 수 있다는 점이다. 그러면 주기적인 push event 등을 처리하는 server 를 따로 둘 수 있다.



    Server side event vs WebSocket

    event driven page 를 만들 땐 SSE 를 사용해도 되고, WebSocket 을 사용해도 된다. 개인적으로는 필요한 부분은 단방향이라서, 양방향 통신이 되는 WebSocket 이 굳이 필요하지 않았다.

    아래는 SSE 와 WebSocket 을 간략하게 정리했다.

    SSE

    1. 2009년 4월 23 일 WHATWG 에서 승인했다. [ref. 7] 
    2. 하지만 SSE 가 좀 더 간편하다. 
    3. 그리고 http protocol 위에서 구현되었다. 
    4. 단방향 통신
    5. client 의 connection 이 종료되었는지 여부를 알 수는 없다.(http 라서 당연한 것일지도.)


    WebSocket

    1. 반면에 WebSocket 은 Tcp/ip 로 다른 port 를 사용한다. 그래서 이 port 가 firewall 에 의해 막혀 있을 수도 있고, 
    2. 이 녀석을 이용하려면, protocol 을 또 정의해야 한다. (ref. 5 에서 좀 더 다양한 의견을 확인할 수 있다.)
    3. 양방향 통신






    Reference

    1. Using server-sent events - Web APIs | MDN
    2. Stream Updates with Server-Sent Events - HTML5 Rocks
    3. Asynchronous connections - RethinkDB
    4. Build a real time data push engine using Python and Rethinkdb | IMPYTHONIST
    5. SSE vs Websockets - Streamdata.io
    6. Lessons Learned Architecting Realtime Applications | Lincoln Loop
    7. Python and Real-time Web | Eat at Joe's
    8. Tornado server-sent events · GitHub : tornado 로 SSE 구현 예제.
    9. Building RESTful APIs with Tornado | Dr Dobb's

    [컴][웹] V8 에서 JavaScript 의 pipeline

    v8 engine 의 동작 / 동작원리 / 크롬 자바스크립트 엔진 / 크롬 엔진 / 크롬 렌더링 엔진 /



    V8 에서 JavaScript 의 pipeline

    v5.9 이전의 pipeline

    from: https://v8.dev/blog/ignition-interpreter

    원래는 baseline compiler(위의 그림에서 Ignition 과 Full codegen 의 위치에 있는 것이라 여기면 될 듯 하다.) 가 machine code 를 빠르게 만들고, 이 code 가 실행되는 동안에 이 code를 분석하고 일부를 optimizing compiler 가 optimized code 로 다시 compile 한다.

    이 때 사용되는 2개의 optimizing compiler 가 crankshaft, turbofan 이다.

    • TurboFan : Ignition의 bytecode를 바로 최적화된 machine code 로 바꿀 수 있다.[ref. 4]
    • Crankshaft: 소스코드를 다시 컴파일을 해서 최적화된 machine code 를 만든다.[ref. 4]
    참고로, v5.9 부터 Full-codegen 과 Crankshaft 는 사용하지 않는다.[ref. 4]

    Ignition 의 등장

    그런데 이 상황에서 Ignition 을 만들어서 "baseline compiler 가 machine code 를 만드는 것"을 대신해서 Bytecode 를 만들게 했다.

    Ignition 는 처음에 모바일에서 사용하기 위해서 만들었다.[ref. 4]  JIT 가 만든 machine code 의 size 가 커서 메모리를 너무 잡아먹었기 때문이다.  Ignition 에 의해서 chrome tab 마다 메모리를 약 5% 정도 아꼈다.

    Ignition 은 bytecode 를 생성하는 compiler 이고, 이녀석은 이전의 baseline compiler 를 대체한다.  Ignition 이 bytecode 를 만들때도 당연히 최적화를 한다.

    이 Ignition 은 register machine 이다. 이것은 stack machine 과 다르다. 이건 내 생각이지만, 안드로이드의 경험이 덕을 본듯 하다. (stack-based vs register-based)

    Ignition 이 생기면서 고성능의 interpreter 가 생겼고 이 녀석이 Ignition 이 만든 bytecode 를 실행해주는데, 실제웹사이트에서 속도가 이전의 baseline compiler 가  만든 code 의 속도에 근접한다.

    See Also

    1. V8 관련 글들

    References

    1. Ignition · V8 : ignition 에 대한 여러자세한 설명들의 link 들이 있다.
    2. Firing up the Ignition interpreter · V8
    3. Home · v8/v8 Wiki · GitHub
    4. Launching Ignition and TurboFan · V8
    5. TurboFan · V8 : turbofan 에 대한 정보들이 모여 있다.


    [컴][Hack] Visual Studio C/C++ compiler 로 compile 하기

    Visual Studio C/C++ compiler 로 compile 하기



    Visual Studio C/C++ compiler 로 compile 하기

    환경

    • Visual Studio Community 2015

    compile

    cmd 창을 열고 일단 vsvarsall.bat 를 실행해 주자. 이녀석이 필요한 환경 변수등을 세팅해준다.
    "c:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat"

    그리고 아래처럼 compile 을 하면 된다.
    "c:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\cl.exe" my.cpp

    assembler

    만약 assembler 를 보고 싶다면, /Fa option 을 사용하면 된다.
    "c:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\cl.exe" my.cpp /Famy.asm

    x86_amd64

    64 bit 으로 compiler 는 x86_amd64 에 있다. amd64_x86 라는 folder 도 있는데, 차이는 찾아보지 않아서 일단 패스.
    c:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\x86_amd64\vcvarsx86_amd64.bat
    "c:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\x86_amd64\cl.exe" my.cpp




    See Also

    1. x86 opcode: http://ref.x86asm.net/coder32.html#x83
    2. x86/add: https://www.felixcloutier.com/x86/add
    3. intel sw development manual: http://x86asm.net/links/index.html#intel_man