Electron: Electron으로 앱을 빌드하면 소스가 정말 보호되나요?

아니요, asar 아카이브에 패키징한 경우에도 소스 코드를 얻는 것은 매우 쉽습니다. V8 JavaScript 엔진은 소스 코드를 숨기도록 설계되지 않았습니다. NW.js는 소스 코드의 한 파일을 완전히 숨기는 데 성공하지만 상당한 성능 저하를 초래합니다.

따라서 정말로 소스 코드를 보호하려면 C++로 작성하고 네이티브 Node 모듈을 만들어야 합니다.

몇 가지 옵션이 있지만 제공하는 보호 수준은 @zcbenz가 언급한 이유로 제한됩니다.

• C++ 노드 애드온에서 자체적으로 일부 암호 해독 논리를 구현할 수 있지만 여전히 손상될 수 있습니다(예: 프로그램을 디버그하고 암호 해독 후 평가 전에 소스 복사).
• 도 있습니다 EncloseJS 은 전자 작동 할 수 있도록 주장, Node.js를 / io.js에 대한 코드를 컴파일하는 것을.
• 유사한 프로젝트인 nw.js 는 일종의 보호 기능을 제공하는 v8 스냅샷을 지원합니다(자세한 내용은 여기 참조).

이 모든 방법에는 약간의 성능 저하가 발생합니다.

@etiktin 나도 이 문제를
C++ 애드온에서 node.js 코드를 직접 적용할 수 있습니까?

@fritx , 노드에는 코드를
사용자는 여전히 개발자 도구를 열고 로드된 스크립트를 볼 수 있습니다. 사용자 정의 Electron 빌드를 사용하여 차단하고 Electron 빌드가 변조되지 않았는지 확인하는 애드온 검사를 사용하더라도 사용자는 여전히 메모리의 문자열로 코드를 볼 수 있습니다.

좋은 소리 소스를 보호! :열쇠:

그렇다면 GitKraken, Whatsapp 또는 Slack과 같은 폐쇄형 코드 전자 앱이 코드를 숨길 수 있는 방법에 대한 질문이 있습니다.

@ alexis57 같은 질문이 있습니다. 아마도 검사 요소가 비활성화되었거나 뭔가가있을 수 있습니다.

아니면 주요 코드가 C/C++ 라이브러리에서 가져온 다음 GUI용으로 전자를 사용하는지 알 수 없습니다.

whatsapp과 slack이 소스 코드를 보호하는 방법을 알고 싶습니다.

AFAIK 그것은 단순히 보호되지 않습니다. app.asar를 추출하고 소스 코드에 액세스할 수 있습니다. 응용 프로그램의 민감한 부분에 대해 위에서 제안한 것처럼 일반적으로 C/C++와 같은 컴파일된 언어로 사용자 지정 애드온을 작성합니다.

C++ 코드를 어떻게 컴파일할 수 있습니까?

참조: https://nodejs.org/api/addons.html

@boeserwolf 감사합니다! :)

구독

node-ffi 로도 가능합니다. Electron은 UI에만 사용해야 합니다.

C/C++로 코드를 작성한 다음 emscripten 과 같은 도구를 사용하여 웹 어셈블리로 변환하는 방법을 좋습니다 . 이것은 Chromium에서 잘 작동합니다.

충분한 노력으로 무엇이든 분해/난독화할 수 있습니다. JavaScript로 코드를 작성하고 ASAR에 포함시키면 대다수의 사람들이 접근하지 못하게 됩니다. 저작권/라이선스가 적용되지 않는 코드를 보호해야 하는 이유가 있습니까?

여기 내 2센트, NW가 v8 스냅샷 문제를 해결하는 것 같습니다.
https://nwjs.io/blog/js-src-protect-perf/

nwjs에서 이전에 30%였던 "컴파일된 바이너리 코드가 이제 성능 오버헤드 없이 JS 소스 코드만큼 빠르게 실행됨"이라는 기사를 보았고 NW의 이후 릴리스에서 기본적으로 활성화될 것입니다.

