Schlüsselberechnung

[Stephan H. (stephan-)]

Hallo Leute,

ich habe mal wieder ein Problem beim Kunden. Serverumzug.
Die alte Win3.1 Soft muss wieder auf den neuen Server und wie
immer meckert das Proggi nach einer Freischaltung. Die Softwarefirma 
gibt es zwar noch aber wenn es um dieses Proggi geht, lassen die sich 
verleugnen und sind nicht erreichbar. Mails werden auch nicht 
beantwortet. Vom alten Server läuft sie noch, aber diesen wegen einem 
Proggi laufen lassen ist auch alles andere als sinnvoll.

Ich habe hier mal einen Teil der INI Datei:

[KEY]
VVMWIN=2;45;9:<:<D?
EUROUMST=2;465=>=::D=
VVMWIN602=2849<77A?>>E
LIDS=3
VVM-IP303=2;44=7>:?CB>


VVM-IP1003=288=5<89:<C<@>
VVM-IP1104=29577?;:<=A<=E
VVM-IP0509=2956=<@A<;<<CA

dazu noch eine PNG mit passenden Schlüssel / SN Kombinationen.
Kann sich jemand einen Reim darauf machen, wie die Schlüssel berechnet 
werden könnten ?


Danke

[Daniel A. (daniel-a)]

Wiso entfernst du den Kopierschutz nicht einfach, oder lässt ihn von 
jemandem entfernen? Oder alternativ das Programm ersetzen, oder ein 
eigenes schreiben. Oder das Programm disassemblieren und selbst 
nachsehen.

PS: https://xkcd.com/488/

[Der Andere (Gast)]

Stephan H. schrieb:
> Die Softwarefirma
> gibt es zwar noch aber wenn es um dieses Proggi geht, lassen die sich
> verleugnen und sind nicht erreichbar.

Firmenanwalt fragen:
Vieleicht Einschreiben mit Rückantwort und Androhung einer einstweiligen 
Verfügung.
Entweder Freischaltcode oder Lösung wie die SW ohne Code läuft.
Das sollte aber der Anwalt besser wissen was da sinnvoll ist.


Stephan H. schrieb:
> Vom alten Server läuft sie noch, aber diesen wegen einem
> Proggi laufen lassen ist auch alles andere als sinnvoll.

In einer VM laufen lassen.

[Rufus Τ. F. (rufus)]

Stephan H. schrieb:
> Vom alten Server läuft sie noch, aber diesen wegen einem Proggi laufen
> lassen ist auch alles andere als sinnvoll.

Zieh das Ding in eine virtuelle Maschine um, und bereite Deinen Kunden 
darauf vor, das "Proggi" irgendwann nicht mehr zu nutzen.

[Stephan H. (stephan-)]

VM is klar, die Stromkosten für den alten Server sind dem Kunden auch 
egal.
Wäre halt nur schön wenn.....
Vielleicht schaut ja hier einer rein und sagt.... jo sieht man doch.
so und so dann durch 2*33 etc.pp.

:-))

[Daniel A. (daniel-a)]

Hier mal ne Statistik wie häufig welches Zeichen vorkommt:

Zeichen, Code,  Häufigkeit
2  50  7
3  51  1
4  52  5
5  53  5
6  54  2
7  55  5
8  56  4
9  57  5
:  58  7
;  59  6
<  60  12
=  61  8
>  62  6
?  63  4
@  64  2
A  65  4
B  66  1
C  67  3
D  68  2
E  69  2

[c.m. (Gast)]

oder halt das proggi auf eine aktuelle versi bringen (oder von einen 
anderen anbiti gönnen), so das es auf einer aktuellen soft läuft.
windows 3.1? echt jetzt?

andererseits ist das uralt proggi wahrscheinlich single threaded, und es 
sollte zu schaffen sein mit einem disassembler (z.b. SoftICE) 
entsprechende programmstellen auszunopen.
alternativ nach einem keygen für proggi suchen :)

[Stephan H. (stephan-)]

Hallo,

es gibt keine aktuellere Version davon. Nicht mal die Datenkrake findet 
etwas dazu.Es gibt einen Nachfolger soweit ich weis. Allerdings will der 
Firmeninhaber, der seit 2 Jahren in Rente sein wollte, keinen 
5-stelligen Betrag mehr ausgeben.

[Rufus Τ. F. (rufus)]

Dann wird der alte Server weiterlaufen müssen. Das kostet zwar Strom, 
und macht Krach, aber der Aufwand, das Softwarefossil irgendwohin 
umzuziehen und gar den "Key" zu knacken, steht in keinem Verhältnis zum 
Nutzen.

Ihr solltet Euch nach einer alternativen Lösung für das umsehen, was die 
Software machen soll, und vor allem über Migration der Daten nachdenken.

