2008-09-16 3 views
4

누구든지 펄에 대한 좋은 코드 obsfucator를 알고 있습니까? 나는 클라이언트에게 그것을 공개하기 전에 코드를 obsfucating하는 옵션을 들여다 볼 것을 요청 받고있다. 나는 obsfucated 코드가 여전히 리버스 엔지니어링 될 수 있다는 것을 알고 있지만 이것이 우리의 주된 관심사는 아닙니다.Perl 코드를위한 훌륭한 obfuscater가 있습니까?

일부 고객은 우리가 제공 한 소스 코드를 약간 변경하고 있으며, 문제가 생겼을 때 우리에게 악몽을 퍼붓고 수정해야합니다. 변경되었습니다. 그래서 의도는 단지 코드를 변경하는 것이 어렵 기 때문입니다 (어쨌든 그렇게하지 않아야 함).

+3

충분히 펄 난독로 작성된 코드를 가지고 있지가요 ;-) 코드가 매우 깨끗 것 Acme::Bleach을 사용하는 것입니다? 모든 심각성에서 여분의 공백을 제거하는 간단한 정규식은 먼 길을 갈 것입니다 – rpetrich

+0

나도이 항목이 농담이어야한다고 생각했습니다! – orbfish

답변

31

필자는 전에이 길을 걸어 봤다. 개발자가 개발자의 작업을 수행 할 때 클라이언트 서버의 문제를 디버깅하는 데 엄청난 비용이 쏟아지기 때문에 "난처한"코드를 사용해야하는 것은 절대적인 악몽이다. 코드를 읽지 마라. "deobfuscators"를 사용하여 "실제 코드"를 클라이언트 서버에 복사하거나 여러 가지 다른 문제 중 하나를 유지 관리하는 진정한 번거 로움이됩니다.

내가 어디에서 왔는지는 잘 알고 있지만 관리에 문제가있는 것처럼 들리지만 올바른 해결책이 무엇인지 알기보다는 선택한 솔루션을 구현하는 것이 좋습니다.

이 경우 실제로 라이센스 또는 계약상의 문제 인 것 같습니다. 코드 오픈 소스를 가지고 있지만 라이센스의 일부로 제출하여 변경 사항을 제출하면 승인을 받아야합니다. 패치를 푸시 할 때 모든 코드의 md5 합계를 확인하고 예상과 일치하지 않으면 라이센스 위반으로 인해 비용이 청구됩니다 (훨씬 더 높은 요금이어야합니다). (코드 오픈 소스를 허용 한 한 회사는 기억하지만, 변경 한 경우 2 만 5 천 달러의 비용을 "샀다"고 말하면서 버그 수정이나 업그레이드에 대한 책임을지지 않게되었습니다. 새로운 라이센스).

+0

감사합니다. 와우 사람들이 여기에 빠르게 답합니다! 나는 내 사장과상의 할 것이고, 나는이 접근법보다는 라이센스 집행 접근법을 채택 할 수 있는지 확신 할 수 있는지 알아 보겠다. –

8

제발 그렇게하지 마십시오. 사람들이 당신의 Perl 코드를 변경하는 것을 원하지 않는다면 적절한 라이센스하에두고 그 라이센스를 시행하십시오. 라이선스를 통해 라이선스를 변경할 때 사람들이 코드를 변경하면 설치가 더 이상 작동하지 않을 때 문제가되지 않습니다.

자세한 내용은 perlfaq3's answer to "How Can I hide the source for my Perl programs?을 참조하십시오.

15

하지 마십시오. 그냥 하지마.

소프트웨어의 변경 사항에 대해 책임을지지 않으려면 계약서에 기재하거나 계약서를 수정하십시오. 그들이 코드를 작성한 후 수정하려고하면 코드을 난독 화하여 해결되지 않는 클라이언트 문제가 발생합니다. 그리고 만약 당신이 그것을 모호하게하고 실제적인 문제를 만나면 행운을 빌어서 버그 수 보고서에 행 번호 등을 정확히 알려주도록하십시오.

5

고객이 코드를 수정하여 문제를 해결하는 것이 주된 문제인 것처럼 보입니다. 나는 그들이 당신에게 지원을 요청할 때 파일의 체크섬 (md5, sha 등)을 요청하고 패치 할 때 파일의 체크섬을 확인하는 것이 좋습니다. 예를 들어 클라이언트에게 설치 프로그램을 통해 제공되는 프로그램의 출력을 제공하도록 요청하고 모든 파일을 체크섬 할 수 있습니다.

궁극적으로 그들은 코드를 가지고 있으므로 원하는대로 할 수 있습니다. 라이센스를 시행하고 수정되지 않은 코드 만 지원하는지 확인하는 것이 최선의 방법입니다.

4

이 경우 난독 처리가 잘못된 방법입니다.

클라이언트에 코드를 릴리스 할 때 코드를 디스크에 저장하거나 태그/분기로 버전 관리에 저장하는 것이 좋습니다.

그런 다음 클라이언트가 변경 한 경우 사용자가 보낸 코드와 변경된 코드를 쉽게 비교할 수 있습니다. 결국 변경해야 할 필요성이 느껴지면 어딘가에서 문제가 발생하므로 마스터 코드베이스에서 수정해야합니다.

2

