• Apfeltalk ändert einen Teil seiner Allgemeinen Geschäftsbedingungen (AGB), das Löschen von Useraccounts betreffend.
    Näheres könnt Ihr hier nachlesen: AGB-Änderung
  • Viele hassen ihn, manche schwören auf ihn, wir aber möchten unbedingt sehen, welche Bilder Ihr vor Eurem geistigen Auge bzw. vor der Linse Eures iPhone oder iPad sehen könnt, wenn Ihr dieses Wort hört oder lest. Macht mit und beteiligt Euch an unserem Frühjahrsputz ---> Klick

Unsanity APE? Nein danke!

MacMark

Jakob Lebel
Registriert
01.01.05
Beiträge
4.874
Ich war ja noch nie ein Fan von APE und der diversen Software, die darauf basiert:
http://osx.realmacmark.de/osx_dynamic-overriding.php#application_enhancer

John Gruber von Daring Fireball ist auch kein Fan:
http://daringfireball.net/2006/01/smart_crash_reports

Bei MoAB haben sie einen fiesen Bug im APE gefunden:
http://projects.info-pull.com/moab/MOAB-08-01-2007.html

Es gibt ein paar Jungs, die (ist ja nett gemeint) versuchen die Bugs, die MoAB meldet, per APE zu stopfen. Das ist keine Lösung! APE ist selbst nur ein dreckiger Hack. Wenn man die MoAB-Jungs auch wegen einiger Falschaussagen (der Diskimage-Bug kann entgegen ihrer Aussage im MoKB http://projects.info-pull.com/mokb/ nicht zur Code-Ausführung genutzt werden) und ihres miesen Stils kritisieren kann, so haben sie dennoch, was den APE angeht, eine brauchbare Meinung.

Der APE nistet sich über diverse Drittsoftware ein. Darunter sind viele beliebte Tools. Meine Empfehlung: Einfach darauf achten, bei welcher Software die Worte "Unsanity" oder "APE" oder "Application Enhancer" vorkommen und diese meiden!
 

Sir Q

Rheinischer Winterrambour
Registriert
12.04.05
Beiträge
923
Wir sind in andere Belangen nicht einer Meinung, aber was die Verwendung von APE angeht kann ich dir nur zustimmen und generell von abraten. Es hat schon seinen Grund, warum die Firma sich „Unsanity Software” nennt!
 

MatzeLoCal

Rheinischer Bohnapfel
Registriert
05.01.04
Beiträge
2.422

Was hat denn Smart Crash Reports mit Application Enhancer zu tun?

Beide kommen von der gleichen Firma... aber sonst? SCR nutzt doch APE garnicht!

SCR nutzt Input Manager und ist deswegen bei mir automatisch nicht lauffähig.. und von Haxies usw bin ich schon gar kein Fan...

Aber zurück zu APE... es hat eine Lücke... nahezu jede Software hat Lücken und Fehler ("Hello World" vielleicht nicht...) wenn Unsanity das fixt is doch ok.
 

commander

Baldwins roter Pepping
Unvergessen
Registriert
25.02.04
Beiträge
3.206
Tja, die Wahl zwischen Pest und Cholera ist niemals einfach :)

Die meisten MOABs lassen sich auch anders meiden, als über den APE. Ich hoffe nur, dass Apple in die Gänge kommt und recht schnell Security Patches nachschiebt. Allerdings glaube ich, dass der DiskUtil Rechtemechanismus so leicht nicht patchbar sein wird. Es wird spannend.

Im Vergleich zu anderen Systemen schauts ja immer noch recht gut aus. :) Lasst Euch blos nicht irremachen.

Zum Schmunzeln bringt mich dann doch die Schlammschlacht zwischen den MOABs Hackern und Landon Fuller & Co....

Gruß,

.commander
 

eXiNFeRiS

Schöner von Bath
Registriert
30.08.05
Beiträge
3.652
Auch ich mache mittlerweile einen großen Bogen um den APE und dessen "Jünger", schade für die ein- oder andere Software (ShapeShifter) die leider nur auf dieser Schnittstelle läuft.
 

Kernelpanik

Maren Nissen
Registriert
05.03.04
Beiträge
2.303
Kann nur bestätigen: Finger weg von dem Unsanity Zeugs.
 

MacMark

Jakob Lebel
Registriert
01.01.05
Beiträge
4.874
… Allerdings glaube ich, dass der DiskUtil Rechtemechanismus so leicht nicht patchbar sein wird. Es wird spannend.

Beim Rechtereparieren ist das Problem, daß ein Admin ohne Paßworteingabe die Receipts ändern könnte, weil /Library/Receipts root/admin gehört. Wenn man es auf root/wheel setzt, dann müssen Admins ihr Paßwort tippen.
Ein vergleichbares Problem gab es damals mit den /Library/StartupItems. Die haben nun auch die richtigen Besitzer root/wheel. Wheel ist die primäre Gruppe von Root.

Der Fix ist also recht simpel :)

Außerdem haben Einträge in der Datei
/System/Library/\
PrivateFrameworks/\
DiskManagement.framework/\
Resources/HintFile.plist
Vorrang vor den Einträgen in den BOM-Dateien. Die gehört ebenfalls root/wheel.
 

commander