이것에 정말 관심이 있어서 @craftpip 기사도 빨간색으로 표시

개발자 입장에서는 너무 불편합니다. 포기하고 NW로 바꾸세요...

매우 우아한 방식으로 코드 보호를 사용하는 다른 node.js 프로젝트를 공유하고 싶습니다: https://github.com/zeit/pkg

Electron에 소스 보호에 대한 희망이 있습니까?

일부 부분에 C++를 사용하는 것 외에도 JavaScript 소스를 축소하고 _obfuscate_할 수 있습니다(예: javascript-obfuscator 사용 ).

축소와 난독화는 코드를 "도용"하는 데 필요한 노력을 _극적으로_ 증가시키며(따라서 _비용_), 종종 처음부터 전체 애플리케이션을 쉽게 리버스 엔지니어링하는 것이 훨씬 더 실현 가능해지는 지점까지 갑니다. 기술적으로 할 수 있는 일은 없습니다. 당신이 완전한 네이티브가 되더라도 리버스 엔지니어링에 대해하십시오 (법을 찾는 것 외에는 아무 것도 없음).

소스 코드를 숨기는 것에 대해 걱정하지 않지만 다음과 같은 비밀을 숨기고 싶다면:

• OAuth 자격 증명
• 공개 대상이 아닌 URL(예: 비공개 백엔드 API 엔드포인트)
• REST API 자격 증명
• 모든 키 및 비밀
• 비밀번호

이 문제를 해결하기 위해 무료 서비스를 만들었습니다. 상용 전자 앱을 만들고 있는데 자격 증명이 도용될까 걱정이 되어 만들게 되었습니다.

그것은 실제 전자 응용 프로그램 IFF를 시작하는 크로스 플랫폼 도우미 응용 프로그램을 만들어 작동합니다. 응용 프로그램이 변경되지 않았습니다. 응용 프로그램을 시작하면 환경 변수를 통해 자격 증명을 전달합니다.

추가 정보:

소개:
https://medium.com/@rocketlaunchr.cloud/introducing -electron-vault-d09ade2c2020

선적 서류 비치:
https://rocketlaunchr.github.io/electron-vault-docs/

@JohnWeisz

If the data is indeed sensitive, I think it should be handled by a remote server.

원격 서버 서버는 클라이언트가 실제로 변경되지 않은 Electron 앱임을 어떻게 진정으로 알 수 있습니까?
그것이 내가 해결하려고 했던 문제입니다.

Client Credentials 부여 유형과 함께 OAuth를 사용하는 경우 client_secret 는 여전히 애플리케이션에 구워지고 이론적으로 누구나 읽을 수 있습니다. Electron 소스 코드가 100% 열려 있고 사용 가능하므로 "흥미로운" 문자열을 쉽게 검색할 수 있습니다.

문제를 해결하는 100% 확실한 방법은 없지만 내 솔루션이 확실한 개선이라고 생각합니다.

웹팩이나 angular2/4/6 또는 vuejs2와 같은 SPA 프레임워크로 JS 앱을 빌드하면 이것이 가능하다고 생각합니다. 이렇게 하면 asar 파일을 추출하더라도 코드를 읽기 힘들 수 있습니다.

문제가 실제 암호화에만 초점을 맞춰서는 안 된다고 생각합니다. 그러나 사실 다른 응용 프로그램/사용자가 클라이언트의 소스 코드를 변조하지 않았습니다.

서명된 asar를 보관하거나 소스 코드가 로드되는 유사한 바이너리를 사용하면 전자가 파일의 무결성을 확인할 수 있습니다. 무결성 검사가 전자 바이너리 자체에 통합될 수 있기 때문에 자바스크립트 코드에 과부하가 발생하지 않습니다. 기본적으로 빌드 시 전자는 --include-integrity-check 플래그를 얻을 수 있습니다. 그렇지 않으면 일반적인 방법으로 컴파일됩니다.

