경쟁 상태[편집]

소프트웨어[편집]

소프트웨어 분야에서 경쟁 상태(race condition)는 응용프로그램이 적절하게 작동하기 위해 프로세스나 스레드 의 시간 혹은 순서에 의존할 때 발생한다. 이것은 전자공학에서 처럼, 유효하지 않은 실행과 버그를 만들어내는 치명적인 경쟁 상태(race condition)와 예기치 못한 행동을 만들어내는 비경쟁 상태(non race condition)가 있다. 이 치명적인 경쟁 상태(race condition)은 종종 프로세스 혹은 스레드가 몇몇 공유된 상태에 의존할 때 발생한다. 공유된 상태에서의 작동은 반드시 상호적으로 배타적이어야 하는 중요한 부분이다. 이러한 규칙을 지키지 못했을 경우에 공유된 상황이 더럽혀질수 있는 가능성이 생긴다.

경쟁 상태(race condition)은 재생산이나 디버그 하기 어렵다는 평판을 가지고 있다. 그 끝의 결과는 비결정적이고 서로 간섭하는 스레드 사이의 상대적인 시간에 의존하기 때문이다. 그러므로 생산시스템에서 일어나는 문제는 디버그 모드가 작동할 때, 부가적인 로그가 더해졌을때, 혹은 종종 하이젠베르크라고 인용되는 디버거가 부착되었을때 사라질 수 있다. 결국 주의깊은 소프트웨어 디자인이 이후 문제가 발생 되었을 시에 고쳐나가는 것보다 훨씬 중요할 것이다.

파일 시스템[편집]

파일시스템에서 두가지 혹은 그 이상의 프로그램은 아마 파일을 수정하거나 접근하려는 시도중에 데이터를 더럽힐 수 있는 "충돌"을 할 것이다. 파일을 잠그는것이 주로 사용되는 해결책이다. 좀 더 번거로운 해결책은 하나의 유일한 프로세스(데몬을 실행하거나 혹은 그와 비슷한)가 파일에 대한 독립적인 접근을 가지고, 나머지 파일에 접근이 필요한 다른 프로세스들은 오직 하나의 유일한 프로세스와 프로세스 간 통신을 통하여야만 접근할 수 있는 시스템을 구성하는것이다.(그 과정은 프로세스 레벨의 동기화 과정이 필요하다.)

경쟁 상태(race condition)의 다른 형태로는 관련 없는 프로그램이 다른 프로그램의 디스크공간(혹은 메모리 공간이나 CPU 사이클)같은 사용 가능한 자원을 갑작스럽게 모두 사용함으로써 영향을 주는 파일 시스템에 있다. 주의깊게 이러한 경쟁 상황(race situation)을 고려하여 디자인하지 않은 소프트웨어는 아마 꽤나 깨지기 쉽고 예측하기 어려워질 것이다. 이러한 위험은 아마 믿을만하다고 생각한 시스템속에 오랫동안 간과되어질 것이다. 그러나 갑작스레 충분한 데이터가 축적되거나 충분한 다른 소프트웨어가 더해졌을 때 시스템의 많은 부분들이 불안정해질 것이다. 아마 가장 잘 알려져 있는 이러한 예시로는 화성에 착륙하고 머지않아 기능상실이 일어났던 화성탐사로봇의 Spirit이 있는데, 이것은 주로 많은 컴퓨터 시스템의 위험을 간과해서다. 해결책은 작업하기 전에 필요한 모든 자원들을 미리 보존하고 요청하는 것이다. 만약 요청이 실패하면 작업은 많은 실패가 일어날 수 있는 부분들을 피하면서 작업이 연기된다. (다른 방법으로, 각각 그 부분들이 에러 핸들링을 가지거나, 혹은 모든 작업의 성공이 그 뒤에 다양화 될 수 있다.) 좀 더 일반적이지만 부정확한 접근은 작업이 시작되기 전에 충분한 저장공간을 다양화 하는 것이다. 이것은 적절하지 않은데, 왜냐하면 복잡한 시스템에서 다른 프로그램 작동은 예측하기 힘들기 때문이다.

