4. Problem unter XP Service Pack 2

Problem unter XP Service Pack 2

  • F
     

    __fastcall TF_Update::TF_Update(TComponent* Owner)
    : TForm(Owner)
{
    //Constructor von class TF_Update
    //Dieser Constructor wird unter Service-Pack 2 immer  
    //weiter ausgeführt, obwohl keine Loop definiert ist.
    ... 
    ...

    if (!updateCheck())             
    {
        execute(_projectName); //_projectName ist eine ausführbare EXE-Datei, e.g. project.exe
        exit(0);
    }
}

//---------------------------------------------------------------------------
void TF_Update::execute(AnsiString ziel)
{
    long i;
    i=long(ShellExecute(0, "open", ziel.c_str(), 0, 0, SW_SHOWNORMAL));

    //Fehlerabfang
    if(i <= 32)
    {
     if ( (i == SE_ERR_ACCESSDENIED) || (i == SE_ERR_SHARE) )
      Application -> MessageBox("Die Datei wird bereits verwendet!",
        "Kommunikation", MB_OK + MB_ICONERROR);
     else if ( (i == SE_ERR_ASSOCINCOMPLETE) || (i == SE_ERR_NOASSOC) )
      Application -> MessageBox("Die Dateiendung ist mit keinem Programm verknüpft!","Kommunikation", MB_OK + MB_ICONERROR);
     else
      Application -> MessageBox("Ein unerwarteter Fehler trat auf!"
        , "Kommunikation",MB_OK + MB_ICONERROR);
    }
}

    Ich benutze 'ShellExecute()', um eine ausführbare EXE-Datei aufzurufen. Das läuft ganz gut außer mit XP Service-Pack 2. Der Constructor wird immer ausgeführt, obwohl es gar keine Loop definiert ist. Die EXE-Datei kann auch nicht ausgeführt werden, obwohl der Zurückwert 'i' in Method 'execute()' immer 42 ist, b.z.w. die Zurückwert mehr als 32 bedeutet ok.

    Das Problem liegt bestimmt von XP Service Pack2, aber ich weiß nicht genau, wie ich es lösen soll. Kann jemand mir helfen?

    Danke!

    0
  • ?

    Schon mal die Suche benutzt?

    Ich frag nur mal so, bevor dir Jansen mit ner zusammengerollten Zeitung auf die Birne haut, deine Nase auf den "Suchen"-Button drückt und "PFUI!" brüllt... 😃

    0
  • F

    ich habe das Thema gesucht, und es besteht keine Gleiche schon diskutiert, oder?

    Ich habe den Grund schon gefunden. Es gibt eine neue Feature von Service Pack 2, eine Beschreibung ist wie folgendes:

    Befehlsverweigerung

    Die Execution Protection (NX, no execute) soll die Auswirkungen von
    Angriffen über Buffer Overflows, Integer Overflows, Heap Overflows,
    Format-String-Schwächen und anderen Fehlern minimieren. Ziel solcher
    Angriffe ist es, eigenen Code in das System einzuschleusen und auszuführen
    [3]. Üblicherweise überschreibt man dazu Bereiche in denen Daten abgelegt
    werden, etwa Stacks und Heaps, mit Code und springt ihn durch Manipulation
    des Instruction Pointers an. NX verhindert das Ausführen von Code, der in
    Datenbereichen abgelegt ist, sofern die als "nicht ausführbar"
    gekennzeichnet sind. Ein Angriff des Wurms Lovsan/MSBlaster hätte mit dieser
    Funktion auf Windows XP allenfalls den RPC-Dienst zum Absturz gebracht --
    den Rechner hätte er nicht infizieren können. NX ist standardmäßig aktiviert
    und markiert Datenbereiche wie Stacks und Heaps als nicht-ausführbar.

    Um Execution Protection zu implementieren, greift Microsoft auf die
    Fähigkeiten moderner 64-Bit-Prozesoren zurück, die Funktionen zur
    NX-Kennzeichnung von Speicherbereichen mitbringen. Derzeit stehen dafür der
    Athlon64 von AMD und der Itanium von Intel zur Verfügung. Bislang kann nur
    der Athlon64 mit dem 32-bittigen Windows XP zuammenarbeiten und dies auch
    nur im PAE-Mode (Physical Address Extension). Einige Treiber könnten hier
    zukünftig ihren Dienst versagen, da PAE einen 64-Bit-Adressraum benutzt, den
    32-Bit-Adapter nicht adressieren können. Microsoft hat deshalb auch den
    Hardware Abstraction Layer (HAL) und den Memory Manager modifiziert, um
    weitestgehende Kompatibilität zu älteren 32-Bit-Treibern zu erhalten.

    Ruft eine Applikation eine als NX markierte Speicherseite auf, löst der
    Prozessor eine Exception (STATUS_ACCESS-VIOLATION im User Mode) aus, die in
    den meisten Fällen unbehandelt bleibt und zur Terminierung des auslösenden
    Prozesses führt. Greift der Kernel auf einen geschützten Speicherbereich zu,
    stürzt Windows ab (ATTEMPTED_EXECUTE_OF_NONEXECUTE_MEMORY). Leider schützt
    Execution Protection den Kernel Mode im 32-Bit-Windows-XP nur halb: Einzig
    der Stack wird als NX markiert. Anders beim 64-Bit-Windows-XP: Außer dem
    Stack sind auch die Heaps geschützt.

    Einige Applikationen, die etwa zur Laufzeit neuen Programmcode generieren
    und ausführen wollen, dürften nach der Installation des Service Packs nicht
    mehr funktionieren. Über spezielle Funktionen können neue Anwendungen
    ausführbaren Speicher anfordern, ältere Programme müssen dazu überarbeitet
    werden.

    Unter XP Service Pack 2 darf ein Programm nicht, ein andere Programm aufzurufen. Ich schreibe keine Virus, und ich weiß nicht, wie man unter XP Service Pack 2 andere Programm aufrufen soll?

    0
  • J

    <a href= schrieb:

    Bigwill">Mann muss halt nur dran denken für die BCB.exe die Datenausführungsverhinderung zu deaktivieren.

    Dasselbe sollte wohl für das von dir geschriebene Programm gelten.

    0
  • F

    danke, es ist schon gelöst

    0
Anmelden zum Antworten