0xricksanchez

In a future (very very very future) PR I'd be interesting exploring this idea of building and pushing stuff to a dev-board and debugging it remotely. However, right now, I don't have any specific use case for this scenario

Exactly the use-case I had in mind with this as well :).

I wanted containers for the following things:

- Minimal host system requirements as kernel tool chains can be very much a pain to set up correctly. If I want to compile different kernel versions for different architectures this seemed liked a good trade-off. - I wanted to encapsulate every major logic component into a separate instance so working on the individual components does not require building one insanely large image.

Also note this is very much an early prototype and me just experimenting. Nothing is set in stone yet. Things are likely to change along the way.

You're welcome! Note that this is still very much early alpha stage at best.

PS: If you're using a case-insensitive APFS, Linux kernel compilation will fail. I'm already aware of that

Hi author of like-dbg here :)! The attached debugger is not just raw GDB but is using https://hugsy.github.io/gef/ to make debugging less of a pain. It's still not perfect but helps plenty already. I was not aware of the crash utility you linked, I'll definitely take a closer look :)!

They make use of /etc_ro/public.pem to verify the integrity of a firmware update. So flashing a custom firmware (e.g.: OpenWRT) will fail all checks they put in place. I did not investigate how one could circumvent the update mechanism yet but if you're interested in doing so for these particular models my GitHub repo (https://github.com/0xricksanchez/dlink-decrypt) has a decryption script for these firmware images so you can snoop around the file system for further clues.

You're right with your assumptions! If you go to part 3 pretty much to the bottom of the article there's a good summary of what fields are included in their firmware verification headers.

TL;DR: They verify the length of the encrypted and decrypted firmware as well as multiple RSA signatures.

As much as I like pushing security vectors on embedded/IoT devices... This approach of obscuring what is being pushed in an update may not be the right approach imo.

Thanks! Much appreciated :)

Hi, As much as I have to give credit to Ghidra and its capabilities and I just don't like using it. I find the UI/UX very awful. So I decided to just reverse it in IDA. After I was done with everything I double-checked what I had re-constructed from the disassembly with what Ghidra suggested the decompilation may look like. To be honest they were pretty similar. So again, Ghidra is really powerful tool, I just dislike it :)

Hey, I'm the author of this series (see my Twitter "rant": https://twitter.com/0xricksanchez/status/1290291267914563585 or my repo with the re-constructed source code here: https://github.com/0xricksanchez/dlink-decrypt/blob/master/s... )

All your thoughts and feedback are much appreciated :). I'm happy if you guys liked it!

cheers