Masm: Eintritt ins Wunderland

C

calb

Guest
#1
Gude,

aus aktuellem Anlass des Communityprojektes und weil nun vermehrt Personen auf mich zugekommen sind, welche mich gefragt haben was es denn für gescheite Quellen gibt mit denen man sich (ein-)arbeiten kann, will ich nun einen kleinen "Informationsthread" erstellen, welcher eine kleine Orientierungshilfe sein soll für die Leute die interessiert sind in Masm einzusteigen oder schon damit aktiv arbeiten und eventuell die ein oder andere Quelle noch nicht kannten.

[ Inhaltsverzeichnis ]
+> 1.0 Vorwort
+> 1.1 Literatur

++> 1.1.1 Online
+++> 1.1.1.1 Offizielle/ externe Dokumentationen
+++> 1.1.1.2 Masm Forum
++> 1.1.2 Offline
+++> 1.1.2.1 Grundlagen/ Überblick über den Instruktionssatz
+++> 1.1.2.2 Praktische Anwendung/ Reverse Engineering
+> 1.2 Entwicklungsumgebungen
++> 1.2.1 Visual Studio
++> 1.2.1.1 Erweiterung: AsmDude
++> 1.2.2 Notepad++, Assembler und Linker
+> 1.3 Debugger
++> 1.3.1 x64dbg
++> 1.3.2 OllyDbg



