| Autor |
Beitrag |
anubis2k5
      
Beiträge: 23
Windows 7
Delphi 2010
|
Verfasst: Sa 07.05.11 10:12
Hallo Leute!
Ich habe ein Programm entwickelt, welches auf einen Mehr-Benutzer-PC arbeiten soll. Ziel des Programmes ist es die ausgedruckten Seiten zu zählen und zu speichern, um diese abrechenbar zu machen.
Ich speichere die Daten in eine simple Text-Datei. Nun möchte ich diese sichern, ohne das der Benutzer die Möglichkeit hat diese zu manipulieren oder zu löschen.
Hat jemand eine Idee wie und wo ich diese Datei verstecken kann? Das Programm läuft mit Benutzerrechten, alternativ kann ich bestimmt auch das Programm mit Admin-Rechten starten (wie muss ich noch rausfinden
Danke für eure Hilfe!
|
|
jaenicke
      
Beiträge: 19338
Erhaltene Danke: 1752
W11 x64 (Chrome, Edge)
Delphi 12 Pro, C# (VS 2022), JS/HTML, Java (NB), PHP, Lazarus
|
Verfasst: Sa 07.05.11 10:31
Verstecken? Gar nicht.
Du kannst aber einfach einen Dienst im Hintergrund laufen lassen, der die Daten in eine Datei schreibt, die nur mit Adminrechten erreichbar ist. Dann kannst du die auch sauber ins Anwendungsdatenverzeichnis legen ohne dass jemand diese verändern kann. Denn die Benutzer haben ja sicher nur normale Rechte und keine Adminrechte.
Für diesen Beitrag haben gedankt: anubis2k5
|
|
Tranx
      
Beiträge: 648
Erhaltene Danke: 85
WIN 2000, WIN XP
D5 Prof
|
Verfasst: Sa 07.05.11 11:06
Alternativ wäre es sinnvoll, die Datei einfach zu codieren:
1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: 21: 22: 23: 24: 25: 26: 27: 28: 29: 30: 31: 32: 33: 34: 35: 36: 37: 38: 39: 40: 41: 42: 43: 44: 45: 46: 47: 48: 49: 50: 51: 52: 53: 54: 55: 56: 57: 58: 59: 60: 61: 62: 63: 64: 65: 66: 67: 68: 69: 70: 71: 72: 73: 74: 75: 76: 77: 78: 79: 80: 81: 82: 83: 84: 85: 86:
| unit KonvertUnit;
interface
uses Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs, StdCtrls;
type TForm1 = class(TForm) Button1: TButton; OpenDialog1: TOpenDialog; SaveDialog1: TSaveDialog; Button2: TButton; Listbox1: TMemo; procedure Button1Click(Sender: TObject); procedure Convert(Richtung : integer); procedure Button2Click(Sender: TObject); private public end;
const Codewort = 'Dies ist ein langes Codewort mit vielen Zeichen. ****SdvGFergDEGecvsVergtfrgGer#,##';
var Form1: TForm1;
implementation
{$R *.DFM}
procedure TForm1.Button1Click(Sender: TObject); begin with opendialog1 do begin Filter := '*.xxx'; if Execute then begin Listbox1.Lines.LoadFromFile(FileName); Convert(-1); end; end; end;
procedure TForm1.Convert(Richtung: integer); var c1, cc : char; a1, a2 : word; s : string; i, j, k : longint; begin k := 1; with Listbox1 do begin for i := 0 to Lines.Count-1 do begin s := Lines[i]; for j := 1 to Length(s) do begin c1 := s[j]; cc := Codewort[k]; if Richtung = 1 then c1 := char((Ord(c1) xor Ord(cc))+32) else c1 := char((Ord(c1)-32) xor ord(cc)); s[j] := c1; k := (k mod length(Codewort))+1; end; Lines[i] := s; end; end; end;
procedure TForm1.Button2Click(Sender: TObject); begin with savedialog1 do begin Filter := '*.xxx'; if Execute then begin Convert(1); Listbox1.Lines.SaveToFile(FileName); end; end; end;
end. |
Aus dem folgenden Text:
Delphi-Quelltext 1: 2: 3: 4: 5: 6:
| Gebe hier einen Text ein:
Wert = 34,65
Zahl ist nicht integer! |
wird dann:
Delphi-Quelltext 1: 2: 3: 4: 5: 6:
| #,'6 !:1re,'n)/nS +tƒ*-+m
X7&tmtt3besy
_/hVe 0<e gcb~*c]03@C7s |
Aber wegen der XOR-Verknüpfung der einzelnen Zeichen mit dem Text der Datei (hier in einzelnen Zeilen eines Memo-Feldes) kann der Text vom Programm problemlos gelesen werden. Wenn dann jemand diese Datei (welche zudem ja auch noch jede beliebige Endung annehmen kann) ändert, ist dann der Inhalt nicht mehr komplett lesbar.
Anmerkung:
Die +32 und -32 in der Convert-Funktion ist notwendig, um Zeichen unter ASCII 32 (= Leerzeichen) zu vermeiden. Es käme u.U. zu Zeilenumbrüchen beim Speichern.
Die Programmierung - um es gleich vorweg zu nehmen - ist NICHT zeitoptimiert, da ich nicht davon ausgehe, dass Du 100 MB Daten konvertieren willst. Es ist meine Art, einfach zu programmieren und nicht um jeden Preis das Letzte aus der Geschwindigkeit herauszuholen.
_________________ Toleranz ist eine Grundvoraussetzung für das Leben.
Für diesen Beitrag haben gedankt: anubis2k5
|
|
anubis2k5 
      