네트워크[편집]

네트워크에서 채널을 시작하는 유저가 자동적으로 채널 작동 선점을 얻는 IRC 같은 채팅 네트워크가 분배되었다고 생각해보자. 만약 다른 서버에서의, 같은 네트워크에서의 다른종점에서의, 유저가 같은 이름의 채널에 동시에 접속을 할때, 양쪽의 서버가 아직 다른 서버의 채널을 할당하는 신호를 받지 못하였기 때문에 각자의 유저의 서버는 채널 작동 선점을 각각의 유저에게 승인할 것이다.(이러한 문제는 널리 다양한 IRC 서버 보충에 의해 해결되어진다.)

이러한 경쟁 상태(race condition)의 경우, "공유된 자원"의 개념은 모든 네트워크의 상태를 포괄하게 되고(어떤 채널이 존재하는지, 어떤 유저가 그것들을 시작하고, 그러므로 선점을 하게되는지), 그것은 네트워크의 다른 서버에 변화에 관해서 신호를 보내는 한 각자의 서버가 자유롭게 바꿀수 있다. 그러나 네트워크를 가로지르는 지연시간은 그러한 묘사되어지는 경쟁 조건(race condition)의 종류를 만든다. 이러한 경우 공유된 자원으로의 접근을 제어하는 형태를 부여함으로써 경쟁 상태(race condition)을 방지하는것은(즉 제어하기위해 선점하는것을 유지하는 서버를 정해서) 중심인 하나의 네트워크에서 분산된 네트워크로 전환하는 것을 의미한다.(적어도 네트워크 작동의 한 부분에 대해서)

경쟁 상태(race condition)은 또한 컴퓨터 프로그램이 비동기 소켓으로 쓰여졌을때 발생할 수 있으며, 이러한 경우 프로그램의 수행은 네트워크 링크의 속도에 의존 되어질 수 있다.

생명-중점적 시스템[편집]

소프트 웨어의 흠은 재앙이 될 수 있다. 경쟁 상태(race condition)들은 Therac-25 방사선 치료 기계의 흠에서도 존재했었고, 그것은 적어도 세명의 환자를 죽음으로 몰고갔으며, 그 이상의 심각한 상해를 입혔다.

다른 예시로는 GE 에너지에 의해 제공되어지고 Ohio 기반의 FIsrstEnergy 회사가 사용하는 에너지 관리 시스템이 있다. 경쟁 상태(race condition)은 알람 서브시스템에 존재한다. 3개의 sagging 파워 라인이 동시에 이동되어질때, 그 상태는 모니터링 기술이 발생되어지는 것과, 문제의 인식이 지연되는것을 막는다. 소프트웨어의 흠은 결국에 북아메리카의 2003년 대정전을 초래했다. GE 에너지는 후에 이전에 발견하지 못했던 에러를 수정하기 위해 소프트웨어 패치를 개발했다.

컴퓨터 보안[편집]

경쟁 상태(race condition)의 특정한 종류는 predicate를 찾기위해 검사하는것을 포함하며(예를 들면 인증을 위해), 그러면 predicate에서 작동하며, 그러는 동안 상태는 점검의 시간과 사용의 시간 사이에 변경할 수 있다. 이러한 종류의 버그가 보안-인지 코드에 존재할때 보안 취약점은 time-of-check-to-time-of use (TOCTTOU)버그 가 만들어진다고 한다.

리버스 엔지니어링[편집]

