zonder de source een programma aanpassen..

[BdR]

Ik vroeg me af.. hoe doen ze dat, een programma aanpassen terwijl je de source-code niet hebt? Want ik zie wel eens dat sommige windows/ms-dos programma's (maar het gebeurt vast ook op andere platforms) aangepast en/of uitgebreid worden door mensen die de source-code niet hebben. Hackers dus, zeg maar..

hier 2 voorbeelden, SupraHLE (hack van UltraHLE) en deze hack van het spel Liero

Gaan ze echt met een hex editor in dat programma zitten klooien en gewoon maar wat proberen (hoe kom je ooit achter die geheugen adressen die je moet hebben!?) of nemen ze een dis-assembler en gaan met die code verder? Maar ik had gehoord dat dis-assemblers nooit echt goed werken, de source-code die je krijgt is vaak niet te re-compilen enzo?

ben niet van plan me er bezig te gaan houden (zelf iets schrijven is al moeilijk genoeg) maar ik vroeg het me gewoon af.. iemand ideeen hierover?

[Arjan Scholl]

Hack dit, hack dat..link hier, link daar...mag da wel

[Alarmnummer]

Je hebt ook decompilers. Kun je source weer terug krijgen maar het is wel volledig onleesbaar, en kan niet overal bij.

[BdR]

Op donderdag 04 oktober 2001 13:48 schreef arjanscholl het volgende:
Hack dit, hack dat..link hier, link daar...mag da wel

ja da mag wel want beide programma's die ik noemde zijn freeware. En een programma hacken is ook niets mis mee en niets illegaals aan, zo lang je het ge-hack-te programma niet doorverkoopt of voor illegale practijken gebruikt.. dus..

maar goed, back on topic: weet iemand hoe ze dit doen, want het lijkt mij zo'n bijna onmogelijke opdracht dan wel monnikenwerk

[Arjan Scholl]

Op donderdag 04 oktober 2001 13:52 schreef BdR het volgende:
ja da mag wel want beide programma's die ik noemde zijn freeware. En een programma hacken is ook niets mis mee en niets illegaals aan, zo lang je het ge-hack-te programma doorverkoopt of voor illegale practijken gebruikt.. dus..

maar goed, back on topic: weet iemand hoe ze dit doen, want het lijkt mij zo'n bijna onmogelijke opdracht dan wel monnikenwerk

Owkee

edit: Post numero 500

[Gerco]

Op donderdag 04 oktober 2001 13:52 schreef BdR het volgende:
En een programma hacken is ook niets mis mee en niets illegaals aan, zo lang je het ge-hack-te programma niet doorverkoopt of voor illegale practijken gebruikt.. dus..

Oneens.. in veel license agreements staat dar je een prog NIET mag reverse engineeren of, op wat voor manier dan ook, wijzigen.
Dat mag je dus gewoon niet doen, niet voor eigen gebruik en niet om te verspreiden. Gewoon niet dus.

Dat neemt niet weg dat het een machtig leuk iets is om te doen

[wasigh]

Gerco, heeft gelijk meestal mag het niet..

Maar dan nog.. Als het voor leer doeleinden is
en hoe willen ze het controleren?

[tomato]

Op donderdag 04 oktober 2001 14:24 schreef wasigh het volgende:
en hoe willen ze het controleren?

Door op de gegeven link te klikken

[Gerco]

Op donderdag 04 oktober 2001 14:24 schreef wasigh het volgende:
Maar dan nog.. Als het voor leer doeleinden is
en hoe willen ze het controleren?

Ook niet, dus boeiuh

[BdR]

okee, om niet te verzanden in "mag wel of mag niet" discussie, hier een ander hypothetisch voorbeeld. Je buurman schrijft een Visual C++ proggie die een form toont met een knop, als je eropklikt wordt het form een andere kleur (wie heeft dit ook op school moeten doen? ), hij geeft jou alleen het .EXE bestand. Hoe kan je nu nog het programma aanpassen.. en dan weer terug naar de voorbeelden, hoe hebben ze ooit die (relatief) gecompliceerde programma's kunnen uitbreiden met best nuttige/geinige features?

[MrEdge_]

Maar goed, dat was de vraag niet. De vraag was hoe ze nou van binairies weet terugkomen bij source-files, of hoe het anders wordt opgelost.
En daar was ik eigenlijk ook wel benieuwd naar. Het is volgens mij niet mogelijk om zonder source files te debuggen op een leesbare manier?

