Merkwürdiger EMail-Spam seit ein paar Tagen



  • betreff und body die genannten drei zeichen wie beim OP...



  • Ist doch offensichtlich, das sind Base64 kodierte IPv4 Adressen! Nehmen wir mal die erste, cddygf wird zu 71 d7 72 81, entspricht 113.215.114.129. Das ist dann die IP des Zwischenservers, der die Aufgaben vom Masterserver an die Slaves verteilt. Und weil die Zwischenserver dauernd wechseln, werden deren IPs halt über Mails verteilt. Klare Sache. 🤡

    http://www.iplocation.net/index.php Sagt die IP kommt aus China.



  • cooky451 schrieb:

    Ist doch offensichtlich, das sind Base64 kodierte IPv4 Adressen! Nehmen wir mal die erste, cddygf wird zu 71 d7 72 81, entspricht 113.215.114.129. Das ist dann die IP des Zwischenservers, der die Aufgaben vom Masterserver an die Slaves verteilt. Und weil die Zwischenserver dauernd wechseln, werden deren IPs halt über Mails verteilt. Klare Sache. 🤡

    http://www.iplocation.net/index.php Sagt die IP kommt aus China.

    Na, er wird die Zahl vor dem Versenden schon mit 43 multipliziert haben.

    Sone weiß sogar, warum nicht mit 42.



  • Ich kann mir auch eine IP-Adresse ausdenken, und die mag auch in Kasachstan sein, das heißt noch nichts.

    Informationen? Sagen wir mal, die Kodierung ist ISO 8859-1, ein Byte. Dann haben wir sechs Bytes... genug für eine IPv4 und einen Befehl aus zwei Byte. Warum aber zufällig Buchstaben gewählt wurden... fraglich. Daher: Wahrscheinlich Spam.



  • Sone schrieb:

    Ich kann mir auch eine IP-Adresse ausdenken, und die mag auch in Kasachstan sein, das heißt noch nichts.

    Schade, dachte zu sagst was zu 42 oder 43.

    Sone schrieb:

    Informationen? Sagen wir mal, die Kodierung ist ISO 8859-1, ein Byte. Dann haben wir sechs Bytes... genug für eine IPv4 und einen Befehl aus zwei Byte. Warum aber zufällig Buchstaben gewählt wurden... fraglich. Daher: Wahrscheinlich Spam.

    Sind die zufällig?



  • Moment, können eigenltich noch irgendwo mehr Bytes "versteckt" sein? Im Protokoll oder so?

    Sind die zufällig?

    Die Kodierung ist aber nicht durch den Cracker bestimmt. Es ist unwahrscheinlich, dass alle Zahlen durch Kleinbuchstaben repräsentiert werden.

    Schade, dachte zu sagst was zu 42 oder 43.

    Übersehen.

    Sone weiß sogar, warum nicht mit 42.

    Keine Primzahl?



  • Sone schrieb:

    Keine Primzahl?

    Sei der Code

    uint32_t cypher(uint32_t ipaddress){
       return ipaddress*secretKey;
    }
    

    Welche Werte (auch uint32_t) von secretKey sind möglich, damit die Funktion umkehrbar ist?



  • volkard schrieb:

    Welche Werte (auch uint32_t) von secretKey sind möglich, damit die Funktion umkehrbar ist?

    Die ist nicht umkehrbar. Wenn ich nur das Ergebnis habe, dann kann ich sie nicht umkehren.

    Oder spezifiziere mal, was du unter "Umkehren" genau verstehst: Welche Informationen habe ich?



  • volkard hatte wohl gehofft, dass du beim RSA-Implementieren was gelernt hast.



  • cooky451 schrieb:

    volkard hatte wohl gehofft, dass du beim RSA-Implementieren was gelernt hast.

    ??
    Ja, aber das habe ich doch verstanden! RSA basiert auf Primfaktorzerlegung, für die es keinen effizienten Algorithmus gibt (Falltürfunktion).



  • Chauffeur.

    Bei RSA hättest Du es raffen MÜSSEN, wenn Du RSA verstanden hättest. cooky451 hat ganz recht.



  • Du hast

    Sei der Code

    uint32_t cypher(uint32_t ipaddress){
       return ipaddress*secretKey;
    }
    

    Welche Werte (auch uint32_t) von secretKey sind möglich, damit die Funktion umkehrbar ist?

    Manche keys sorgen dafür, daß jede eingangsadresse auf eine genau dazu gehörende ausgangsadresse abgebildet wird und man daher (egal welcher rechenaufwand) die abbildung umkehren kann. manche abbildungen wie ausgang=eingang*0 sind doof, diese ist extrem doof, man kann sie garnicht umkehren. manche sind ein bißchen doof. welche sind lieb? Und das hat mit Primzahlen zwar was zu tun, aber nur innendrin, welche secretKeys klappen?





  • Primzahlen alleine bringen nichts. Denn die Adresse muss keine Primzahl sein, und dann ist die Zerlegung in Key und Adresse mehrdeutig.

    Ist der secretKey immer der gleiche?

    Oder muss man ihn entsprechend zur Adresse generieren?



  • Sone schrieb:

    Primzahlen alleine bringen nichts. Denn die Adresse muss keine Primzahl sein, und dann ist die Zerlegung in Key und Adresse mehrdeutig.

    *patsch* //edit: Nicht, weil Du unrecht hattest, sondern weil Du es so unbedenkt behauptest.
    weiter bitte



  • Man kann die Frage es auch etwas formaler stellen:
    f_{i,m} : \mathbb{N\_0}\to\mathbb{N\_0},\, n\mapsto n*i\mod m
    Für welche i,m ist die Abbildung surjektiv auf Intervall [0,m-1] ?
    (m im konkreten Fall 2322^{32})



  • Sone schrieb:

    Ist der secretKey immer der gleiche?

    Ja.

    Sone schrieb:

    Oder muss man ihn entsprechend zur Adresse generieren?

    Nein.

    Es kann natürlich ein Befehl geflooded werden übers Botnetz, daß der key ab jetzt durch einen neuen ausgetauscht wird. Muss uns aber hier nicht kümmern. Wochenlang gilt ein bestimmter key.

    Wochenlang ist maildata*key=angriffsip

    es sollte sichergestellt sein, daß niemals maildata1*key==maildata2*key, wenn maildata1!=maildata2. Damit nicht falsche Server angefunkt oder angegriffen werden. Damit die Polizei mehr zu suchen hat (optimalerweise den gesamten Suchraum aller IP-Adressen, ein Bißchen weniger ist auch ok, halb so viele schenken wie ungern. Nir primzahlige IPs wären zu wenig). Außerdem sollte key aus einer möglichst großen Menge genommen werden können, damit die Polizei nicht die sagen wir mal nur 100000 sinnvollen keys austesten kann. Was ist die größte Menge der keys bei diesen Spielregeln?



  • Das gefällt mir besser.

    Für welche i,m ist die Abbildung surjektiv auf Intervall [0,m-1] ?

    Die Frage ist also, ob jeder Wert, der bei dem Modulo vorkommen kann, auch vorkommt.

    Also ein offensichtlicher Fall ist i=1.

    i=2 funktioniert für ungerade m.

    Und wenn ich mehr nachdenke, stelle ich fest: i und m dürfen keine gemeinsamen Teiler haben. Soviel sehe ich durchs ausprobieren. Oder?

    Edit:

    maildata*key=angriffsip

    Ach, so herum!



  • supi weiter!



  • Also Base64 ist das wohl eher nicht, es sind schließlich nur Kleinbuchstaben.
    Eine IP Adresse und ein bisschen mehr könnte aber trotzdem in die 9 Zeichen reinpassen.


Anmelden zum Antworten