Linguaggio di programmazione personalizzato e traduttore che lo traduce in Java per rendere più difficile ottenere la fonte

Is there a flaw I'm not seeing?

Devi creare la tua lingua personalizzata. Non avrai accesso a strumenti come IDE e debugger che semplificano la scrittura di codice in quella lingua. Devi scrivere un traduttore per tradurre il tuo linguaggio personalizzato in bytecode Java. Non avrai accesso alle librerie già pronte per un ampio set di funzionalità, quindi dovrai scrivere le tue o trovare un modo per incorporare il codice esistente nella tua lingua. Non è facile quindi sì, c'è un grosso difetto che non vedi.

Direi che il difetto nel tuo ragionamento è che tu presumi che qualsiasi aspirante tecnico inverso sarebbe interessato al tuo codice sorgente. In effetti, per il reverse engineering, gli aggressori sono interessati a un modulo "codice sorgente" che consente di raggiungere qualsiasi obiettivo l'attaccante, di solito comprendendo un piccolo algoritmo. Il formato per bytecode Java è sufficientemente regolare e semplice da poter essere gestito direttamente per quel tipo di lavoro.

Quindi un utente malintenzionato potrebbe semplicemente eseguire un disassemblatore (come questo ) e probabilmente un assemblatore corrispondente (come quello ) per testare le sue modifiche o inserire chiamate di debug aggiuntive. Può farlo sui file compilati .class , indipendentemente dal linguaggio di programmazione utilizzato al tuo fianco.

Questo non è nuovo. Le persone sono state applicazioni C e C ++ per il reverse engineering per decenni, osservando l'assemblaggio.

In order to modify my game's code, the hacker would have to learn my custom language and create their own custom decompiler which would take some time. At least how I figure.

Un hacker non ha bisogno di decompilare fino alla tua lingua personalizzata. L'hacker avrebbe solo bisogno di trovare e riconoscere il posto nel codice byte in cui il codice decrementa il numero di vite rimaste e modificarlo in un incremento. Non è necessario un decompilatore completo.

Se ho capito bene, stai facendo le seguenti traduzioni:

Custom language > Java > Java bytecode

Nel frattempo l'hacker può utilizzare direttamente il bytecode Java per scoprire come funziona il tuo gioco

Non ti consiglierò di andare in quel modo, ti aggiunge la complessità di codificare un traduttore che non ti darà alcuna protezione ma ti darà più mal di testa dato che non sarai in grado di usare alcun IDE o usare le librerie direttamente

Cosa si può fare a un livello difficile nello stesso livello, il compito del reverse engineering consiste nell'usare un codice offuscatore. Ti offrirà tutti i vantaggi dell'uso di Java standard (compresi IDE e librerie) e non richiede una lingua e un traduttore personalizzati

Raccomando di utilizzare uno strumento di offuscamento già disponibile. DexGuard è uno di questi codici offuscatore che offre un certo livello di protezione per le applicazioni Android. Direi che sarebbe meglio utilizzare il prodotto di uno sviluppatore il cui unico obiettivo è l'offuscamento piuttosto che scrivere il proprio e quindi avere anche più tempo per concentrarsi sullo sviluppo del gioco.

Come per tutti i tipi di impacchettamento del codice, ciò aumenta semplicemente la complessità della retromarcia e un determinato attaccante potrebbe sempre trovare la via.