@tulpn

무결성 검사가 전자 바이너리 자체에 통합될 수 있기 때문에 ...

-- 그러면 이미 Electron이 하는 무결성 검사나 암호화/복호화를 추출하는 것뿐이며 소스 코드가 있습니다. 나는 난독화가 여기에서 취할 수 있는 유일한 접근 방식이라고 확신합니다(축소, 축소+난독화 또는 기본 코드 컴파일).

또는 일부 앱 코드를 원격 서비스로 이동합니다(보안이 필요한 경우 인증 포함).

데이터를 암호화하고 런타임에 암호를 해독하고 토큰이나 모든 종류의 민감한 데이터와 같은 변수에 직접 로드할 수 있지만 전체 자바스크립트 파일 암호화에 대해 이야기하는 경우 성능이 저하됩니다. Node C++ Addons에 기회를 줄 수 있습니다.

nodejs는 다음과 같이 말합니다.

Node.js 애드온은 C++로 작성된 동적으로 연결된 공유 객체로, require() 함수를 사용하여 Node.js에 로드할 수 있으며 일반 Node.js 모듈처럼 사용할 수 있습니다. 주로 Node.js에서 실행되는 JavaScript와 C/C++ 라이브러리 간의 인터페이스를 제공하는 데 사용됩니다.

기본적으로 코드를 바이너리로 컴파일하므로 코드를 추상화할 수 있고 성능이 훨씬 빨라지고 코드를 어느 정도 숨길 수 있습니다.

아니요, asar 아카이브에 패키징한 경우에도 소스 코드를 얻는 것은 매우 쉽습니다. V8 JavaScript 엔진은 소스 코드를 숨기도록 설계되지 않았습니다. NW.js는 소스 코드의 한 파일을 완전히 숨기는 데 성공하지만 상당한 성능 저하를 초래합니다.

따라서 정말로 소스 코드를 보호하려면 C++로 작성하고 네이티브 Node 모듈을 만들어야 합니다.

C++ 애드온에서 devtools를 비활성화하는 방법과 C++ 애드온에서 전자의 모든 API에 액세스하는 방법은 무엇이며 devtool 없이 앱을 패키징할 계획이 있습니까? 해킹을 방지하고 애플리케이션 크기를 줄이는 데 도움이 될 수 있습니다( @ zcbenz )

우리는 소스코드가 공개되는 것에 지쳤습니다. 나는 nw로 이사한다

@ahmtcn123 귀하의 의견이 이 문제를 해결하는 데 어떻게 도움이 됩니까?

essense에 의해 소스 코드가 공개되어 있는 웹 기술을 사용하여 앱을 빌드하고 싶으므로 그러한 태도를 유지하지 마십시오.

• 이 문제를 해결하기 위해 Electron에 기여할 수 있습니다.
• C++ 모듈 작성
• 코드 축소/난독화/맹글링(소스 맵을 비활성화하는 것을 잊지 마십시오)
• 다른 유사한 기술(예: nw.js)로 이동하거나 기본으로 이동할 수 있습니다.
• 몇 가지 다른 솔루션이 여기에서 공유되었습니다. 성능에 대한 난독화를 교환할 수 있습니다(Electron의 성능/리소스 소비를 이미 알고 있는 경우에는 그렇게 분명하지 않은 선택입니다)

건배!

_편집: 계속 반대 투표하세요_ 🍿

왜 v8snapshot을 지원하지 않습니까?

나는 우리가 소스 코드를 완전히 보호할 수 없다는 것을 이해합니다. 그러나 또 다른 방법은 논리 코드를 보호하고 localhost를 통해 전자 UI에서 호출하기 위해 기본 컴파일된 기술(예: golang)을 사용하여 웹 서비스를 생성할 수 있습니다.

마지막 말

북서

이 문제가 종료된 이유는 무엇입니까?

소스 코드 를 숨기는 것은 코드를 보호하는 매우 나쁜 방법인

