225 karma · joined September 4, 2022
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.
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 don't post a lot, but when I do, I try to make it interesting. So far I've covered:
- a creative use of Rust's type system (https://ktkaufman03.github.io/blog/2023/04/20/rust-compile-t...)
- taking a deep dive into some obscure, closed-source scanner drivers, and ultimately creating new ones (https://ktkaufman03.github.io/blog/2022/09/04/pakon-reverse-...)
I do have some more posts planned for the not-so-distant future, which I think will be interesting!
If for some reason you want to subscribe, I have an RSS feed set up: https://ktkaufman03.github.io/feed.xml
Remote: Yes, potentially open to hybrid
Willing to relocate: No
Technologies: C#, C/C++, Java, Rust, Python, Go
Résumé/CV: Available on request
Email: ktkaufman AT wpi DOT edu, include "HN February 2023" in the subject line
LinkedIn & GitHub: https://www.linkedin.com/in/kai-kaufman & https://github.com/ktkaufman03
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!
[1] Reviving the Pakon film scanner: https://news.ycombinator.com/item?id=32714806
Remote: Yes, potentially open to hybrid
Willing to relocate: No
Technologies: C#, C/C++, Java, Rust, Python, Go
Résumé/CV: Available on request
Email: kaufmank03@gmail.com
LinkedIn & GitHub: https://www.linkedin.com/in/kai-kaufman & https://github.com/ktkaufman03
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!
[1] Reviving the Pakon film scanner: https://news.ycombinator.com/item?id=32714806
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.
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'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.
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.
I make no claims about my own coolness :-)
In all seriousness, I like learning about things that were before my time, and that's why I use the term "archaeology." It's not really archaeology, since I know plenty of people who were alive at the time, but it still appeals to my inner curiosity.
The practical results can best be described as 36 super high-quality TIFFs (if you scan a full 35mm roll) obtained in just a couple of minutes. You can find more information by looking at other online sources - one I'd recommend reading, if you're interested, is https://www.dantestella.com/technical/f235plus.html.
I'm not surprised that it's relatively unknown - after all, digital photography has mostly taken over, and even those people who benefited from drug-store film development/scanning probably wouldn't have cared too much about what hardware was in use.
In any case, those who are really curious won't have a hard time finding pictures. I'll include some next time :-)
Linux support is a completely different beast. There is a lot of code that I didn't talk about, including the absolutely massive image post-processing/color-correction library that we only have a Windows version of (and no source code for, obviously.) The Pakon's added complexity (especially automatically finding frame boundaries) makes a cross-platform, source-code-less port extremely unlikely to succeed in a remotely reasonable amount of time.