What about performance overheads? I think the reason a lot of people write C is that they have direct control over the generated assembly to maximise performance.
Even direct control over the generated assembly (C does not provide this; only writing assembler does, and only if you don't do things like LTO) is not sufficient.
Modern CPUs do all sorts of weird things. Assembly instructions can be executed out of order. Your conditional jump instruction can be speculatively executed before the condition's truth is known. Fetches from main memory can be reordered.
Even more wildly, copying the contents of one register to another is often a no-op. Yes, that's right; the following code:
mov edx, eax
... does next to nothing on some modern CPUs. All it does sometimes is set an internal note to the effect of "later references to edx should read/write eax instead", until that note is cleared by some other operation.
You can write your assembler with the best of intentions as to how it should behave, only to discover that the CPU does things entirely differently. You still end up getting the same observable result out of it, but any timing and order of operation guarantees went out the window decades ago.
There is no point in asking such questions, the model doesn't know what it is on its own, and you could get many different answers if you repeat it a few more times.
Looks like a typical mitm attack, which confuses me a bit, don't the developers use something like tls or dtls to protect their communications?
The most recent game I analysed was helldivers 2, which uses dtls. i would have thought that would be fairly common knowledge.
That's the issue - they don't!
But even games like Helldivers 2 have had silly vulnerabilities (just not RCE) - see https://helldivers.io/freesupercredits for some examples.
I had recently run into an embedded problem where when switching the order of two functions in the source code, one of them would refuse to work. I tried a number of things without identifying the real error, and finally had to add a comment warning any later parties not to do this.
I even checked the assembly and they seem to be consistent. But when I upload to firmware, the error keeps coming back over and over again.
Remote access tool. There are plenty of legitimate uses of rats, and given that its no longer the 90s the rat and the trojan are separate programs in almost non-toy implementation
go-size-analyzer, a tool for analysing different dependency volumes in go binaries.
Specifically, I'm looking for help from some people who have experience with reversing on the Mac OS platform, and I'd like to address this issue, which is about how binary relocations handle memory addresses on Mac OS.
gsa obtains the memory address by calculating the address expression in the dwarf, and subsequently looks for the static content in the binary that actually corresponds to the memory address, but when the macho file contains relocations, the calculated memory address needs to be relocated with the same logic to get the correct binary content. I've been working on this problem for a while, but I'm really not familiar with the macho structure and I don't own a macbook, I'd like to get help from developers who have experience in this area.
reply