Say what you like, I think the #XPM format is kind of beautiful.
xpmprime.info
Tim Chase
R.L. Dane 
🍵 
/* XPM */
static char *Apple_Menubar_Logo[] = {
/* columns rows colors chars-per-pixel */
"11 14 7 1 ",
" c None",
". c #DD1C00",
"X c #FF6600",
"o c #01BB00",
"O c #FFFF01",
"+ c #002FDD",
"@ c #FF2C99",
/* pixels */
" oo ",
" oo ",
" o ",
" ooo ooo ",
" oooooooooo",
"OOOOOOOOO ",
"OOOOOOOOO ",
"XXXXXXXXX ",
"XXXXXXXXXX ",
"...........",
" @@@@@@@@@@",
" @@@@@@@@@@",
" ++++++++ ",
" ++ ++ "
};
If you so choose, you can use ASCII palette indices in DPF files, just like you would in XPM files. But in DPF there's no reason you wouldn't use any Unicode codepoint for palette indices. In fact, if you use coloured square emojis instead of plain ASCII characters,.
If you do it that way, when you cat a .dpf file with icons, what you will get will be... oh surprise!
...icons!
Another post by @hawkes with some useful #vulnerability #research tips: How to Build a #Fuzzing Corpus
https://blog.isosceles.com/how-to-build-a-corpus-for-fuzzing/
I wonder how the commoncrawl method would fare with more obscure file formats such as #XPM
https://security.humanativaspa.it/nothing-new-under-the-sun/
Fuzzing for security vulnerabilities is a strange thing. Throwing randomly generated or mutated data at an application until it crashes sounds like an extremely primitive way to find vulnerabilities, and yet the last decade is full of fuzzing success stories. In many respects, it's still poorly understood why fuzzing works
@alix @carnage4life The sad thing is that scanning it at a high resolution into a simple #XPM (https://en.wikipedia.org/wiki/X_PixMap) or #NetPBM (https://en.wikipedia.org/wiki/Netpbm) and then printing it out on punched-cards would survive the test of time quite well at a minimal cost while remaining simple to decode and feasible even by hand (if very tediously).
It is their attempt at cost-cutting that has caused the issue.
@haitchfive
Generic Person
raptor
LisPi