CA v. Altai (where the abstraction-filteration-comparison principle comes from) and SAS v. World provide pretty strong positive evidence that clean room is a valuable technique in both the US and Europe.
I do agree with you that the term is misused (it’s almost completely irrelevant here, anyway) and over-applied, but “not having ever been in a position to see or access the source code” is proven, especially in SAS v World, to be a pretty strong defense that’s worth pursuing in some re-implementation scenarios.
By not having void air space in between cylindrical cells like you'd get with two 18650s? It's mostly just a matter of packaging.
Pouches can be made to have better volumetric density than cylindrical cells quite easily, which is why laptops aren't generally full of cylinder cells anymore; the challenge is just providing them enough external support/compression and swelling allowance, which can be accomplished through chassis design.
I read this as the chunks are 64 bytes and thus each chunk is split over 9 frames. I haven’t looked yet but it’s probably an ISO-TP esque framing protocol.
Yep, this is the case. Nine frames are transmitted with the first frame containing a sequence number and the first five bytes, followed by seven frames containing just data, and a final frame containing the last three bytes of data, and a two byte CRC.
Newer Deere equipment has a lot of components that have to be adapted using DSA - turbo actuators, various hydraulic sensors, various suspension leveling sensors, fuel injectors, interior displays, and anything SCR related are the big ones. Basically, any sensor that needs a calibration step or triggers an emissions code, or a few intentionally vehicle locked modules (ECM).
Interesting. I just finished with a thorny hydraulics problem on a 9870 Combine. It turned out to be a faulty sensor. Part of my troubleshooting involved buying a new sensor, and swapping out each sensor in the system one by one with the new unit until I was sure they were all working correctly. No calibration needed. When i do need to calibrate a system i can do it all from the onboard computer.
Yeah, that’s a good way to summarize what people are mad about; they basically moved all of the calibration from onboard to offboard diagnostics, and then thwarted most efforts to access the offboard diagnostics.
Automotive is similar and I’m a bit worried for EVs; for ICE autos there’s enough emissions related regulation that some diagnostics and manuals are accessible, but for EVs there’s nothing much stopping a Deere style complete lockdown.
Exactly, go look at Lucid/Tesla and a few others for examples of how the car is a brick without the manufacturers sekret unlock codes and calibration software. If they decide not to help, you are out of luck.
Palantir sell consulting services ("forward deployed engineering") around graph and map database platforms, using data supplied by customers. Some of their customers ask them to make surveillance aggregation systems, others ask them to make totally banal and random enterprise software (this is why you commonly see freak-outs around hospitals buying "Palantir," for example; usually they are operating as consultants making some kind of medical records warehousing system owned by the customer).
Samdesk provide risk analytics using traditional risk analysis investigation and research, which they have now welded an "AI platform" to, like everyone does these days. They aggregate crime and protest data to make a map of "places your employees might be at risk" and sell it to companies.
Samdesk would be a Palantir _customer_ if they liked parting with their money, not a competitor; Palantir operate at a much "lower level" and don't do the data collection or research on their own.
No? Windows also has its own graphics subsystem, compositor, and an even bigger set of user land UI/forms/controls libraries than Mac OS. It really is just a critical velocity / adoption / time thing, there’s nothing strongly technical separating Mac OS API/ABI translation from Windows ala wine.
Microsoft's business model regarding Windows is to sell an operating system capable of running on as many devices as possible.
Apple's business model regarding macOS is to sell as many devices as possible capable of running that operating system.
The former lends itself to intrinsic portability such that an independently derived emulation layer is possible (not easy, just possible), whereas the latter has the freedom of assuming device capabilities/features always present for any given release.
I don't agree that this particular trait of macOS makes an implementation at the layer WINE implements (full API+ABI) any harder or easier. Certainly, vertical integration makes OS porting (ie Asahi) and lower level emulation more difficult, since the hardware and firmware's contract with the OS is entirely proprietary and can be freely changed from revision to revision, but something like WINE operates many layers above this anyway.
There's a reasonable argument that the Win32 API was designed to be more stable than the Mac OS one and this makes WINE's task easier, but this sword is double-edged: while slow change is useful, backwards compatibility expands the Win32 API surface area, since each API also needs to continue to support every way it was ever wrongly used. With the continued proliferation of Windows UI frameworks and OS subsystems, it becomes difficult to argue that Windows is any easier than Mac OS would be to implement at an API layer.
I do think there is an argument to be made that Win32 was more straightforward and felt more tractable when WINE _started_, and therefore the project was able to scale with the problem space, while OS X started from a "larger" place and was therefore more daunting, but this again is a timing and traction argument more so than a purely technical one.
>> Apple's business model regarding macOS is to sell as many devices as possible capable of running that operating system.
> I don't agree that this particular trait of macOS makes an implementation at the layer WINE implements (full API+ABI) any harder or easier.
Here is my corroboration. Apple publishes XNU to the world in this repository:
https://github.com/apple-oss-distributions/xnu
There is no such publication of the GUI frameworks required by macOS programs.
> I do think there is an argument to be made that Win32 was more straightforward ...
I did not make that argument. Instead, the position I hold regarding Windows is:
... an independently derived emulation layer is
possible (not easy, just possible) ...
When an organizational goal is to sell devices, instead of operating system licenses, there is no need to engineer portability within the OS as the target hardware is well-known. This is a luxury MS-Windows never had, as its goal has been to run on as many disparate devices as plausible. Thus the "intrinsic portability" I referenced.
In fact, you have made my point for me:
> ... while slow change is useful, backwards compatibility expands the Win32 API surface area, since each API also needs to continue to support every way it was ever wrongly used.
I don't think this is new with LLMs (finding an exploit based on a few words offhand has always been a fun part of exploit development), but it's scaled and democratized to mass exploitation of low value targets. Backing exploit PoCs out of patches, commit messages, and random overheard or over-read sentences is a practice as old as vulnerability research. The difference with LLMs is that an explosion in actors "skilled enough" (human or not) has enabled sloppy / low-skill "exploit the whole Internet" actors in a way they weren't previously enabled.
I do agree with the author's ideas, though; most of these are things that should have been done much sooner, and I suppose it's good in a sense that there is a forcing factor now.
> Backing exploit PoCs out of patches, commit messages, and random overheard or over-read sentences is a practice as old as vulnerability research
True, but it used to take days or weeks of research, testing, and RE to get those PoCs.
Today the entire chain - reading commits, RE patch binaries, building exploit, scripting exploit scan, $profit - can be fully automated and happen in minutes or hours.
It seems like it could go either way to me in the US (not a lawyer, but someone who has a fair amount of experience in reverse engineering / fair use issues).
On the one hand, it is fairly clear that producing source code with the explicit goal of reproducing a 1:1 binary is in no way transformative, so that's out. This would be a really hard argument to even attempt.
On the other hand, these projects are mostly free, intended for owners of the game to play the original game on a different platform or in a modified format, and not likely to have a negative effect on the original work's desirability or value. And, the reproductions aren't complete and alone usually produce limited to no value to a consumer (usually, they won't start without the original game files). These are the other important factors considered in fair use determinations and generally go the way of these being OK.
So, it's hard to say. With reverse engineering and copyright in the US in general, context is crucially important; something that would be completely illegal for one purpose (ie - decompiling and recompiling a competitor's software to distribute it without a license or use it internally without purchasing it would be obviously illegal) could be OK for another one.
In a sane world, if brought before a court, the binary itself wouldn't have any protection unless hand authored. The actual creative work/human expression was the source code. The entire point of compiling is to strip that extra data out, leaving pure functional logic that doesn't even strictly match the source logic thanks to optimization.
Then a freshly written project would be completely different with no derivative elements at all; the only commonality between the two codebases is their functional elements. You can compile a decomp into the same binary, but that's only to prove functional equivalence. The intended mode would be with a modern compiler that completely rewrites the logic (it might even have to if it writes it for a completely different computer architecture, which describes every retro console game). Then neither the source nor the compiled artifact would match.
> The entire point of compiling is to strip that extra data out, leaving pure functional logic that doesn't even strictly match the source logic thanks to optimization.
I strongly disagree with this notion from even a conceptual (much less legal) level; the point of compilation is not to erase the algorithms the programmer implemented, just to optimize and implement them.
> You can compile a decomp into the same binary, but that's only to prove functional equivalence.
This is like saying that a translated book is only "functionally" identical to the original; there's a lot of precedent in copyright law for this not being the case, and I don't think any argument revolving around the transformativeness of the compilation process would fly at all.
A huge portion of the actual thing I write when writing a program does not exist at all in the compiled binary. Names, types, type parameters, etc. being big ones, but many types are also aliases for the empty struct, so their value doesn't exist at runtime either. Conversely, I can write _.map(_.map(_.map(f))) and have that turn into all sorts of looping and branching logic that I didn't write, and the meaning of which is basically "do whatever must be done to make the types work".
Programs as written are nothing like programs as compiled, certainly not as an expressive endeavor. Books don't have an analog. There's no point where we strip all conceptual meaning from the book and leave only the procedural algorithms the semantics demand. There's no point where we replace all the individual words with autovectorized versions, or where we automatically delete impossible sentences, or remove every layer of abstraction that the programmer put in there exactly for the ability to convey ideas.
> it is fairly clear that producing source code with the explicit goal of reproducing a 1:1 binary is in no way transformative, so that's out. This would be a really hard argument to even attempt.
Absolutely false. There are an infinite number of programs that will compile to the same machine code. Especially when an optimizer is involved. Discovering one of those is a creative process, transformative, and protected.
Using an LLM to do it for you? I wouldn’t touch that with a 10 foot pole. Seems too close to mechanical transformation to me.
Most of these projects carefully distribute only the source code representation of the binaries, for this reason, relying on the consumer to acquire / own the art assets and copyrighted material (logos, trademarks, etc.).
None of the original source code exists in these projects. It’s all created from scratch.
Copyright for this new code is owned by the person doing decompilation. No one knows how similar to the original it is or not, just that it compiles to the same output.
Edit to clarify: by not exist, I mean it is not publicly available.
A decompilation is not clean room, nor is it "created from scratch". If that was the case, you could just compile a program to remove the copyright, because the machine code doesn't resemble the source code at all either.
A reimplementation or a behavior-based clone is an entirely different legal world from decompilation.
The compiled binary is protected and the property of the original company. The source code written by people doing decompilation is owned by the people doing the decompilation. That source code can compile to a lot of different binary representations, just like a lot of code representations (infinitely many) could compile to the original binary.
In fact, the goal of most decomp not to produce the same binary, that’s just used as a validation.
It's not an obvious legal argument that it is not a derivative work of the compiled code or the original source code that produced that. Clean room reverse engineering is meant to give you a strong argument for that, and while it's not necessarily required to prevail against a copyright case (or actually sufficient) it's gonna make things harder if you don't. (All of this is made more murky because copyright is meant to only cover expressions of human creativity, and code is kind of a mix of creativity and mechanical details: the clean room approach is meant to separate out the mechanical details)
Also, If it is an unauthorized derivative work, as I understand it then it might not even qualify for copyright protection itself.
> Realistically, that sort of thing isn't useful as non-homogeneous architectures really suck for an application or OS to deal with.
I agree that if each core doesn't "support" the full ISA it's a huge pain (the one generation of Intel AVX-512-but-not parts were incredible), but that hasn't been common in years. Usually (and in this case, according to my reading) the small cores get a horrible slow/decoder-emulated implementation of every instruction, so that if you schedule on the "wrong" core you don't trap but just run really slowly instead.
Otherwise, heterogeneous architectures are the present and future of mobile and consumer desktops and have been for years. Desktop OSes are getting better and mobile OSes are just fine at scheduling across different core families (the higher level of abstraction everyone complains about in mobile apps actually helps a lot here).
Only server, as far as I know. Server is now either high-density E core (Sierra Forest) or low-density P core (Granite Rapids), but desktop and laptop are heterogeneous still; laptops are getting even more heterogeneous because they have P-Cores, E-cores, and Low Power Island cores.
Did Intel ever ship any heterogeneous server parts? I'm not aware of any, and it looks like even the Raptor Lake desktop silicon sold under the Xeon brand only had P-cores enabled.
The worst of Intel's processor core asymmetry was with Meteor Lake and Arrow Lake, where the two LP-E cores on the IO die had no L3 cache and really bad DRAM latency despite being directly adjacent to the DRAM controller, resulting in those two cores combined offering about as much performance as one of the E-cores on the CPU chiplet. And they used the same IO die across both generations, while updating the microarchitecture of the CPU chiplet, so things diverged even more. And because the performance of the LP-E cores was so bad, Windows wouldn't schedule any threads on them unless it was trying to operate exclusively on those LP-E cores with the CPU chiplet powered down entirely—but those two LP-E cores were still reported to software in the total thread count, so heavy multithreaded applications would launch two more threads than could actually be scheduled at once.
With Panther Lake, Intel still has three tiers of CPU cores, but the performance gap between E cores and LP-E cores is down to only about 10%.
I do agree with you that the term is misused (it’s almost completely irrelevant here, anyway) and over-applied, but “not having ever been in a position to see or access the source code” is proven, especially in SAS v World, to be a pretty strong defense that’s worth pursuing in some re-implementation scenarios.
reply