Hopefully this works out for Hex-Rays, allowing them to invest more into developing IDA and expanding their low-cost product offerings. The general sentiment I have seen among people doing SRE is that IDA is rapidly losing market share to Ghidra. While it excels in some areas, the licenses are pricy even for tech employers, and entirely out of reach for students or colleges. It's hard to convince an employer to fork out cash for IDA licenses when new employees are asking to use Ghidra, because that's what they use at home and at school.
I am not going to hold my breath on extending their hobbyist offerings.
I own a copy of IDA (legally). It was an absolute pain to purchase and it seems that a large portion of their margins are dedicated to piracy control. I won't detail the process...but it seems unusually personal.
If I had to guess they will expand their decompilers (the actual flagship project). It will be years before Ghidra + a community catch up to them and Binary Ninja (I also own a copy of it) may never. The disassembler is just a familiar tool. Their decompilers are way, way far ahead.
> It was an absolute pain to purchase and it seems that a large portion of their margins are dedicated to piracy control
I know what you mean. I tried to purchase it and got this email:
Dear Sir/Madam,
Thank you for your order. Please could you send a copy of your passport and fill out the attached form? Our compliance policy now requires this.
Many thanks
Hex-Rays SA
It used to be worse under Pierre. His personal mission in life was to make sure no one dodgy ever got a license and to hunt down every possible source of a cracked copy. My manager had purchased a license for me because it was cheap enough that he could approve it… a year later I tried to renew by emailing Pierre about it. He never replied, instead he contacted my manager to tell him that the license was being pirated and blah blah blah. Was very annoying to sort out.
Amen. I had a 10-email back-and-forth exchange with Ilfak maybe 10 years ago - multiple times I said "I'm literally begging you to take my money, you don't seem to want it." I am self-employed, we were on the phone with each other in real time, and when I placed with order (with my home address) he said, "Oh, nice home, according to the pictures on Zillow and Google Maps". He sounded like he was trying to startle me, ha ha nice try Ilfak.
Can you elaborate? I would really like to see what the HexRay decompiler does better (or worse) than Ghidra, but I am too poor to buy it (and dogbolt.org is not interactive, so I cannot edit function signatures to "help" the decompiler etc.).
Is it better in general, for a specific programming language or platform (e.g. C++, Windows), or for a specific use case (e.g. obfuscated code)? I heard about their cloud-based stuff, although I don't know what they are exactly doing there. Maybe ML trained on source code? Function signatures of the latest malware?
After several hundred hours with Ghidra, I think it certainly would need some polishing, in particular:
- UI. Too many frequently-used dialogs are not optimized for keyboard usage.
- Decompiler too stubborn sometimes, ignoring user input (e.g. manually specified types).
- Decompiler needs better heuristics for the treatment of some common cases (e.g., often doesn't recognize for-loops and array accesses)
- Quite dangerous: Sometimes the decompiler gets lost, especially if a function contains handwritten assembly code with unusual control flows. Okay, can happen. But instead of displaying a warning it just shows you the part it could decompile and you have to figure out by yourself that something is missing.
But most of the above issues are fixable. Instead, I would be interested in learning about more fundamental differences between the two decompilers.
> - Decompiler too stubborn sometimes, ignoring user input (e.g. manually specified types).
This is the thing that sticks out the most IMO. IDA decompiler is quite a bit more flexible than Ghidra's. When you assert a type, it will usually not ignore it. It may sometime get a bit lost if you give conflicting types to dependant variables, but otherwise, it's pretty good at this.
One of the annoying bits of ghidra (though it may have improved, it's been around a year since I last used it) is that there's no way to "split" a variable. Sometimes, ghidra will have some code that looks roughly like:
int x;
x = 0;
doSomething(x);
x = 1;
doSomething2(x);
(Obviously, really simplified).
The problem is, sometimes, x needs to be an int for the first function, and a bitflag structure for the second. But Ghidra has no way to say, "hey, from this assignment on, treat `x` as another variable", so you have to either generate a union (ugly) or deal with sending the wrong type (also ugly).
IDA tends to be much better at this. All variables start out as "split" as it can make it (almost in static single assignment form). Then, the user can tell it "Those two variables are actually the same, please treat them as one". I find this flow works really, really well.
In my experience, in Ghidra you can Ctrl+L to mark a variable as a different type, but retyping or renaming sometimes fails because it creates a HASH variable which sometimes fails to apply to the decompiler output (instead creating a new variable of the right type but the code still references the old wrong one).
Also can I haz offset pointers pretty please? It's not in the last released version I tried, and the last Git version I tried had offset pointers but they didn't affect decompiler output so multiple inheritance and container_of linked lists still came out broken.
Right click -> “Split Out As New Variable”, but it seems like this doesn't work for stack reuse yet (just registers, or more generally, simple varnodes).
This was my biggest frustration when first using Ghidra (granted, I didn't spend much time reading the documentation before diving in). Big thanks to the people responding to your comment with workarounds!
Sure, the thing about decompilation is it's by nature taking lossy data and trying to turn it into something that is almost lossless. The working theory of most decompilers, including Ghidra's, is to have a base level of "translation" ability between asm and C (for example). However, there's a ton of stuff that is missed in this base level. Every compiler speaks it's own dialect of assembly, and different compilers prefer different optimizations, code removal, etc as a strategy. As a result a good decompiler also includes heuristics that are expensive to create and learn about. Hex Rays has dedicated an entire company to finding these heuristics in many compilers across many platforms. This isn't knowledge that is easy to acquire or maintain. I think that Ghidra has the right sauce to do it (a large community) but it will be a while before that community can organically produce the same results.
Due to these heuristics IDA produces real actionable code quicker. My experience with Ghidra (less than yours) is that it produces mostly garbage on a lot of different things and it requires a lot of prep work to make truly usable. This might not be noticeable on small or simple binaries but on larger binaries it actually becomes a real measurable problem. While Hex Rays isn't perfect, it's about as close as we can come to it right now and it generates very human-looking code with smart optimization removal. One thing I remember with Ghidra not long ago was a common optimization like using SSE registers for arrays would produce a page worth of non-sense for something simple. Additionally, detection of standard libraries still isn't good so you end up wasting your reversing time on re-reversing a different compilers version of strlen than actually doing the work you need to do. If you could use FLIRT signatures in Ghidra legally I'd imagine Ghidra would be vastly improved.
My PhD work is about detecting standard library functions in obfuscated/stripped binaries. My most recent model gets about 70% accuracy for a handful of musl-linux-x64 functions. No signatures, just machine learning and disassembly from r2.
I'm not a reverse engineer, but I have been working on this with the assumption that it would be a good time-saver for a reverse engineer. Feel free to DM me if you'd like to discuss.
OTOH, I was able to add decompiler support for a new architecture (or1k) to Ghidra in two weekends just by following examples and without pre-existent Ghidra internals knowlege and without writing any Java code. To me that's an awesome flexibility.
> The general sentiment I have seen among people doing SRE is that IDA is rapidly losing market share to Ghidra. While it excels in some areas, the licenses are pricy even for tech employers, and entirely out of reach for students or colleges. It's hard to convince an employer to fork out cash for IDA licenses when new employees are asking to use Ghidra, because that's what they use at home and at school.
I don't have formal data, but in my narrow slice of the world that's what I'm seeing as well.
IDA's price is so high that it's easy to justify using Ghidra instead. Heck, if Ghidra does something less well, it might be cheaper to pay to improve Ghidra (and then you can use those improvements forever). I encourage organizations who are thinking of using Ghidra to contribute back to it; if those improvements get integrated back in, then those improvements will continue into the future along with other improvements.
Ghidra is just better overall now. Full stop. IDA still does some things better, but Ghidra is a great tool and most people still on IDA are there because of their existing tooling, scripts, and experience with the software. Starting from scratch, Ghidra would win. Been using IDA for like 16 years now.
ooof, ghidra is great because it is free and works, but I wouldn't call it better. I'd still choose ida or binja over ghidra for work. IDC about license cost, I care about ease of use, and binja wins on ease of use for me (and. alot of people I talk to)
Stuff like IDA refusing to have an undo feature and other dumb stuff until the market forced them to. No reason for it, just Ilfak's insistence on an outmoded philosophy of software design that does not benefit users. I do like Binja but Ghidra is free and works. I think Binja has the edge on the highest end features now. I have and use both. I like getting a second opinion on disassembly anyway. Some times they are just wrong and one tool catches something another doesn't. Can't count the hours lost to poor disassembly. Correctness is probably one of the most important features of any disassembler and reverse engineering tool.
I think a lot of the people that say how much better ghidra is, just started reversing and use the decompiler a lot. The workflow and UX of IDA is so much better.
I guess there are a lot of people that just click around in the UI but for a keyboard based workflow, Ghidra has a lot of catching up to do even to IDA 4.x.
I've been doing RE work off and on for about twenty years. IDA is a solid tool with some really neat features[1], but the only reason I use it anymore is if I need to look at a binary that's for an architecture so obscure that Ghidra doesn't support it yet.
I like Ghidra's interface better, but I'm also not a keyboard-first type of user. I work with a lot of different OSes and software. I stopped trying to remember most keyboard shortcuts 10+ years ago, because there were too many variations, and the consequences of using the wrong one can be dire.
Releasing and open-sourcing Ghidra was a truly magnificent gift by the NSA, and I can't thank them enough for it.
[1] I'd love to see a Ghidra equivalent of Lumina, for example.
I have not done it full time, but I find IDA is only useful for niche processors and out of the way things. I have still done it deeply and consistently for the last 16 years. For day to day use Ghidra is just better for me and I went pretty deep into the IDA well with tooling and Python scripting. Decompiler, yes, but it really depends on what features you need and what processor architectures you are reversing. IDA is still the most versatile and indispensable for some tasks, but that is not the majority of my work or interests these days and when it is, right tool, right job, etc.
Arguments of keyboard/mouse efficiency are dead to me. The limiting factor of any reverse engineering is definitely not how efficiently you can keyboard navigate a UI. People are too in love with efficiency of the wrong things and not what the real limiting factors of reversing are, which is comprehending the program. I don't love clicking around but it has never once slowed me down on a project.
For me I got the Company I was contracting for to buy me an IDA license and as I was trying to take over from there Hexrays never responded to any requests.
I'm guessing that I'm on the same pirate blacklist that a lot of people landed. I guess I should have expensed it instead of having the Company buy it. I was the only person doing RE work, it was a single user person license and I was also the only linux user out of that 300 people org.
I think there are a lot of people that would like to pay for IDA but can't get it.
On the other hand I really don't like the Ghidra user experience.
Is there something similar to FLIRT in r2 or ghidra?
can't speak for r2, but we are definetely active. The project github page has better details :)
But as far as i know rizin is the only tool capable to fully support flirt, and i would love to extend the support even more (and obviously add more features) in both tools (rizin & cutter).
It’s not r2 or ghidra, but binary ninja has signature libraries: “The matching algorithm is inspired by FLIRT, which was designed with similar requirements in mind.”
I don't think Ghidra has a proper FLIRT equivalent yet. That's one of those bells and whistles that may (or may not) be worth the license fee, along with in my opinion a more polished UI.
Just to clarify, if I wasn't concerned with budget and had to pick a product today, I'd still go with IDA, but the mindshare among new hires and interns is swinging pretty rapidly towards Ghidra. If they are able to continue adding features (with US government funding, and open source development), IDA is right to be worried about whether they will still be the best choice in 5 years.
Ghidra has function id databases, but only ships with signatures for relatively modern visual studio.
You can create your own signature databases, although i have been unsuccessful in my brief attempts.
The algorithm is different from flirt though.
Its roughly, mask a bunch of stuff (relocations, etc), and hash whats left. There is some parent/child analysis for ambiguous calls i believe.
My recollection is flirt also masks its version of a bunch of stuff, but builds a trie of the first xx bytes with some provision for needed values past that, and some parent child analysis. They have a paper on the algorithm you can google.
Ida ships with more signatures out of the box, In my experience.
Although i havent seen them listed anywhere.
They can have growth and huge margins by offering students a free license that has to be renewed yearly, the way Tableau does; or by giving 80-90% student discounts the way Adobe did before they switched to subscriptions.
But then again those take time to show their benefit, and they probably make piracy easier.
There's also competitors like Binary Ninja. Ida is best at Mac/ios and Windows by far though, so it's still used in those spaces alot. But for embeded, linux and whatever else, Ghidra/Binja are good enough that employers literally won't buy it anymore and are refusing it to senior engineers and telling them to use something else.
I have forced myself to move to other tools like Ghidra, x32dbg, ollydbg, etc. I haven't settled yet on a perfect workflow, but I have found that most of my needs are met without having to launch IDA nowadays.
Very little. Everyone who was passing around pirated copies of IDA continued to do so before and after the release of Ghidra. More than anything I think binary.ninja started to eat their lunch because it was a far superior experience and up front reasonable pricing.
Hex-Rays did ultimately release IDA Home, but you have to sign up for an account to even find out what their hobbyist license costs.
I cannot underscore how much Hex Rays never wanted to have customers or sell products. Maybe this restructuring will fix that?
I disagree with this for a non-direct sales reason: before, you learned IDA, cracked or not. If you learned to reverse software of any kind, you acquired IDA.
Now, more and more tutorials and introductions use Ghidra. Is it better than IDA? In some cases yes, in most not yet, but it’s easier to get.
If I were Hex-Rays, I’d be very concerned with a generational shift as people stop bothering to pirate IDA and those who learned on Ghidra enter the industry and don’t demand an IDA license.
This just came up in my current org a couple months ago and we cancelled our IDA licenses to start using Ghidra. Ghidra is ver capable in my opinion.
When I was in the US Gov there were plenty of IDA licenses floating around despitr the existence of Ghidra. The Gov thinking was basically "better to have it and not need it instead of need it and not have it". There must be a thousand licenses that never get used year after year. I suspect IDA is safe for a while for this reason alone, but of course could be wrong and don't have the numbers-just speculation.
It's also really quite easy to add at least basic support to Ghidra for extra targets. I for example got quite far writing a TMS7000 [0] target for Ghidra [1] to reverse engineer the firmware for a TI teletype... though I still haven't dumped the ROMs to actually get further with it.
Exactly, I am at a job where we have decades of cumulative experience using IDA and even we are wondering if we should not cut ourselves free of Hex-Rays's lock in and begrudgingly learn Ghidra.
For a "new" professional/team, it makes zero sense to buy a IDA license nowadays.
> Hex-Rays did ultimately release IDA Home, but you have to sign up for an account to even find out what their hobbyist license costs.
And even then, IDA Home comes with some pretty serious limitations. It's not just a no-commercial-use version of IDA Pro; it's also a cut-down version with no decompiler, no batch mode, and which only disassembles code for one processor family (which you have to choose at the time of purchase, from a limited subset of what IDA Pro supports).
IDA Pro doesn't come with a decompiler either. For that you need to spend extra and pay for the hex-rays license on top of the price for the disassembler.
The total price kicks licensing costs well outside that of hobbyist use cases.
For IDA Home they do give you their cloud decompiler for 64-bit binaries: “The 64-bit PC, ARM and PPC come with a compatible cloud-based Decompiler currently in beta testing mode”
https://hex-rays.com/products/idahome/
But, like you said, IDA Home is additionally limited to one architecture, which is a bit annoying.
They were, according to this, doing 20MM in 2020, which is surprisingly high for something like IDA. I think they mostly just don't want people like us as clients.
If you translate this article you’ll see that they didn’t just do 20 million in revenue, they made 18 million in profit with 18 employees, 11 of them being devs:
https://archive.ph/Abxqp
It's roughly the cost of a very good Macbook, right? Many companies that employ the kinds of people who spend their days in IDA don't bat an eye at the cost of the laptops.
That's for floating licenses, though, which are like 2x the price of the fixed and named licenses, right?
IDA has a problem where, for some shops, it really makes sense to just have one concurrent IDA user, because IDA is like 10-15% of the work hours --- but it's a critically important 10-15%. So they're super careful to charge for the ability to rotate a team of consultants through the same IDA license.
We had a client, a decade or so ago, that brought us in to do IDA-based vulnerability research work. We wrote some blog posts about the work, and it was so unusual for any of their clients to have that licensing arrangement that IDA (this is in the Pierre era, not the Hex-Rays era) publicly accused us of pirating our copy (which was annoying, because we couldn't out our client, but they absolutely did have the licensing worked out for this.)
It's all super off-putting. But IDA is in sort of a bind, because there just aren't that many users for their ultra-hyper-specialized product. You can have the very best decompiler in the world and you're still going to be a rounding error compared to companies like Figma, because (1) not that many people use disassemblers and (2) less and less software is written in C/C++ every year.
It's not that much cheaper. $1,935.50 for a one year fixed or named license, then $2,709.70 per architecture. Let's say you need the typical four for x86 and ARM, that's over $12k per seat. A lot of companies would balk at that.
Yeah, that's for the decompiler. And I just saw your edit and agree that they are in a tricky spot. Their product is hyper-specialized and they deserve to get paid for the craft and expertise that they have put into their product, but at the same time they have been a significant barrier to entry for people getting into SRE due to the prohibitive cost. Their new offering of a limited license for $365 a year is a step in the right direction, but they only took that step after competition forced their hand.
Edit: Ironically the NSA is the entity commoditizing their complement here, getting an in-house SRE tool and making it easier to hire students out of college with skills they want.
Can you even get the limited licence? It feels like they are comically hostile, ask for a huge amount of really unnecessary things, "KYC procedures", for a $1/day commodity software
> You can have the very best decompiler in the world and you're still going to be a rounding error compared to companies like Figma, because (1) not that many people use disassemblers
(1) could be changed by making a decent offer to hobbyists that they can't refuse, and making the buying experience for them hassle-free.
Right, but if you want that MacBook you call up Apple and they will ship you those computers tomorrow, hassle-free, and you can hand those laptops to any of your employees without someone harassing you for how you're doing licensing. For large companies the issue isn't even the cost but the annoyance. Like, the employees who use those IDA licenses are paid pretty well…annoyances you put in the path of them getting IDA that waste their time are pretty expensive too.
Depends a bit what you do. I work with firmware that uses all kinds of architectures. Paying an extra $2k per architecture I want the decompiler for is simply too much.
Yes, the license cost is likely marginal if you only disassemble Windows malware on Windows.
Hopper is my go-to for light reveng or macOS binaries, Ghidra for Windows mainly because you can refine your typing until the decompiler window becomes very readable.
as an aside - When I was taught Ghidra the trainer said "in IDA you spend most of your time in the disassembly graph, in Ghidra I rarely leave the decompiler"
Interesting, I found Ghidras decompiler much less capable than IDA's. It generated incorrect or partial output far too often and the code generated was always extremely verbose, much less concise than IDA's, though this was shortly after the public release of Ghidra, things may have changed since.
Have you seen the price of used cars due to inflation? Those prices ain't going down for years given the 2+ years long supply shortage of new cars. If anything software like IDA is one of the few things to avoid inflation (at least partially) so it becomes better value as time goes on.
in my world of embedded reverse engineering, very few people use ghidra for their daily work. we use ida or binja or vivisect.
we all know how to use it more or less at a hobbiest level, we even teach it at cons and trainings because it's free and people have heard of it.
but for reeeeaaal work, that needs to be done by the deadline, it rarely gets considered.
Not sure why Hex-Rays spends so much time fighting piracy and making the purchase a very complicated process, it's a lost battle, there will always be pirated copy of IDA, stop fighting it and embrace it to make a better offering.
It seems like a completely senseless waste of their efforts, given the nature of the product they are selling and the user community who knows how to use such a thing.
they need to go the binja route and just give away a minimal version for free, stopped of the fancy features and scripting. we use binja at work, which means a dozen enterprise licenses, because binja was easily usable legally for free.
we all love ida, but licensing is a pita with them. so we never bothered.
They do have a free version of IDA, the problem is most people who use it want the decompiler these days and that costs big.
Looks like they've actually added the "cloud-based x64 decompiler" to the free offering now, so maybe if you're not working with 32-bit code and not working with anything too sensitive that could be of use.
For reference, I downloaded a cracked copy off TPB (or some such place) when I was in high school for reversing video games, and I've never seen a legitimate reason to upgrade or get a real license.
It's really a testament to the robustness of the software.
The people who worked on IDA should be teaching classes on development. I do not think I have ever encountered a single bug in my usage (obviously they exist as with almost any system of moderate complexity). It's just a rock solid application.
Structure editor sometimes bugs out and removes all items from the view, together with comments that serve as help text. The window is completely empty.
Also this Python detection tool that needs to be executed prior the first run didn't support python 3.10 at some point -- they've did version detection based on the filename that detected 3.10 as 3.1 (windows9-style version detection). Not sure what's the case with recent IDA versions, because I'm using Ghidra since a long time now.
But overall I agree, I would never suggest IDA when being asked about an example of a buggy software.
Their debugger used to be pretty buggy, just after the 5.0 or 5.1 release I'd crash it on a regular basis. More recent versions have improved this though and they offer some really slick features in the debugger than other tools can't even do.
This makes me hopeful that users will switch to Binary Ninja. I picked up Binja a while ago (because it’s actually affordable for an individual) & haven’t felt any need to return to IDA. There’s also Rizin which seems pretty robust from what I’ve seen (haven’t tried it myself), & of course there’s also Ghidra. IDA isn’t the only effective disassembler in town anymore.
I see people going to binja in waves. not only is it easier to acquire, but it's freaking good and intuitive to use.
they cater to the hobbiest market to, with a free version that will honestly work for soooo many things. I don't understand why people use ghidra honestly. but hey, nsa has some good pr people
Did they ever fix the debugger situation in Binja? Looks like it's still in beta.
I really hated using Ghidra and Binja compared to IDA as I'm a bit reliant on dynamic RE for some purposes, while IDA is able to bridge the gap between static and dynamic without the need to break out x64dbg or similar.
It's been on the dev builds enabled by default for several months now and no longer labelled beta, but we're in the middle of a release process right now so at some point soon this week the current stable will have a full debugger release (though you can try that version now if you switch to dev)
I personally gave up on this product a long time ago. The only way I see this panning out is via extremely aggressive enterprise sales schemes and a further reduction of hobbyist accessibility. Good riddance from the hobbyist perspective...
binja had more to do with loss of enterprise customers than ghidra. I know maybe 100 professional sres and none of them use ghidra on a daily basis. most use binja now, and others admit they only use ida, because they already have it and know how to use it. they also admit if they have to move to a place without ida licenses, they would be happy to go binja full time if that's what their teammates use
"""
With the new shareholders on board, Hex-Rays must evolve from an engineering company to a commercial company. “After the takeover, we want to structure the company, develop a commercial team and a management team and continue internationalization,” say Ingels and Luyten.
The intention is to transform the current commercial model of perpetual licenses into a recurring model. In the first model, customers pay a large amount at the start and then annually for updates and maintenance. The other includes an annual payment for the license and all associated services.
Hex-Rays' next growth phase will be led by a new CEO, who will take over from Guilfanov. He will eventually become chief technology officer (CTO) of the Liège company and chairman of the board of directors.
"""
I was a heavy ida pro user from 2008-2012. I have probably been responsible for or directly approved giving them 35-40k at different places over the years.
I wanted to do some pic disassembly a while back and out of curiosity asked if they had a low cost personal license for non commercial use and basically got told to pound sand. They said the price for the full version was what it was, no discounts. Then they came out with their ‘home’ edition which is an insult at $365 per architecture and not all architectures are available.
I don’t care how much better it is than open source stuff, until they have a full featured personal version and lower their price, they won’t be getting a dime of my (or my companies) money. It isn’t 2008 anymore.
This seems like "acquired" in a different sense than we normally mean; it's more like an announcement of an investment round than an acquisition, right?
He sold majority share to an investment group. So every button will now become an in-app purchase. Function decompilations will cost in-app currencies.
And today they’re offering the pro-pack. 10,000 decomp units for $1,200 bucks. Of course now they can devalue the value of a unit at will.
AFAIU Ilfak is planning retirement. Retirement and tired have the same root. He got in this business pretty much accidentally and never wanted to become the most hated person in wannabe cracker circles.
"retire" is from French retirer, to pull (something) back -- as e.g. a general might do with troops that need to stop an attack.
"tire" (verb) goes back to Old English tiorian, and its etymology before that is not known and in particular doesn't seem to come from French "tirer" or its Latin antecedents.
Please don’t take this the wrong way, but googling is a very important skill to have.
There’s quite a bit of information out there and I’ll basically just repeat what you can find online already.
You’re additionally not very specific about your goals, which makes it hard to give specific advice.
Practical Malware Analysis is a really great book, even if you don’t intend to reverse malware. It has labs after every chapter, along with solutions.
It teaches you about windows, how to approach reversing a program and what to focus on to not waste too much time.
Once you worked through that CTFs should be much more approachable.
Reverse Engineering: Secrets of Reverse Engineering and Practical Reverse Engineering are also often mentioned as good books, but I personally haven’t read them.
Aside from that, the books from nostarch.com are great.
If you want to learn more about windows itself, there are the “windows internals” books.
It’s also a good idea to find a community with similar interests, learning together is often more fun.
And when you ask for help try to properly state your problem and what approaches you already tried to solve it, along with their outcomes.
>There’s quite a bit of information out there and I’ll basically just repeat what you can find online already.
Yeah, too much information. Maybe I'm just not finding the precise search words to find what I want.
Your reply was very helpful so thanks for that.
>You’re additionally not very specific about your goals
I'd like to be able to do very basic audits of how programs work and precisely what they're doing, and also modify their behavior in simple ways (change hardcoded servers, change program execution flow, disable or enable certain functionality). Reverse engineering with basic modifications.
I'd also like to have a go at modifying firmware of embedded devices, eg a car head unit with a stupid splash screen on startup that I'd like to disable.
For example I have a camera with wifi functionality, and you can control it from a phone app. It would be cool if I could somehow control that from the command line, or create my own basic app for the PC to control it. On top of that it would be good if I could modify the firmware to make it automatically start up in that remote control mode.
Mostly just for adding to my box of tools and general understanding though.
> I'd like to be able to do very basic audits of how programs work and precisely what they're doing, and also modify their behavior in simple ways (change hardcoded servers, change program execution flow, disable or enable certain functionality). Reverse engineering with basic modifications.
The listed books should help with that! I think Practical Malware Analysis really is a good start, even for that. When looking at malware you also try to find important functionality and the book teaches you how to get there quickly.
> I'd also like to have a go at modifying firmware of embedded devices, eg a car head unit with a stupid splash screen on startup that I'd like to disable.
There are probably forums for that, where you can find some info. There's also a nostarch book on car hacking (https://nostarch.com/carhacking) and for embedded (https://nostarch.com/hardwarehacking). I haven't read either, but it might be worth to check out some reviews for it. Maybe they're good and can help you achieve your goals.
The difficulty probably depends on how new the car is. In case you need to actually find a vulnerability in the infotainment system to get proper access, something like Hacking: The Art of Exploitation (https://nostarch.com/hacking2.htm), which I heard many good things about, is probably a good read. But if it's too new it might be too time consuming (see e.g. https://www.youtube.com/watch?v=k_F4wHc4h6k)
> For example I have a camera with wifi functionality, and you can control it from a phone app. It would be cool if I could somehow control that from the command line, or create my own basic app for the PC to control it. On top of that it would be good if I could modify the firmware to make it automatically start up in that remote control mode.
I think getting at least a CLI client could be relatively easy. For that you probably don't even need to reverse a binary using IDA/Ghidra/Binary Ninja. You can try to get the .apk file of the app and decompile it using something like jadx (https://github.com/skylot/jadx/). You'll receive mostly readable Java code. It can try to deobfuscate names, if they're obfuscated. The code you're interested in is probably somewhere under "com.manufacturer...".
How easy it is to modify the firmware once again likely depends on how old or new the camera is. They could, for example, have some integrity checks that keep you from doing that. But I have absolutely zero experience here, so it might as well be really easy. I think there could be forums for this, too.
Also be warned that modifying the firmware of your car or camera can break (parts of) them if things go wrong. E.g. I accidentally (soft) bricked a device because I tried to flash it from within a VM. I don't know how big the risk in your cases is, maybe there isn't any. But it's a good idea to read lots before accidentally breaking something expensive!