리버스 엔지니어링(혹은 역공학)은 사람이 만들었거나 그걸 재생산한 것 혹은 추출한 정보를 기반으로 재생산한 모든것에서부터 지식이나 디자인 정보의 추출 과정이다. 그 과정은 종종 기계장치, 전기적 요소, 컴퓨터 프로그래밍 혹은 생명, 화학 혹은 유기적인 문제들을 디스어셈블링하는것을 포함하며, 이것의 요소나 디테일한 작동을 분석한다.

그러한 정보를 얻고자 하는 이유와 목표는 사회적 이익부터 범죄적 행위까지 다양하며 상황에 따라 다르다. (종종 지적 재산권은 침해되지않는데, 예를들면 개인이나 기업은 어떻게 그것이 작동되는지, 그것들이 무엇을 하는지, 그리고 그들을 위해 리버스 엔지니어링을 할 필요성을 기억해 낼수 없기 때문이다.)?? 리버스 엔지니어링은 또한 멀웨어로 의심되어지는 것을 역공학 해서 이것이 무엇을 하는지, 어떻게 탐지하고 제거할수 있는지 이해 할 수 있고, 컴퓨터와 장치들이 함께 작동("interoperate(상호작용)")하는 것을 인가할 수 있으며, 노후된 시스템에서의 저장된 파일을 새로운 시스템에 사용하도록 인가하는데 사용할 수 있어 범죄 예방에 있어 유용하다. 반대로 리버스 엔지니어링은 또한 소프트웨어나 미디어의 복제방지를 제거하기 위해 "크랙"에 사용되거나, 더 나은 복사본을 만들고 심지어 모조품을 만들기도 한다(knockoff가 중단이란 뜻도 있는데, 찾아보니까 모조품이라는 뜻으로 사용한 것 같습니다). 이것은 종종 경쟁자들의 목표이다.

리버스 엔지니어링은 상업이나 군사의 목적을 위한 하드웨어 분석에 이것의 기원을 둔다. 그러나, 리버스 엔지니어링 그 자체의 과정은 복제품 생산이나 생산품의 변경과는 관련이 없다. 이것은 단지 본래 상품의 거의 전무한 지식과 이 상품으로 부터 설계 특징을 추론하기 위한 분석이다. 몇몇 경우, 리버스 엔지니어링 과정의 목표는 단순히 합법적인 시스템의 재문서화(redocumentation)이 될 수 있다. 심지어 경쟁자의 상품을 역공학 했을 때, 그것의 목표는 아마 복제가 아닌, 경쟁자의 분석을 수행함일 것이다. 리버스 엔지니어링은 아마 또한 상호정보 교환이 가능한(interoperable) 상품을 만들기 위해 사용 할 때 쓰인다. 비록 몇몇 제한적인 US와 EU 입법에서만 봐도, 위의 목적을 위해 특정한 리버스 엔지니어링 기술을 사용하는 것은 20년 이상 세계 널리 법정에서 논쟁되어지고 있다.

동기[편집]

리버스 엔지니어링을 하는 이유 :

인터페이스(컴퓨터와 컴퓨터 시스템의 연결) : 리버스 엔지니어링은 인터페이스가 시스템에서 다른 시스템으로 요구되어질때 사용 되어질 수 있고, 양쪽 시스템의 조율이 잘 성립 되어지게 할 수 있다. 그러한 요구는 전형적으로 정보처리상호운용(interoperability)을 위해 존재한다.

군사 혹은 상업적 스파이 행위 : 적군 혹은 경쟁자의 최근 연구 프로토타입을 훔치거나 붙잡음으로써 그리고 이것을 분해하면서 습득하기 위해서다. 이것은 아마 유사한 상품이나 혹은 더 나은 대책의 결과를 낳는다.

문서의 결점 상향 : 리버스 엔지니어링은 또한 이것의 설계나 제품 작동 혹은 유지를 위한 시스템의 문서가 결점을 가질때, 원래의 설계자가 이것을 향상시키려 하나 이용할 수 없는 경우 사용되어 질 수 있다. 소프트웨어의 리버스 엔지니어링은 소프트웨어 시스템의 현재 상태의 대부분을 이해하기 위해 필요한 문서를 제공 할 수 있다.

