xor42

True, although if you're in the EU, there should be a 30 days reference period.

"In all EU countries traders are obliged, when offering a discount, to indicate the lowest price applied to the item at least 30 days before the announcement of the price reduction."

Of course, enforcement of such rules is the problem here. But if you notice such discrepancies, you are more than encouraged to file a complaint to the shop and then to your national agency responsible for the protection of consumers if the seller doesn't act in good faith. I was fairly surprised to see how well the latter has worked against a large company in my Balkan country.

Source: https://europa.eu/youreurope/citizens/consumers/unfair-treat...

Regarding the Quake engine and its evolutions (Q3, Call of duty, RTC Wolfenstein), the most common trick was to modify the rendering mode of all player entities so that they are drawn above everything else.

The engine has a flag that is mainly used to draw the player's weapon (which is rendered above the rest). Using this flag for players was the "engine compliant" way of making a wall hack.

A bit off topic, but I have recently acquired a PCB which uses a Conexant CX92755. It is kind of supported by the Linux kernel, but I am completely unable to find a user manual / proper datasheet for this chip. If someone happens to have it stashed somewhere, I'd be super grateful as it would give me a few week ends of hacking with the board.

My guess is that airplanes are cool/fascinating for a lot of people. Aerospace is a field where a lot of things are unknown to most of the population, which triggers curiosity even for the smallest details.

I have done IT consulting in the field, and have been genuinely happy to get a tour of some facilities and debugging software while sitting in a life-size simulator. It really tickles your engineering senses.

My first experience with Delphi is quite recent actually. I've done quite a lot of C/C++ programming & reverse engineering (the latter as a hobby) and recently had to scratch the itch to take a closer look into the ecosystem of a popular alarm systems manufacturer. Their hardware is well designed but the quality of their software is unfortunately not quite what you'd expect to see in this field. As such, I wanted to see what could be learnt/exploited by exploring their binaries.

As it turns out, their software suite is written in Delphi, which required me to read quite a lot about it, and use/write some custom tools to help me analyze the binaries in Ghidra.

An existing tool I have relied on is called IDR[0]. It relies on "knowledge bases" which are binary files generated by another project[1] from the same author to store information about all the types and classes provided by each version of Delphi. The source code of these two projects is pretty "funky" from a software engineering point of view, but quite enlightening from a research standpoint to understand how Delphi binaries are generated.

I can see from this thread that a lot of people are nostalgic about how easy/enjoyable it was to use. I now find the low-level analysis of this technology just as fun and interesting.

As a side note and to loop back to the reason of this whole endeavor, after many hours spent reversing the software of this manufacturer, I can attest that the rumors about the code quality are not just rumors :)

[0] https://github.com/crypto2011/IDR [1] https://github.com/crypto2011/KBBUILDER

Actually it depends on how far you want to go. You can jump to protected mode with a few lines more. But you won't have a very interesting exercise.

Basically, one would have to setup multiple registers like the GDT which sets the protection on different memory ranges (hence protected mode). Once you have your GDT setup, set a few bits in CR registers and execute a long jump to the code segment of the GDT (provided you have instructions loaded there).

Then once in protected mode, everything changes. The system allows you to set interrupts habdlndlers through the LIDT, to enable memory paging and you'll have to reload the GDT again. But no more access to the convenient BIOS functions.

You also set up the PIC of your system to get a ticking clock for scheduling your kernel operations. Once you got all that is where the fun begins and you can start implementing memory managers and allocators, writing a disk operations layer and implement (or write your own!) filesystem.

OS Dev is truly a fascinating subject because there's so much to learn. Even more with 64-bit, and multiple core initialization and usage.

I don't know how all of this works on ARM, but I might order myself an experimentation board to get my hands on.