[ 1.0 Vorwort ]
Ich würde gerne erstmal ein paar Worte verlieren, welche den Aufbau des Threads verständlicher/ nachvollziehbarer für euch machen sollte, damit es zu keinen Missverständnissen kommt. Ganz klar vorab: Dies ist kein Thread indem ich direkt auf Sachverhalte eingehen werde, sondern ich werde euch Anlaufstellen für eure Probleme nennen, welche euch beim Selbstständigen lösen eures Problems helfen sollen. Auch möchte ich für mein Gewissen erwähnen, dass ich definitiv kein Profi bin was Masm angeht, ich betreibe das Programmieren als Hobby neben meinem Sport und meiner Arbeit. Alles was ich hier sage, stammt aus meinen persönlichen Erfahrungen und ist in keinster Weise durch Dritte beeinflusst. Ich programmiere in Masm nun ca ein halbes Jahr, ich habe bevor ich mit Masm angefangen habe schon ungefähr 1 Jahr praktische Erfahrungen mit C++ und C gesammelt gehabt, aber ich hatte in keinster Weise vertieftes Wissen was Assembly angeht - ich wusste wie ein Stack funktioniert oder was ein Heap ist, allerdings hatte ich nie wirkliche Anwendung für dieses Wissen gefunden. Mein Grund wieso ich das Programmieren angefangen habe, was nun schon etwas länger zurückliegt, war die Mathematik - ich komme definitiv nicht aus der "Game Hacking" Szene! Dies ist mir wichtig zu erwähnen, da man so eventuell besser nachvollziehen kann wieso ich verschiedene Entscheidungen getroffen habe, bzw. wieso ich welche Empfehlungen ausspreche. Ich habe am 30.Dezember 2016 - mein Registrationsdatum hier auf HighMinded - angefangen mich für das Game Hacking zu interessieren. Ich würde mal behaupten dass ich in dem halben Jahr meiner Anfänge so ziemlich Alles falsch gemacht habe was man falsch machen kann. Ich habe Code kopiert und nicht verstanden wieso er nicht funktioniert, ich habe damit andere Leute genervt und war mehr am Verzweifeln als am Reversen/ Programmieren. Bis ich den Scheiß satt hatte und mir mal ein vernünftiges C++ Buch gekauft habe und mich konsequent nach der Schule, Arbeit und dem Sport hingesetzt und gelernt habe. Und siehe da, die ersten Zusammenhänge erschließen sich Einem und es fängt wirklich Spaß zu machen - kurz und knapp: man fängt mit einem verdammt großen Puzzle an und erkennt das Motiv immer ein Stücken mehr. Und was hat das Gelaber jetzt bitte mit Masm zu tun? Richtig - gar nichts! Ich will euch nur mal meine "Essenz" des Programmierens etwas näher bringen. Ihr werdet immer wieder aufs Maul bekommen und ihr werdet immer ein Grund finden irgendeinen Gegenstand in euren Monitor zu schieben weil euch der Debugger irgendeine kryptische Errormeldung vor die Nase wirft, aber das gehört halt dazu. Der Wille und die Neugier sind zwei Grundelemente beim Lernen, egal ob Fremdsprachen, Naturwissenschaften oder Programmiersprachen, wichtig ist dass ihr immer dazulernen wollt und dran bleibt. Der nächste Elementare Punkt: Wieso Masm und nicht Nasm, Fasm oder Tasm ? Weil ich mein Licher nur gekühlt trinke! Spaß beiseite, das ist und bleibt Geschmackssache - dieser Thread behandelt Masm und keine andere Form von Assembly bzw. keinen anderen Syntax. Nun mal zum Kern, ich bin immer gut mit einer Kombination aus "Online"-quellen wie msdn oder diverse Onlineboards und "Offline"-quellen wie Bücher klargekommen. Ich muss dazu noch erwähnen, dass ich ein Buch in der Hand immernoch einem E-Book vorziehe, dies ist aber Geschmackssache und bleibt euch überlassen. Ihr kennt euch selbst am Besten und wisst wie ihr am effizientesten euch Wissen aneignet, ich bin zum Beispiel ein Mensch der sich ohne Probleme 100 Seiten trockene pure Theorie nach einem vollen Tag geben kann, ohne dass ich aus dem nächstbesten Fenster springe. Allerdings ist es nie verkehrt ein grobes Problem zu kennen und einfach mal drauf los zu programmieren ohne sich groß einen Kopf um die Details gemacht zu haben, quasi nach dem Motto "Learning-By-Doing". Was ich euch aber echt ans Herz legen kann ist, dass ihr euch bevor ihr ein Problem angeht euch kurz mal die Zeit nehmt und mal über die Problematik nachdenkt wie man diese am Besten angeht, ohne großartig in den Details zu versinken. Das hat mir echt nochmal einen großen Fortschritt gebracht, da ich so wirklich strukturiert meine Probleme angehen konnte. Aber letzten Endes bleibt es wie immer euch überlassen. Auch ein für etwas elementares ist das "Spielen", sprich ihr findet eine gewisse Thematik spannend und auch wenn diese euch erstmal nicht direkt neues Wissen verspricht, probiert ihr diese aus. Als kleines Beispiel um es etwas verständlicher zu machen, ich fand schon immer das mutieren von Programmcode sehr spannend. Angefangen in Biologie mit dem Thema Genetik und der dort stattfindenen Nukleotidmutationen. Auf den Punkt gebracht: Ich habe angefangen mir ein Programm zu schreiben, welches Assembly Code interpretiert und versucht möglichst effizient zu mutieren. Anfangs noch recht primitiv mit einfachen push-pop-Vertauschaktionen oder Stackmanipulationen aber über die Zeit hat sich das Ganze in ein größeres Projekt entwickelt, mit welchem ich enormen Spaß hatte und mehr gelernt habe, als ich anfangs dachte. Ich habe mein Wissen über Assembly vertieft, indem ich versucht habe dies möglichst korrekt auf neue Situationen anzuwenden. Ein ganz wichtiger Faktor ist auch, dass ich mit vielem Neuen in Berührung gekommen bin, als ich an dem Projekt gearbeitet habe und genau das ist auch der Grund wieso man solche Projekte realisieren sollte! Ich sehe mein Wissen über Assembly als einen "Wortschatz" an, diesen habe ich stark vergrößern können indem ich mal abseits von Büchern oder vorgegebenen Problemen gearbeitet habe und mal meinen Weg gegangen bin und das getan habe was mich wirklich gefuchst hat. Solche "Seitensprünge" sind meiner Meinung nach essentiell wichtig, ihr sollt nicht nur Zeug lernen was euch nicht die Bohne bockt, dass macht man eventuell in der Schule im Religions- oder Kunstunterricht aber doch nicht bei einem Thema was einem Spaß machen soll. Seid da nicht zu streng zu euch, solange ihr etwas nachhaltig und damit qualitativ lernt, macht ihr alles richtig! Wenn ihr einem Problem gegenüber steht und ihr wirklich Alles(!) was in eurer Macht steht schon ausprobiert habt und nicht selbst fähig seid dieses zu lösen, dann zögert auch nicht Jemanden zu fragen. Wir leben von einer guten Kommunikation, dass es für diese auch ein paar Regeln gibt die man einhalten sollte, sollte Jedem klar sein. Der Umgangston ist wichtig, nur weil der dumme Penner im Forum euch nicht direkt eine Lösung gibt, sondern einen Denkansatz heißt das noch lange nicht dass ihr ihm den Blitz beim Scheißen wünschen dürft. Qualität - Denkt lieber doppelt oder dreifach über eure Frage nach und lasst gerne auch mal etwas Zeit zwischen jedem Reflektieren, dies hat mir immer geholfen. 70% der Probleme habe ich nicht vor dem Computer gelöst, sondern beim Laufen in der Natur oder auf dem Klo beim Blättern in der Zeitung. Denkt immer dran, ihr wollt auch nicht sinnlos genervt werden, wenn aber alle diese Punkte ihre Richtigkeit haben dann stellt gerne eure Frage und seid nicht schüchtern, wir sind alle nur Menschen. So ich denke dass war jetzt genügend Text, ich bin eh gespannt wer sich das Alles bis hierhin geben wird, schreibt mal unauffällig "Grüße, calb" in eure Posts :b Ich werde euch nun nur noch die Quellen aufzählen, welche euch bei Problemen helfen können und welche mir sehr oft den Arsch gerettet haben. Auch möchte ich erwähnen, ich bin gerne ein Ansprechpartner für euch, falls ihr mal ein Problem oder eine Frage habt - ich freue mich über jeden Menschen der eine Leidenschaft in Assembly findet!