보호를 원하는 경우 중요한 작업을 수행하기 위한 인증, 암호화 등과 같은 보다 표준적인 방법을 사용하십시오.

진심으로, 당신은 당신의 앱을 C로 작성하고 바이너리를 배포할 수 있습니다. 어쨌든 우리는 당신의 소스 코드를 얻을 것입니다.

PD: 당신은 빅 보이즈(whatsapp web, slack, 팀, vscode)의 소스 코드에 접근할 수 있고 그들 중 누구도 그것에 대해 신경 쓰지 않습니다. 아마도 당신이 뭔가 잘못하고 있는 것입니다.

"""PD: 빅 보이즈(whatsapp web, slack, 팀, vscode)의 소스 코드에 액세스할 수 있으며 그들 중 누구도 신경 쓰지 않습니다. 아마도 당신이 뭔가 잘못하고 있는 것 같습니다."""

이보다 더 멍청한 주장은 거의 할 수 없습니다.

리버스 엔지니어링되고 비정상적이지 않은 방식으로 사용되는 것을 원하지 않고 소프트웨어를 판매하는 것은 실제로 사용자가 계속 사용하는 것을 막지 않는 정확히 이에 대한 법률이 있습니다.

@kidandcat

진심으로, 당신은 당신의 앱을 C로 작성하고 바이너리를 배포할 수 있습니다. 어쨌든 우리는 당신의 소스 코드를 얻을 것입니다.

계속해서 Microsoft Word, Photoshop 또는 최고 판매 게임과 같은 모든 최고 판매 앱의 소스를 얻으십시오. 당신은 억만 장자이고 나는 그것을 모르고 있습니까?

아니요, 저는 억만장자가 아닙니다. 왜냐하면 그 프로그램의 소스 코드를 가지고 있는 것은 쓸모가 없기 때문입니다. 당신은 그것을 가지고 무엇을 하시겠습니까?

여러분, 이 스레드에는 각 댓글에 대해 알림을 받는 많은 사람들이 있습니다. 건설적인 상태로 유지하세요.

제 생각에는 JavaScript의 소스 코드 특성을 처리하는 것이 많은 경우에 거래 차단기가 아닌 이유를 요약하면 다음과 같습니다.

• 여기에 나열된 많은 예시 앱/서비스는 주로 _traction_에 의해 구동됩니다. 예를 들어 Twitter를 사용하면 내부적으로 어떻게 작동하는지 정확히 알 수 없지만 완전히 복사하고 전체를 복제하더라도 트래픽, 광고, 브랜드, 지원 인프라, 등.
• 적절한 난독화로 인해 의미 있는 방식으로 소스 코드에 액세스하는 것이 극도로, _금지적으로_ 어려워지며, 원본에 의존하지 않고 애플리케이션 자체의 동작을 단순히 관찰하고 이를 기반으로 리버스 엔지니어링하는 것이 훨씬 더 실현 가능해집니다. 소스 코드 -- 예를 들어 C++의 경우와 매우 유사합니다.
• 저작권법으로 보호되는 애플리케이션에서 아이디어 및/또는 솔루션을 훔치는 것은 기술적인 문제가 아니라 법적 문제이므로 구현된 보호 수준에 관계없이 구현을 보호하는 것은 법적 문제입니다. 어설픈 중국 회사는 JavaScript로 작성되었는지 어셈블리로 작성되었는지에 관계없이 문제 없이 귀하의 로고와 앱을 훔칠 것입니다.
• 또한 난독화에 대해 확신이 서지 않는 경우 응용 프로그램에 C++ 코드를 포함하거나 다른 모든 것(C++ 포함)과 달리 직접 검사(역설계가 아닌)로부터 완벽하게 보호되는 원격 서비스로 코드를 이동할 수 있습니다. 그렇지만)

@JohnWeisz 는 정말 합리적인 말을 많이 했습니다. 또한 충분하지 않은 경우 오늘 WebAssembly를 사용할 수 있다고 덧붙입니다. 소스 코드를 보호하는 측면에서 이는 상당히 좋을 것입니다.

