wie sicher ist zend safeguard
am 20.11.2006 14:05:37 von GreenRoverGibt es schon eigentlich was um zend safeguard (Kompilierung /
Verschlüsselung was ist es eigentlich genau) wieder rückgängig zu machen?
Gibt es schon eigentlich was um zend safeguard (Kompilierung /
Verschlüsselung was ist es eigentlich genau) wieder rückgängig zu machen?
Heiko (GreenRover) Henning schrieb:
> Gibt es schon eigentlich was um zend safeguard (Kompilierung /
> Verschlüsselung was ist es eigentlich genau)
Wie wärs, wenn Du mal bei Wikipedia vorbei schaust? Steht alles dort
beschrieben.
wieder rückgängig zu machen?
Manual lesen?
Ulf Kadner schrieb:
> Wie wärs, wenn Du mal bei Wikipedia vorbei schaust? Steht alles dort
> beschrieben.
laut wikipedia also beides.
> wieder rückgängig zu machen?
Das heist, auch wenn wann es encryptet und decompiliert bekommt, ist der
code immer noch.
Obfuskatiert. Was man ja nicht rückgängig machen kann.
Gibt es den Mittel und wegen um die ersten beiden Hürden zu überwinden?
Heiko (GreenRover) Henning schrieb:
> Das heist, auch wenn wann es encryptet und decompiliert bekommt, ist de=
r
> code immer noch. Obfuskatiert. Was man ja nicht rückgängig machen k=
ann.
Natürlich kann man das rückgängig machen. Jeder, der schon mal eine=
n
symbolischen Disassembler geschrieben hat, wird da vor keinem Problem
stehen.
> Gibt es den Mittel und wegen um die ersten beiden Hürden zu überwin=
den?
Natürlich. Wenn der Prozessor rankommt, komm' ich auch ran. Es gibt
keinen unknackbaren Schutz für Programme, der nicht dem Verbrennen
gleich kommt.
MfG
Niels
--=20
| http://www.kolleg.de =B7 Das Portal der Kollegs in Deutschland |
| http://www.bsds.de =B7 BSDS Braczek Software- und DatenSysteme |
| Webdesign =B7 Webhosting =B7 e-Commerce =B7 Joomla! Content Management =
|
------------------------------------------------------------ ------
Niels Braczek schrieb:
> Heiko (GreenRover) Henning schrieb:
>
>> Das heist, auch wenn wann es encryptet und decompiliert bekommt, ist der
>> code immer noch. Obfuskatiert. Was man ja nicht rückgängig machen kann.
>
> Natürlich kann man das rückgängig machen.
Und wie willst Du das anstellen? Wie willst Du aus den zufälligen,
nichtssagenden Zeichenfolgen, die statt der ursprünglichen Bezeichner
drinstehen, wieder die ursprünglichen Bezeichner ermitteln?
Bin mal gespannt, wie Dein Ansatz aussieht.
> Jeder, der schon mal einen
> symbolischen Disassembler geschrieben hat, wird da vor keinem Problem
> stehen.
Was ist ein "symbolischer Disassembler"?
Ich kenne bisher nur eine Art von Disassemblern. Und die machen nichts
Anderes, als den Maschinencode eines Programms wieder in
Assemblerbefehle zurück zu verwandeln. Und auch ein Disassembler hat
keinerlei Informationen über die ursprünglichen Bezeichner.
GruÃ. Claus
--
,~°O O
O
/ |¯`. Das neue Hochzeits-Branchenbuch im Internet ,´ / | |\
/__| `~...............................................~´ /___|/ /
Claus Reibenstein schrieb:
> Niels Braczek schrieb:
>
>> Heiko (GreenRover) Henning schrieb:
>>
>>> Das heist, auch wenn wann es encryptet und decompiliert bekommt, ist der
>>> code immer noch. Obfuskatiert. Was man ja nicht rückgängig machen kann.
>> Natürlich kann man das rückgängig machen.
>
> Und wie willst Du das anstellen? Wie willst Du aus den zufälligen,
> nichtssagenden Zeichenfolgen, die statt der ursprünglichen Bezeichner
> drinstehen, wieder die ursprünglichen Bezeichner ermitteln?
Was willst du mit ursprünglichen Bezeichnern?
$var1, $var2 und $var3 reichen doch völlig aus statt
$vielsagende_variable, $nochmehrsagende_variable und
$wasserfallredende_variable
for ($i=0; $i<$j; ++$i)
{
$k=$i;
echo $k;
}
und
for ($var1=0; $var1<$var2; ++$var1)
{
$var3=$var1;
echo $var3;
}
sind absolut gleich für den Rechner.
Oder?
MfG
Sebastian Wessel
--
Informatiker haben Humor, allerdings laesst sich der nur schwer im
Quelltext ausdruecken. Ausnahme Microsoft: Dort arbeiten die
Kabarettisten der Informatik, die sogar lustigen Quelltext schreiben
koennen. [Oliver Schad in dclpm]
Sebastian Wessel wrote:
> Claus Reibenstein schrieb:
>> Niels Braczek schrieb:
>>
>>> Heiko (GreenRover) Henning schrieb:
>>>
>>>> Das heist, auch wenn wann es encryptet und decompiliert bekommt,
>>>> ist der code immer noch. Obfuskatiert. Was man ja nicht rückgängig
>>>> machen kann.
>>> Natürlich kann man das rückgängig machen.
>>
>> Und wie willst Du das anstellen? Wie willst Du aus den zufälligen,
>> nichtssagenden Zeichenfolgen, die statt der ursprünglichen Bezeichner
>> drinstehen, wieder die ursprünglichen Bezeichner ermitteln?
>
> Was willst du mit ursprünglichen Bezeichnern?
> $var1, $var2 und $var3 reichen doch völlig aus statt
> $vielsagende_variable, $nochmehrsagende_variable und
> $wasserfallredende_variable
>
> for ($i=0; $i<$j; ++$i)
> {
> $k=$i;
> echo $k;
> }
>
> und
>
> for ($var1=0; $var1<$var2; ++$var1)
> {
> $var3=$var1;
> echo $var3;
> }
>
> sind absolut gleich für den Rechner.
>
> Oder?
>
>
Hallo,
ja für den Rechner, für dich auch? Ansonsten wären wir wie in Basic vor 20
Jahren noch bei 2-Zeichen Variablennamen.
Christian
Claus Reibenstein schrieb:
> Niels Braczek schrieb:
>> Heiko (GreenRover) Henning schrieb:
>>=20
>>> Das heist, auch wenn wann es encryptet und decompiliert bekommt, ist =
der
>>> code immer noch. Obfuskatiert. Was man ja nicht rückgängig machen=
kann.
>>=20
>> Natürlich kann man das rückgängig machen.
>=20
> Und wie willst Du das anstellen? Wie willst Du aus den zufälligen,
> nichtssagenden Zeichenfolgen, die statt der ursprünglichen Bezeichner=
> drinstehen, wieder die ursprünglichen Bezeichner ermitteln?
Die ursprünglichen Bezeichner sind irrelevant. Sie müssen nur *mir*
etwas sagen. Ich ersetze also schlicht die wirren Zeichenfolgen durch
(aus der analyse gewonnene) sprechende Namen.
>> Jeder, der schon mal einen
>> symbolischen Disassembler geschrieben hat, wird da vor keinem Problem
>> stehen.
>=20
> Was ist ein "symbolischer Disassembler"?
Das ist ein Disassembler, der Einsprungadressen, Sprunganweisungen und
Datenadressen durch Labels, also symbolische Namen ersetzt. In der Regel
arbeitet so ein Disassembler mit mehreren Durchgängen, die immer mehr
Bedeutungen zutage fördern. Die Bezeichner vergibt man dabei manuell.
Mit dieser Technik habe ich seinerzeit das Betriebssystem des Commodore
CBM 8032 und der Floppystation 8050 analysiert und war dadurch in der
Lage, diese Betriebssysteme zu patchen.
MfG
Niels
--=20
| http://www.kolleg.de =B7 Das Portal der Kollegs in Deutschland |
| http://www.bsds.de =B7 BSDS Braczek Software- und DatenSysteme |
| Webdesign =B7 Webhosting =B7 e-Commerce =B7 Joomla! Content Management =
|
------------------------------------------------------------ ------
Christian Schmelzer schrieb:
>> $var1, $var2 und $var3 reichen doch völlig aus statt
>> $vielsagende_variable, $nochmehrsagende_variable und
>> $wasserfallredende_variable
>>
>> for ($i=0; $i<$j; ++$i)
>> {
>> $k=$i;
>> echo $k;
>> }
>>
>> und
>>
>> for ($var1=0; $var1<$var2; ++$var1)
>> {
>> $var3=$var1;
>> echo $var3;
>> }
>>
>> sind absolut gleich für den Rechner.
>>
>> Oder?
>
> Hallo,
> ja für den Rechner, für dich auch? Ansonsten wären wir wie in Basic vor 20
> Jahren noch bei 2-Zeichen Variablennamen.
Du siehst das einfach zu wenig abstrakt.
Wenn's dir nicht ausreicht gibt es immernoch grep, sed, awk, ...
MfG
Sebastian Wessel
--
Informatiker haben Humor, allerdings laesst sich der nur schwer im
Quelltext ausdruecken. Ausnahme Microsoft: Dort arbeiten die
Kabarettisten der Informatik, die sogar lustigen Quelltext schreiben
koennen. [Oliver Schad in dclpm]
Heiko (GreenRover) Henning schrieb:
>>Wie wärs, wenn Du mal bei Wikipedia vorbei schaust? Steht alles dort
>>beschrieben.
>
> laut wikipedia also beides.
>
>
>>wieder rückgängig zu machen?
>
> Das heist, auch wenn wann es encryptet und decompiliert bekommt, ist der
> code immer noch.
> Obfuskatiert. Was man ja nicht rückgängig machen kann.
>
> Gibt es den Mittel und wegen um die ersten beiden Hürden zu überwinden?
Ja, für einen halbwegs guten C-Programmierer ist es kein Problem, die
Zend-Engine an der richtigen Stelle dazu zu bewegen, den Code zu
veröffentlichen. Das ist der generelle Nachteil der Überführung von
PHP-Code in irgendwelche Binärformate. Der Interpreter sieht es. Und die
Obfuskation soll auch nur den Betrachter verwirren - mit ein wenig
Geschick ist das aber keine ernsthafte Hürde.
Gruß,
Torsten
Sebastian Wessel schrieb:
> Du siehst das einfach zu wenig abstrakt.
> Wenn's dir nicht ausreicht gibt es immernoch grep, sed, awk, ...
Dann hast du nun aber ein Problem, das es Obfuskatoren gibt, die einen
Variabellen mehrfach nutzen, wenn es ausgeschlossen ist, das sie sich
beeinflussen. Und das können grep, sed, awk ja nun nicht unterscheiden.
Ich weiß nun nicht wie Zend das handhabt.
Torsten Zuehlsdorff schrieb:
> Ja, für einen halbwegs guten C-Programmierer ist es kein Problem, die
> Zend-Engine an der richtigen Stelle dazu zu bewegen, den Code zu
> veröffentlichen. Das ist der generelle Nachteil der Überführung von
> PHP-Code in irgendwelche Binärformate. Der Interpreter sieht es. Und die
> Obfuskation soll auch nur den Betrachter verwirren - mit ein wenig
> Geschick ist das aber keine ernsthafte Hürde.
>
Ja, aber ich finde diese Hürde schon noch recht groß.
Wenn man bedenkt, das es "nur" PHP code ist und du dafür einen recht
guten C-Progger brauchst.
Kann mir deshalb nicht so wirklich vorstellen, das mir da einer meine
kommerziellen Scripte auf diesen Wege offen legt.
Will sagen, das der Aufwand doch über dem Nutzen liegen dürfte ?!
Heiko (GreenRover) Henning schrieb:
> Sebastian Wessel schrieb:
>
>>Du siehst das einfach zu wenig abstrakt.
>>Wenn's dir nicht ausreicht gibt es immernoch grep, sed, awk, ...
>
> Dann hast du nun aber ein Problem, das es Obfuskatoren gibt, die einen
> Variabellen mehrfach nutzen, wenn es ausgeschlossen ist, das sie sich
> beeinflussen. Und das können grep, sed, awk ja nun nicht unterscheiden.
Aber es sollte kein Problem sein, dieses Vorgehen auf bestimmte Räume
(z.b. Funktionen) einzuschränken. Das ist natürlich aufwendig, aber
keine Hürde.
Gruß,
Torsten
Heiko (GreenRover) Henning schrieb:
>>Ja, für einen halbwegs guten C-Programmierer ist es kein Problem, die
>>Zend-Engine an der richtigen Stelle dazu zu bewegen, den Code zu
>>veröffentlichen. Das ist der generelle Nachteil der Überführung von
>>PHP-Code in irgendwelche Binärformate. Der Interpreter sieht es. Und die
>>Obfuskation soll auch nur den Betrachter verwirren - mit ein wenig
>>Geschick ist das aber keine ernsthafte Hürde.
>
> Ja, aber ich finde diese Hürde schon noch recht groß.
> Wenn man bedenkt, das es "nur" PHP code ist und du dafür einen recht
> guten C-Progger brauchst.
> Kann mir deshalb nicht so wirklich vorstellen, das mir da einer meine
> kommerziellen Scripte auf diesen Wege offen legt.
>
> Will sagen, das der Aufwand doch über dem Nutzen liegen dürfte ?!
Das wäre Ansichtssache. Die notwendigen Änderungen sind (soweit ich in
Erfahrung bringen konnte) nicht allzu groß oder kompliziert. Desweiteren
müssen sie ja nur genau einmal vollzogen werden.
Lediglich das "lesbar machen" des obfuskatorierten Codes würde eine
Hürde darstellen, die zu der Kosten/Nutzen-Überlegung führen könnte.
Gruß,
Torsten