NateLawson

There's another reason why USB-to-parallel adaptors can't replace a PC with a printer port: the latency for round-trip applications is significantly higher over USB. It takes a few microseconds to read/write a byte from a PC printer port. Over USB, the control message latency leads to this taking tens of milliseconds. USB beats it on throughput, but only when transferring lots of data.

Before they disappeared, printer ports on motherboards began getting worse for latency and compatibility. This was likely due to cost reduction since low latency two-way communication was not needed for printing.

There was an interface for old Commodore floppy drives that is just remapped pins on the printer port[1]. When PC's circa 2005 stopped working with it, I designed a USB microcontroller board to implement the protocol[2]. It had to do some fancy state machines to get around the round-trip problem, caching a set of commands until the host was ready for the transfer. Then it would send them all back-to-back and start streaming back the bulk data. Fun stuff.

[1] https://www.c64-wiki.com/wiki/X1541

[2] http://www.root.org/~nate/c64/xum1541/

Yeah, the ISP I founded in 1995 (elite.net) was a PM2ER for both dialup and routing with a Pentium 90 as the shell & web server. We quickly hit the 30 line limit and went up to the PRI-based Portmaster models. Fun and exciting times, just bringing a rural community online for the first time ever.

These typically work by changing the media bit encoding to be easier to process with 6502 instructions instead of a lookup table. Others simplify the table and use more RAM so that fewer lookups are needed. I haven’t looked at how Transwarp works yet but it seems like the latter.

Some discussion with the author: https://www.lemon64.com/forum/viewtopic.php?t=78558&start=0

There’s a newer version here: https://csdb.dk/release/?id=214786

Release notes: https://csdb.dk/release/?id=214786&show=notes#notes

More details from another advanced loader:

https://www.linusakesson.net/programming/gcr-decoding/index.... https://www.linusakesson.net/software/spindle/v3.php

A semi-legit app can later drop malicious code and run it. Think of a repackaged OSS project or pirated software that has an auto-updater built in.

Xprotect is part of GateKeeper, which arrived in Mountain Lion (and late versions of Lion).

Here's a good summary of the flaw:

https://guidovranken.com/2022/06/27/notes-on-openssl-remote-...

Note that the bug is only in 3.0.4, which was released June 21, 2022. So if you didn't update to this version, it's unlikely you're vulnerable.

My company, Root Labs, has consulted on various lawsuits. We aren't trial witnesses but we've done supporting work, such as reverse engineering and writing a detailed technical analysis of how a product works. This report was then reviewed by the testifying expert, who wrote their own report to be entered as evidence.

I recommend not working as a testifying expert for a few reasons:

- You have to take sides, and the other side will never want to work with you again. Are you sure you'll never want to work with AT&T if you represented Verizon once, for example? What if you want a job there some day?

- Despite the term "expert", it comes down to how you present yourself in the courtroom versus what you know. The opponent's "expert" might seem more believable than you, despite being wrong about the technical issues.

- You have to stick to one particular area of technology your whole career, and many of the cases cover the same ground. Do you want to be "Ethernet Implementation Person" your whole life?

- A lot of the work is boring, and lawyers are generally not technically adept. Juries are worse. So if you love explaining something repeatedly in oversimplified terms, maybe you'd like this.

Usually testifying experts are older and do it after they've finished a career in some subject area. It might make sense at that point as a second career.

If you did a pure analog copy (dual tape deck), you had generation loss. Eventually copies of copies would have too much noise and thus persistent load errors. Additionally, in-band signals were included in the gaps between blocks that would mess with the auto gain control, causing an unreadable copy as the tape deck tried to compensate. The loader would skip over these sections during the regular load process.

All copy protection relies on asymmetries between the production/mastering environment and the consumer equipment.

Same year, and every engineering and CS student I knew had one in their dorm room. The lowest spec I saw was 386SX-16 with 2 MB and the highest was 486DX-50 with 16 MB RAM. Most used DOS/Windows but the CS students dual booted to Linux (Slackware mostly, some SLS).