https://developer.mozilla.org/en-US/docs/WebAssembly

@kidandcat 사실입니까?"진심으로 C로 앱을 작성하고 바이너리를 배포할 수 있습니다. 어쨌든 소스 코드를 얻을 것입니다."

Google에서 검색했는데 C/C++에서 컴파일된 바이너리에서 소스 코드를 가져오는 것이 불가능한 것 같습니다. 기껏해야 어셈블리 문을 얻을 수 있습니다.

상업용 Windows 데스크톱 소프트웨어를 개발 중입니다. 코드 로직은 핵심 역량입니다. 이러한 논리는 클라이언트 측에서 실행되어야 하지만 경쟁업체가 이를 가져오는 것을 원하지 않습니다. 따라서 코드 보호는 제 경우에는 거래 차단기입니다.

@z1988hf

C/C++에서 컴파일된 바이너리에서 소스 코드를 가져오는 것은 불가능한 것 같습니다. 기껏해야 어셈블리 문을 얻을 수 있습니다.

이것이 실제로 의미하는 바는 원본 소스 코드 또는 이와 동등한 것을 리버스 엔지니어링할 수 있다는 것입니다. 일반적으로 너무 어렵고 비용이 많이 듭니다. 난독화된 코드에 대해서도 마찬가지입니다.

@kidandcat 사실입니까?"진심으로 C로 앱을 작성하고 바이너리를 배포할 수 있습니다. 어쨌든 소스 코드를 얻을 것입니다."

Google에서 검색했는데 C/C++에서 컴파일된 바이너리에서 소스 코드를 가져오는 것이 불가능한 것 같습니다. 기껏해야 어셈블리 문을 얻을 수 있습니다.

상업용 Windows 데스크톱 소프트웨어를 개발 중입니다. 코드 로직은 핵심 역량입니다. 이러한 논리는 클라이언트 측에서 실행되어야 하지만 경쟁업체가 이를 가져오는 것을 원하지 않습니다. 따라서 코드 보호는 제 경우에는 거래 차단기입니다.

또한 어셈블리는 코드 메이트이며 논리가 있습니다. 코드를 컴파일하는 것보다 코드를 보호하기 위해 더 많은 작업을 수행해야 합니다. (그러나 @JohnWeisz가 말했듯이 리버스 엔지니어링 소프트웨어는 매우 비싸므로 경쟁자가 시도하기 위해 수천 달러를 투자하는 데 관심이 없다면 걱정할 필요가 없습니다)

Slack과 같은 앱을 소스 코드 보호에 신경 쓰지 않는다고 언급하는 사람들에게는 모든 앱에 대한 최상의 비교가 아닙니다. Slack은 온라인에서 작동하는 서비스이며 전자 앱은 웹 앱을 표시하기 위한 셸일 뿐입니다. slack과 같은 앱의 비밀 소스의 대부분은 웹 서버에 있습니다.

Slack과 같은 앱을 소스 코드 보호에 신경 쓰지 않는다고 언급하는 사람들에게는 모든 앱에 대한 최상의 비교가 아닙니다. Slack은 온라인에서 작동하는 서비스이며 전자 앱은 웹 앱을 표시하기 위한 셸일 뿐입니다. slack과 같은 앱의 비밀 소스의 대부분은 웹 서버에 있습니다.

@당신이 좋아하는
Spotify는 어떻습니까!!!,우리는 당신이 무엇을 의미하는지 알지만 오프라인 앱은 어떻습니까??