Beiträge: 23
Windows 7
Delphi 2010
|
Verfasst: Sa 07.05.11 12:06
Danke Tranx,
aber das bringt mich nicht wirklich weiter, denn der Benutzer kann die Datei ja immer noch einfach löschen...
|
|
Luckie
Ehemaliges Mitglied
Erhaltene Danke: 1
|
Verfasst: Sa 07.05.11 12:33
Und was spricht gegen die Lösung mit dem Dienst?
|
|
Tranx
      
Beiträge: 648
Erhaltene Danke: 85
WIN 2000, WIN XP
D5 Prof
|
Verfasst: Sa 07.05.11 13:32
Das Problem ist ja, dass die Daten immer in eine Datei geschrieben werden. Mag sein, dass man die nur mit Administratorrechten bearbeiten oder gar löschen kann. Aber wie wäre es, wenn Du die Daten gar nicht in eine Datei, sondern in die Registry schreibst. Ich weiß ja nicht, wieviele Daten Du da erfasst. Wenn es nur wenige sind, z.B. nur 5 Benutzer, dann bräuchtest Du ja bloß 5 Registry-Einträge, um die Daten zu erfassen. Der Vorteil wäre auch der, dass eben keine Datei neu erzeugt würde, also auch dies nie in einer Suche erscheinen würde. Auch wenn man sie nur mit Administratorrechten löschen kann, ist diese Datei doch nicht wirklich sicher. In der Registry irgendwelche Einträge zu suchen, ist dahingehend schon wie die Suche der Stecknadel im Heuhaufen. Denn der Nutzer müsste ja wissen, wonach er suchen soll. Du als Programmierer hingegen weißt es und kannst die Registry auslesen und die Daten verwenden.
_________________ Toleranz ist eine Grundvoraussetzung für das Leben.
|
|
Kha
      
Beiträge: 3803
Erhaltene Danke: 176
Arch Linux
Python, C, C++ (vim)
|
Verfasst: Sa 07.05.11 14:18
Tranx hat folgendes geschrieben : | | Auch wenn man sie nur mit Administratorrechten löschen kann, ist diese Datei doch nicht wirklich sicher. |
Natürlich ist sie das, wenn die Anwender keinen Adminzugriff besitzen  . Deine Obfuscation-Ansätze sind dagegen nutzlos, sobald jemand, der halbwegs Ahnung vom Programmieren hat, die Datei manipulieren will.
_________________ >λ=
|
|
glotzer
      