As late as the mid-90s in California, some kids showed up at university without a computer. There were PC and Mac labs on campus that were open pretty late, as well as VT100 terminal labs open 24/7 (though these were only used by most students to check email between classes and were on the way out).

All engineering students had a computer, though.

This article is a good list of implementation flaws with RSA, both in parameter selection and protocols.

However, I disagree with the recommendation to use ECIES. It has a separate MAC and encryption algorithm approach which is better served by AEAD algorithms these days.

You need to get access to the raw entropy stream in order to characterize it and test it under a number of different situations. At Cryptography Research, we did a number of reviews of hardware entropy sources.

You have to look into behavior during very early startup (power on reset), suspend/resume from low power states, under high heat and thermal shutdown, as well as stable operation. You look at different samples of chips to look for production variation. You build software models that try to simulate the underlying hardware behavior to see how close they get to predicting outputs (which is a bad thing if it works too well!)

You then review how the system processes this entropy since ideas that look good to hardware engineers (like a string filter) are actually really bad for entropy. You analyze the path for side channels or race conditions that could leak raw entropy across process boundaries.

Anyway, here are the reports:

https://www.rambus.com/wp-content/uploads/2015/08/IntelRNG.p... (1999)

https://www.rambus.com/wp-content/uploads/2015/08/VIA_rng.pd... (2003)

https://web.archive.org/web/20141230024150/http://www.crypto... (2012)

QKD relies on many underlying assumptions, which researchers conveniently sweep under the rug while continuing to build castles ever higher on the theoretically "perfect" but insecure foundation. It is unclear how the underlying implementation for QKD can be made as secure as modern silicon countermeasures are against attacks like fault injection.

A while back, I summarized all the ways I could think of where the layer under QKD fall apart. I think the list is still valid:

https://rdist.root.org/2008/10/24/quantum-cryptography-is-us...

This is kind of a ridiculous announcement, but I appreciate what they're trying to do. I find it ironic that they're trying to improve security & privacy for app users, but then the first apps they certify are almost exclusively VPNs, which are some of the worst for user privacy.

VPN vendors collect all kinds of data on their users and are sometimes even backed by intelligence agencies. Sure, use them to get around region restrictions for something uncontroversial, but don't send all your traffic through them and expect privacy.

I also see that they didn't tackle the hardest part of mobile app security -- the backend services. Many apps scrape data from the device and then push it to the service, where it is logged (for how long?) and reused in who knows how many ways. The lack of transparency around backend processing is the real problem for app users.

How many users have been had their data exposed by an open S3 bucket or database versus by a vulnerability in the app code itself?

Kirk McKusick took this kind of scale into consideration when designing softupdates for UFS. One of his criticisms of the competing log structured filesystems at the time was that the replay process would require RAM in excess of any server's capacity once disk drives were large enough. He had designed the softupdates recovery process to be incremental and use a fixed amount of RAM that didn't scale with volume size.

This kind of holistic systems' awareness is a sign of software that's designed well.

Hacking became "cool" for the corporate world in the late 90's. Movies like The Matrix and the fact that nothing too valuable was online yet meant that getting hacked was likely just web site defacement. Meanwhile, there was finally real money to be made in developing security for when the web finally became worth protecting.

There was some ongoing consternation at ISS around 96-97 about an employee being a Phrack editor. Management talked to them but it didn't threaten their career.

My university had terminal labs in the early 90s, tables full of Wyse terminals hooked up to the central UNIX cluster. PCs and Macs were common in other labs, but a terminal lab was still a convenient place to check email or get on IRC between classes. I would log into two terminals next to each other in order to have a screen for IRC while coding on the other one.

One early morning, I walked into a lab that was vacant except for one person. He was slumped over the keyboard with a hand around an empty Coke can. The amber screen was scrolling upward every few seconds:

  YOU ARE HUNGRY...
  YOU FEEL TIRED...
  > 
  YOU ARE HUNGRY...
  YOU FEEL TIRED...
  >

Butler Lampson (Xerox PARC researcher who created the Alto) recently revised this classic paper from 1983, updating it for more modern systems and principles (e.g., eventual consistency).

