• 0 Posts
  • 98 Comments
Joined 1 year ago
cake
Cake day: July 29th, 2023

help-circle


  • Very annoying - the apparent author of the backdoor was in communication with me over several weeks trying to get xz 5.6.x added to Fedora 40 & 41 because of it’s “great new features”. We even worked with him to fix the valgrind issue (which it turns out now was caused by the backdoor he had added). We had to race last night to fix the problem after an inadvertent break of the embargo.

    He has been part of the xz project for 2 years, adding all sorts of binary test files, and to be honest with this level of sophistication I would be suspicious of even older versions of xz until proven otherwise.

    Damn. I would love to see a full post mortem on this compromise.













  • The circuitry doesn’t determine which cable is the correct one. That is determined by a protocol that associates various IP networks with different network interfaces. So, for example, all data going to 192.168.5.0/24 goes to interface eth0, and 192.168.0.0/24 goes to eth1 and 10.0.0.1 goes to eth2 and so on. Each interface is a separate RJ45 Ethernet port on your router, for example. It doesn’t have to be RJ45 it could be your router has a Thick Ethernet or Thin Ethernet connector. Or it could have wifi. Or something else.

    Anyway, forwarding the packet to the correct interface / subnet can be done with a static route defined on the router. Another way is dynamic routing using BGP (border gateway protocol) which is an exterior gateway protocol that dynamically routes between your network and somewhere exterior to your network. Yet another protocol is OSPF (open shortest path first) which is used inside a corporate network for dynamic routing.

    For any of these the router knows how to send the IP packet to the next hop, another router, which in turn knows how to send it to the next hop.

    Where to send is based on the destination IP. The routers know which interfaces and which other routers are responsible for different subnetworks.

    It is sort of like how once your mail makes it to a main hub in your state, it is then routed to the main hub for the destination state, and from there to the post office responsible for the destination zip code, and then to the mail route (and hence truck) responsible for the street and number.

    So if your destination is 1.1.1.1 maybe there is a router known to be responsible for 1.0.0.0/8 and then it knows what router is responsible for 1.1.0.0/16 and so on until we get to a router that has 1.1.1.1 on one of its subnets then it sends directly to 1.1.1.1.



  • Load average of 400???

    You could install systat (or similar) and use output from sar to watch for thresholds and reboot if exceeded.

    The upside of doing this is you may also be able to narrow down what is going on, exactly, when this happens, since sar records stats for CPU, memory, disk etc. So you can go back after the fact and you might be able to see if it is just a CPU thing or more than that. (Unless the problem happens instantly rather than gradually increasing).

    PS: rather than using cron, you could run a script as a daemon that runs sar at 1 sec intervals.

    Another thought is some kind of external watchdog. Curl webpage on server, if delay too long power cycle with smart home outlet? Idk. Just throwing crazy ideas out there.




  • You probably want to look for books on reverse engineering. And a book on assembly for your CPU.

    I learned assembly language for VAX-11 (this was like 30+ years ago) in a CS class. We also learned 6502 assembly in a computer engineering class. Neither book would help you. You want a book specific to whatever CPU you’re using.

    Now, I never took it, but friends in college took a CS Compilers course where they learned the basics of writing a compiler. But that’s not what you’re talking about though it might help.

    Trying to understand what a program does is reverse engineering. And a tool like IDA Pro would help you understand subroutines, variables, flow, library calls, and so on.

    A debugger will be invaluable for seeing a program execute one instruction at a time.

    You would need to know the assembly language for your CPU. And it would help to become familiar with certain patterns. I haven’t done much assembly (but I have done assembly on a few different CPUs) nor much reverse engineering so I’m not sure I can lend a whole lot of insight there.

    As you learn assembly instructions, you will start to understand how loops, subroutines, if/then/else, and other things are accomplished for your CPU.

    For example, if/then/else and loops are often accomplished with conditional branching. The conditions are based on CPU flags (bits in the Status Register) that are set by a comparison instruction. You’ll start to recognize how if/then/else and loops and other things are commonly implemented in assembly (without necessarily having to study the compiler; it will be obvious without knowing anything but assembly).

    Another example might be how C structs are implemented. Some CPUs provide convenient memory addressing modes for structs, some don’t. Nearly all I am familiar with provide a convenient way to reference arrays with a simple index.

    Subroutines are jumps to a set location and at the end of that code is a return instruction. Usually registers have to be saved when jumping and restored when returning. Arguments to the subroutines are pushed on to the stack either by value or by reference. Return value is provided through some convention (machines with lots of registers might always use one particular one for return).

    I guess bottom line, learn assembly for your particular CPU, then take a crack at using a debugger and disassembler / reverse engineering tool.

    I’m not entirely sure I follow why that is needed to learn how to do branching in forth but I only vaguely remember that language. Maybe if I did it would be more clear.

    Anyway I hope this helps at least a little.