Beiträge: 393
Erhaltene Danke: 49
Win 7
Lazarus
|
Verfasst: Sa 07.05.11 14:26
"nur mit Adminrechten löschen können" ist doch auch nicht sicher. Ich nehm einfach eine Linux-live cd/dvd und lösch die Datei damit.
Sobald jemand physikalisch an den PC ran kann, kann er damit machen was er will.
_________________ ja, ich schreibe grundsätzlich alles klein und meine rechtschreibfehler sind absicht
|
|
Tranx
      
Beiträge: 648
Erhaltene Danke: 85
WIN 2000, WIN XP
D5 Prof
|
Verfasst: Sa 07.05.11 15:45
Das Problem bei einem Ansatz der Art, wie ihn der Threadstarter sucht, ist, was die Benutzer wollen. Wollen sie seine Absicht, die Benutzung festzuhalten und abzurechnen, torpedieren, oder eben nicht. Wenn sie es wollen, kann sein, dass sie dann auch einfach das Programm umgehen. Dann werden die gewünschten Daten nicht aufgezeichnet und das Ergebnis ist nicht auswertbar. Wenn sie das nicht wollen, oder es ihnen egal ist, was das Programm über ihre Nutzung aufzeichnet, dann braucht er wohl kaum einen großen Aufwand treiben, um die Daten zu schützen. Im ersteren Fall ist der Aufwand - je nach Computerkenntnissen der Nutzer - sicher enorm.
Vielleicht - sollte es solche Fälle von absichtlicher Torpedierung der Absichten des Programmierers geben, ist dann eine möglicherweise redundante Speicherung der Daten an mehreren Orten angebracht. So dass eben die Suche nach der berühmten Stecknadel im Heuhaufen notwendig wird, um seine Spuren zu verwischen. Dies scheint mir im Übrigen Microsoft mit einigen Daten anzustellen, die das Betriebssystem speichert. Die sind auch an mehreren Orten gespeichert. Und wer weiß, wo sie auch noch gespeichert sind, außerhalb des PCs, meine ich.
Ich gebe Glotzer Recht. Man kann - wenn man will und die entsprechenden Möglichkeiten oder Hilfsmittel hat - alles mit dem PC anstellen. Das Einfachste ist, man meldet sich als Administrator an. Basta! Und wer jetzt sagt, das sei nicht möglich, sollte sich mal fragen, ob er das ehrlich glaubt, was er sagt. Ein Administratorpasswort herauszubekommen, z.B. des Netzwerkadministrators, ist sicher nicht unmöglich. Und die Administratordaten des lokalen Rechners herauszufinden, ist sicher noch viel einfacher.
Aber das beste Versteck ist immer noch dasjenige, welches ganz offensichtlich ist. Oder?  Womit niemand rechnet.
_________________ Toleranz ist eine Grundvoraussetzung für das Leben.
|
|
Hidden
      
Beiträge: 2242
Erhaltene Danke: 55
Win10
VS Code, Delphi 2010 Prof.
|
Verfasst: Sa 07.05.11 15:59
Moin,
Ich nehme an, der Drucker läuft über's Netzwerk? Dann könnten die Daten auch an einen Server gehen, der irgendwo geschützt im Gebäude steht. Der Server bucht die Punkte vom Konto ab und schickt den Druckauftrag an den Drucker - dieser ist so konfiguriert, dass er nur vom Server annimmt, selbst wenn man die IP kennt.
lg,
|
|
Tranx
      
