코드 난독 화의 경우?

코드를 개발하는 사람들과 해당 코드를 실행하는 비즈니스 (문제의 코드가 실제로 상용 코드 인 경우)에게 실질적인 이익이라는 측면에서 난독 화 된 코드를 작성해야하는 가장 큰 이유는 무엇입니까? 난독 화가 나쁜 것보다 더 좋은시기를 설명하는 문서화 된 사례 (일부 지역에서 온라인으로 제공)가 있습니까? 예를 들어, 난독 화가 악의적 인 제 3자가 코드를 가져 오는 것을 의미있게 지연시키는 것으로 잘 알려진 예가 있습니까? 자동차 창문을 굴리는 것처럼 사람들이 차를 깨고 스테레오를 훔치는 것을 막지 않는 것처럼 코드를 난독 화하면 정직한 사람들이 정직하게 유지됩니다.

=========

배경:

이것은이 주제에 대한 나의 가정에 고의로 도전하려는 시도입니다.

나는 일반적으로 코드 난독 화를 사용하는 것에 대해 큰 시간을 보내고 있지만 뭔가 빠진 것이 궁금합니다. JavaScript와 같은 경우 최소화로 인해 더 빨리로드하는 데 도움이되는 이유를 알 수 있지만 실제적인 기능적 이점이 있습니다.하지만 코드 난독 화를 일으키는 단일 이유 는 장애물이되는 이유가 없습니다. 코드 / 알고리즘의 섹션이하는 일을 발견하는 것은 실제로 어떤 목적에도 효과적입니다.

오픈 소스가 열렬한 인기를 끌면서 질문은 "코드를 공유하거나 독점적인가?" 상업용 코드에 관해서는, 왜 모든 것을 공유 할 수 없는지 이해할 수 있으며, 도둑과 싸울 법이 있습니다.

BTW, 누군가가 난독 처리 된 코드를 작성하는 이유가 "직업 보안"인 경우 일관되게 발견 된 프로그래머를 해고하고 의도적으로 난독 화 를 사용하여 작업을 유지하는 데 도움이되는 유일한 목적으로 해고 할 것입니다. 사업상의 이점. 그것은 완전히 반팀이어서 말도 안되며, 잘못 안내 된 관행을 통해 업무를 유지하고 멋진 소프트웨어를 작성하기 때문에 유지하는 데 더 관심이있는 사람을 지적합니다.

나는 사람들이 보통 농담을하고 있다는 사실을 알고 있지만, 직업 안전만을위한 난독 화가 좋은 생각이라는 기본적인 견해에 대한 답변을 막고 싶기 때문에이 특정한 경우에 대해서만 언급한다.

난독 화에 대한 매우 흥미로운 사용 사례 중 하나는 불법 복제의 출처를 추적하는 것입니다. 난독 처리가 상대적으로 저렴한 작업이라고 가정하면 원본 작성자는 각 클라이언트에 다른 난독 처리 된 버전의 응용 프로그램을 제공 할 수 있습니다. 불법 복사본이 발견되면 작성자는 제공된 버전과 비교하여 불법 복제의 출처를 추적 할 수 있습니다.

그것은 "반역자 추적"암호 체계 에서 영감을 받아 변형 된 형태의 스테 가노 그라피 입니다. 공통적인지 ¹ , 또는 좋은 아이디어인지는 모르겠지만 실제로 다음 매개 변수에서 적용되는 것을 보았습니다.

• 단 2 개의 공급 업체로 경쟁이 치열한 전국 시장
• 약 50 개의 배포가 시장을 덮었 고
• 두 응용 프로그램의 평균 개발 시간은 몇 년 (약 1 년)이었습니다.
• 우리 응용 프로그램의 평균 난독 처리 시간은 몇 시간이었습니다.
• 두 응용 프로그램의 수명은 약 10 년으로 예상되었습니다.