노후 : 직접회로(integrated circuits)는 종종 노후된 상태로 설계되었으며, 소유주가 있는 시스템인데, 그것은 시스템이 더이상 유지 되어질 수 없을 때(여분의 파츠 부족이나 비효율 등) 유일하게 새로운 기술의 기능을 설립할 수 있는 방법은 현재 있는 칩을 역공학 하는 것이고, 이것을 새로운 기능들을 위해 재설계 하고, 거기서 얻은 이해들을 가이드로써 사용하는 것이다. 역공학을 함으로써 해결할 수 있는 다른 문제는 계속된 작동을 위한 서포트의 존재와 (더이상 그들의 OEM(?)에 의해 서포트 될 수 없는 레거시 장비가 필요하다.)??

소프트웨어 개정(moderization을 근대화보다는 개정이 더 맞는거같습니다.) - 종종 지식은 시간에 걸쳐 잃어가고, 그것은 업데이트와 증진을 통해 예방 할 수 있다. 리버스 엔지니어링은 일반적으로 있는 지금 그대로의 상태를 분석(understand)하거나 혹은 시스템 지식을 나중의 상태로 옮기기 위한 비용(effort)을 추정하기 위해 레거시 소프트웨어를 분석(understand)하기 위해 필요하다. 이것의 대부분은 아마 실용,편의 혹은 보안의 요구가 변함에 따라 생겨진다.

제품 보안 분석 : 어떻게 제품이 작동하는지 조사하기 위하여, 제품의 요소들의 사양이 무엇인지, 비용을 추정하고 잠재적인 특허 침해를 확인하기 위해 쓰인다. 시스템 부품(component)의 설계를 디스어셈블링과 분석을 통하여 섬세한 데이터를 얻기위해 쓰인다. 다른 의도는 아마 복제 방지 제거와 접근 제어 회피를 위함이다.

버그 수리 : 더이상 제작자가 서포트할수 없는 레거시 소프트웨어를 고치기 위해 쓰인다.(예를 들면 어밴던웨어)

라이센스가 없거나 승인이 안된 복제품 생산 : 그러한 복제품은 때때로 컴퓨터 영역에서(computing domain)에서 복제품(클론clone)이라고 불린다.

학업/학습 목적 : 교육 목적을 위한 리버스 엔지니어링은 아마 성공적이지 못한 설계나 차후의 설계 증진의 중요한 이슈로 이해 될 수 있다.

경쟁력 있는 기술적 정보(인텔리전스가 information과 다른점은 기밀과 정보로 알고있는데 여기서도 그뜻인가요.) : 그들의 경쟁자사 실제로 하고있는 것을 이해하는것과 그들이 하고있는 것들 말하는 것의 대조(무슨뜻인지 잘 모르겠습니다.)

비용 절감(있어보이게 돈 절약대신 비용 절감이라고 썼습니다) : 전자기계의 한 부분이 얼마나 수용 가능한지를 이해 할 때 이것은 분리된 제품의 비용으로부터 사용자가 비용을 절감할 수 있다.

리퍼포징(repurposing 수리. 컴퓨터용어로 그냥 '리퍼포징'이라고 읽는것 같습니다.) : 수리하지 않으면 노후화 될 부품들을 리퍼포징할 기회는 좀 더 큰 유틸리티의 몸체속에 포함되어 질 수 있다.(?)

일반적인 상황[편집]

기계 역공학