[ 1.1.1.1 Online - Offizielle/ externe Dokumentationen ]
Ich kann euch definitiv die offzielle Dokumentation ans Herz legen, diese ist hier zu finden: Microsoft Macro Assembler Reference .
Gerade wenn man mit Visual Studio arbeitet und/ oder manuell compilen will ist es recht nützlich die Parameter für den Assembler oder Linker geordnet finden zu können. Was aber noch wichtiger ist, dass dort alle Direktiven, Symbole oder Operatoren mehr oder weniger gut erklärt sind. Ich habe meistens erst den Namen für eine Funktionalität auf msdn gesucht und dann nach Praxisbeispielen gegoogled und mir anhand der beiden Quellen versucht den Syntax dahinter zu verstehen, hat so eigentlich immer gut funktioniert. Für mich ein Muss, wenn ich Masm programmieren will, was ja gerade von Microsoft kommt. Außerdem finde ich folgende Webseite als Nachschlagewerk empfehlenswert: X86 Opcode and Instruction Reference . Gerade für den x86 und den x64 Syntax ist diese Seite ein Segen, wenn man schnell mal schauen will ob verschiedene Operatorenkombinationen bei einer Instruktion möglich sind oder ob z.B. eine Instruktion die EFLAGS beeinflusst oder nicht, soviele Fragen können durch diese wundervolle Seite geklärt werden - definitiv ein Lesezeichen wert!

[ 1.1.1.2 Online - Masm Forum ]
Ich möchte keinesfalls hier dreist Werbung für ein anderes Forum machen, deswegen wird es hier keinen direkten Link dazu geben, es ist aber auch nicht sehr schwer es mit Google zu finden :wink: Ich habe solche Foren eigentlich immer gerne genutzt um mir verschiedene Problematiken oder Diskussionen durchzulesen und zu schauen was andere Menschen über gewisse Sachverhalte denken. Ich denke es nicht verkehrt immer mal eine neue Meinung zu seiner Eigenen zu hören und auch ggf. mitzudiskutieren, dies erweitert das Wissen und man lernt sich richtig mit Problemen auseinanderzusetzen.

