Hacker Newsnew | past | comments | ask | show | jobs | submit | tdullien's commentslogin

The old warez cracking scene had an outsize impact on computer security. GRSecurity, Heartbleed vulnerability, most reverse engineering tools for security, etc. etc. etc.

There's so much history here, touching on all sorts of insanity including selling 0-day to the US government that was then used to apprehend high-level Al-Qaida personnel, random warez busts leading to people taking oversea jobs, etc. etc. etc.

If anyone still has old .NFO archives from 1990-2000, I'd be very interested in getting as many as possible.


> If anyone still has old .NFO archives from 1990-2000

Have you checked https://srrdb.com ?


.nfo archives is quite complete out there on the archive sites. Those days were crazy busy in the warez world and the nfo files are a blast to read.


Here's the one I uploaded. It was the most extensive collection back in the day.

The dates listed are from when they were fetched, they encompass all eras.

https://archive.org/details/nfo_large_collection_2009_2012


Have you posted the right link? It seems to be a 2009-2012 collection, when the question was about the 90s.


Interesting. Where is it possible to read up on this?


The privatization of the train system in Germany was a particularly insane disaster that is only now, 30 years later, being undone/repaired.

If you look at an org chart of the DB these days, the most fascinating part is that DB consists of almost 600 separate corporate entities that are all supposed to invoice each other.

Speaking with insiders, it appears that when the privatization happened, the new corporate structure took what was essentially every mid-size branch of the org chart and created a separate corporate entity, with cross-invoicing for what would normally normal intra-company cooperation. I think the (misguided) goal was to obtain some form of accountability inside a large organisation that had been state-funded and not good at internal accounting.

This fragmentation lead to insane inflexibility, as each of the 600 entities has a separate PnL and is loathe to do anything that doesn’t look good on their books.

Add to this a history of incompetent leadership (Mehdorn, who also ran AirBerlin into the ground, and who was also responsible for the disastrous BER airport build-out), repeated rounds of cost-cutting that prioritized “efficiency” over “resiliency of the network” etc. etc.

DB is currently undergoing a massive corporate restructuring to simplify the 600+ entity structure, but there has been a massive loss of expertise, underinvestment in infrastructure, poor IT (if you see a job ad for a Windows NT4 admin, it’s likely DB), etc. etc. — it’ll take a decade or more to dig the org out of the hole it is in.


It was a privatization in name only. The German state held 100% of its shares since the beginning. As such, it might have no longer been subject to the state specific demands of hiring etc. - but instead found itself in an uneasy tension as the only supplier of services to an entity that was something between a customer and a shareholder.

Which brings up an interesting question: How do you structure something with a large piece of infrastructure like a rail network in a way that could benefit from the market forces of competition and innovation?


> Which brings up an interesting question: How do you structure something with a large piece of infrastructure like a rail network in a way that could benefit from the market forces of competition and innovation?

A rail network is near to a natural monopoly. You can build overlapping rail networks, but it's complex and interconnecting instead of overlapping would usually offer better transportation outcomes and there's a lot less gauge diversity so interconnection is more likely than overlap.

All that to say, you can't really get market forces on the rails. Rails compete with other modes of transit, but roads and oceans and rivers and air aren't driven by market forces either.

Transit by rail does compete in the market for transit across modes. You can have multiple transportation companies running on the same rails, and have some market forces, but capacity constraints make it difficult to have significant competition.


> capacity constraints make it difficult to have significant competition

Thirty years ago, you would be correct. In the modern day, you could tie switch signalling to real-time auctions and let private rail's command centers decide how much to bid and thus whether or not they win the slot for putting their cars onto the shared rails. The public rail owner likely needs to set rules allowing passenger rail to pay a premium to secure slots in advance (say, a week) so that a timetable can be guaranteed to passengers during peak rush hour, but off-peak slots can and should be auctioned to naturally handle the difference between off-peak passenger rail and not-time-sensitive, more-cost-averse freight rail.


You can’t. Every attempt at privatizing rail is a failure with worse performance, higher prices, and an inevitable level of special treatment by the state due to the monopolistic utility-like nature of rail infrastructure. Not everything needs to or should be privatized.


This 100%. It should be seen as critical infrastructure because of everything it can enable when run well.


> It was a privatization in name only.

Not, that "insight" again. Yes it was privatized and yes it is still completely owned by the state. "Privatization" is a term of art (in German) that refers to the corporate structure not the ownership. There are also public corporations in Germany, that are fully owned by random people: e.V. = registered association.


I believe modern economists are studying how ownership should be assigned. The thinking is that contracts and rules handle the majority of situations but emergencies and edge cases require an owner who has authority and whose interests align with the thing they control. And you want a mechanism to reassign ownership when the previous owner is incompetent.

In the case of a national train system, you may want to create a national entity to develop, coordinate, and make the physical trains and support technologies. You would create regional or metro entities to control the train network for their local area including the train stations. They coordinate with each other via negotiated contracts. Any edge cases or emergency falls under the purview of the owning entity. For example, the national entity controls the switch from diesel locomotives to the newest engine. The local authority is responsible for repairing the lines after a natural disaster.

If an entity is egregiously incompetent or failing, the national regulatory authority, with support of the majority of all the different train entities, takes control and reforms it.


keep the rails as a state-owned monopoly, let different train operators run on it. Basically we have that for airplanes, and it works well enough.


There's been an ongoing issue with North Korean state agents infiltrating SV companies, and this proposal helps them pass the interview process more easily.

There's multipronged benefit for them: Access to company infrastructure to potentially cause harm or ransom in the future, access to technology / intelligence, but also simply foreign currency.


