---

Hej,

nogen som kender en rigtig god og freeware obfuscator til Java kildefiler
(.java) eller evt. bytecode (.class). Obfuscatoren skal kunne obfuscate
strenge og ikke tillade at en streng står som "en streng" i kildefilen eller
evt. når bytecoden dekompileres.

Mvh KK

---

"Kasper Kau" <kasper@kau.dk> skrev i en meddelelse
news:9vl487$rct$1@sunsite.dk...
> Hej,
>
> nogen som kender en rigtig god og freeware obfuscator til Java
kildefiler
> (.java) eller evt. bytecode (.class). Obfuscatoren skal kunne
obfuscate
> strenge og ikke tillade at en streng står som "en streng" i
kildefilen eller
> evt. når bytecoden dekompileres.

En af de bedste er DashOPro

--
With many Thanks

Soren ' Disky ' Reinke ICQ #1413069
http://www.disky-design.dk/fish
Remove IHSYD from email address when replying by email

---

"Soren 'Disky' Reinke" <disky@disky-design.ihsyd.dk> wrote in message news:_ZAT7.79$rB6.577714198@news.euroconnect.net...
>
> "Kasper Kau" <kasper@kau.dk> skrev i en meddelelse
> news:9vl487$rct$1@sunsite.dk...
> > Hej,
> >
> > nogen som kender en rigtig god og freeware obfuscator til Java
> kildefiler
> > (.java) eller evt. bytecode (.class). Obfuscatoren skal kunne
> obfuscate
> > strenge og ikke tillade at en streng står som "en streng" i
> kildefilen eller
> > evt. når bytecoden dekompileres.
>
> En af de bedste er DashOPro
Men den er ikke gratis!

Den eneste jeg kender til (som i øvrigt er let at bruge) er
RetroGuard, men den er vist ikke imponerende god...
http://www.retrologic.com/

OT:
Jeg testede DashOPro her forleden, damn det er underligt at bruge!!
hvis du har en tutorial, må du godt smide den efter mig...

personligt synes jeg godt om Zelix KlassMaster - simpelt at bruge
(men heller ikke gratis)!
http://www.zelix.com/


/Brian Matzon

---

> Jeg testede DashOPro her forleden, damn det er underligt at bruge!!
> hvis du har en tutorial, må du godt smide den efter mig...