Beiträge: 648
Erhaltene Danke: 85
WIN 2000, WIN XP
D5 Prof
|
Verfasst: Sa 07.05.11 16:45
Das Problem scheint zu sein, dass das Programm auf einem PC läuft, an dem mehrere Nutzer arbeiten. Dann reicht es nicht, nur die IP des Rechners zu kennen. Man muss auch die aktuellen Benutzerdaten kennen.
Ich denke, wenn es kritisch ist, also die Nutzer die Auswertemöglichkeit des Programms absichtlich torpedieren wollen, bleibt nur die Chance, die Daten an mehreren Stellen gleichzeitig im Netz zu speichern, oder an einer Stelle im Netz, die automatisch an einer Stelle gesichert wird, die die Nutzer nicht erreichen können. Dann könnte man auch die erzeugte Datei an dieser Stelle sofort wieder löschen.
Das liefe dann so:
Benutzer-PC: Programm, sichert die Daten an der Stelle x im Netz.
Admin-PC: fragt mittels eines Programms ständig die Datei an der Stelle x im Netz auf Änderung ab. Dann sichert ein Programm diese Datei an der Stelle y (z.B. auf dem lokalen Laufwerk des Admin-Rechners) und löscht die Datei an Stelle x oder er liest die neuen Daten ein und speichert sie dann anderswo wieder ab.
Ein Nutzer hätte in einem solchen Fall keine Chance, außer er käme an den Admin-Rechner heran, die Daten zu manipulieren, da sie im Moment der Erstellung auch fast schon wieder verschwunden wären.
Ich wende ein solches Verfahren bei einer Messdatenauswertung an. Da der Messdatenrechner sehr langsam ist, läuft die Auswertesoftware auf einem anderen Rechner im Netz. Der Messwerterechner speichert die neuen Daten im Netz und der Auswerterechner stellt fest, dass neue Daten vorliegen und ruft diese ab. Das Gleiche kann auch hier angewendet werden.
_________________ Toleranz ist eine Grundvoraussetzung für das Leben.
|
|
trm
      
Beiträge: 491
Erhaltene Danke: 19
Windows 7x64
Delphi 7
|
Verfasst: Sa 07.05.11 17:04
Es gibt auch die Möglichkeit, die Daten direkt an die ausführbare Datei zu hängen.
Vor vielen Jahren wurde das von Nico B. dargestellt.
Damals noch im "Spotlight Forum" von Peter.
Ich habe auf die Schnelle den Beitrag nicht gefunden, aber der ist noch im Archiv, das weiß ich.
Einen ähnlichen Beitrag von Nico gibts auch im Archiv hier im Entwickler-Forum.
Der Vorteil wäre, dass OHNE die exe das Programm nicht aufrufbar wäre.
Der Nachteil wäre, dass sich der Benutzer die "alte" Exe einfach kopiert und immer wieder eine frische Kopie vom 1. Original startet.
Viele Grüße
Mathias
_________________ In Erfurt gibt es eine Pension, in der es gemütlich ist, Google einfach nach Pension Fiege
|
|
Hidden
      
Beiträge: 2242
Erhaltene Danke: 55
Win10
VS Code, Delphi 2010 Prof.
|
Verfasst: Sa 07.05.11 18:01
Wenn unbeaufsichtigter Zugriff auf den Drucker besteht, ist die Sache so oder so nicht völlig sicher zu bekommen.
Vor Manipulation des Punktekontos im Nachhinein kann man sich schützen: Die Daten nicht lokal speichern. Die Identifikation erfolgt dann selbstverständlich nicht über eine IP, sondern über Usernamen und Passwort
Ich würde die Hardware jetzt aber nicht groß umstellen oder von vornherein viel Aufwand betreiben: Blätter abzählen, die ihr einlegt. Wenn welche verschwinden, könnt ihr noch immer verschärfen.
Um welchen Standplatz geht es denn, und welche Größenordnung? Davon ist ja auch ein wenig abhängig, womit man rechnen muss.
lg,
_________________ Centaur spears can block many spells, but no one tries to block if they see that the spell is a certain shade of green. For this purpose it is useful to know some green stunning hexes. (HPMoR)
Zuletzt bearbeitet von Hidden am Sa 07.05.11 20:36, insgesamt 1-mal bearbeitet
|
|
Tranx
      
