Threads for tgfrerer

  1. 8

    I got two things on my list for now.

    • Unity. So for the past two years or so I’ve been slowly moving away from embedded systems work, which was pretty sad, actually, because I love it and I really didn’t want to do that, but I didn’t have much of a choice. Entirely by accident, I ended up doing some game development and I might have a pretty cool contract lined up next year, so I have basically taken a very long detour to fulfilling my mission from back when I was nine and I decided I want to learn programming to make my own games (naturally). Unity, as you know, is pretty big in this field. I’ve already learned enough of it to be dangerous but it’s not exactly second-nature to me, and I need it to be.

    • Exploit writing. For the longest time I’ve hovered at the borders of “real” security work, again, mostly by accident. Writing crypto code or doing security audits was never formally a part of my job description but I occasionally lent a hand whenever weird hardware and electricity were involved. I’ve also worked on hardware and software that was relevant in this field, and it’s been a long-time interest of mine, too. So this year – now that I don’t have to chase embedded projects anymore – I may have a little more time for it, and this looks as good a place as any to get started with.

    Background stuff:

    • Lua. Python has been my go-to scripting language for a long time now but today, managing anything written in Python is a pain in the ass. I’m sick of nursing pip and virtualenv and whatnot for hours just to cobble together a ten-line script. I’ve played a little with Lua, a language I’ve been interested in for years now, and I like it and I think I might just run with it.

    • Rust. I’ve been slowly absorbing it over the past couple of years, to the point where I could write and play with a very simple OS kernel in the background. Unfortunately, it’s excruciatingly slow work, and it’s not particularly rewarding. It feels like I’m doing cool stuff about 20% of the time, and the rest of the time is spent tricking the compiler into doing something useful, and I’m not enthusiastic enough about the language to frame it as “it’s forcing you to make good design decisions”. I’m also not yet convinced it’s worth it in the long run, so I’m taking it slow.

    • Swift and macOS development. It’s been nearly a year since I switched to this thing and, other than Homebrew being a pain in the ass, I sort of like it. I don’t like everything about it, but a year without having to debug why systemd won’t restart my computer or start my VPN tunnel again, without firing up a game only to find out sound is coming out my monitor instead of my speakers again, without any pretentious drama pouring out of the GTK ivory tower… I don’t like my computer, but I’m content with it, and not by using it like a PDP-11 with a fancy graphical terminal. Only problem is I know jack shit about programming this thing because last time I wrote something for a Mac, the OS X flavour of the day was Tiger. Now I keep coming at it like it’s a weird FreeBSD machine, and I think it’s time I did something about it. Thing is, though, I’ve used FOSS systems for so long I’m not sure I want to do it. Apple is a huge commercial vendor, and I’m not sure I want to invest much in a system that, ten years from now, might decree computers are obsolete and start selling me iPads that I can’t do anything on without an iCloud account…

    1. 1

      python: Yep, the tooling (culture) is surprisingly behind. Use asdf to manage language runtimes and poetry to manage dependencies. If you want a binary to share, make a docker image. That’s as good as interpreted gets (“I have some code to share with you, please install a dev environment, sorry!”). You could also look at nim-lang which compiles and has similar syntax. Or do none of this and continue with Rust but of course it depends on the project. I think you summed up the whole trade-off for like a CLI pretty well.

      1. 1

        Exploit writing

        Any resource to suggest to learn it? I have “The shellcoder Handbook” on my bedside.

        1. 1

          Any particular resources you’re looking at for learning exploit writing? It’s something I’m interested in too, and I read a lot of exploit writeups, but without exercises I don’t really get the concepts concretely. I’ve done some CTFs (which are pretty sink-or-swim, but have managed a few of the easier binary and web exploits) and really enjoyed working through a some of the problems in cryptopals.

          1. 2

            I got this thing bookmarked from a while back: https://dayzerosec.com/blog/2021/02/02/getting-started.html . I’ve no idea if these are any good or not but maybe some of these might be useful starting points. I’ve been putting off a real literature review for after Christmas, my brain is a little low on neurons after this year :-D.

            1. 1

              https://guyinatuxedo.github.io/ was a great intro for me during the last lockdown. It’s a collection of CTFs, coming with all the binaries needed for the puzzles, write ups for all challenges, and even an introduction to some techniques and for how to use ghidra… It’s quite addictive ;)

          1. 1

            What’s change ringing? I’ve never heard of it.

            1. 3

              it’s a bell (think church bells) ringing technique surprisingly closely related to group theory in mathematics. Here’s a video explaining theory and practice: https://m.youtube.com/watch?v=f5GmUxl2NaU

              1. 2

                tl;dr:

                • Ringing church bells (or handbells);
                • every permutation is different;
                • bells don’t move more than one place from one permutation to the next (think braiding);
                • you need a pattern of changes that produces the sequence of permutations

                Take a church tower with usually six bells, but let’s say four, to keep the examples simple.

                Now ring those bells in order from high to low:

                1 2 3 4
                

                Next ring the bells in a different order (a different permutation), but each bell may only (a) swap places with the bell before or after it, or (b) stay in place. For example, you could swap the last two bells:

                1 2 3 4
                    ---
                1 2 4 3
                

                Each permutation of the four bells is called a row: we have just rung two rows. Now you want to keep going: but:

                • you don’t want to repeat any rows (permutations)
                • your bells are still limited to either swapping places with their neighbour, or staying in place.

                and to that you add these artistic constraints:

                • you want to ring every permutation of your 4 or 6 bells, or perhaps half or a quarter of all possible permutations, without repeating any permutation
                • you want your ringers to be able to remember what to ring – they’re not going to memorize the 6! = 720 permutations, and the place of their bell in each permutation. (A conductor who “calls the changes” helps here; but you’d still want large stretches to be predictable, so that the conductor can limit themself to calling the special bits.)

                So you need a predictable pattern (of, say, 24 rows) of which bells stay in place, and which bells swap; and when you reach the end, you swap two bells and repeat the pattern with a different starting row, so you get another 24 permutations out of it; and you do that again until you’ve finally rung all possible rows (or an eighth/quarter/half of them). That pattern is also called a method, and because it determines the sequence of notes you hear you could also call it a compostion.

                All the above is explained much better in the video @tgfrerer linked, which is shortish and enjoyable.

                Compositions have exciting names like “Kent Treble Bob” or “Double Oxford Minors” or “Grandsire Triples”.

                For fun, and because we have an infinite canvas here, here’s you could go through all 24 permutations of 4 bells by swapping exactly one pair each round. Another method/composition could have you swapping sometimes two bells, sometimes one; and with six bells there’s even more possible ways to generate subsequent permutations, eventually generating all of them.

                 1 2 3 4   The first row of a peal is traditionally from high to low, a.k.a. rounds
                     --- } Bell 4 hunts down (towards the front)
                 1 2 4 3 }
                   ---   }
                 1 4 2 3 }
                 ---     }
                 4 1 2 3
                     ---   The back end swaps
                 4 1 3 2
                 ---     } Bell 4 hunts up (towards the back)
                 1 4 3 2 }
                   ---   }
                 1 3 4 2 }
                     --- }
                 1 3 2 4
                 ---     } The front end swaps
                 3 1 2 4
                     --- } Bell 4 hunts down
                 3 1 4 2 }
                   ---   }
                 3 4 1 2 }
                 ---     }
                 4 3 1 2
                     ---   The back end swaps
                 4 3 2 1
                 ---     } Bell 4 hunts up
                 3 4 2 1 }
                   ---   }
                 3 2 4 1 }
                     --- }
                 3 2 1 4
                 ---     } The front end swaps
                 2 3 1 4
                     --- } Bell 4 hunts down
                 2 3 4 1 }
                   ---   }
                 2 4 3 1 }
                 ---     }
                 4 2 3 1
                     ---   The back end swaps
                 4 2 1 3
                 ---     } Bell 4 hunts up
                 2 4 1 3 }
                   ---   }
                 2 1 4 3 }
                     --- }
                 2 1 3 4  And that's the last of the 24 possible permutations!
                (---    ) If we'd continue the pattern, we'd be back where we started
                (1 2 3 4)
                
              1. 2

                This is good stuff, but there’s so much more… One of my favorite books, The Self-Made Tapestry by Phillip Ball, surveys an impressive range of basic processes. Most of them can be modeled in software, at least crudely.

                Why are snowflakes so symmetrical? Sure, basic hexagonal symmetry is due to the shape of the water molecule. But how does information get distributed between branches during growth? Last I checked, there were models that almost but couldn’t quite definitively answer that. There’s so much we still don’t know… and that’s before we start considering even the simplest biological processes.

                1. 1

                  Wow, what a fantastic reference, thank you very much! It would fit very nicely on the shelf next to On Growth and Form by D’Arcy Wentworth Thompson, I should think :)