[ 1.1.2.1 Offline - Grundlagen/ Überblick über den Instruktionssatz ]
Hier spreche ich eine klare Kaufempfehlung für ein Buch aus und zwar dieses: Modern X86 Assembly Language Programming .
Dieses Buch ist in englischer Sprache erhältlich, ich habe keine deutsche Übersetzung gefunden.
Damit habe ich angefangen Assembly zu lernen. Es ist schwer - zumindest empfinde ich es so, gerne korrigieren - gescheite Literatur für Assembly zu finden, welche nicht schon veraltet ist oder gefühlt mehr als die Keramik Bremsanlage bei Porsche kostet. Vorallem sind meistens die Bücher nicht immer vollständig, bzw. lassen simple Dinge weg, welche für einen "Aha"- Moment sorgen würden beim Leser. Dieses Buch ist allerdings ein guter Kompromiss wie ich finde, ich habe ja erzählt dass ich, bevor ich mit Assembly angefangen habe schon eine Weile C++ programmiert hatte, dies hat mir direkt meinen Horizont erweitert, denn welcher Mensch, der kein Sadist ist und nicht calb heißt, programmiert heutzutage noch seine Programme vollständig in Assembly? Eigentlich Keiner, da die Compiler mittlerweile schlauer als wir Menschen sind, allerdings gibt es immernoch Situationen die der Mensch besser lösen kann als die Maschine, diese Lösungen sind meist auf "atomarer" Ebene, was letztendlich heißt dass dieser Schritt in keine kleineren Teilschritte mehr aufgedrösselt werden kann. Somit kann man C++, eine moderne Hochsprache, mit den Vorteilen von Assembly kombinieren - was für ein Gedanke! Das Buch vermittelt sehr gut die Grundlagen zu Assembly und steigert sich schön linear auf einem gut lernbarem Niveau, welches auch für Assemblyanfänger geeignet ist. Hier wird auch nicht nur x86, sondern auch x64, SSE und AVX behandelt was dieses Buch in meinen Augen schon zu einem wichtigen Kompendium macht! Auch ein klares Muss in meinen Augen, dieses Buch dient mir auch noch heute als Nachschlagwerk und hat seinen festen Platz auf meinem Schreibtisch!

[ 1.1.2.2 Offline - Praktische Anwendung/ Reverse Engineering ]

Hier wird es nun etwas schwieriger was das Niveau des Buches angeht, aber in meinen Augen ein wichtiger Begleiter was die Praxis angeht und was einem nochmals den Horizont erweitern kann. Ich spreche von folgendem Buch: Practical Reverse Engineering: x86, x64, ARM, Windows Kernel, Reversing Tools, and Obfuscation . Dieses Buch ist auch leider wieder nur in Englisch erhältlich nach meinem Wissensstand. Ich kann aber auch dieses Buch reines Herzens empfehlen, da man so auch mal eine etwas andere praktische Art mit auf seinen Weg bekommt. Dieses Buch ist ganz klar auf Malware-Analyse gerichtet, was dem Buch in meinen Augen definitiv nicht schadet, ganz im Gegenteil es werden wichtige Elemente wie z.B. Aufrufskonventionen, im Englischem "Calling Conventions" angesprochen welche gerade im Game Hacking eine wichtige Rolle spielen. Man lernt auch z.B. ARM kennen was einem auch nicht schaden kann, wenn man sich mal mit "RISC" oder "CISC" Architekturen auseinandersetzt und was ich sehr cool finde das Obfuscation, Deobfuscation, Debugging und der Kernel angesprochen werden. Ich konnte viele kleine Tipps mitnehmen welche mir heute noch regelmäßig helfen, wie z.B. ein kleiner Trick beim Debuggen oder etwas mehr Verständnis wieso die WinApi so aufgebaut ist, wie sie es ist. Ich würde sagen, wer nicht "tiefer" in Assembly einsteigen will oder wenig Lust auf das "Drumherum" hat sollte hier die Finger von lassen. Wer allerdings offen für Neues ist und sein Wissensschatz aufbauen/ vergrößern will, kann gerne zuschlagen - auch dieses Buch hat seinen Platz bei mir auf dem Schreibtisch und war immer eine treue Klolektüre :tongueclosed:


Mir fällt jetzt schon meine Hand ab, aber wir sind ja noch nicht am Schluss. ^^

[ 1.2.1 Entwicklungsumgebungen - Visual Studio ]
Hier wird es jetzt ein wenig "persönlich", denn letztendlich bleibt euch überlassen wie ihr am "Bequemsten" programmiert. Ich kann euch nur meine Erfahrungswerte mit auf den Weg geben. Ich persönlich halte Visual Studio für eine sehr sehr gute Lösung um Masm zu programmieren. Erstmal müssen wir uns nicht die "nervigen" Parameter für Assembler und Linker heraussuchen wenn, sondern können ganz bequem per Einstellungen alles regeln, wo wir sehr übersichtlich eine Erklärung zu den verschiedenen Feature finden. Des Weiteren bin ich ein großer Fan von dem Datei Management von Visual Studio geworden - Übersichtlichkeit und Ordnung ist in meinen Augen ein Grundelement, ohne welches ein Projekt nicht wirklich angenehm ist. Hier könnt ihr euere eigene Ordnerhierarchien anlegen und diese schön übersichtlich gestalten, was bei größeren Projekten ein wahrer Segen ist. Ein kleines bildliches Beispiel:

https://gyazo.com/43381817d3e45adf8ff1a9c40e407d40

Und hier ist anzumerken dass dies nur ein "kleineres" C++ Projekt ist, ich versichere euch dass sowas bei Masm sehr schnell sehr ausarten kann, wenn man Alles sauber trennt. Da ist man selbst und die Leute die an diesem Projekt mitarbeiten sehr dankbar, wenn man eine vernünftige Struktur hat. Der wohl wichtigste Punkt in meinen Augen ist die Hilfe bei Fehlern und das Syntax-Highlighting, welches durch Erweiterungen möglich ist aber dazu mehr im nächsten Abschnitt. Es gibt nichts schöneres als eine IDE die beim Debuggen die Register anzeigt und erlaubt mit Breakpoints - zu Deutsch "Haltepunkten" - arbeiten zu können und dies ist nur ein ganz kleiner Bruchteil der Funktionalitäten von Visual Studio. In heutiger Zeit ist eine gescheite IDE ein unverzichtbares Muss. Hier könnte ich alleine 5000 Wörter nochmal tippen, aber ich versuche mich kurz und knapp zu halten.

[ 1.2.1.1 Visual Studio - Erweiterung: AsmDude ]

Hier gibt es Erweiterungen, welche euch das Leben um Einiges leichter machen z.B. AsmDude . Diese Erweiterung kann ich Jedem nur ans Herzen legen, denn man bekommt ordentliches Syntax-Highlighting und das erleichtert einem das Leben ungemein oder der Punkt dass man mit meinem Hover über die Instruktion eine Erklärung zu dieser bekommt - einfach ein Traum! Diese Erweiterung umfasst noch viel mehr Funktionen wie z.B. gute Querverweise innerhalb des Codes auf Funktionen und deren Funktionsprototypen, hier lohnt es sich echt mal diese Erweiterung auszuprobieren, denn diese ist auch noch kostenlos!

[ 1.2.2 Entwicklungsumgebungen - Notepad++, Assembler und Linker ]

Zur Vollständigkeit wollte ich diesen "Oldschool"-Weg auch noch hier erwähnen, so hat man früher als noch keine wirklichen IDEs gab seine Programmie kompiliert. Man hat in einem Textprogramm wie z.B. das hauseigene Notpad von Windoof seinen Assemblycode geschrieben, danach von einem Assembler in Maschinensprache übersetzen lassen und letztendlich von einem Linker zu einer ausführbaren Datei umwandeln lassen - ganz ganz ganz grob erklärt. Dies ist heutzutage natürlich auch noch möglich, allerdings würde ich das keinem Anfänger oder Profi empfehlen der sich einem ernsten Projekt widmen will. Visual Studio liefert z.B. einen Assembler für x86 und x64, als auch Linker mit welche man benutzen kann. Die Dateien findet man im Installationsordner von Visual Studio unter dem Namen "ml.exe", "ml64.exe", und "link.exe", wobei die "link.exe" den gleichen Namen hat für x86 und x64, darauf sollte man achten! Die Parameter fürs übersetzen und linken findet man auf der Dokumentation von msdn, welche ich oben ja verlinkt habe.

[ 1.3.1 Debugger - x64dbg ]
Kommen wir zum zweiten Teil "des Herzens", neben einer guten IDE, dem Debugger! Vertraut mir wenn ich euch sage, wenn euer Debugger scheiße ist auch euer Tag scheiße ist. Das Programm welches man nutzt um seine Fehler zu finden, muss passen wie ein Handschuh, das darf nicht so sehr eure Hand abschnürren dass sie nach 5 Minuten taub ist, sondern optimalerweise lässt der Handschuh eure Hände bei der winterlichen Kälte auch nicht austrocken und hält eure Hände warm. Ist jetzt ein wenig abstrakt das Beispiel, aber es geht einem schlichtweg auf den Sack wenn das Debuggen irgendwie umständlich ist. Hier gibt es auch verschiedene Debugger mit mehr Funktionalitäten als ich Haare auf dem Kopf habe, ich möchte mich hierbei nur auf meine Erfahrunge berufen und euch meinen Favoriten, welchen ich aktuell nutze und weiterhin nutzen werde, vorstellen. Mein Favorit ist: x64dbg . Wieso? Ganz klar die Kombination aus Zuverlässigkeit, Erweiterbarkeit und Handhabung. Dieser Debugger hat mir stets treue Dienste geleistet und mich bisher nicht einmal wirklich abgefuckt, die Handhabung ist, einmal wirklich verstanden, echt simpel und recht schnell, was in meinen Augen ein Muss bei einem guten Debugger ist. Was auch echt klasse ist, ist das Plug-In System, welches - gerade verbunden mit Scylla echt nützlich ist - ein extrem nützlicher zusätzlicher Aspekt, welcher erhöhte Flexibilität bietet da man eigene Plug-Ins programmieren kann für seine Aufgaben, was kurzgefasst einfach überragend ist! Alle Funktionalitäten/ Sachverhalte die ich bei OllyDbg vermisst habe, werden von diesem Programm aufgeschnappt.

[ 1.3.2 Debugger - OllyDbg ]
Hier brauche ich denke ich nicht mehr allzu viele Worte verlieren, ein wirklichen Unterschied denke ich merken Anfänger nicht zwischen den beiden Debuggern, aber es sprechen eben die oben genannten Punkte für x64dbg. Ich erwähne OllyDbg nur, weil ich auch gerne noch eine Alternative anbieten will. Mit OllyDbg habe ich angefangen wirklich "richtig zu debuggen", es ist kein schlechter Debugger ist aber in meinen Augen in die Jahre gekommen und ich glaube nicht wirklich empfehlenswert wenn es eine Alternative wie x64dbg gibt.





Soooo, dann haben wir es nun endlich geschafft, bzw. du hast es geschafft mit meinem Thread. Ich bedanke mich herzlich für deine Aufmerksamkeit und stehe natürlich gerne für Kritik/ Anregungen/ Ergänzungen zur Verfügung. Ich habe den Text jetzt einmal Probe gelesen, alle Rechtschreibfehler die ich jetzt nicht mehr gefunden haben bleiben euch erhalten, denn wie wir wissen: "Das bleibt alles so wie's hier ist!!" :grin:

Ich wünsche einen schönen Abend und ein schönes Halloween, ich werde jetzt erstmal meine Finger schonen, habe schon gefühlt den 3.Krampf hinter mir aber hat ja Spaß gemacht. Ich möchte nochmals anmerken, ich bin kein Profi und dieser Thread kann inhaltliche Fehler beinhalten, ich werde diese sofort korrigieren wenn ihr mich darauf hinweist, aber bitte lasst mich nicht dafür in die Hölle kommen. ^^

Grüße, calb.
 

Gab

Moderator
10 Jul 2017
4,764
3,158
#2
Ihr werdet immer wieder aufs Maul bekommen und ihr werdet immer ein Grund finden irgendeinen Gegenstand in euren Monitor zu schieben weil euch der Debugger irgendeine kryptische Errormeldung vor die Nase wirft, aber das gehört halt dazu.
Besser kann man es nicht ausdrücken, ehrenwerter Post.
 
C

calb

Guest
#6
Warum kein Visual Studio Debugger?
Gude,
ich gehe ja in 1.2.1 kurz auf die sinnvolle Funktionalität des VS-Debuggers ein, die beiden externen Programme wurden unabhängig von der IDE genannt und sollen eine sinnvolle Ergänzung zum eigentlichen Debuggen darstellen. Beispiel hierfür wäre eine bessere Übersichtlichkeit des Disassembly, übersichtlichere Suchen nach Textreferenzen oder die erhöhte Funktionalität durch Plug-Ins, welche z.B. runtime dumps erlauben. Du hast aber völlig Recht, dass der VS-Debugger auch eine gute Wahl ist, kommt bei meinem Post anscheinend noch nicht so raus. Ich überleg mir wie ich das sinnvoll ergänzen kann. ^^

Danke dir für dein Feedback und es freut mich dass ich dir wenigstens mit der Erweiterung helfen konnte! :grin:

Grüße, calb.
 
Likes: lach

palonE

Well-Known Member
15 Aug 2017
874
1,102
#8
Junge @calb ich liebe dich und so.

Include White Space Between Paragraphs
Leave spaces in between your paragraphs. Don't have one paragraph end and the next one start only one line below, but make sure there is a line of white in between.
Don't just make a single line break like this with new paragraphs.
This is not a good way to format paragraphs and sentences on a new line.
It simulates a wall of text, even if you have your writing broken into paragraphs.