Not necessarily North Koreans only.

Anyone in a very low income area can benefit from pretending they're in a high income area and negotiating US-like pay.

Although the cancer stuff does look very scammy.


There's an event bigger number of Indian candidates trying to scam themselves into US jobs, than north Korean ones.

Especially when the recruiting process of big companies becomes predictable and well documented online, candidates will just perfect the targeting and cheating of that specific system.

What if the future just becomes in person interviews again, because every remote candidate will either be an Deepfaked scammer with a stolen ID, or a cheater with someone nearby whispering AI generated answers to him?


Employers are already including 'proof-of-life' checks on the low hanging fruit freelance sites such as Upwork. One example is literally having to get on a virtual call and obstruct your face with your hand or something similar to prevent passing any automated checks.

Cat and mouse.


Xoogler here (2011-2018). It's heartwarming that a core part of Google culture ("for every problem we have 3 solutions: 2 that are deprecated and 1 that is experimental") is alive and well.


I only remember 2015 TF and I was wondering: why would I use Python to assemble a computational graph when what I really want is to write code and then differentiate through it?


With all the negative comments here: This is existing technology on ARM64 (MTE) and on modern iPhones (https://security.apple.com/blog/memory-integrity-enforcement...).

For a good intuition why this (coupled with instrumenting all allocators accordingly) is a game-changer for exploitation, check https://docs.google.com/presentation/d/1V_4ZO9fFOO1PZQTNODu2...

In general, having this come to x86 is long-overdue and very welcome.


But wait, how do you know that's what this is?

The reason I'm negative is the entire article has zero detail on WTF this instruction set is or does. The best you can do is guess from the name of the instruction set.

Compare the linked iPhone article to this blog and you'll quickly see the difference. There's very real discussion in the MTE article of how the instructions work and what they do. This article just says "Memory safety is hard and we'll fix it with these new instructions that fix memory safety!"


So there's a long intellectual history behind these technologies, and Intel had multiple chances of taking the leadership on this around 2018 - they failed to do so, some of the talent went to Apple, and now Intel has to play catch-up.

I'm pretty certain it'll be the x86 variant of either MTE or MIE.


This is how, amongst other things, IBM POWER cpus do memory tagging for capability-based security on iSeries/OS400.

IIRC, later SPARC64 chips also had a version of this.


According to this: https://www.devever.net/~hl/ppcas the POWER approach is not a true hardware capability architecture (“nothing about these ISA extensions provides any kind of security invariant against a party which can generate arbitrary machine code”). It's just something that helps software to store one bit per 128 bits of data on the side (plus some other weirdness about load-with-offset instructions).

(SPARC ADI is similar, machine code is still trusted.)


ADI, since 2015, still shipping.


The x64 Windows Kernel is starting to get support for this. There are a few references to memory tagging appearing in the public symbol files.


Probably because it's very likely that both AMD and Intel have had engineers working on this sort of thing for a long time, and they're now deciding to collectively hash out whatever the solution is going to be for both of them.


Better to have this than two sets of instruction, as is currently the case for virtualization entry/exit points on amd64 platforms.


A lot of this sort of thing come from AMD/Intel clients, rather than internally.

In this particular case, it definitely does :)


>But wait, how do you know that's what this is?

A lot of these extensions come from Intel/AMD/etc clients first, and because of how long it takes a thing to make it into mainstream chips, it was probably conceived of and worked on at least 5 years ago, often longer.

This particular thing has a long history and depending on where they worked, they know about that history.

However, they are often covered by extra layers of NDA's on top of whatever normal corporate employee NDA you have, so most people won't say a ton about it.


I don't know if it is intended this way, but there's one useful outcome even with the limited amount of detail disclosed:

There are industry partners who work closely with AMD and Intel (with on-site partner engineers etc.), but who are not represented in the x86 ecosystem advisory group, or maybe they have representation, but not at the right level. If these industry partners notice the blog post and they think they have technology in impacted areas, they can approach their contacts, asking how they can get involved.


Wow that weird state machine doc is great! Thanks for sharing.

I’m lukewarm on this.

- It is long overdue and welcome.

- It won’t stop a sufficiently determined attacker because its probabilistic and too easy to only apply partially

Is this good? Yes. Does it solve memory safety? No. But does it change the economics? Yes.


Yeah it's the most succinct explanation I've seen of weird machines and memory tagging. Definitely bookmarking this one. I wonder if video of the talk that presumably presented this is available.


I don't know tbh, and I gave that talk when I was in terrible shape, so I'm not upset ;).

If people care a lot, I can record a YouTube video on the topic.



Is there a comparison of memory tagging designs for different architectures (POWER, SPARC, CHERI/Morello, Arm MTE/eMTE, Apple MIE, x86, RISC-V)? e.g. enforcement role of compiler vs. hardware, opt-in vs mandatory, hardware isolation of memory tags, performance impact, level of OS integration?


> This is existing technology on ARM64 (MTE) and on modern iPhones (https://security.apple.com/blog/memory-integrity-enforcement...).

Previous discussion https://news.ycombinator.com/item?id=45186265


The usual story they tell themselves is that the software is used against criminals and child pornography and terrorism. Which is not wrong, the majority of the use cases are probably that, in the majority of jurisdictions.


It's just off by a factor of 35?


A rounding error, really.


The obvious solution is for the state to accept illiquid securities as payment for tax.


This would be hilarious. I would support that change for entertainment value alone.


German here. I fully agree that German companies tend to be crazy hierarchical.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: