This is my own channel, but I made a 10+ part series on modern ARM assembly you may find interesting. I used CPUlator for the demonstrations, which is a nice way to inspect the memory as well as the individual registers as you are running a program.
Thanks for your work on this. I’ve bookmarked several of these videos and used them as reference.
Learning assembly with a really good visualizer or debugger in hand is highly underrated; just watching numbers move around as you run your code is more fun than it has any right to be.
> If you can't make CPUs and you can't keep the internet up, where are you going to get the equipment for enough "private peering or Sat links" for the privileged?
Storage. You only need a few hundred working systems to keep a backbone alive. Electron migration doesn’t kill transistors if they are off and in a closet.
> You need CPUs to build optical media drives! If you can't build CPUs you're not using optical media in 30 years.
You don’t need to make new drives; there are already millions of DVD/Bluray devices available. The small microcontrollers on optical drives are on wide node sizes, which also make them more resilient to degradation.
> they're definitely f-ing going to have been able to repeat all the R&D to build a 68k CPU in 30 years (and that's assuming you've destroy all the literature and mind-wiped everyone with any knowledge of semiconductor manufacturing).
If you read the post, the scenario clearly states “no further silicon designs ever get manufactured”. It’s a thought experiment, nothing more.
> If you read the post, the scenario clearly states “no further silicon designs ever get manufactured”. It’s a thought experiment, nothing more.
This kind of just breaks the thought experiment, because without the "why?" of this being vaguely answered, it makes no sense. How do you game out a thought experiment that starts with an assumption that humanity just randomly stops being humanity in this one particular way? What other weird assumptions are we meant to make?
OK, no silicone. But we might be just fine after all. Just yesterday we had a story about Bismuth transistors that are better in every way than silicon ones. Maybe a tad more expensive. There are a plenty of other semiconductors out there too. We’ll have to adjust manufacturing but it will probably be just one upgrade cycle skip. Even with a complete mind wipe it’s still not that bad if only silicone is out.
The three “flaws” that this post lists are exactly what the industry has been moving away from for the last decade.
Arm’s SVE, and RISC-V’s vector extension are all vector-length-agnostic. RISC-V’s implementation is particularly nice, you only have to compile for one code path (unlike avx with the need for fat-binary else/if trees).
Malimite is first and foremost intended to be a tool to help Reverse Engineer iOS/Mac binaries, much like JADX for Android.
As it turns out, LLMs are quite good at “converting” C-Pseudocode into an approximation of the original Swift or Objective-C code. Therefore, you can optionally use the LLM extension to help analysis.
Of course, it’s not 100% accurate, but significantly easier to read, and I find it to save hours of manual research.
Thanks for for the two replies, the replies make a lot of sense to me. It's hard for someone who is just starting out to find information on the "workflow" side of things, what kind tools people use and in my early journey to reverse engineering, so right now I assume to be somewhat blind to deficiencies in some tools I've tried so far.
Before Ghidra, I had been looking around /r/reverseengineering reddit and random Google searches to find what kind of tools people work with and how a reverse engineering work goes in general, and I'm happy there's a lot of blog posts that describe a project reverse engineering some project this and that.
Found a few things like "binwalk" to inspect a random binary for structure (apparently it was rewritten in Rust recently and not totally sure it's actually better (yet) than their slower Python-written older version also called "binwalk"). Also learned things like setting up mitmproxy (and how to Python script it) I was able to get to my entire home network through a Synology NAS with an iptables+mitmproxy setup I'm abusing as a firewall and as an inspection tool. On Linux specifically I learned some basics of seccomp() and existence of qemu-emulation, thought I might try some kind of "behavioral inspection" of untrusted binaries at some point with these tools or similar to them.
And on top of that, learned about cryptography at a more deep level, I think my entire interest this year started from me and my friend getting fed up with VSCode live share bugs and quirks (I do code teaching), doing research on alternatives, finding an alternative VSCode extension that seemed sketchy and then wanting to learn how do I "security audit" the thing. Ended up deobfuscating the JavaScript, reading its crypto, learning a lot about historical attacks on crypto and what is the typical kind of mistake that happens, AES-GCM misuse (IIRC it affected other AEAD schemes too, Invisible Salamanders), SHA length extension attacks, canonicalization attacks, re-using nonces in a scheme where that's really bad to do (AES-GCM again was my context but I think it applied to stream ciphers in general that take a nonce), the PS3 mess up with their private keys, Signal double ratchet thing, legal basics how much risk you do in reverse engineering against uncooperative companies (EFF had guides on legal side of it), and so on. Important to my security audit thing but also if I have ever have to "roll some crypto" and not completely make it totally amateur crap that breaks immediately when an actually competent cryptographer sees it and laughs at it.
Soooo many tools and things to learn. The above is just what I happened to remember on top of my head. I don't intend to become some superhacker but I want to be able to do some basic "sketchiness" check on applications I don't trust.
I looked at pictures off the Internet on the JADX tool, and yeah it clearly has a bit of a focus than Ghidra itself, and now Malimite makes a whole lot more sense as its own tool. While I thought Ghidra is mind-blowing (maybe a noob's first impressions and it isn't actually that amazing :) it definitely is also ugly and a bit heavy) there seems to be a rich set of tools to use.
My targets on reverse engineering are not currently any mobile apps or macOS apps, I have my interests right now elsewhere, but your Malimite tool here entered my notes to check out for iOS/macOS app decompilation if that comes up. I was already aware of the macOS .app structure, I've messed with them but not in any sophisticated reverse engineering sense. There's a video game called Don't Starve for example that contains a .zip file with lots of .lua code inside that is just readable as-is, not much effort or special tooling required.
Also technically you are the first human I've asked a question on reverse engineering (learned of existence of JADX and a more rich ecosystem of tools) and got an answer so I got happy for a sort-of "did first human interaction on an reverse engineering topic" achievement, even if it was just baby steps.
All runs in the browser:
https://youtube.com/playlist?list=PLn_It163He32Ujm-l_czgEBhb...