TL;DR: it's in a gray area, but nobody with power actually cares (at least for now), so it's effectively fine.
As I understand it, Lego is aware of the project (there's been a significant increase in interest in Lego Island in the past few years, with attempts to obtain the original source code) and simply does not care. It's an ancient IP and can't realistically compete with anything new, at least not in a way that would significantly affect Lego's revenue. This is not unlike the way several other companies have acted when their respective older games have been given the same treatment; if a fan project is not actively causing problems (reputational, financial, etc.), most companies will just leave it alone. For companies that actually seem to care about public opinion (as opposed to, say, Nintendo), I think it's fair to assume that the bad optics of taking legal action against a random fan project, however legally justified it might be, far outweigh any possible benefits.
I can tell you from firsthand experience that people - including people I have personally worked with at large organizations - have absolutely heard of Wiz. Yes, it is a relatively new player, but the people there have been putting out high quality research for years and have also demonstrated a very compelling approach to securing cloud environments. They get a lot of praise, and they've earned it.
Second, I have no idea what you're doing to get Wix results from a search for Wiz. When I search for Wiz, I get a whole bunch of results about Wiz, including links to discussion threads where random people (i.e., not high-rep HN users) also talk about how much they like the product.
Finally, something to consider: would Google actually pay $32B for a company that "nobody has heard of" and doesn't provide any value? Probably not. I would hope not.
I was annoyed by having to write the same boilerplate code over and over again to handle "failures" that would never actually occur, so I took matters into my own hands and came up with what I think is a pretty elegant (if slightly complicated) solution. As it turns out, the architecture of this solution can be applied to other issues!
I am a college sophomore studying cybersecurity with several years of practical experience in software reverse engineering, malware analysis and the automation of binary analysis tasks. I am also familiar with computer forensics tools such as Volatility. Some of my past projects include reverse engineering, fixing and updating legacy scanner drivers [1] as well as writing deobfuscators to handle software in various languages. While I was in high school, I uncovered and reported vulnerabilities in various ed-tech software packages.
I am looking for an internship in the cybersecurity field, ideally in a role that involves software reverse engineering. I'm open to other roles as well, including penetration testing work. If you think we'd be a good match, please do reach out!
I am a college sophomore studying cybersecurity with several years of practical experience in software reverse engineering, malware analysis and the automation of binary analysis tasks. I am also familiar with computer forensics tools such as Volatility. Some of my past projects include reverse engineering, fixing and updating legacy scanner drivers [1] as well as writing deobfuscators to handle software in various languages. While I was in high school, I uncovered and reported vulnerabilities in various ed-tech software packages.
I am looking for an internship in the cybersecurity field, ideally in a role that involves software reverse engineering. I'm open to other roles as well, including penetration testing work. If you think we'd be a good match, please do reach out!
The way the scanner deals with dust is by complaining that there's dust :-) (It doesn't have a special dust error, AFAIK, but it does do some checks that will end up failing if too much dust has accumulated.)
The way to avoid dust accumulation is to keep it covered when it's not being used. That works nicely and is a reasonable thing to do anyway.
In theory it's unnecessary. The problem is that one of the main selling points of the Pakon is its convenience - then again, if somebody wants to do things the hard way, who am I to stop them?
I don't have any plans to develop a cross-platform client, but I will be publishing more technical information about the scanner so people aren't left wondering what I know.
I had help, but yes. I think it's worth the cost to give people peace of mind that they won't have to disable some of the most important security features available to them in order to use a scanner.
Oddly, there are files on the CDs that are dated after the date on the packing slip - several months after, in fact. So I'm not quite sure exactly how old my kit is...
The custom drivers will be released soon :-) If you're not in the Pakon Facebook group, I recommend requesting to join it, since there's a lot of useful information there.
>I think it's still nightmare because Windows require driver signature verification by default
I've taken care of that already :) My custom drivers are properly signed and basically ready to release once I tidy up some loose ends.
I'm not entirely sure if this really needs to run at the kernel level. In the future I might investigate converting it to a user-mode driver, but for now I think a signed kernel-mode driver will suffice.
By popular demand, the article now has a picture of the scanner I have access to - an F135 Plus - with a bit more information about how it's used. For those who wish to see an F235 and/or F335, I recommend Google Images, since I'm not going to use someone else's pictures without their permission.
I've addressed this a couple of times in response to others, but the main problem is that there are multiple models that look quite different from each other. I could pick one, but that wouldn't be telling the whole story, or I could show them all and add extra clutter to the page.
That being said, I'll probably just pick a model and add a picture to the article. Google Images is good for finding the others.
Good point about the Cypress acquisition. While I was investigating part of the driver code recently, I realized it was based on FX2 sample code. The development kit that I got, on the other hand, was pre-FX2. The article notes that Cypress acquired Anchor Chips, the original creator of EZ-USB, in 1999, which would seem to line up perfectly with the time frame in which the Pakon scanners were developed.
TIL about PCI-X. Northlight looks like a pretty cool piece of hardware! It's cool to see what other obscure stuff is out there - that's why I like Hacker News :-)