Good game concept and implementation. Run smoothly even on phone.

Extend the capability to include timer, boost of speed and even levels with enemies.. I would love to also try having a kind of multi level support for moves.. Like 3 layers to explore the 3d navigation with layers of ground for moves.

Awesome experiments that could easily become viral! :)

I remember the talk and thought about it when I saw the news.

No conspiracy or whatever, just thinking about the complex system which is also vulnerable for some parts.

> The used radio protocols Versacom and Semagyr, which carry time and control signals, are partially proprietary but completely unencrypted and unauthenticated, leaving the door open for abuse.

You don't think the omission of encryption and lack of authentication imply a criminal absence of due diligence.

I guess some huge contracts are in the offing fix those necessary features which should have been built-n in the first instance.

Super interesting article and results shared by the Author, as always!

Quite surprised by the overall processing results especially on general detection of features.

Really precise blog post with useful case, as usual with the author. Love his writing, findings and technical details.

My only feedback was that he should really really consider linking the text `Open Charge Map` to the website.

I've experimented with GCP's Stack using Agent Builder and relying on Gemini Pro 1.5.

I also experimented with pretty large of various files (around 6000 video games full notices) where I used OCR parsing in a similar configuration with mixed results due to the visual complexity of the original content.

Well written and highly detailed description, as always with Fabien's work.

I remember seeing the investigation on this iPhone protection back at the time, what a journey it has been since this work.

Also, I hope someone can provide more information about that minus 0x400 shift before data write so it would be completely explained.

The minus 0x400 shift appears to work like this:

  Seek(fd, 0xA0020000 - 0x400);

We seek to 0x400 before where we need to write the data

  SendWrite(fd, foo, 0x400, false);

We set the first 0x400 bytes of what we want to write to 0

  SendWrite(fd, fw, fwsize, true);

We then set the rest of the bytes to our data.

  SendEndSecpack(fd);

The iphone copies the data from 0x400 bytes onwards (which is all the data we wanted to write), then tries to verify the signature and fails. If the signature could be verified the first 0x400 bytes (which we left as all zeros) would then be copied.

Ouch! That's a fail on the same level of Microsoft forgetting the XBox decryption keys on the secret ROM.

The product itself was, at this stage, very rushed to market.

The IFX team that produced the baseband firmware had never heard of Sicherheit. It was … riddled with trivially exploitable security issues.

So very many products are, but most people never see any of it, and most are boring enough that nobody cares to break them apart and see what's inside.

its also worth noting, on balance, that apple quickly made it a relatively hardened platform.

I think Fabien is looking for an explanation as to why shifting by 0x400 bypasses the signature check. For example, is that shift somehow corrupting the signature check logic, or bypassing it by convincing the checker that no check needs to be performed?

My guess is that the chip doesn't have enough RAM to store firmware image, verify it, and only then write it to flash. So instead it needs to write it on the fly as it receives data in chunks of 0x400 byte pages. It starts by erasing first page, but instead of immediately writing it instead keeps buffer for that page for later. Then it transfers remaining pages normally, and at the end only when signature is correctly verified it goes back to write the first page.

That would also be my assumption.

However, it seems the firmware was written as 0x800 byte pages:

https://cdn.cs50.net/2014/fall/lectures/1/w/src1w/iUnlock.c

Thank you guys for your explanation.

From what I understand on this thread, the header of the firmware is 0x400 long. A page can be up to 0x800:

``` int size_to_write = Size > 0x800 ? 0x800 : Size; ```

So it would appear the firmware has a header of 0x400 which is buffered during upload but discarded if the firmware fails the checksum at the end of the upload.

I'm reading this as the iPhone holds the first 0x400 bytes in a buffer and doesn't write them until the signature has been verified. Everything else does get written. The assumption is that stripping off those initial bytes would render the firmware unusable, except in this case where they just padded the write by 0x400 bytes!

I think it was lack of imagination on the part of whoever programmed it. I wager they were more afraid of someone taking total control of the baseband so they figured everyone would start writing programs at 0, so they protected the beginning, which is their most important code. They didn't foresee someone just skipping that part and writing part of the firmware for such a small change.

Out of the selected topic, the technical context is amazingly well written and the analysis is strong.

PostGIS usage and optimizations are well detailed and I really liked the various options exploration and index explanation and implementation by samples.

Thanks a lot for sharing.

Really interesting article, with lots of knowledge and illustrations.

Thanks to the author and to the person sharing it. I really enjoyed this reading today.

I worked for Eurotunnel/Getlink, actual operator of the tunnel(s), as a software architect between 2012 and 2020.

I can tell several fossils were displayed in the main office building both in France and in UK.

I remember a big ammonite, like 90 cm wide at least, displayed on the French Terminal, main office building with a sign next to it explaining the context of the discovery.

thanks for the info

We all have the biggest movie in mind and we know the unfortunate situation our heroe is facing right now, makes us all doomed.

More seriously, interestingly, those analysis would require early detection and therefore investments on such approach, which might not be always the case. The article was interesting and I hope we won't be prototyping soon.