@annymosse Spotify의 비밀 소스는 그들의 앱이 아닙니다. 누군가 Spotify 앱 소스를 훔쳤다면 별로 문제가 되지 않을 것입니다. 앱은 충분히 좋습니다. 사람들이 Spotify를 사용하고 비용을 지불하는 진짜 이유는 제공되는 콘텐츠와 음악 스트리밍의 편리함 때문입니다. 많은 Spotify 고객이 대안보다 선호하는 일부 UX 세부 정보가 있지만 경쟁업체는 이를 복사하기 위해 소스 코드가 실제로 필요하지 않습니다. 또한 Spotify의 소스 코드를 보려고 시도하지 않았지만 어딘가에 앱에 일종의 보호 기능이 내장되어 있다고 생각합니다. 네이티브 C 애드온뿐만 아니라 일부 견고한 난독화 가능성이 있습니다. 이것이 DRM으로 인해 그들에게 필요한 요구 사항이 될 것이라고 생각합니다.

@yourfavorite 소스를 살펴보세요. 때때로 상용 앱에 대한 소스를 asar files 및 package.json 및 *.js 를 전달하는 최소한 몇 가지 방법

소스 코드 보호에 반대하는 것이 아니라 Slack과 Spotify가 대부분의 사람들이 전자로 수행하는 작업에 대한 최상의 비교가 아닐 수 있습니다. 또한 소스 코드 보호가 제품에 중요한 경우 전자가 현재로서는 가장 적합하지 않을 수 있습니다.

그리고 분명히 말하자면, 나는 전자에 오는 일종의 소스 코드 보호에 찬성합니다.

소스 코드 보호가 필요합니다. 여기에 사용 사례를 제공하겠습니다.

Google 번역 API를 기반으로 번역 소프트웨어 기반을 구축하려고 합니다.

사용자가 .srt/.ass 자막 파일을 소프트웨어로 드래그하면 소프트웨어가 Google 번역 API를 사용하여 모든 라인을 번역합니다.

예시

사용자는 1개의 비디오와 1개의 영어 자막을 다운로드했습니다.
이제 그들은 이 소프트웨어를 사용하여 이 영어 자막을 번역할 수 있습니다.
중국어 또는 다른 언어로.
그래서 그들은 내용을 이해할 수 있습니다.

문제

소스 코드를 쉽게 얻을 수 있는 경우.
분명히 공격자가 내 API 키 및 비밀을 얻을 수 있습니다. 그리고 그것을 남용하십시오.
Google에서 엄청난 청구서를 받게 됩니다($500? $1000? 더?)

빠른 업데이트(2020년 3월 29일)

Vue.js + Webpack을 Electron.js와 함께 사용하고 있습니다.
모든 코드가 축소되므로 더 이상 문제가 되지 않습니다.

@1c7

글쎄, 아마도 이것을 달성하기 위해 외부 보호를 사용해야 할 것입니다. C++ 소프트웨어에서도 API 키를 쉽게 가져올 수 있습니다. 문제 없습니다. 따라서 이것은 실제로 전자 관련 문제가 아닙니다.

@lvkins 아
팁 감사합니다!

기본적으로 모든 프로그래밍 언어는 리버스 엔지니어링될 수 있습니다. 항상 큰 걱정거리였습니다. 모든 보호가 보호가 없는 것보다 낫다는 것은 사실이지만 여전히 그렇습니다. 어떤 프로그래밍 언어를 사용하든 민감한 데이터를 보호하기 위해 더 많은 노력을 기울여야 합니다. 귀하의 경우 C++ 라이브러리로 이동하여 추가 소금을 넣고 node.js에 연결해야 합니다. 그렇게 하면 됩니다.

@lvkins 답장
제안해 주셔서 감사합니다. 나는 이것에 대해 조사할 것이다.

이 번역 소프트웨어를 Mac과 Windows에서 모두 실행할 수 있기를 원하기 때문에 Electron.js를 사용하고 싶습니다.

Electron.js + 일부 C++가 내 API 키 및 비밀을 보호할 수 있는 것 같습니다.

@lvkins님 감사

@1c7 과연 😃

여기에서 시작하십시오: https://nodejs.org/api/addons.html

전자의 보안 부족이 우려된다면 NW.js를 사용해 볼 수도 있습니다.

행운을 빕니다!

@1c7 과 Linux가 아닌 이유는 무엇입니까?! 나는 그것이 모든 플랫폼에 동일한 코드 기반이라고 생각합니다 ??!