난독 처리의 대안은 ActiveState's Perl Dev Kit과 같은 것을 사용하여 스크립트를 바이너리로 변환하는 것입니다.

3

이것은 심각한 제안은 아니지만, Acme::Buffy을 살펴보십시오.

적어도 하루를 밝게 할 것입니다!

4

프로그램을 이진 파일로 변환하는 또 다른 방법은 무료 PAR-Packer 도구 (CPAN)입니다. 다른 사람들이 말했듯이, 코드 난독 화를위한 필터조차도 있습니다. 그것은 가치가있는 것보다 더 큰 문제 일 수 있습니다.

2

몇 명의 사람들이 이미 말했듯이 :하지 마십시오.

Perl 인터프리터의 특성상 Perl이 난독 화 스크립트/바이너리 거짓말을 남겨 둘 필요가 있음을 의미하기 때문에 Perl 인터프리터의 특성에 따라 Perl을 난독 화하기위한 모든 작업을 취소 할 수 있어야합니다. 통역사 (및 귀하의 고객)가 그것을 찾을 수있는 곳 주변 :)

실제 문제를 해결하십시오 : 체크섬 및/또는 적절하게 말한 라이센스. 그리고 '당신이 그것을 바 꾸었습니다. 우리는 면허 34b 항을 요구하고 있습니다. 우리는 그것을 만지기 전에 $ X, 000이 될 것입니다. '...

더 일반적인 대답은 why-should-i-use-obfuscation을 읽으십시오.

2

Windows O/S를 실행 중이고 IndigoSTAR에서 perl2exe를 사용 중입니다. 결과 .EXE 파일은 현장에서 변경 될 것 같지 않습니다.

다른 사람들이 말했듯이, "나는 그것을 어떻게 알아 듣지 못합니까"라는 것이 잘못된 질문입니다. "고객이 코드를 변경하지 못하게하려면 어떻게해야합니까?"라는 말이 맞습니다.

4

이전 제안 사항에 동의합니다.

그러나 실제로 원하는 경우 PAR 및/또는 Filter::Crypto CPAN 모듈을 볼 수 있습니다. 함께 사용할 수도 있습니다.

우리는 광학 미디어에서 우리 제품을 선적 할 때 "보호"라는 매우 가벼운 형태로 후자 (Filter :: Crypto)를 사용했습니다. 그것은 당신을 "보호"하지 않지만 소스 파일을 수정하려는 사람들의 90 %를 막을 것입니다.

2

체크섬 및 계약 아이디어는 설명하는 "문제점"을 방지하는 데 유용하지만 롤아웃 업그레이드 및 버그 수정의 어려움이있는 경우 고객이 통과하지 못한 변경 사항은 무엇입니까? 포괄적 인 테스트 스위트? 그들이 이러한 변경 작업을 수행 할 수 있다면 (또는 적어도 코드가 원하는 것을 표현하는 변경 작업) 지원 티켓을 열고 패치를 업로드하는 것이 쉽고 자동화되지 않는 이유는 무엇입니까? 고객은 고객이 원하는 것을 항상 정확히 입니다. ("올바른 방법"을 수행하는 방법에 대한 단서가 없을 수도 있지만, 그 이유는 고객에게 지불하는 이유입니다.)

난독 화가를 원하는 더 좋은 이유는 모든 고객이 서있는 계약을 체결하지 않은 대대적 인 시장 용 데스크톱 배포를위한 것입니다. 이 경우, 같은 것을 PAR - 암호화 된/난독 화 논리를 컴파일 된 바이너리로 압축하는 방법은 없습니다.

1

변경 사항을 제공 할 수 있도록 해당 SVN 트리에 SVN 트리를 초대하고 변경 사항을 내 개발 트리에 통합 할 수 있습니다.

싸우지 말고 포용하십시오.

1

오비드 (Ovid)가 말했듯이, 그것은 계약상의 사회적 문제입니다. 코드를 변경하면 보증이 무효화됩니다. 이 문제를 해결하기 위해 많은 금액을 청구하지만, 동시에 변경 사항을 제안 할 수있는 채널을 제공하십시오. 가능한 경우 구성을 변경하고 변경하려는 부분을 살펴보십시오. 그들은 그들이하고 싶어하는 것을 가지고 있으며, 당신이 그것을 만족시킬 때까지, 그들은 계속 당신 주위로 가려고 노력할 것입니다.

Mastering Perl에서 나는 obfucators를 물리 치기에 대해 조금 이야기합니다. 말도 안되는 변수 이름 등을 작성하는 경우에도 Perl::Tidy과 같은 Perl 도구와 함께 B::DeparseB::Deobfuscate과 같은 모듈을 만들면 지식이 풍부하고 의욕적 인 사용자가 소스를 쉽게 얻을 수 있습니다. 어쨌든 코드를 어떻게 처리해야할지 모르기 때문에 무의미하고 무모한 것에 대해 걱정할 필요가 없습니다.

저는 관리자에게이 문제에 관해 이야기 할 때 일반적인 비용 편익 분석을 진행합니다. 당신은 할 수있는 모든 종류의 물건이 있지만, 그것의 다량이 당신이 얻는 이득보다 적게 비용.

행운을 빌어 요,

0

또 다른되지 심각한 제안, 그것은