4. Zugriffsverletzung bei return

Zugriffsverletzung bei return

  • B

    C0dR schrieb:

    out ist der output buffer, da kommt das Ergebnis rein.

    Ja, aber wie groß ist denn das Ergebnis? In Deiner ursprünglichen Version passte ja nur ein Byte in out, wenn das Ergebnis jetzt mehr als 255 Byte hat, ist out immer noch zu klein ...

    0
  • C

    Das Ergebniss sollte aber nicht größer werden, denn diese (erste) nachricht ist vorbestimmt und sollte nicht mehr als 255 zeichen groß werden.
    Ich kann aber auch nicht vorher sehen wie groß diese wird.
    Aber liegt das Problem echt an dieser Stelle?

    0
  • C

    Hast du denn bei der Stringverarbeitung auch daran gedacht, (a) Platz für den Null-Terminator zu lassen und (b) diesen immer ordnungsgemäß zu setzen? (ich bin mir nicht sicher, ob sich Funktionen wie encrypt() oder recv() immer darum kümmern)

    0
  • C

    Mit null Terminator meinst du das \n am ende einer Nachricht?
    Oder hab ich dich falsch verstanden?

    0
  • B

    CStoll schrieb:

    Hast du denn bei der Stringverarbeitung auch daran gedacht, (a) Platz für den Null-Terminator zu lassen und (b) diesen immer ordnungsgemäß zu setzen? (ich bin mir nicht sicher, ob sich Funktionen wie encrypt() oder recv() immer darum kümmern)

    recv / send kümmern sich da nicht drum, die erwarten Längenangaben.

    C0dR schrieb:

    Das Ergebniss sollte aber nicht größer werden, denn diese (erste) nachricht ist vorbestimmt und sollte nicht mehr als 255 zeichen groß werden.
    Ich kann aber auch nicht vorher sehen wie groß diese wird.
    Aber liegt das Problem echt an dieser Stelle?

    Keine Ahnung, das bisschen Code, das Du hier zeigst, ist aber ansonsten in Ordnung. Es muss sichergestellt sein, dass in aes->Encrypt nicht mehr nach buf geschrieben wird, als Platz da ist. Und da out danach als C-String benutzt wird, um einen std::string zu initialisieren, sollte es nullterminiert sein.

    0
  • -

    C0dR schrieb:

    Mit null Terminator meinst du das \n am ende einer Nachricht?
    Oder hab ich dich falsch verstanden?

    Warum \n ? Das wäre dann die escape sequenz (newline).
    Ein NULL - Terminator ist immer noch '\0'.

    folglich...

    buffer[m_len] = '\0';
    0
  • C

    Ah ok, hab es jetzt so gemacht und ich bin jetzt auch mal schritt für schritt durchgelaufen und der Fehler taucht immer in strlen.asm auf, hat also wohl wirklich was mit der Länge der chars zu tun?

    um genau zu sein an dieser Stelle:

    str_misaligned:
        ; simple byte loop until string is aligned
        mov     al,byte ptr [ecx]

    tut mir leid wenn ich euch damit nerfe, aber ich komm einfach nicht weiter 😞

    //Edit:
    Ich hab mir beim debuggen jetzt auch mal die Werte der ganzen variablen angeguckt und da kam doch teilweise schon was sehr komisches heraus.Deswegen hab ich die ganzen Variablen noch einmal überarbeitet und jetzt kommt am ende auch was (hoffentlich) richtiges raus. Es hat zumindest die richtige Länge und es sind auch AES typische Zeichenfolgen.

    Den Fehler mit dem Access Violation hab ich auch (mehr oder weniger gefunden) weil ich hab bin ihn jetzt umgangen:

    void Socket::SendData(std::string s,bool* msg) {
    if(send(mySocket,s.c_str(),s.length(),0) != SOCKET_ERROR){
    *msg = true;
    //return true;
    }
    else
    *msg = false;
    //return false;
    }

    Aber jetzt komm ich nicht mehr aus der Funktion ConnectToServer über return raus. Wieder access violation. 😡
    Wie kann das eigentlich passieren dass ich aus keiner meiner funktionen mehr über return raus komme??

    0
  • C

    WOW!
    Ich hab den Fehler gefunden!
    Und das ist echt strange, es lag an der Zeichensatzkodierung von meinem Java server.
    Der hat falsche zeichensätze zurückgesendet welche dann beim entschlüsseln ziemliches chaos verursacht haben.
    Hab in java den Zeichensatz auf Windows-1252 gestellt und schon gabs keine Probleme mehr.

    Auf sowas muss man erstmal kommen -.-

    Aber vielen Dank euch allen für eure Hilfe! Hat mir geholfen auf den richtigen Pfad (der Fehlerbehebung) zu kommen 😃

    0

  • @C0dR:
    Wenn dein Client beim Dekodieren einfach abstürzt (Access Violation o.ä.), dann hat er aber immer noch einen Bug, den du fixen solltest.

    0
  • -

    hustbaer schrieb:

    @C0dR:
    Wenn dein Client beim Dekodieren einfach abstürzt (Access Violation o.ä.), dann hat er aber immer noch einen Bug, den du fixen solltest.

    Dies meine ich auch...
    [at]C0dR
    Und bei Deinen Grundlagenkenntnissen haperts auch noch ein little bit. Denn sonnst wüsstest Du was eine String - NULL-Terminierung ist '\0'.

    0
Anmelden zum Antworten