[Gerco]

Op donderdag 04 oktober 2001 14:31 schreef BdR het volgende:
lap tekst

Met SoftICE, Win32dASM en meer van die leuke progjes. De assembly source bekijken en die wijzigen, dat omrekenen naar een offset in de binary file en patchen.

[Gerco]

Op donderdag 04 oktober 2001 14:32 schreef Mr Edge het volgende:
Maar goed, dat was de vraag niet. De vraag was hoe ze nou van binairies weet terugkomen bij source-files.

Niet, dat doen ze dus met een debugger (SoftICE) (op ASM niveau) of een disassembler (Win32dASM), maar het blijft asm niveau, tenzij je java gaat kraken, daar kun je de complete source (incl. commentaar?) terugkrijgen uit een .class.

[Mir]

Op donderdag 04 oktober 2001 14:34 schreef Gerco het volgende:

[..]

Niet, dat doen ze dus met een debugger (SoftICE) (op ASM niveau) of een disassembler (Win32dASM), maar het blijft asm niveau, tenzij je java gaat kraken, daar kun je de complete source (incl. commentaar?) terugkrijgen uit een .class.

Ik heb er zelf idd ook nog mee zitten kloten, je kan doormiddel van een debug aangeven dat het programma moet pauzeren als een geheugen adres beschreven wordt!

incl commentaar: lijkt mij niet.
wat heb je er aan in een EXE?
En de EXE zal ook weer veel groter worden omdat daar ook weer ruimte voor gemaakt moet worden..


BTW Waarom geen DLL ipv EXE

[Verwijderd]

helemaal eens met Gerco...

maar uiteraard doe ik hier ook niet aan!

[MrEdge_]

Ah ok, ic. Maar dan wordt het wel een echt monnikkenwerkje
Trial and error dus.

[Alarmnummer]

Op donderdag 04 oktober 2001 14:34 schreef Gerco het volgende:

[..]

Niet, dat doen ze dus met een debugger (SoftICE) (op ASM niveau) of een disassembler (Win32dASM), maar het blijft asm niveau, tenzij je java gaat kraken, daar kun je de complete source (incl. commentaar?) terugkrijgen uit een .class.

Je kan bij het reverse engineren niet de documentatie terug krijgen , want dit wordt niet meegenomen in de class files. (Zouden de class files veel te groot worden) Om te zorgen dat niet iedereen je source terug kan krijgen kun je die class files ook gaan obfuscaten. Je kunt alle class,methode en variable namen volledig verneuken. Lastiger om te inzicht te krijgen.

Maar er worden soms ook truucjes toegepast om een decompiler helemaal de mist in te laten lopen. Kortom, het is met java wel mogelijk om je class files te beschermen tegen 'lieve' gebruikers

[BdR]

Op donderdag 04 oktober 2001 14:38 schreef Mir het volgende:
incl commentaar: lijkt mij niet.
wat heb je er aan in een EXE?
En de EXE zal ook weer veel groter worden omdat daar ook weer ruimte voor gemaakt moet worden..