@annymosse 방금 Linux에 대해 언급하는 것을 잊었습니다. Linux에 대한 것은 없습니다.

참고로:

• 저는 Macbook Pro 2017 15인치(Mac)를 사용하고 있습니다.
• 대부분의 사용자는 Windows(Windows)를 사용합니다.
• 내 소프트웨어 사용자가 Linux(Linux)에서 사용하는 것을 본 적이 없습니다.

https://github.com/1c7/Translate-Subtitle-File을 돌리는 것에 대해 생각하고 있었습니다.
이 프로젝트를 진지한 프로젝트로 전환합니다(돈을 청구하고 품질을 높이십시오(시간을 더 많이 투자)).
그래서 나는 지금 연구를 하고 있다

이 도구는 현재 주로 중국 시장을 대상으로 합니다. (모든 버튼과 텍스트는 중국어로 되어 있습니다)
i18n은 지도에 있지만 곧 없을 것입니다.

i18n 및 Yandex 변환기 API를 만들 계획이 있었지만 동일한 문제로 인해 프로젝트를 취소했습니다. 그런 다음 Linux에서 대부분의 신규 사용자는 Linux에 존재하지 않거나 대안이 없다고 생각하는 프로그램에 대한 확신이 없습니다. 따라서 해당 프로젝트를 만들고 사용자 대상이 미디어만 번역하는 경우 모든 Linux 배포판이나 내가 선호하는 배포판(중국어 Linux 배포판)을 사용할 수 있습니다. 당신과 모든 Linux 사용자에게 최선을 다하기를 바랍니다.

API 키 및 비밀은 게시된 앱에 있으면 안 됩니다. 대신 가지고
당신의 API/백엔드에서 그것들을, abd 어떤 유형으로 그들을 보호하십시오.
인증/조절. 그런 다음 앱에서 API를 사용하도록 합니다.

Em dom, 2019년 10월 20일 10:22, Cheng Zheng [email protected]
에스크로:

@annymosse https://github.com/annymosse 방금 Linux에 대해 언급하는 것을 잊었습니다.
리눅스에 대해 아무것도

—
이 스레드에 가입했기 때문에 이 메시지를 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/electron/electron/issues/2570?email_source=notifications&email_token=ADCOXMFCSHRX3PZTE7GHKDTQPRLQRA5CNFSM4BODX2F2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXH
또는 구독 취소
https://github.com/notifications/unsubscribe-auth/ADCOXMCKPUOMQPM3JKZP5J3QPRLQRANCNFSM4BODX2FQ
.

아무도 읽을 수 없도록 Javascript 파일을 바이너리 파일로 변환할 수 있는 bytenode라는 라이브러리가 있습니다.

먼저 서버와 폴더에 bytenode를 설치하십시오.

>npm i -g bytenode
>npm i bytenode

다음 코드가 포함된 일반 nodeJS 파일을 만듭니다. 다음 코드의 이름을 ok.js로 지정한다고 가정해 보겠습니다.

>console.log('bytenode works!);
그런 다음 자바스크립트 코드를 컴파일합니다. 이 명령은 파일과 이름이 같은 .JSC 파일을 생성합니다.

user<strong i="15">@machine</strong>:~$ bytenode -c ok.js
그런 다음 기본 전자 JS 파일에서 바이너리를 호출합니다. test.js라고 합시다.

const bytenode = require('bytenode'); 
const myFile=require('./ok.jsc'); 
myFile;

저장해.

그런 다음 test.js: node test.js를 호출하여 테스트합니다. "cat ok.jsc"를 실행하여 그것이 실제로 바이너리이고 아무도 당신의 코드를 볼 수 없다는 것을 확인하십시오. 원본 일반 테스트 js 파일을 다른 위치로 이동할 수 있습니다.
나는 전자에서 그것을 테스트하지 않았지만 그것이 작동 할 것이라고 생각합니다. 그렇지 않습니까?