Beiträge: 648
Erhaltene Danke: 85
WIN 2000, WIN XP
D5 Prof
|
Verfasst: Sa 07.05.11 18:37
Mit einem Programm alleine ist sicher eine Druckerverwaltung nicht machbar. Es kann aus so vielen Programmen auf einen Drucker zugegriffen werden, dass dieses Programm schon jeden Druckvorgang abfangen muss. Wenn zu viele Druckvorgänge im Betrieb passieren, ist darüber nachzudenken, wie über einen allgemeinen Appell (Auflistung der Druckseiten pro Monat in einer Grafik und appellieren an die Benutzer, ihre Drucke zu reduzieren) an die Vernunft dies zu minimieren ist. Überwachung der Benutzer hilft selten und führt nur zu Frust und Gegenwehr.
Wenn ganze Abteilungen - aber im vorliegenden Fall scheint das nicht so zu sein - abgerechnet werden sollen, ist eher über getrennte Drucker zu reden. Aber im vorliegenden Fall scheint es bloß um mehrere Nutzer zu gehen. Da ist eher ein Gespräch mit den Beteiligten angesagt.
_________________ Toleranz ist eine Grundvoraussetzung für das Leben.
|
|
trm
      
Beiträge: 491
Erhaltene Danke: 19
Windows 7x64
Delphi 7
|
Verfasst: Sa 07.05.11 19:00
Tranx hat folgendes geschrieben : | | Mit einem Programm alleine ist sicher eine Druckerverwaltung nicht machbar. |
Kennst Du nicht das wirklich gute Programm "InkSaver" ?
Leider ist das nur bis Windows XP nutzbar, aber damit kann JEDER Ausdruck abgefangen werden.
Ich denke, über so einen Ansatz, einen Treiber zu definieren, welcher zwischen Drucker und Druckertreiber liegt, sollte überlegt werden. Hier kann dann gezählt werden.
Gruß Mathias 
_________________ In Erfurt gibt es eine Pension, in der es gemütlich ist, Google einfach nach Pension Fiege
|
|
anubis2k5 
      
Beiträge: 23
Windows 7
Delphi 2010
|
Verfasst: Sa 07.05.11 19:28
Ohh wow! Da habe ich ja eine interessante Diskussion entfacht - ich danke euch allen für die vielen Vorschläge.
Aber Karten auf dem Tisch:
zunächst ist es in der Tat ein PC, an welchem max. 16 Benutzer arbeiten. Der Drucker ist direkt an LPT1 angeschlossen, das OS Windows XP. Die Benutzer sind - naja sagen wir mal "unter _geschützten_ Verhältnissen" - mehr will und kann ich dazu nicht sagen. Fakt ist, das die Benutzer sich Blätter für den Druck "kaufen" müssen. Leider ist es oftmals so, dass uns die Benutzer betrügen und somit die Kosten für den Toner nicht wieder rein kommen. Das Finanzielle spielt hier eher eine untergeordnete Rolle - vielmehr die Ehrlichkeit und Transparenz der Benutzer.
Von den Vorschlägen bin ich begeistert, scheint mir, für meine Zwecke, aber das ein oder andere zu hoch gestochen zu sein.
Für mich interessant wäre die Möglichkeit die Daten in der Registry abzulegen - geht das denn als normaler Benutzer, die Daten in HKEY_LOCAL_MACHINE - ohne Adminrechte zu legen? Wobei ich über die Daten des Admin-Accounts natürlich verfüge...
Desweiteren finde ich die Option verführerisch, die Daten an die Exe-Datei anzuhängen. Da schweben mir auch schon einige Ideen vor. Da könnte man ja eine komplette History anlegen...
Das mit dem Windows-Dienst ist auch eine alternative, aber an der beiße ich mir seit heute früh die Zähne aus - siehe diesem Thread: www.delphi-forum.de/...=0&postorder=asc
Vielen Dank!
|
|
Luckie
Ehemaliges Mitglied
Erhaltene Danke: 1
|
Verfasst: Sa 07.05.11 20:41
anubis2k5 hat folgendes geschrieben : | | Für mich interessant wäre die Möglichkeit die Daten in der Registry abzulegen - geht das denn als normaler Benutzer, die Daten in HKEY_LOCAL_MACHINE - ohne Adminrechte zu legen? Wobei ich über die Daten des Admin-Accounts natürlich verfüge... |
Nein, du müsstest die Daten in der Anwendung hinterlegen, wo man sie natürlciha uch bganmz einfach wieder auslesen kann, da sie dort im Klartext drinstehen und dann wäre das gesamte Konto kompromittiert.
| Zitat: | | Desweiteren finde ich die Option verführerisch, die Daten an die Exe-Datei anzuhängen. Da schweben mir auch schon einige Ideen vor. Da könnte man ja eine komplette History anlegen... |
Du kannst eine Exe nicht so einfach verändern. Das Anhängen ist kein Problem aber nicht so einfach an eine laufende Exe. Zudem brauchst du dazu auch wieder Administratorenrechte, da du Schreibzugriff auf die Exe brauchst, die nicht jeder Benutzer hat.
Das dürfte die einzige sinnvolle Lösung sein.
|
|
jaenicke
      
