umanghere

This is bizarre. I used to work in offensive security, doing a lot of vulnerability research and exploit development. Given the nature of the work and the fact that our products were subject to export controls, we used to work in an actual, airgapped environment - emphasis on the word _actual_. We had mirrors of package registries that would be synced once a day, and if a dep you wanted wasn’t mirrored, you needed to ask IT to have it mirrored.

We considered this just good discipline. I am sure that IT would have loved to allow just the mirror to have internet access, but it was an active decision not to let it, because it had potential to exfiltrate data out of the development network.

Reading this telling of the story, I can’t help but walk away with the conclusion that these frontier labs lack rigour when it comes to securing their models, especially given how much they hype up their models’ capabilities.

Utterly bizarre.

I completely encourage you to write this as a blog post, you’ve articulated all of the concerns I had with Go’s package management wonderfully.

Fascinating article, and I am surprised how well peer pressure works on LLMs.

Somewhat tangential though, but I find the amount of perl clutching from the AI industry about writing malware code a bit ridiculous. Most of the examples cited in the article are just a Google search away. I do not think that the LLM generating malware for you lowers the bar one bit.

I started reverse engineering at 13 with an IDA Pro of questionable provenance - at that time, I found it quite difficult.

One thing which really helped me (and I wholeheartedly recommend) is to write simple programs, run them through the compiler and then in the disassembler. It really helps build a correspondence between program structure and its object code.

Eventually, you can make it even more fun and challenging by stripping debug symbols and turning on compiler optimisations.

Happy reversing!

https://umangis.me Not a lot of content, but enough to be of some interest to a few niches.

4) Hacking is Cool

Pardon my French, but this is the dumbest thing I have read all week. You simply cannot work on defensive techniques without understanding offensive techniques - plainly put, good luck developing exploit mitigations without having ever written or understood an exploit yourself. That’s how you get a slew of mitigations and security strategy that have questionable, if not negative value.

I don’t mean to sound argumentative, but that’s a knee jerk response.

It’s possible to reverse engineer the OS code to verify that the biometrics indeed end up on the SEP’s encrypted storage, and several people have done this in the past.

Here’s an excellent presentation on the SEP, found by just a simple Google search. [0]

[0] https://www.blackhat.com/docs/us-16/materials/us-16-Mandt-De...

In my opinion, a better submission title would be: Open Source distributions for macOS 13.5 have been released.

The current title is a bit misleading, because several parts of macOS, including those covered partially by the OSS releases, are proprietary.

https://archive.is/Kxdeh

It took forever to get the document off SFTC’s website, so I mirrored it behind CloudFront for everyone’s convenience.

https://blog.umangis.me/static/08539708.pdf

Unfortunately it can’t be done even if you target an M1 iPad — virtualization is locked behind an entitlement that’s not publicly available on iOS.

Just allowing kexts to be loaded should not increase the attack surface or expose the author to any currently known exploits. The reason that people avoid doing it anyways is because third party kexts have a history of obvious vulnerabilities and don't receive the same amount of eyeballs that first party kernel extensions do.

As you put it, it really is a desire for maximum security at play here.

There are publicly available SecureROM dumps online, see http://securerom.fun

The author(s) maintain the site out of personal interest.

__padding replied to you, but unfortunately their comment is dead because of their account being new, so I’ve reposted it as I cannot vouch yet.

__padding 45 minutes ago [dead] [–]

Typically with devices like network cards (that also operate over PCI-E) You send the device a circular list of descriptors (pointers) to a region of main memory. In order to send data to the device, you write your network packet to the memory region associated with the pointer of the current ‘head’ of the descriptor list. So far, you have a ring of pointers, one of those pointers points to a location you just wrote to in ram. You then tell the device that the head of the list has changed (as you just wrote some data to the region that the head of the list is pointing to - so it can consume that pointer), the device then goes ahead and copies the data from ram into an internal buffer on the card. Once the data is consumed, the tail pointer of the ring buffer is updated to indicate that the card is finished with that memory region.

iPhones do not use the A1 chip as of quite a few years ago. Besides, the M1 and the A12+ have significant microarchitectural similarities, to the point that the DTK used the A12Z.

Furthermore, the keyboard app extension and the keyboard app are installed as a single package whose components are not supposed to communicate, hence why I brought this up.

While Marcan has written in a very entertaining fashion, there is perhaps one application of this vulnerability that wasn't considered.

If this can be reproduced on the iPhone, it can lead to 3rd party keyboards exfiltrating data. By default, keyboard app extensions are sandboxed away from their owning applications [0], but they may communicate with the app over this channel and leak data. It's not as easy as I describe because the app would have to be alive and scheduled on the same cluster, but it's within the realm of possibility.

[0] https://developer.apple.com/library/archive/documentation/Ge...

They (Facebook) have done this before too. I recall that they bought full-page ads in all major newspapers to promote their "Free Basics" initiative.

There are also other examples, but I consider this level of advertising by them to be very desperate.

You can still pull the database from an iOS backup on your Mac or created from `idevicebackup2`.

The file is named `1b6b187a1b60b9ae8b720c79e2c67f472bab09c0`, `275ee4a160b7a7d60825a46b0d3ff0dcdb2fbc9d`, or `7c7fba66680ef796b916b067077cc246adacf01d`.

On macOS, these executables can be signed with a detached signature. Surprisingly, the embedded codesignature also works (but the signature is stored in an extended attribute on the filesystem).

Speaking from experience, that's not necessarily true. EU countries accept equivalent experience in lieu of academic qualifications.

Assuming that you are offered a position that pays well, and have around 5-ish years of experience, emigration is a breeze.

My experience with getting might not be universal since I work in a niche CS field, but getting a work permit (also alluded to by other commenters) was trivial and likely applies to everyone.

This seems to be quite similar to the other unikernel that was posted recently [1]. It would be useful to have an in-depth comparison of these (and other) unikernels, especially with regard to performance and compatibility.

I can see that HermiTux has the ability to select only the syscalls needed by the embedded program, and to transform syscalls to function calls, which seems quite interesting.

[1] https://news.ycombinator.com/item?id=25405672

Here’s a list of SolarWinds’s customers: https://www.solarwinds.com/company/customers

I’m not in favour of having public client lists, especially when you’re a critical software vendor — but this list is just terrifying. There are a lot of big there, and I won’t be surprised to hear of more incidents in the coming days.