Compsci Library π
Ousterhout,_John_K_A_Philosophy_of_Software_Design_2018_2019,_Yaknyam.pdf
Software is Malleable
Different with physical design, software is easy to change. It smoothly adapt to change program structure rather structure in building or hardware while construction. For example, it easy to change your navbar website from top to left side in construction even production! (do with your own risk) rather changing Steel material into Titanium in Eiffel tower.
So, how to design and develop software need to address this nature? Incremental design, first start from small design then compounding by redesign and redevelop to adapt with change until grow big, similar with Snowflake method in writing fiction.
Before dive to incremental design, let see the predecessor: Waterfall design. Waterfall design is way to design software and engineering stuff, start from requirement analysis phase, planning, design, develop and release.
Pretty simple and make sense, yes. There a catch, each phase can not backtrack to previous step and change any definition from that phase. Like, there something planning requirement not possible in design phase.
It possible to change it by yourself, but that not how management works. In waterfall each phase done mean that no go back, fire and forget sort like that. The name waterfall imply this, the no water jump back to it belong after fall to ground.
If you do change that will affect budget, deadline and resources which is pain in ass, in other word start fresh cycle.
Ok, maybe you thinking about if there change or not comply each phase, why not put it to next development cycle to address ?
This what Incremental development for, it continously design and develop. These approach address malleablility in software. Such Agile, Rapid Application Development, XP, you name it.
Quite different with waterfall that once design and develop then done, so in certain case it done - clearly define planned design which is rare, human want A but stated B or C or else.
Different with physical design, software is easy to change. It smoothly adapt to change program structure rather structure in building or hardware while construction. For example, it easy to change your navbar website from top to left side in construction even production! (do with your own risk) rather changing Steel material into Titanium in Eiffel tower.
So, how to design and develop software need to address this nature? Incremental design, first start from small design then compounding by redesign and redevelop to adapt with change until grow big, similar with Snowflake method in writing fiction.
Before dive to incremental design, let see the predecessor: Waterfall design. Waterfall design is way to design software and engineering stuff, start from requirement analysis phase, planning, design, develop and release.
Pretty simple and make sense, yes. There a catch, each phase can not backtrack to previous step and change any definition from that phase. Like, there something planning requirement not possible in design phase.
It possible to change it by yourself, but that not how management works. In waterfall each phase done mean that no go back, fire and forget sort like that. The name waterfall imply this, the no water jump back to it belong after fall to ground.
If you do change that will affect budget, deadline and resources which is pain in ass, in other word start fresh cycle.
Ok, maybe you thinking about if there change or not comply each phase, why not put it to next development cycle to address ?
This what Incremental development for, it continously design and develop. These approach address malleablility in software. Such Agile, Rapid Application Development, XP, you name it.
Quite different with waterfall that once design and develop then done, so in certain case it done - clearly define planned design which is rare, human want A but stated B or C or else.
How I write HTTP services in Go after 13 years.
https://grafana.com/blog/2024/02/09/how-i-write-http-services-in-go-after-13-years/
https://grafana.com/blog/2024/02/09/how-i-write-http-services-in-go-after-13-years/
Grafana Labs
How I write HTTP services in Go after 13 years | Grafana Labs
Mat Ryer, principal engineer at Grafana Labs and host of the Go Time podcast, shares what he's learned from more than a dozen years of writing HTTP services in Go.
β€βπ₯1π1
π€1
π₯1
COPYRIGHT DOES NOT EXIST
Linus Walleij, 1998
p.s: There interesting story about hacker and computer
https://www.devili.iki.fi/pub/misc/books/cdne.pdf
Linus Walleij, 1998
p.s: There interesting story about hacker and computer
https://www.devili.iki.fi/pub/misc/books/cdne.pdf
Dissecting-the-Arsenal-of-LockBit-HuiSeong-Yang.pdf
14.4 MB
Dissecting the Arsenal of LockBit
Hui Seong-Yang
π«£ staring to one of you who want start RAAS *pun intended
Hui Seong-Yang
π«£ staring to one of you who want start RAAS *pun intended
Bruce_Dang,_Alexandre_Gazet,_Elias_Bachaalany,_SΓ©bastien_Josse_Practical.pdf
4.6 MB
Practical Reverse Engineering: x86, x64, ARM, Windows Kernel, reversing tools, and obfuscation (2014)
Bruce Dang, Alexandre Gazet, Elias Bachaalany, SΓ©bastien Josse
This truly practical book from page 2 you already throw by reading assembly, despite kind of masochistic nature, it scale well which make it fun to read *ehem* with good amout of free time. If you want to understand the point of reversing, I suggest read this first: https://t.me/compsciresources/245
Bruce Dang, Alexandre Gazet, Elias Bachaalany, SΓ©bastien Josse
This truly practical book from page 2 you already throw by reading assembly, despite kind of masochistic nature, it scale well which make it fun to read *ehem* with good amout of free time. If you want to understand the point of reversing, I suggest read this first: https://t.me/compsciresources/245
β€βπ₯1
Producing Open Source Software
How to Run a Successful Free Software Project
https://producingoss.com/en/producingoss-b5.pdf
How to Run a Successful Free Software Project
https://producingoss.com/en/producingoss-b5.pdf
Rui_Ueyama_Introduction_to_creating_a_C_compiler_for_those_who_want.pdf
1 MB
Introduction to creating a C compiler for those who want to know the lower layer
Rui Ueyama
note: the image can't translated
Rui Ueyama
note: the image can't translated
β€βπ₯4
Forwarded from vx-underground
One thing noobie scoobies don't seem to understand is that malware is literally just software. Understandably, that seems kind of obvious, it's in the name β 'malicious software'. But it seems less obvious to some that, in order to write malware, you apply the exact same principles, techniques, and structures that legitimate software uses.
Malware is regular ol' programming with some sprinkles of weird stuff. These weird things are documented and shared. Some try to find new weird things.
When people ask what language is best for malware... it's kind of like asking 'what's the best ice cream flavor?'. It's entirely subjective. Everyone will tell you something different. You'll notice a lot of people will prefer Chocolate or Vanilla, you may encounter some who like Raspberry Banana Sprinkle Jam-Blam Blast, or Minty Schminty SpongeBob Sticks Bombs, but at the end of the day it's all still ice cream.
In it's most simple form, all malware techniques are things legitimate software may do.
Ransomware?
- Step 1. Enumerate files in a directory
- Step 2. Lock and encrypt files
Information Stealers?
- Step 1. Enumerate files in a directory
- Step 2. Upload files somewhere
RATs?
- Step 1. Make program run at start
- Step 2. Execute commands (cmd, powershell, other programs)
- Step 3. Upload files somewhere
Loaders?
- Step 1. Download file from somewhere
- Step 2. Run file
Everything the malware does is just an expansion of what is explained above.
Want to find new malware techniques? Find new ways to execute a process, find new ways to enumerate files in a directory, file new ways to upload files somewhere, find new ways to download files from somewhere, find new ways to write to files or delete files, etc.
How do you do this? Read. Read everything. Blogs, Windows documentation, StackOverflow, Wikipedia, our website. Look at every DLL you find on your computer in Ida or Ghidra, just open stuff and look around. Look at other peoples work and see if you can expand on it and find something new.
tl;dr learn to code, then learn weird stuff
Malware is regular ol' programming with some sprinkles of weird stuff. These weird things are documented and shared. Some try to find new weird things.
When people ask what language is best for malware... it's kind of like asking 'what's the best ice cream flavor?'. It's entirely subjective. Everyone will tell you something different. You'll notice a lot of people will prefer Chocolate or Vanilla, you may encounter some who like Raspberry Banana Sprinkle Jam-Blam Blast, or Minty Schminty SpongeBob Sticks Bombs, but at the end of the day it's all still ice cream.
In it's most simple form, all malware techniques are things legitimate software may do.
Ransomware?
- Step 1. Enumerate files in a directory
- Step 2. Lock and encrypt files
Information Stealers?
- Step 1. Enumerate files in a directory
- Step 2. Upload files somewhere
RATs?
- Step 1. Make program run at start
- Step 2. Execute commands (cmd, powershell, other programs)
- Step 3. Upload files somewhere
Loaders?
- Step 1. Download file from somewhere
- Step 2. Run file
Everything the malware does is just an expansion of what is explained above.
Want to find new malware techniques? Find new ways to execute a process, find new ways to enumerate files in a directory, file new ways to upload files somewhere, find new ways to download files from somewhere, find new ways to write to files or delete files, etc.
How do you do this? Read. Read everything. Blogs, Windows documentation, StackOverflow, Wikipedia, our website. Look at every DLL you find on your computer in Ida or Ghidra, just open stuff and look around. Look at other peoples work and see if you can expand on it and find something new.
tl;dr learn to code, then learn weird stuff
π5