u/casept

Mods, can we please just ban LLM posters?

Going to second the logic analyzer recommendation, one of those cheap 5 EUR salae clones should do already.

IIRC EDL mode is usually entered if the bootloader cannot be retrieved from eMMC / UFS, so you probably have dead main storage. I doubt it's "just" a corrupted bootloader, given that the device stopped responding when it was already on.

None that I'm willing to share in public, but I've had it find and exploit 3 different binary components in an embedded system with little more than me telling it to print something via UART on success to prove it has achieved RCE and pointing it at ghidra-mcp. Admittedly none of these were extremely sophisticated bugs (1 fairly simple heap buffer overflow and 2 shell injections), but still.

Not really, AI is plenty capable of reverse engineering and throwing exploits against binaries.

The company I work for uses 32-bit ARM in several projects and we're preparing to upgrade our kernels. It's really not that rare.

Without dmesg no-one will be able to help you. After a failed boot, you should reboot and run run journalctl -b-1 > boot.log and put that file somewhere.

If you want to debug native code, Frida has APIs for modifying memory. Alternatively you can also use the LLDB server bundled with Android (debuggerd), though I've found it to be a massive pain to work with.

If you want to debug JVM code, you can either modify AndroidManifest.xml to declare the app as debuggable, or use something like https://github.com/Palatis/XAppDebug if you have root. Then you can attach by following https://developer.android.com/studio/debug/apk-debugger.

Really depends on what you want to change. Patching out a couple anti-features doesn't take nearly that long.

Intel is pretty good value (especially used) and has much better drivers on Linux than Windows.

I have a server running 24/7 for torrents, so I sometimes catch seeders on stuff I added months or years ago.

There's also https://github.com/mahaloz/decomp2dbg, for a cross-debugger solution.

You can modify the app to inject frida-gadget, you don't need root.

Get into systems or embedded programming, people have been finding jobs with pretty much the same stack for 30 years.

There's also https://github.com/mahaloz/decomp2dbg, which works with all popular decompilers and debuggers.

Depends on what you want to reverse. For most proprietary software that's not obfuscated you're going to be using the decompiler 99% of the time anyways and pretty much just need to know enough assembly to judge whether it produced total garbage.

You can try crosstool-ng, if it supports your target.

We can't help you without logs. Read your error message, it contains the path to a log file for the build. Upload that somewhere and link it here.

The problem with the reactor approach is that it could lead to drift if, say, a package is manually installed while the salt master is restarting.

Do you know how well salt would cope with massive event spam (e.g. several hosts undergoing Debian upgrades at once)?

Yes, both the ability to generate a diff between what's installed and what's expected, as well as the ability to optionally remove everything that's not expected. And not just for pacakges, but also users/groups, services, and entries in managed configuration files.

Basically, for bcfg2 items like packages can be in one of three states: OK (item is present on both the host and in the configuration), invalid (item is not present on the host but present in the configuration), or extra (item is present on the host but not in the configuration). And there are commands to ensure invalid items turn valid (e.g. installing a package or starting a service), as well as commands to remove extra items (e.g. uninstall a package).

In bcfg2, we actually do manage base system packages and services as well. It's really not that much work as all our hosts run on a narrow range of Debian versions only.

The job cache could indeed be a possible solution. Do you know if it keeps track of packages which were in the correct state already, or does it only track what it had to change?

The problem is that our entire infrastructure is not really designed with image-based deployments in mind (e.g. we have physical hosts under management, some of which would require a lot of work to enable painless re-imaging). I also have very tenuous political buy-in for Salt, and changing our entire way of working would not be tolerated.

This feature would be incredibly useful for us, because many of our hosts are very long-lived and survive several Debian version upgrades, which tend to leave behind unwanted packages. Also, not everyone is familiar with configuration management. Knowing what was changed enables people to set the system up manually and others to enter them into config management later.

Figured it out.

The simplest solution is to add a common MACHINEOVERRIDE to all machines that should be affected by the change, like so in a machine.conf:

MACHINEOVERRIDES =. "hybris-machine:"

Then, the regular override syntax can be used in the recipe:

``` PACKAGECONFIG_GL:append = "eglfs gbm kms"

PACKAGECONFIG:remove:hybris-machine = "tests widgets gl" PACKAGECONFIG_GL:remove:hybris-machine = "eglfs gbm kms" ```

West Taiwan