근거는 과정이었다 무명 통해 보안 처음에, 그것은 어떤 점에서 전술 체계에서 진화 ² . 두 벤더 모두 합법적으로 서로의 이진 코드에 액세스 할 수 있었고 두 디 컴파일 시도가 예상되는 것이 분명하다고 생각합니다. 난독 화는 장기적으로 보안 측면에서 아무 것도하지 않았습니다. 두 벤더 모두 매우 수익성 있고 틈새 시장에서 일하는 동기가 높고 재능있는 팀을 보유하고 있었으며 결국 우리 제품은 비슷하지 않았으며 모호하지 않은 다른 수단을 통해 경쟁 우위를 확보했습니다.

(a) 경력 초기에 설계 결정이나 추적 계획의 결과 (있는 경우) 및 (b) 내 참여 중 일부에 대한 명확한 개요를 얻지 못했기 때문에 실제로 확장 할 수 없습니다. 프로젝트는 NDA하에있었습니다.

난독 화에 대한 또 다른 유효한 사용 사례는 코드를 제 3 자에게 제출 해야하는 법적 의무 가있는 경우 일 수 있습니다 .

회사에서 기술 회사를 위해 IP 작업을 수행하거나 소프트웨어 소스 코드와 관련된 경우에는 고객의 소스 코드를 USPTO, 법원 또는 제 3 자에게 제출해야 할 수 있습니다.

소스 코드는 영업 비밀로 간주되기 때문에 대부분의 규제 기관은 "50 %"규칙을 사용합니다. 제출 된 소스 코드가 가려져 그대로 사용할 수 없습니다.

IANAL 및 링크는 실제 작업 코드가 아닌 하드 코드 사본과 관련이 있으므로 이는 전혀 관련이 없습니다.

이제 자바 스크립트는 난독 화의 일반적인 예이므로 일반적으로 고려되지 않는 부작용이 있으며, 난독 화 된 자바 스크립트에서 악성 코드가 숨겨져 있습니다. ³ Javascript 를 축소하면 확실한 이점이 있지만 실제 난독 화에 대해서는 아무런 언급이 없으며 Douglas Crockford가 저에게 동의합니다 .

마지막으로 코드 프라이버시 문제가 있습니다. 이것은 잃어버린 원인입니다. 결정된 해커가 귀하의 프로그램을 이해하지 못하게하는 변환은 없습니다. 이것은 모든 언어의 모든 프로그램에 적용되는 것으로 판명되었습니다. JavaScript는 소스 형식으로 제공되기 때문에 더욱 분명합니다. 난독 화로 인한 개인 정보 보호 혜택은 환상입니다. 사람들이 프로그램을 보지 못하게하려면 서버를 분리하십시오.

"작업 보안"에 대한 난독 화에 관해서는, 이는 코드 검토를 절대 통과해서는 안되는 행동이며, 식별 된 경우 허용되지 않아야합니다. 처음에는 범인을 해고하지는 않지만 반복 범죄자들은 ​​적어도 좋은 스 패킹을받을 자격이 있습니다.

결론적으로, 난독 화는 모호함을 통한 보안의 전형적인 예이며, 억제력과 같은 것이 아니라는 것은 명백한 장점입니다. 이 창조적 인 사용 사례 수 있습니다 ⁴ 내가 아는 없지만, 일반적으로 혜택은 기껏해야 최소한이다.

_{¹ 이것을 작성한 후 나는 기본적으로 동일한 체계를 설명하는 이 대답 을 찾았 으므로 더 일반적으로 생각할 수 있습니다.
² 스테 가노 그래피는 여전히 모호성을 통해 안전합니다.
³ 축소 ~ 공백을 제거하고 토큰을 단축하며 의도적으로 모호하지 않습니다.
⁴ 않는 국제 난독 C 코드 대회는 계산?}

코드 난독 화의 경우 코드가 어떤 / 어떻게 작동 하는지를 판단하기 위해 타사의 기준을 높입니다.

그러나 이것이 개발자가 난독 처리 된 코드를 작성해야한다는 의미 는 아닙니다 .

참조, 이것은 귀하의 질문에서 누락 된 것입니다 : JavaScript 난독 화와 같은 코드 난독 화는 개발자가 수동으로 수행 할 필요가 없으며 그렇게해서는 안됩니다. 마찬가지로 이것은 버전 제어에서 핵심 소스 파일로 저장되어서는 안됩니다.