Baldwins roter Pepping
Unvergessen
Registriert
25.02.04
Beiträge
3.206
@MacMark: Stimmt, damit hast Du unzweifelhaft recht.

Ich bin insgesamt sowieso etwas enttäuscht vom MOAB, einige heftigere Fehler hätte ich mir schon erwartet. QT und DiskUtil, das wars bisher....

Gruß,

.commander
 

MatzeLoCal

Rheinischer Bohnapfel
Registriert
05.01.04
Beiträge
2.422
@MacMark: Stimmt, damit hast Du unzweifelhaft recht.

Ich bin insgesamt sowieso etwas enttäuscht vom MOAB, einige heftigere Fehler hätte ich mir schon erwartet. QT und DiskUtil, das wars bisher....

Gruß,

.commander

Also ich erwarte eigentlich für heute einen "Hammer" ... denn für die AttentionWhores ist der heutige Tag ja wie geschaffen ;)
 

mfkne

Weisser Rosenapfel
Registriert
03.04.06
Beiträge
776
Übrigens scheint auf der Logitech-Treiber für einige Mäuse ein Plugin für den APE mitzubringen und ggf. APE zu installieren.
 

homer_s

Hildesheimer Goldrenette
Registriert
14.07.06
Beiträge
689
ich hatte bei mir mal shapeshifter zum testen drauf, den ich jetzt wieder runtergeschmissen habe. allerdings weiß ich nicht wie ich application enhancer deinstallieren kann. kann mir da jemand helfen?

gruß homer_s
 

MacMark

Jakob Lebel
Registriert
01.01.05
Beiträge
4.874
Der Installer vom APE bietet ein Deinstall. Ansonsten müßten sie in diesen Libraries liegen: /Library oder ~/Library.
 

homer_s

Hildesheimer Goldrenette
Registriert
14.07.06
Beiträge
689
bei mir wurde ape zusammen mit shapeshifter installiert, aber nur shapeshifter deinstalliert und nicht ape.
 

Peter Maurer

Pommerscher Krummstiel
Registriert
16.03.04
Beiträge
3.077
Ich bin erklaertermassen kein APE-Fan, u.a. auch deshalb, weil ich als Entwickler schon mal lange und ausfuehrlich Ueberzeugungsarbeit leisten musste, bis ich die Unsanity-Leutchen davon ueberzeugt hatte, dass WindowShade eins meiner Programme tatsaechlich schuldhaft abstuerzen liess.

Aber das hier...

APE ist selbst nur ein dreckiger Hack.
Naja. Dass APE ein Hack ist, das hat niemand je verschwiegen. Deshalb heissen die APE-Module ja auch "Haxies". Und "dreckig" geht zu weit, finde ich. Ich empfinde es eher so, wie commander sagt ...

Tja, die Wahl zwischen Pest und Cholera ist niemals einfach :)
... wenn ich auch nicht ganz sicher bin, ob der Satz sich auf APE bezieht. ;)

Jedenfalls gibt es Aufgaben, die sich unter Mac OS X derzeit nur mittels APE, Input Manager oder mach_inject loesen lassen. Alles Hacks, aber wenn man eine dieser vorgenannten Aufgaben unbedingt loesen will, dann gibt es schlicht keinen anderen Weg.

Und dabei muss man das, was man erreichen will, eben gegen das Sicherheits- und Stabilitaetsrisiko abwaegen. Ich weigere mich aber, die Sicherheit als K.O.-Kriterium anzuerkennen. Wenn ich das taete, dann wuerde ich keinen Computer benutzen und die Fenster in meiner Wohnung zumauern.
 

MacMark

Jakob Lebel
Registriert
01.01.05
Beiträge
4.874
Du kannst sie auch von Hand beseitigen. Schau unterhalb von /Library und ~/Library in Application Support, InputManagers und Frameworks nach Namen wie APE, Unsanity und Application Enhancer.
 
  • Like
Reaktionen: homer_s

homer_s

Hildesheimer Goldrenette
Registriert
14.07.06
Beiträge
689
Du kannst sie auch von Hand beseitigen. Schau unterhalb von /Library und ~/Library in Application Support, InputManagers und Frameworks nach Namen wie APE, Unsanity und Application Enhancer.


ich habe nur noch den ordner "applicationenhancer.framework". der lässt sich allerdings nicht löschen. der papierkorb sagt, dass "aped" und "applicationenhancer" in verwendung sei.
 

MacMark

Jakob Lebel
Registriert
01.01.05
Beiträge
4.874
... Jedenfalls gibt es Aufgaben, die sich unter Mac OS X derzeit nur mittels APE, Input Manager oder mach_inject loesen lassen. Alles Hacks...
Alles drei sind Wege, die technisch unzuverlässig sind. Es ist keine saubere, daher dreckige Programmierung, weil nicht vorgesehene Eingriffe gemacht werden über nicht definierte, nicht vorhandene Schnittstellen. Es gehört immer in diesen Fällen Glück dazu, denn man kennt die Software, die damit verändert wird, die sog. Ziel- oder Opfer-Programme nicht im Quellcode, kann also einwandfreies (sprich sicheres) Funktionieren des eingeschleusten Drittcodes nicht garantieren.
http://osx.realmacmark.de/osx_dynamic-overriding.php