캐드가 보편화 되면서, 리버스 엔지니어링은 CAD,CAM,CAE 혹은 다른 소프트웨어에서 물리적으로 존재하는 부분을 3D 가상 모델로 만들 수 있는 방법이 되었다. 리버스 엔지니어링 과정은 물체를 측정하고 3D모델로 재건설하는 과정을 포함한다. 물리적인 물체는 CMMs, 레이저 스캐너, 구조화된 빛 디지털 변환기(structed light digitizers), CT스캐너같은 3D스캐닝 기술로 측정 될 수 있다. 이 측정된 데이터는,종종 point cloud라고 불리는, 위상정보가 빠져있고, 그러므로 종종 측정된 데이터는 좀더 사용 가능한 형태로 가공되어지고 모델로 되어진다. 예로는 삼각형의 매쉬, NURBS 표면의 집합 혹은 캐드의 모델이 있다.

리버스 엔지니어링은 또한 실재하는 지형을 디지털 기계의 개발 환경으로 가지고 오기 위해 쓰고, 제품의 디지털 3D 레코드를 만들기위해, 또한 경쟁자들이 제품을 평가하기 위해 쓴다. 예를들면 리버스 엔지니어링은 제품이 어떻게 작동하는지, 제품이 무엇을 하는지, 그리고 어떤 요소로 이루어져 있는지, 비용은 얼마인지, 그리고 잠재적인 특허 침해를 확인하기 위해 쓰인다.

가치공학(VE) 또한 이러한 활동과 관련되어 있다. 그것은 제품을 분해하고 분석하는것을 포함하나, 목적은 비용절감이다.

소프트웨어 역공학

소프트웨어에서의 리버스엔지니어링은 사람마다 다르며, Chikofsky 와 Cross는 다양한 사용을 조사하고, 분류할 것을 촉구하고 있다. 그들에 따르면, "리버스 엔지니어링은 추상적인 하이레벨에서 시스템을 대표하는 Subject 시스템을 분석하는 과정이다"라고 표현했다. 이것은 또한 "개발과정을 통하여 뒤로 가는 것" 으로도 볼 수 있다. 이러한 모델에서 시행과정의 결과(소스코드 형태에서)는 분석단계에서 역공학 되고, 전통적인 폭포모델(waterfall model)의 도치에 있다(?)

In this model, the output of the implementation phase (in source code form) is reverse-engineered back to the analysis phase, in an inversion of the traditional waterfall model. Another term for this technique is program comprehension.[3]

Reverse engineering is a process of examination only: the software system under consideration is not modified (which would make it re-engineering). Software anti-tamper technology like obfuscation is used to deter both reverse engineering and re-engineering of proprietary software and software-powered systems. In practice, two main types of reverse engineering emerge. In the first case, source code is already available for the software, but higher-level aspects of the program, perhaps poorly documented or documented but no longer valid, are discovered. In the second case, there is no source code available for the software, and any efforts towards discovering one possible source code for the software are regarded as reverse engineering. This second usage of the term is the one most people are familiar with. Reverse engineering of software can make use of the clean room design technique to avoid copyright infringement.

On a related note, black box testing in software engineering has a lot in common with reverse engineering. The tester usually has the API, but their goals are to find bugs and undocumented features by bashing the product from outside.[11]

Other purposes of reverse engineering include security auditing, removal of copy protection ("cracking"), circumvention of access restrictions often present in consumer electronics, customization of embedded systems (such as engine management systems), in-house repairs or retrofits, enabling of additional features on low-cost "crippled" hardware (such as some graphics card chip-sets), or even mere satisfaction of curiosity.

espionage 스파이 행위 knockoff 중단 / 모조품 design feature 설계 특징 tailored ~맞춤의 Obsolescence 노후 incorporate 포함하다. 설립하다. legacy 유산 -> 컴퓨터: 컴퓨터 분야에서 과거로부터 물려 내려온 기술, 방법, 컴퓨터 시스템 및 응용 프로그램을 의미하며, 새로이 대체 가능한 기존의 기술 as is 있는 그대로 funtional 기능위주의 , 실용적인 specification 설명서 / 사양(컴퓨터 사양 이런거) circumvent 우회하다. subsequent 차후의 inversion 도치