Hacker News Reader

Comment by DoingIsLearning | Hacker News Reader

> The thing about humans is: they're human. Humans like nice round numbers. They like exactness, even when it is unnecessary. This helps a lot in reverse engineering. For example, what response does the constant 0x380000 elicit in you? None? Probably. What about 0x36EE80. Now that one just catches the eye. What the hell does that mean? So you convert that to decimal, and you see: 3,600,000. Well now, that's an hour's worth of milliseconds. That length is probably only useful for long-term low power sleep. I have lost track of how many things I've reverse engineered where constants of this variety lit the way to finding where sleep is being done!

Really great work! This was probably the simplest yet coolest insight from this write-up.

Flipping this on it's head, anybody can recommend a reading list on more robust strategies to obfuscate this sort of breadcrumbs?

View on HN

You can do a few things:

- Laser off the part marking. Not knowing what a part is makes the job much more difficult

- One time programmable chips: can't modify or read off firmware if the JTAG bus is disabled

- Encrypted firmware: helps if someone is able to fuzz the chip to dump the firmware

- BGA parts: hide the pins, bury the traces. It makes the job harder but not impossible

- Programming before soldering: you can leave the programming pins disconnected so someone would have to remove the chip before attempting anything on it

- Use more advanced features of the chip: some chips offer secure memory locations that can contain decryption keys, magic numbers, whatever you want. You could have a magic number that you XOR with every literal. It would certainly make things more difficult to determine what is what in the assembly code if you could decrypt it

- Pour some epoxy over the chip or board: makes repairs impossible but also can screw over the reverse engineer.

- Work with a manufacturer to build a custom chip. You could do crazy things like move the programming pins around and hide them as other things. Like the JTAG test points would be random decoupling caps hidden in the board.

- Finally, threaten to sue anyone that publishes anything

How would you protect (non-SaaS) software against copying or reverse engineering?

Something like that needs a threat model including your attackers' motivations and means.

You can't. It goes against the very nature of the medium, like trying to delete something on the internet. If it's something a CPU has to execute, it has to be in memory where it can be dumped. At best all one can do is make it harder to stop less determined adversaries.

That said, there actually is one nasty [1] workaround: run some critical functionality on a custom USB dongle that the user has to have connected in order to use the software. It could be a calculation in a critical path that's not compute bound but without which the software is unusable. It could even be a JIT engine that consumes encrypted code and returns polymorphic executable code designed to be near impossible to assemble back into a static binary. Some fabs can make tamper-resistant ASICs with a specialized packaging process that couples the on chip memory to the package so that opening the package makes the memory unrecoverable for extra security. This level of protection would be effective against all but the most determined and well funded nation state or competitor.

[1] Nasty for the user, the developer, and the investor all in one!

Sounds like someone could build a company on that idea.

That's basically what the casino gaming industry is. They're done of the most physically secure systems against reverse engineering that you're likely to run across. More so than atms or a lot of other secure systems.

A good real world example of how security by obscurity is actually more secure.

It seems that many have interpreted the idea that security by obscurity means that any obscurity is completely useless. But I'm sure whoever coined that phrase simply meant that if your only security is obscurity, then you are going to have a bad time.

The reality is, obscurity can be a great additional wall of defense. Something that the real world has known since forever (think hidden safes or unmarked money trucks that rotate their schedules on random intervals).

Use different units. 1 hour = 2.976 millifortnight

>anybody can recommend a reading list on more robust strategies to obfuscate this sort of breadcrumbs?

Did you maybe mean to de-obfuscate?

Probably not, that's why they said "Flipping this on it's head"

Can confirm, the question was on obfuscation strategies when designing rather than Reverse Engineering.

Sorry, English is not my native language so i didn't get the head flipping part.

"turn something on its head" normally means "to treat or present something in a completely new and different way[1]" e.g. when trying to fix a machine, flipping a part over to see if it fits better "the other way"

In this conversation, it was used to mean "flipping the script", to change or reverse something dramatically

The grandparent comment wanted to ask "the opposite question", not "how to make it easier to reverse engineer something", but "how to make it harder to reverse engineer something".

[1] https://www.collinsdictionary.com/us/dictionary/english/turn...

[2] https://idioms.thefreedictionary.com/flip+the+script

Reply on news.ycombinator.com