코드 난독 화는 프로덕션 빌드로 컴파일하는 동안 사후 처리 단계로 발생해야합니다. 이 작업을 수행 할 타사 제품이 많이 있으므로 집에서이 작업을 수행 할 이유 가 거의 없습니다.

예를 들어 : Dotfuscator

IEEE는 코드 난독 화 의 효과에 관한 논문을 가지고 있습니다

결과에 따르면 이름을 바꾸면 공격의 효율성이 현저히 낮아져 적어도 성공적인 공격을 완료하는 데 필요한 시간이 두 배로 늘어납니다 (최악의 경우에도 최악의 시나리오에서도). 또한 난독 화 는 초보자와 숙련 된 공격자 사이의 격차를 줄여 후자를 덜 효율적 으로 만들고 공격하기 쉬운 시스템을 본질적으로 침입하기 어려운 시스템과 더 명확하게 유사하게 만듭니다.

강조합니다.

MMORPG 개발에 참여했습니다. 여기에는 서버 로직과 클라이언트 로직이 포함됩니다. 다년간의 프로젝트 개발 과정에서 클라이언트와 서버 간의 인터페이스를 고려할 때마다 항상 해킹 당했다는 가정하에 클라이언트가 서버에 의해 항상 처리되어야한다는 것이 규칙이었습니다. 다시 말해, 서버는 서버에서 장애를 일으키거나 클라이언트가 부정 행위를 할 수있는 클라이언트로부터 응답이 없을 수있는 방식으로 작성되어야했습니다. 그러나 처음부터 해커가 필연적으로 시스템에서 구멍을 찾아서 속임수로 악용하는 것으로 알려졌습니다. 그리고 얼마 후 그들은했다.

물론 고객을 위대한 세계로 운송하기 전에 고객을 난독 처리해야합니다. 난독 화는 다음과 같은 영향을 미쳤다고 생각합니다.

1. 비전문가 해커도 시도하지 못하게 막았습니다.
2. 그것은 해커를 달성하는 데있어 전문 해커를 지연시켰다.
3. 전문 해커가 해킹 한 횟수를 줄였습니다.
4. 해킹의 효과가 제한되었습니다.
5. 가장 중요한 것은 해커가 해킹 작업을 수행하기 전에 해킹 된 클라이언트를 서버에 대해 더 많은 테스트 실행을 수행하게함으로써 서버 로그에서 불규칙한 활동을 찾아서이를 발견 할 가능성을 높였습니다.

발견 된 해커의 게임 계정은 환불없이 해지되었으므로 해킹 비즈니스의 비용과 매력이 떨어졌습니다.

따라서 위의 모든 사항으로 인해 난독 화가 게임에서 전반적으로 긍정적 인 영향을 미쳤으며, 더 나아가 난독 화는 해킹 당하기 쉬운 소프트웨어에 전반적으로 긍정적 인 영향을 줄 수 있다고 생각합니다. (예 : 복사 방지 조치가 포함 된 소프트웨어)

난독 화가 유지 관리에 미치는 영향은 거의 없었습니다. 경험이 부족한 일부 프로그래머가 식별자의 이름에 대해 가정을 한 곳이 몇 군데 있었지만 (그들은 리플렉션을 사용하고 있었지만) 일단 정리하면 모든 것이 잘되었습니다. 난독 화 단계는 게임의 프로덕션 버전에 대한 전체 빌드 단계의 일부가되었으므로 대부분의 개발자는 그것에 대해 걱정하거나 관련이 없습니다. 우리는 이미 게임의 로그를 볼 수있는 도구를 가지고 있었기 때문에, 즉시 로그를 번역하기 위해 obfuscator가 생성 한 연관 테이블 (난독 화 된 식별자를 적절한 식별자로 매핑)을 사용하도록 도구를 수정했습니다. 현장에서 수집 한 로그를 기반으로 사후 검사를 수행하는 동안 난독 처리 된 식별자를 확인해야했습니다.

난독 화 된 코드를 읽고 이해 (그리고 분명히 작성)하는 것은 흥미로운 정신적 도전이 될 수 있습니다. 아마도 당신이 요구 한 것의 범위를 벗어나는 것이지만, IOCCC 와 같은 예 는 공포뿐만 아니라 오락의 원천이 될 수 있습니다.