Hvad er problemet ? Jeg benytter jævnligt Dasho OE, hvilket fungerer helt
perfekt. Det er den bedste obfuscator (og desværre dyreste :( ) jeg har set
på markedet.

Med venlig hilsen,
Jacob Møller
www.kiloo.dk

---

"Jacob Møller" <jacob@jvector.dk> wrote in message news:9vo6vn$gdd$1@news.cybercity.dk...
>
>
> > Jeg testede DashOPro her forleden, damn det er underligt at bruge!!
> > hvis du har en tutorial, må du godt smide den efter mig...
>
> Hvad er problemet ? Jeg benytter jævnligt Dasho OE, hvilket fungerer helt
> perfekt. Det er den bedste obfuscator (og desværre dyreste :( ) jeg har set
> på markedet.

Må indrømme at jeg ikke brugte store mængder af tid på programmet, men
det ville ikke makke ret!
Når jeg bruger obfuscators, gør jeg det at jeg kompilere, herefter obfuscater
jeg det kompilerede og laver først herefter jar fil. Det kunne *jeg* ikke få
Dasho til at gøre... men jeg vil da lige prøve det en ekstra gang...

/Brian Matzon

---

"Jacob Møller" <jacob@jvector.dk> wrote in message news:9vo6vn$gdd$1@news.cybercity.dk...
>
>
> > Jeg testede DashOPro her forleden, damn det er underligt at bruge!!
> > hvis du har en tutorial, må du godt smide den efter mig...
>
> Hvad er problemet ? Jeg benytter jævnligt Dasho OE, hvilket fungerer helt
> perfekt. Det er den bedste obfuscator (og desværre dyreste :( ) jeg har set
> på markedet.

Så fik jeg prøvet DashO ordenligt - og er ikke specielt begejstret!
Dens obfuscation er ikke i nærheden af Zelix. Endvidere krypterer
den ikke strings (grantd, zelix er ikke verdens bedste - men bedre
end ingen ting!) - hvilket er et must for en obfuscator!
nedenstående er samme metode, obfuscated af hhv DashO og KlassMaster
så må du selv vælge hvilken du mener obfuscater bedst!

run() obfuscated med DashO (decompiled med jad):
public void run()
{
while(e)
try
{
if(g && (c.size() > 0 || d.size() > 0))
{
b b1;
for(Enumeration enumeration = d.elements(); enumeration.hasMoreElements(); a(b1))
{
b1 = (b)enumeration.nextElement();
b1.d();
}

b b2;
for(Enumeration enumeration1 = c.elements(); enumeration1.hasMoreElements(); a(b2))
{
b2 = (b)enumeration1.nextElement();
b2.d();
}

}
if(g && a.b() == 0)
{
e = false;
} else
{
f();
o o1 = (o)a.a();
if(o1 != null)
a(o1);
}
}
catch(Exception exception)
{
g.a("Error in dispatch of events", exception);
}
if(!g)
b.c();
}
==============
run() obfuscated med Zelix (decompiled med jad):

public void run()
{
int i1 = d.c.s.s.e.d;
if(i1 == 0) goto _L2; else goto _L1
_L1:
g;
_L30:
if(i1 != 0) goto _L4; else goto _L3
_L3:
JVM INSTR ifeq 139;
goto _L5 _L6
_L5:
c;
if(i1 != 0) goto _L8; else goto _L7
_L7:
size();
JVM INSTR ifgt 52;
goto _L9 _L10
_L9:
d.size();
if(i1 != 0) goto _L4; else goto _L11
_L11:
JVM INSTR ifle 139;
goto _L10 _L6
_L10:
d;
_L8:
elements();
Enumeration enumeration;
enumeration;
if(i1 == 0) goto _L13; else goto _L12
_L12:
enumeration.nextElement();
_L16:
(f);
Object obj;
obj;
((f) (obj)).d();
a(((f) (obj)));
_L13:
if(enumeration.hasMoreElements()) goto _L12; else goto _L14
_L14:
c.elements();
if(i1 != 0) goto _L16; else goto _L15
_L15:
Enumeration enumeration1;
enumeration1;
if(i1 == 0) goto _L18; else goto _L17
_L17:
obj = (f)enumeration1.nextElement();
((f) (obj)).d();
a(((f) (obj)));
_L18:
if(enumeration1.hasMoreElements()) goto _L17; else goto _L6
_L6:
this;
if(i1 != 0) goto _L20; else goto _L19
_L19:
g;
_L4:
JVM INSTR ifeq 175;
goto _L21 _L22
_L21:
a;
if(i1 != 0) goto _L20; else goto _L23
_L23:
c();
JVM INSTR ifne 175;
goto _L24 _L22
_L24:
e = false;
if(i1 == 0)
break; /* Loop/switch isn't completed */
_L22:
g();
a.b();
_L20:
(a);
obj;
if(obj == null)
break; /* Loop/switch isn't completed */
a(((a) (obj)));
if(i1 != 0) goto _L6; else goto _L25
_L25:
continue; /* Loop/switch isn't completed */
Exception exception;
exception;
d.c.s.s.e.a(a("\013v-\031\bnm1V\036'w/\027\016-l\177\031\034na)\023\024:w"), exception);
if(i1 == 0);
_L2:
if(e) goto _L1; else goto _L26
_L26:
this;
if(i1 != 0) goto _L28; else goto _L27
_L27:
g;
if(i1 != 0 || i1 != 0) goto _L30; else goto _L29
_L29:
if(i1 != 0) goto _L3; else goto _L31
_L31:
JVM INSTR ifne 263;
goto _L32 _L33
_L32:
this;
_L28:
b;
c();
_L33:
}


/Brian Matzon

---

> Så fik jeg prøvet DashO ordenligt - og er ikke specielt begejstret!
> Dens obfuscation er ikke i nærheden af Zelix. Endvidere krypterer
> den ikke strings (grantd, zelix er ikke verdens bedste - men bedre
> end ingen ting!) - hvilket er et must for en obfuscator!
> nedenstående er samme metode, obfuscated af hhv DashO og KlassMaster
> så må du selv vælge hvilken du mener obfuscater bedst!

Jeg kan godt se at Zelix Klassmaster obfuscerer bedre end Dasho, men jeg
mener helt klart at en obfuscator er mere end blot obfusceringen af koden.
Jeg har lige forsøgt at obfuscere en lille applet med både Dasho & ZKM.
Dasho var størrelsesmæssigt 25% bedre end ZKM. Dertil kommer at ZKM har det
væmmeligste interface jeg længe har set.

Har du prøvet Jax i den nye udgave med GUI ? (Altså efter at IBM stoppede
med at udbyde den gratis).

Med venlig hilsen,
Jacob Møller
www.kiloo.dk

---

"Jacob Møller" <jacob@jvector.dk> wrote in message news:9vtmis$1uur$1@news.cybercity.dk...
> Jeg kan godt se at Zelix Klassmaster obfuscerer bedre end Dasho, men jeg
> mener helt klart at en obfuscator er mere end blot obfusceringen af koden.
> Jeg har lige forsøgt at obfuscere en lille applet med både Dasho & ZKM.
> Dasho var størrelsesmæssigt 25% bedre end ZKM. Dertil kommer at ZKM har det
> væmmeligste interface jeg længe har set.
100% enig, nå man obfuscater kan det være pga Performance, Size samt
Obfuscation - typisk er det vigtigste for mig obfuscation, men størrelse
er dog oxo en faktor! (ligeledes er Performance oxo, men synes ikke man gainer
ret meget...)

> Har du prøvet Jax i den nye udgave med GUI ? (Altså efter at IBM stoppede
> med at udbyde den gratis).
Nu har jeg prøvet den - man kan vist heller ikke lovprise JAX'es UI for meget!
Umiddelbart vil jeg sige den compresser bedst af de tre, men den obfuscater
desværre heller ikke strings - men jeg vil da for eftertiden overveje at bruge
JAX når jeg skal compresse for space, og stadigt bruge Zelic når det skal være
"mere sikkert". Kan ikke se nogen grunde til at bruge DashO - ud fra den
relativt lille test jeg har fortaget...
Bemærk, jeg har ikke testet hvilken af de tre der obfuscater mest korrekt! -
jeg har oplevet at obfuscaters, obfuscater lidt FOR godt!

/Brian Matzon

---

> Bemærk, jeg har ikke testet hvilken af de tre der obfuscater mest
korrekt! -
> jeg har oplevet at obfuscaters, obfuscater lidt FOR godt!
>

Ja, det har jeg også oplevet - men det var vist i 97 engang

Med venlig hilsen,
Jacob Møller
www.kiloo.dk

---

Hmm har set på den men er ikke hvad jeg har brug for. Deres
Overload-Induction(tm) er åbenbart deres mest avancerede feature. Men i bund
og grund det samme som alle de andre. Den kan ikke obfuscate strenge i
klassefiler. Det er vigtigt for mig af sikkerhedshensyn. Det skal ikke være
muligt at dekompilerer og læse strenge brugt i applikationen.

Mvh KK

"Soren 'Disky' Reinke" <disky@disky-design.ihsyd.dk> wrote in message
news:_ZAT7.79$rB6.577714198@news.euroconnect.net...
>
> "Kasper Kau" <kasper@kau.dk> skrev i en meddelelse
> news:9vl487$rct$1@sunsite.dk...
> > Hej,
> >
> > nogen som kender en rigtig god og freeware obfuscator til Java
> kildefiler
> > (.java) eller evt. bytecode (.class). Obfuscatoren skal kunne
> obfuscate
> > strenge og ikke tillade at en streng står som "en streng" i
> kildefilen eller
> > evt. når bytecoden dekompileres.
>
> En af de bedste er DashOPro
>
> --
> With many Thanks
>
> Soren ' Disky ' Reinke ICQ #1413069
> http://www.disky-design.dk/fish
> Remove IHSYD from email address when replying by email
>
>

---

"Kasper Kau" <kasper@kau.dk> skrev i en meddelelse
news:9vn837$ir2$1@sunsite.dk...
> Hmm har set på den men er ikke hvad jeg har brug for. Deres
> Overload-Induction(tm) er åbenbart deres mest avancerede
feature. Men i bund
> og grund det samme som alle de andre. Den kan ikke obfuscate
strenge i
> klassefiler. Det er vigtigt for mig af sikkerhedshensyn. Det
skal ikke være
> muligt at dekompilerer og læse strenge brugt i applikationen.

Så er det ikke en obfuscator du ønsker men en encryption engine
du mangler.

--
With many Thanks

Soren ' Disky ' Reinke ICQ #1413069
http://www.disky-design.dk/fish
Remove IHSYD from email address when replying by email

---

"Kasper Kau" <kasper@kau.dk> wrote in message news:9vn837$ir2$1@sunsite.dk...
> Hmm har set på den men er ikke hvad jeg har brug for. Deres
> Overload-Induction(tm) er åbenbart deres mest avancerede feature. Men i bund
> og grund det samme som alle de andre. Den kan ikke obfuscate strenge i
> klassefiler. Det er vigtigt for mig af sikkerhedshensyn. Det skal ikke være
> muligt at dekompilerer og læse strenge brugt i applikationen.

Kan du godt droppe - er ikke teknisk muligt!
Det eneste man kan gøre, er at tilføje en decryption rutine, der bliver
kørt på runtime tidspunktet - ala Zelix KlassMaster - men man kan selv
lave en decrypter til disse strenge, men det fjerner da det værste kravl!

Generelt - det er umuligt (læs: umuligt!!!) at lave klient sikkerhed -
specielt i Java!!

/Brian Matzon

---

Brian Matzon wrote:

> "Kasper Kau" <kasper@kau.dk> wrote in message news:9vn837$ir2$1@sunsite.dk...
> > Hmm har set på den men er ikke hvad jeg har brug for. Deres
> > Overload-Induction(tm) er åbenbart deres mest avancerede feature. Men i bund
> > og grund det samme som alle de andre. Den kan ikke obfuscate strenge i
> > klassefiler. Det er vigtigt for mig af sikkerhedshensyn. Det skal ikke være
> > muligt at dekompilerer og læse strenge brugt i applikationen.
>
> Kan du godt droppe - er ikke teknisk muligt!
> Det eneste man kan gøre, er at tilføje en decryption rutine, der bliver
> kørt på runtime tidspunktet - ala Zelix KlassMaster - men man kan selv
> lave en decrypter til disse strenge, men det fjerner da det værste kravl!
>
> Generelt - det er umuligt (læs: umuligt!!!) at lave klient sikkerhed -
> specielt i Java!!

Det har vel ikke noget specielt med Java at gøre at det ikke kan lade sig
gøre. Problemet er vel, at algoritmen nødvendigvis skal stå i programmet,
hvis der ikke er nogen ekstern sikkerhed (udleveret password, kørsel
af afkodning på fjern server, etc)?

Ulrik Magnusson

---

"Ulrik Magnusson" <ulrikm@yahoo.com> wrote in message news:3C202E8E.91F5042A@yahoo.com...
<SNIP>
> > Generelt - det er umuligt (læs: umuligt!!!) at lave klient sikkerhed -
> > specielt i Java!!
>
> Det har vel ikke noget specielt med Java at gøre at det ikke kan lade sig
> gøre. Problemet er vel, at algoritmen nødvendigvis skal stå i programmet,
> hvis der ikke er nogen ekstern sikkerhed (udleveret password, kørsel
> af afkodning på fjern server, etc)?

Grunden til at det er mere kritisk i java end i andre sprog (compilede,
ikke scripts), er at det er relativt let at læse dekompilerede class
filer.
Men ja, det er netop problemet i klient sikkerhed, at algoritmen medfølger.

/Brian Matzon

---

"Brian Matzon" <brian@matzon.dk> skrev i en meddelelse
news:3c204cba$0$55542$edfadb0f@dspool01.news.tele.dk...
> "Ulrik Magnusson" <ulrikm@yahoo.com> wrote in message
news:3C202E8E.91F5042A@yahoo.com...
> <SNIP>
> > > Generelt - det er umuligt (læs: umuligt!!!) at lave klient
sikkerhed -
> > > specielt i Java!!
> >
> > Det har vel ikke noget specielt med Java at gøre at det ikke
kan lade sig
> > gøre. Problemet er vel, at algoritmen nødvendigvis skal stå i
programmet,
> > hvis der ikke er nogen ekstern sikkerhed (udleveret password,
kørsel
> > af afkodning på fjern server, etc)?
>
> Grunden til at det er mere kritisk i java end i andre sprog
(compilede,
> ikke scripts), er at det er relativt let at læse dekompilerede
class
> filer.
> Men ja, det er netop problemet i klient sikkerhed, at
algoritmen medfølger.


Et stort problem med obfuskering er at de nye hotspot compilere
ikke kan hardcore tune programmerne da de ikke kan 'genkende'
funktionaliteten. Det vil sige man får dårligere performance.

--
With many Thanks

Soren ' Disky ' Reinke ICQ #1413069
http://www.disky-design.dk/fish
Remove IHSYD from email address when replying by email

---

Brian Matzon wrote:

> "Ulrik Magnusson" <ulrikm@yahoo.com> wrote in message news:3C202E8E.91F5042A@yahoo.com...
> <SNIP>
> > > Generelt - det er umuligt (læs: umuligt!!!) at lave klient sikkerhed -
> > > specielt i Java!!
> >
> > Det har vel ikke noget specielt med Java at gøre at det ikke kan lade sig
> > gøre. Problemet er vel, at algoritmen nødvendigvis skal stå i programmet,
> > hvis der ikke er nogen ekstern sikkerhed (udleveret password, kørsel
> > af afkodning på fjern server, etc)?
>
> Grunden til at det er mere kritisk i java end i andre sprog (compilede,
> ikke scripts), er at det er relativt let at læse dekompilerede class
> filer.

Du mener vel 'kompilerede class filer'? - hvis vi kan gå ud fra at den
kære obfuscator hindrer alt andet end manuel dekompilering og dermed
basere sikkerheden på dens komplethed. Er Java bytecode nemmere
at læse end anden assembly?

Ulrik Magnusson

---

In <3C218239.45452F1F@yahoo.com> Ulrik Magnusson <ulrikm@yahoo.com> writes:

>Brian Matzon wrote:

>> "Ulrik Magnusson" <ulrikm@yahoo.com> wrote in message news:3C202E8E.91F5042A@yahoo.com...
>> <SNIP>
>> > > Generelt - det er umuligt (læs: umuligt!!!) at lave klient sikkerhed -
>> > > specielt i Java!!
>> >
>> > Det har vel ikke noget specielt med Java at gøre at det ikke kan lade sig
>> > gøre. Problemet er vel, at algoritmen nødvendigvis skal stå i programmet,
>> > hvis der ikke er nogen ekstern sikkerhed (udleveret password, kørsel
>> > af afkodning på fjern server, etc)?
>>
>> Grunden til at det er mere kritisk i java end i andre sprog (compilede,
>> ikke scripts), er at det er relativt let at læse dekompilerede class
>> filer.

>Du mener vel 'kompilerede class filer'? - hvis vi kan gå ud fra at den
>kære obfuscator hindrer alt andet end manuel dekompilering og dermed
>basere sikkerheden på dens komplethed. Er Java bytecode nemmere
>at læse end anden assembly?

Jeg synes personligt at java bytecode er nemmere at laese end f.x.
assembly.

/Martin

---

Ulrik Magnusson wrote:

> Er Java bytecode nemmere
> at læse end anden assembly?

Ja.

--
Jonas Kongslund <jonas(at)kongslund.dk> XNS: =Jonas Kongslund

When you want to change the world, you don't see the dawn by
getting up early - you see it by not sleeping through the night.

---

"Jonas Kongslund" <gamma@post.tele.dk> skrev i en meddelelse
news:3c219f28$0$62861$edfadb0f@dspool01.news.tele.dk...
> Ulrik Magnusson wrote:
>
> > Er Java bytecode nemmere
> > at læse end anden assembly?
>
> Ja.

Nej ikke hvis assembler koden er fra en Mc680xx cpu.

--
With many Thanks

Soren ' Disky ' Reinke ICQ #1413069
http://www.disky-design.dk/fish
Remove IHSYD from email address when replying by email

---

Kasper Kau wrote:

> Hmm har set på den men er ikke hvad jeg har brug for. Deres
> Overload-Induction(tm) er åbenbart deres mest avancerede feature. Men i bund
> og grund det samme som alle de andre. Den kan ikke obfuscate strenge i
> klassefiler. Det er vigtigt for mig af sikkerhedshensyn. Det skal ikke være
> muligt at dekompilerer og læse strenge brugt i applikationen.


Vi kan måske komme med nogle forslag til hvad du kan gøre hvis du
fortæller hvad det er du skal bruge. Skal du gemme et password som
applikationen skal validere mod eller hur? I så fald, kan du bruge
en hash'et værdi (secure hash, fex. SHA1) af strengen og så hashe
bruger input og sammenligne værdier.

Morten

--
Morten Primdahl Caput A/S Phone +45 70 12 24 42
System Integrator Nygade 6 Fax +45 70 11 24 42
morten@caput.com DK-1164 Kbh K http://www.caput.com/