Beiträge: 19338
Erhaltene Danke: 1752
W11 x64 (Chrome, Edge)
Delphi 12 Pro, C# (VS 2022), JS/HTML, Java (NB), PHP, Lazarus
|
Verfasst: Sa 07.05.11 21:19
|
|
anubis2k5 
      
Beiträge: 23
Windows 7
Delphi 2010
|
Verfasst: So 08.05.11 09:39
jaenicke hat folgendes geschrieben : |
anubis2k5 hat folgendes geschrieben : | | Für mich interessant wäre die Möglichkeit die Daten in der Registry abzulegen - geht das denn als normaler Benutzer, die Daten in HKEY_LOCAL_MACHINE - ohne Adminrechte zu legen? Wobei ich über die Daten des Admin-Accounts natürlich verfüge... | Theoretisch ja, aber dann müsste dein Programm die Adminzugangsdaten kennen und das wäre Blödsinn.
|
wieso wäre das Blödsinn? Wenn die Admindaten ordentlich in der Exe "versteckt" sind, dürfte da doch keiner mehr daran kommen... Die Admindaten habe ich. Wie wäre denn dann der Weg?
Grüße Thomas!
PS.: Gehe dann doch den Weg per Dienst, allerdings interessiert mich der Zugriff auf die Registry auch von einem Nicht-Admin-Konto auf HKEY_LOCAL_MACHINE.
|
|
trm
      
Beiträge: 491
Erhaltene Danke: 19
Windows 7x64
Delphi 7
|
Verfasst: So 08.05.11 10:26
anubis2k5 hat folgendes geschrieben : | | Wenn die Admindaten ordentlich in der Exe "versteckt" sind, dürfte da doch keiner mehr daran kommen... Die Admindaten habe ich. Wie wäre denn dann der Weg? |
Mach das lieber nicht. Selbst wenn die Daten verschlüsselt in der exe liegen, müssen die irgendwann als Klartext in den Speicher gelangen, um damit agieren zu können.
Mit einem Hexeditor (WinHex) kann der Speicher durchsucht werden, man benötigt kein spezielles Programm wie OllyDbg oder ähnliches.
Von dieser Sicht aus ist DiESE Variante, Festverdongelte Passwörter zu speichern, absolutes "No-Go".
Des Weiteren, was, wenn jemand das Adminpasswort ändert oder den Adminaccount sperrt?
Gruß
Mathias
_________________ In Erfurt gibt es eine Pension, in der es gemütlich ist, Google einfach nach Pension Fiege
|
|
|