Denn wenn der alte Server die Grätsche machen sollte, steht Ihr vor 
einem ganz anderen Problem.


Was macht denn die ungenannte Software so tolles und einzigartiges?

[Stephan H. (stephan-)]

ist eigentlich nur ein Proggi für Aufträge/ Rechnung und Provisionen. 
0815 also. Das Problem ist der Datenstamm und die weitere Nutzung 
dessen. Es gibt keine Doku zum Aufbau der DB und Tabellen. Wenn der 
Server hinüber geht, kommt er eben in eine VM. Den Namen des Proggis 
habe ich ja absichtlich nicht genannt, ist aber zu sehen für den der es 
kennt.

[Daniel A. (daniel-a)]

Stephan H. schrieb:
> Es gibt keine Doku zum Aufbau der DB und Tabellen

Ist die DB ein Proprietäres Programm, oder files mit unbekanntem Format? 
Dann könnte man das versuchen zu reverse engineeren.
Falls es nur MySQL, Postgres, MSSQL, sqlite, oder sonst was übliches 
sein sollte, solte es recht simpel sein die Daten zu exportieren und 
woanders zu Importieren.

Es währe viel einfacher, wenn man das Program hätte, da man es dann 
disassemblieren könnte.
Oder die Files der Datenbank, falls Proprietär, oder die Tabellen descs, 
falls es eine Bekannte DBSoftware wäre. Dann könnte man die Daten 
vermutlich relativ einfach für alternative Software anpassen.Aber 
vermutlich sind das ja vertrauliche Daten... Ihr habt nicht zufällig ne 
leere DB mit Testdaten?

[TestX (Gast)]

Ehrliche Antwort:
Kauf euch irgendein! neues Programm, dass die Anforderungen erfüllt. zB 
etwas von Lexware oder SAGE.

Dann setzt Ihr da jemanden ein paar Tage dran, der die Daten manuell 
migriert. Das ist in solchen Fällen der einzig praktikable 
Lösungsansatz.

[Stephan H. (stephan-)]

mit Daten von Inkasso- Auskunftsunternehmen soll man nicht hausieren.
Die DB sind ganz normale dbf Dateien. Wie gesagt der Inhaber will seit 2 
Jahren schon weg sein, ohne die Leute auf die Straße zu setzen. Da kann 
ich verstehen auf unnötige Investitionen zu verzichten. Deswegen läuft 
das jetzt erstmal so weiter. Solange der alte Server läuft bleibt das 
eben so. Danach muss eben eine VM her.

[Georg (Gast)]

Stephan H. schrieb:
> Die DB sind ganz normale dbf Dateien

Dann ist die Migration doch problemlos, sofern bei Ausfall des Servers 
noch eine Sicherung verfügbar ist(!!).

Allerdings sollte man die vornehmen, bevor der letzte Programmierer 
gestorben ist, der sich noch mit DBase, Clipper, Fox usw. auskennt.

Daniel A. schrieb:
> Falls es nur MySQL, Postgres, MSSQL, sqlite

Naja, die heutige Jugend...

Georg

[R. M. (Gast)]

Georg schrieb:
> Allerdings sollte man die vornehmen, bevor der letzte Programmierer
> gestorben ist, der sich noch mit DBase, Clipper, Fox usw. auskennt.

Ist nichtmal zwingend erforderlich, da die DBF-Tabellen von gängiger 
Software (mir würde da als Erstes, mit den niedrigsten Einstiegshürden, 
LibreOffice einfallen) problemlos weiterbearbeiten kann. Erst wenn die 
alten Automatismen nachgebaut werden sollen, wäre etwas Programmiererei 
angesagt. Und auch da ist die Auswahl gross.
mfG

[Rufus Τ. F. (rufus)]

R. M. schrieb:
> Ist nichtmal zwingend erforderlich, da die DBF-Tabellen von gängiger
> Software (mir würde da als Erstes, mit den niedrigsten Einstiegshürden,
> LibreOffice einfallen) problemlos weiterbearbeiten kann.

Das setzt allerdings voraus, daß die Tabellen sinnvoll strukturiert 
sind, d.h. daß die Spaltennamen irgendwas mit dem Inhalt zu tun haben, 
und nicht zig Querverweise auf andere Tabellen verwendet werden.

In so Softwarefossilien findet man ja manchmal die drolligsten Dinge, 
ich begegnete mal einer, in der es Tabellen namens "aa", "aaa" und "bb" 
gab. Das war wohl eine Lagerverwaltung, geschrieben von einem 
vergreisten Softwareakademiker (der den geistigen Vorruhestand schon vor 
Erscheinen von DBase III erreicht hatte).