Yes, parsing of untrusted data, race conditions, etc. are still a problem in general. My complaint was with the uninformed article, not your analysis.

Sure, how about linking against the platform OpenSSL implicitly by grabbing a lib.so from an actual Android phone, linking against it with the NDK, and hoping that the ABI will never change?

https://sourcedna.com/blog/20150806/predicting-app-crashes-o...

And all that only to get access to MD5 or AES...

I've spent a lot of time both reversing and creating these kinds of schemes. Anyone else here?

I gave a talk a few years back, comparing both retro and modern copy protection schemes. Also designed hardware for dumping floppies at the bitcell level (ZoomFloppy) and co-designed the Blu-ray content protection system.

http://www.slideshare.net/rootlabs/copy-protection-wars-anal...

Now my day job (SourceDNA) is building tools to reverse lots of code at scale. A never-ending stream of apps provides a ton of "wat?" moments as you never expect developers to make the choices they do.

There is no IOMMU in USB. You've got it backwards: the IOMMU in PC's is on the host side of the USB controller, not the device side.

There's an easy way to tell. Does the bus carry memory addresses? Then it supports DMA. Does it just send messages? No DMA to protect against.

The USB controller on a PC does support DMA. The OS device driver allocates buffers and passes them to the controller to fill. If it's properly programmed, it will only store data into those buffers. An IOMMU is there to prevent malicious kernel privileged code from bouncing through peripherals that support DMA to compromise other privileged code.

Messages on the USB bus side have no addresses in them and there is no DMA involved.

This is correct. The problem in this example is not the pendrive, but the automatic selection of device drivers based on the PC OS 100% trusting physical access.

An easy way to see this is recompile the USB keyboard driver to ignore keyboard descriptors with a particular address or vendor ID. If you do this, the pendrive can't do anything because USB is host-controlled, as implemented by the OS. Without the OS initiating a conversation with the pendrive and saying "ok, I'll configure you as a keyboard and interpret responses from you as keystrokes", it can't happen.

As you point out, the main CPU on a phone does not implement HID autoconfig on the internal baseband bus.

For one example, see the Android kernel for Qualcomm HSIC baseband interface (baseband-qct-mdm-hsic.c)

https://git.sphere.ly/Lloir/android_kernel_htc_evitareul/tre...

The way manufacturers "mitigate" baseband to main CPU compromise is by using a protocol that allows no initiation from the peripheral device (baseband). It can only talk to the main CPU via a serial-like protocol, not access its memory directly.

Other routes, such as side channel leakage or possible flaws in the main CPU software that interpret messages received from the baseband are still a potential source of problems, but there is no such DMA capability in the HSIC protocol.

It is valid to have general distrust and annoyance with the spy agencies for their actions to create backdoors. But there is no technical basis for this article's claims, and the author should retract them.

The original post talks about DMA being a method the baseband can use to compromise the AP, which is false for any mainstream design. Trust doesn't have anything to do with it; the protocol literally does not support DMA.

The premise of the article is flat out wrong. Mainstream smartphones do not provide DMA access from the baseband to the application processor's memory.

The connection is usually HSIC, which is a chip-to-chip USB derivative.

https://www.synopsys.com/dw/dwtb.php?a=hsic_usb2_device

The AP is responsible for setting up buffers for communication and manages its own host controller. But like I2C or even older UARTs, the AP remains in control of the communications.

Yes, basebands need more auditing and a security model more like modern APs (e.g., separation of privileges and exploit countermeasures like ASLR and non-exec). Yes, getting baseband access then lets you monitor regular voice and SMS comms. But no, it does not instantly compromise the AP so using the Signal app would still be secure.

We both download apps and scan apps developers upload to us.

Many do require this, but there are current sandbox limitations that make this harder to change quickly.

Exactly right. What we expect to happen next is runtime generation of an XPC identifier to call the underlying service, replicating the behavior of the private API with none of its code.

We're moving ahead with detecting this too as it's an obvious next step.