bij gecompileerde java bestanden (JAR's) schijnt er idd ook het commentaar enzo bij te zitten als je et de-compiled. java rulez! (naja.. voor wat dit compile/de-compile betreft dan..)

[dusty]

in assembler kom je heel veel jumps tegen, kwestie van op de juiste plaats een extra jump neerzetten, je eigen gedeelte toevoegen en dan terug laten springen naar de oorspronkelijk doel.

Tada gepatched

Veel simpele "beveiligen" kan je kraken door een "jump not equal" te vervangen door een "jump equal"

[Alarmnummer]

Op donderdag 04 oktober 2001 15:13 schreef BdR het volgende:

[..]

bij gecompileerde java bestanden (JAR's) schijnt er idd ook het commentaar enzo bij te zitten als je et de-compiled. java rulez! (naja.. voor wat dit compile/de-compile betreft dan..)

Neem aan dat je het nog nooit zelf hebt gedaan

[Alarmnummer]

Stukje java code.

code:

/**
 * De hoofd class om het systeem op te starten
 */
package com.jph.expertSysteem;

import javax.swing.*;
import com.jph.expertSysteem.dialogs.*;
import com.jph.expertSysteem.editor.*;

import com.jph.stream.*;

public final class Main
{
    public static void main(String args[])
    {
        try
        {
            MainFrameHolder.getInstance();
            
            //ze de log file aan.
            SystemLog sl = new SystemLog("ExpertSysteem.log");
            
            //zorg ervoor dat overal de finalizers worden aangeroepen.
            System.runFinalizersOnExit(true);
            
            //schakel de os look and feel aan.
            String lookAndFeel = UIManager.getSystemLookAndFeelClassName();
            UIManager.setLookAndFeel(lookAndFeel);
            
            //als er argumenten worden meegegeven dan zet de splasher aan.
            if(args.length>0)
                new Splasher(Main.class.getClassLoader().getResource("About2.jpg").getFile(),5000,true);
            
            //ze de editor op het scherm.
            Editor.getInstance().show();
        }
        catch(Throwable e)
        {
            e.printStackTrace();
            JOptionPane.showMessageDialog(null,"Startup failure:"+e.getMessage(),"", JOptionPane.ERROR_MESSAGE);
        }
    }
}

En dit maakt de compiler ervan.

code:

public final class com.jph.expertSysteem.Main extends java.lang.Object {
    static java.lang.Class class$com$jph$expertSysteem$Main;
    public com.jph.expertSysteem.Main();
    public static void main(java.lang.String[]);
    static java.lang.Class class$(java.lang.String);
}

Method com.jph.expertSysteem.Main()
   0 aload_0
   1 invokespecial #6 <Method java.lang.Object()>
   4 return

Method void main(java.lang.String[])
   0 invokestatic #7 <Method com.jph.expertSysteem.MainFrameHolder getInstance()>
   3 pop
   4 new #8 <Class com.jph.stream.SystemLog>
   7 dup
   8 ldc #9 <String "ExpertSysteem.log">
  10 invokespecial #10 <Method com.jph.stream.SystemLog(java.lang.String)>
  13 astore_1
  14 iconst_1
  15 invokestatic #11 <Method void runFinalizersOnExit(boolean)>
  18 invokestatic #12 <Method java.lang.String getSystemLookAndFeelClassName()>
  21 astore_2
  22 aload_2
  23 invokestatic #13 <Method void setLookAndFeel(java.lang.String)>
  26 aload_0
  27 arraylength
  28 ifle 75
  31 new #14 <Class com.jph.expertSysteem.dialogs.Splasher>
  34 dup
  35 getstatic #15 <Field java.lang.Class class$com$jph$expertSysteem$Main>
  38 ifnonnull 53
  41 ldc #16 <String "com.jph.expertSysteem.Main">
  43 invokestatic #17 <Method java.lang.Class class$(java.lang.String)>
  46 dup
  47 putstatic #15 <Field java.lang.Class class$com$jph$expertSysteem$Main>
  50 goto 56
  53 getstatic #15 <Field java.lang.Class class$com$jph$expertSysteem$Main>
  56 invokevirtual #18 <Method java.lang.ClassLoader getClassLoader()>
  59 ldc #19 <String "com/jph/expertSysteem/resources/About2.jpg">
  61 invokevirtual #20 <Method java.net.URL getResource(java.lang.String)>
  64 invokevirtual #21 <Method java.lang.String getFile()>
  67 sipush 5000
  70 iconst_1
  71 invokespecial #22 <Method com.jph.expertSysteem.dialogs.Splasher(java.lang.String,int,boolean)>
  74 pop
  75 invokestatic #23 <Method com.jph.expertSysteem.editor.Editor getInstance()>
  78 invokevirtual #24 <Method null>
  81 goto 118
  84 astore_1
  85 aload_1
  86 invokevirtual #26 <Method void printStackTrace()>
  89 aconst_null
  90 new #27 <Class java.lang.StringBuffer>
  93 dup
  94 invokespecial #28 <Method java.lang.StringBuffer()>
  97 ldc #29 <String "Startup failure:">
  99 invokevirtual #30 <Method java.lang.StringBuffer append(java.lang.String)>
 102 aload_1
 103 invokevirtual #31 <Method java.lang.String getMessage()>
 106 invokevirtual #30 <Method java.lang.StringBuffer append(java.lang.String)>
 109 invokevirtual #32 <Method java.lang.String toString()>
 112 ldc #33 <String "">
 114 iconst_0
 115 invokestatic #34 <Method void showMessageDialog(java.awt.Component, java.lang.Object, java.lang.String, int)>
 118 return
Exception table:
   from   to  target type
     0    81    84   <Class java.lang.Throwable>

Method java.lang.Class class$(java.lang.String)
   0 aload_0
   1 invokestatic #1 <Method java.lang.Class forName(java.lang.String)>
   4 areturn
   5 astore_1
   6 new #3 <Class java.lang.NoClassDefFoundError>
   9 dup
  10 aload_1
  11 invokevirtual #4 <Method null>
  14 invokespecial #5 <Method java.lang.NoClassDefFoundError(java.lang.String)>
  17 athrow
Exception table:
   from   to  target type
     0     5     5   <Class java.lang.ClassNotFoundException>

Ik zie hier geen commentaar instaan. Beetje jammer dat je zoveel mensen hebt die totaal niet weten waarover ze praten.

[BdR]

Op donderdag 04 oktober 2001 15:22 schreef Alarmnummer het volgende:
Ik zie hier geen commentaar instaan. Beetje jammer dat je zoveel mensen hebt die totaal niet weten waarover ze praten.

okee kzeg al niets meer dat van dat java de-compilen zei een collega hiero.. misschien met een andere de-compiler? anyway toch fijn dat jij je kennis ook weer ff tentoon kan spreiden

[Alarmnummer]

Op donderdag 04 oktober 2001 15:33 schreef BdR het volgende:

[..]

okee kzeg al niets meer dat van dat java de-compilen zei een collega hiero.. misschien met een andere de-compiler? anyway toch fijn dat jij je kennis ook weer ff tentoon kan spreiden

Aha... en een andere decompiler die kan uit de class files (waar dus geen commentaar inzit) wel commentaar halen? Wow.. moet ik die decompiler ook ff hebben

[djexplo]

Als je exe bestand wil editten kan je ook gewoon debug.exe wat onder old dos zat gebruiken, daarmee kan je ook als het programma draait, kijken wat er met het geheugen etc, gebeurd. Dit is super handig aangezien je in een spelletje b.v een leven kan halen en dan kijken waar dat in het geheugen wordt opgeslagen etc.

[pelican]

Op donderdag 04 oktober 2001 15:43 schreef djexplo het volgende:
Als je exe bestand wil editten kan je ook gewoon debug.exe wat onder old dos zat gebruiken, daarmee kan je ook als het programma draait, kijken wat er met het geheugen etc, gebeurd. Dit is super handig aangezien je in een spelletje b.v een leven kan halen en dan kijken waar dat in het geheugen wordt opgeslagen etc.

Kende je zeker ook GameWizard wel dan. Echt superhandy in de dos-tijd. Bijv. dune2000 werkte hier perfect mee. Dan zocht je in het geheugen naar een adres dat de waarde bevatte van je geld (hexadecimaal). Als je dan een harvester binnenkreeg, keek je welke van deze adressen was meeverandert naar de nieuwe waarde. Uiteindelijk hield je er dan nog 1 over, en kon je deze freezen.

Werkte bij echt veel spellen, superhandy

[Gerco]

Op donderdag 04 oktober 2001 15:37 schreef Alarmnummer het volgende:
Aha... en een andere decompiler die kan uit de class files (waar dus geen commentaar inzit) wel commentaar halen? Wow.. moet ik die decompiler ook ff hebben

Ik heb het ff geprobeerd en ik kreeg idd geen commentaar terug, maar wel VEEL mooiere code dan jij daar had staan. Gewoon de originele source incl variabelenamen enzo, maar geen commentaar.

Ik heb DJ gebruikt.

[Alarmnummer]

Gebruikte geen decompiler maar een disassambler..

[Verwijderd]

Op donderdag 04 oktober 2001 14:39 schreef Mr Edge het volgende:
Ah ok, ic. Maar dan wordt het wel een echt monnikkenwerkje
Trial and error dus.

Dat valt nogal mee. Een goede cracker heeft een programmaatje gemiddeld binnen een uurtje gekraakt.

[Fatamorgana]

In het DOS tijdperk heb ik ook veel games gehacked om die stomme copyprotection vragen te ontwijken EN voor de uitdaging natuurlijk. Gewoon met SoftIce debuggen en ervaring opdoen, dan zijn de meeste games zo te hacken. Ook wel eens wat trainers en loaders gemaakt enzo. Gewoon voor de lol. Alleen met de invoering van Windows ben ik er mee gestopt, toen trok het me niet meer.

[Alarmnummer]

Op de Amiga 500 kon je er een kaste bij kopen: de action replay en dan kon je het spel bevriezen. Je hebt bijvoorbeeld nog 5 levens, dus je laat hem zoeken naar 5 (vind ie natuurlijk heel veel).. Dan ga je 1 keer dood en dan ga je zoeken op 4. Er zijn natuurlijk niet zo veel adressen waar eerst 5 stond en nu 4. Dit doe je tot dat je nog maar een paar adressen hebt, en dan alles op FF Dat waren nog een gouden tijden.

[tomato]

Op donderdag 04 oktober 2001 16:03 schreef Lestat het volgende:
Dat valt nogal mee. Een goede cracker heeft een programmaatje gemiddeld binnen een uurtje gekraakt.

Yeah right

[BdR]

Op donderdag 04 oktober 2001 15:37 schreef Alarmnummer het volgende:
Aha... en een andere decompiler die kan uit de class files (waar dus geen commentaar inzit) wel commentaar halen? Wow.. moet ik die decompiler ook ff hebben

nee ik bedoelde .. ach laat ook maar.. hier heb je die decompiler

Op donderdag 04 oktober 2001 16:03 schreef Lestat het volgende:
Dat valt nogal mee. Een goede cracker heeft een programmaatje gemiddeld binnen een uurtje gekraakt.

dit soort stoere verhalen hoor je altijd.. je spreekt uit ervaring? ik geloof er niets van!

Op donderdag 04 oktober 2001 16:14 schreef Alarmnummer het volgende:
Op de Amiga 500 kon je er een kaste bij kopen: de action replay en dan kon je het spel bevriezen. Je hebt bijvoorbeeld nog 5 levens, dus je laat hem zoeken naar 5 (vind ie natuurlijk heel veel).. Dan ga je 1 keer dood en dan ga je zoeken op 4.

diezelfde functie zat ook in mn SNES copyboxje, en zit nu ook in MAME trouwens, inderdeed erg handy!

[Verwijderd]

Op donderdag 04 oktober 2001 16:41 schreef BdR het volgende:
dit soort stoere verhalen hoor je altijd.. je spreekt uit ervaring? ik geloof er niets van!

En het suffe is het is nog waar ook, vroeger in het dos tijd perk deed de programmeur nog wel es moeite z'n kopieer beveiliging goed te verbergen dmv van wat sneaky assembly trukjes, maar een groot gedeelte van de huidige shareware (uitzonderingen daar gelaten natuurlijk) wordt het boeltje gewoon in C geschreven op +- de volgende manier.

bool CheckKey(naam, code)
{
strGoedeCode= Gencode(naam)
CheckKey = (StrGoedeCode==code)
}

En dat is inderdaad kinderlijk eenvoudig (ruim binnen een uurtje) te hacken..

[raptorix]

Heel lang terug deden we het op de commodore 64 om extra leventjes te krijgen in spelletjes

Vaak ging het toen vrij amateuristisch omdat kennis van assembler minimaal was, dus dan was het vaak zoeken op een bepaald getal en gokken dat dat het was, dat het programma meestal 200 keer vastliep voordat resultaat bereikt werd was alleen maar spannend

[tomato]

Op donderdag 04 oktober 2001 16:48 schreef Yarvieh het volgende:
En het suffe is het is nog waar ook, vroeger in het dos tijd perk deed de programmeur nog wel es moeite z'n kopieer beveiliging goed te verbergen dmv van wat sneaky assembly trukjes, maar een groot gedeelte van de huidige shareware (uitzonderingen daar gelaten natuurlijk) wordt het boeltje gewoon in C geschreven op +- de volgende manier.

bool CheckKey(naam, code)
{
strGoedeCode= Gencode(naam)
CheckKey = (StrGoedeCode==code)
}

En dat is inderdaad kinderlijk eenvoudig (ruim binnen een uurtje) te hacken..

Als we het over kleine shareware programmaatjes hebben is het over het algemeen inderdaad wel waar. Maar uitzonderingen zijn er zeker wel, er zijn er ook genoeg geweest waar ik helemaal niet uit ben gekomen toen ik daar nog interesse voor had.

[Alarmnummer]

Op donderdag 04 oktober 2001 18:16 schreef raptorix het volgende:
Heel lang terug deden we het op de commodore 64 om extra leventjes te krijgen in spelletjes

Vaak ging het toen vrij amateuristisch omdat kennis van assembler minimaal was, dus dan was het vaak zoeken op een bepaald getal en gokken dat dat het was, dat het programma meestal 200 keer vastliep voordat resultaat bereikt werd was alleen maar spannend

Misschien kun je als debugger bij windows werken