ktkaufman

Canvas is open-source and can be self-hosted.

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.

https://ktkaufman03.github.io/

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

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!

Location: Worcester, MA

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

Location: Worcester, MA

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 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.

I've added a picture of my scanner to the article :-)

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.

A more accurate title would be "Reviving the coolest scanner you've probably never heard of", but it was already a bit long.

I make no claims about my own coolness :-)

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 :-)

That does look pretty cool!

Huh, I guess I should tell everyone I know that I don't exist ;)

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.

I don't plan on doing a walkthrough - the only reason I even touched a Pakon scanner was for development/testing purposes - but there's an abundance of information online that I'd encourage you to seek out if you're interested.

I had never even heard the name "Walter Oney" before I started researching this thing. I was pleasantly surprised by how well his 20 year old code held up, though.

Apologies for jumping into code - this is "Hacker" News, after all. The feedback is still appreciated. I actually meant to include pictures but forgot :/

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.

Good question - honestly, I forgot. Also, there are multiple models that look very different, so then the question becomes: which one do I show?

In any case, those who are really curious won't have a hard time finding pictures. I'll include some next time :-)

Kodak sold a lot of their patents to other companies as a result, IIRC, of their bankruptcy. I'd have to look at the patents for this particular system again, because I can't remember if they were ever reassigned or if they were simply allowed to expire.

Patched versions of the original drivers will be released, along with the new drivers. I'm not sure if I'll release the source code yet because of the legal gray area around this sort of work, but it's still something I'm considering.

Like steve_austin said, releasing the code is in a grey area. Realistically, it's highly unlikely that anyone would actually be upset about it, so it may happen in the future.

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.

Indeed it does. I was born a few years later :-) That's what I love about "digital archaeology" like this - it's so much fun to find and explore things from a time you can't possibly imagine on your own.