cnvogel

Here’s what I don’t get: why the many layers of obfuscation in the build phase? (I understand why in the binary linked into ssh.)

Once the first stage, extracting a shell script from one of the „test“ data blobs, has been found it was clear to everybody that something fishy is going on.

It’s inconceivable that I’ve would have found the first stage and just given up, but then it was „only“ a matter of tedious shell reversing…

They could easily done without the „striping“ or „awk RC4“, but that must have complicated their internal testing and development quite a bit.

You are not observing the "problem" of entropy running low. Because it doesn't.

You are observing the misguided attempts of fixing this non-problem.

https://www.qualcomm.com/products/qualcomm-9205-lte-modem

The Qualcomm® 9205 LTE modem is our next-generation ...

Qualcomm 9205 uses the latest generation (gen9) Qualcomm® GNSS engine ...

Location

Satellite Systems Support: GPS, GLONASS, Beidou, Galileo ...

Yes, that's certainly a solution.

Or using a certification authority for users (TrustedUserCAKeys in sshd_config), so that any user that has a signed certificate, and owns the corresponding private key, would be allowed to login. No further updates of authroized_keys files needed.

And, to further automate the ssh login, maybe your LUKS container could have a second (Nth) key-slot being a random key RSA-encrypted with the other machine's identity private key? (https://bjornjohansen.no/encrypt-file-using-ssh-key for examples)

But generally, I really dislike the use of LUKS in this case, as I think a filesystem based encryption (not encrypting whole block devices) would make more sense. I understand that this isn't as mature as LUKS, though.

Also I’m curious about the 1-bit recording. Is that a thing?

Yes. This homemade GPS receiver uses a simple comparator (1 bit) to sample the signal (after amplification to get the noise floor over the decision threshold).

http://www.aholme.co.uk/GPS/Main.htm

Here's a paper that shows reflections (Fig. 3, "S11") and insertion loss (Fig. 4, "S12") on coplanar waveguides, when using a sharp 90° bend, a 90° bend with a champfer and the case where the bend is replaced by two successive 45° turns ("final design").

The frequency scale spans 10..90 GHz.

http://tentzeris.ece.gatech.edu/ECTC09_Rida.pdf

The examples should only view the bit/address mapping, not be a complete example on how to access memory mapped peripherals.

It's still non-esoteric today:

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc....

ARM Cortex M4 supports adressing individual bits (often registers of hardware peripherals) of memory locations as one additional memory location writing to, or reading from a single bit.

e.g., from the examples of said infocenter url:

   *(uint32_t*)0x20000000 |= (1<<7)
   *(uint32_t*)0x20000000 &= ~(1<<7)

   *(uint32_t*)0x2200001C = 1;
   *(uint32_t*)0x2200001C = 0;

Quote from the Article: """The figure is calculated by multiplying 2 by itself 77,232,917 times and then subtracting 1."""

Would HN agree that multiplying 2 by itself once is 2⨯2 = pow(2,2), twice is 2⨯2⨯2 = pow(2,3) and N times yields pow(2,N+1)?

The Mersenne Prime found is pow(2,77232917) − 1, hence the article got the number wrong?

The ban is specifically for the ability of the watches to covertly record or transmit audio, not about GPS logging.

https://www.python.org/dev/peps/pep-0238/

{Describing the old python-2 behavior:}

-------- Quote: -------

The classic division operator makes it hard to write numerical expressions that are supposed to give correct results from arbitrary numerical inputs. For all other operators, one can write down a formula such as xy*2 + z, and the calculated result will be close to the mathematical result (within the limits of numerical accuracy, of course) for any numerical input type (int, long, float, or complex). But division poses a problem: if the expressions for both arguments happen to have an integral type, it implements floor division rather than true division.

-----------------------

To guarantee the correct mathematical behavior in python2, one would probably have to write:

    def true_math_div(a,b) :
        if type(a) is int or type(a) is long :
            a = float(a)
        if type(b) is int or type(b) is long :
            b = float(b)
        return a/b

There is no general relativity involved in calculating your position. Solving for your position is basic geometry, if you want to have better resolution, have good model for the effects of the atmosphere on the radio waves.

http://www.aholme.co.uk/GPS/user_position_solution.pdf

Another example:

    $ nohup ./long_running_process &
    $ logout

You could interpret this as "breaking user-space", as it's contrary to long-running practice and user-expectations.

Or you could say that systemd is superior as it's reliably cleaning up unwanted lingering processes which may have bothered some before. And this is worth the hassle of explicitly running intended background processes via systemd-run(1), or adding code to e.g. tmux/screen doing the equivalent via the dbus-api.

A DAQ that reconstructs a perfect square wave (or a perfect stair-step function) is employing a "Zero Order Hold", and it would make a god-awful audio DAC.

https://en.wikipedia.org/wiki/Zero-order_hold

With a 0OH you'd gain the ability to potentially reconstruct a infinite bandwidth signal (the squarewave), which is irrelevant in the audio case: With a 10kHz squarewave, the next harmonic would be at 30kHz which is already waaaay out of the human range of hearing.

But limiting the bandwidth of a DAC (or ADC) is the fundamental property which causes it to be able to perfectly reproduce the frequencies within its bandwidth (~up to 20kHz in HiFi Audio), so that's desirable. And the "ripples" on top of a squarewave are just the manifestation of this property: If you cut away the frequencies above Nyquist, you get a rippled squarewave. And conversely if you compute the difference between the perfect squarewave and the "rippled" squarewave you get out of an Audio DAC this only contains (non-audible) energy outside of the bandwith of the DAC!

They didn't say "convert to greyscale".

Very good point. But even then, assume that one page of a leaked document contains a large picture with areas around the thrshold value: With the agency being able to recreate a perfect replica of the initially scanned paper version, but without yellow dots, it might be possible to extract the (very few) bits necessary to boil it down to a single printer serial number by statistical methods.

Yes, b/w converting is not sufficient. Once printed, the yellow dots are hard to remove.

http://imgur.com/a/kLovh

And even when you mask them out so that they are no longer visible in the "all white" (paper) background, e.g. by messing with the white/black point of the image there's still the possibility that they could be recovered with correlation methods in grey areas where they aren't visible to the naked eye or just by increasing the contrast.

From the datasheet (linked on the website):

Housing type: DIN rail housing (for DIN rail version EN 50022) Housing material: Polycarbonate

If you install the "moreutils", there's sponge doing the same.

https://joeyh.name/code/moreutils/ https://linux.die.net/man/1/sponge

What's that supposed to mean? Binary only, closed source kernel module?

>> Drivers for both cards will be available ... as well as varieties of Linux (3.10, 3.12, 3.2, 4.2 and 4.4).

Yes, I know. And it's sad. I'm also not a "gui" person, and couldn't make a useful graphical interface if my life depended on this.

But I'm especially confused as why this hasn't been built into Windows for years, especially considering how many people were e.g. hurt by "Autoplay" in the old days:

    You've plugged in a device that claims to be...
        [ ] a mouse (driver available)
        [ ] a storage device (driver available)
        [X] a soundcard (driver will be downloaded and installed)
    Tick any of the functions you want to activate, or press CANCEL
    if you don't want to activate any functions of this device, e.g.
    because it's a phone you just want to charge from your laptop.

I want a non data transferring power plug that can't be used to compromise my machine should a manufacturer opt to do that.

At least in Linux you can disable automatic binding of kernel drivers to devices like so:

    echo 0 >/sys/bus/usb/drivers_autoprobe

    # dmesg
    [ 1017.031703] usb 1-10.4: new low-speed USB device number 8 using xhci_hcd
    # lsusb -s 1:8
    Bus 001 Device 008: ID 046d:c30e Logitech, Inc. UltraX Keyboard (Y-BL49)

This can even be done with a different mechanism on a per-bus basis as described in https://www.kernel.org/doc/Documentation/usb/authorization.t...

If I decide to use the 2nd keyboard, I'll manually bind this device to the usb hid driver like so:

    # echo 1-10.4:1.0 > /sys/bus/usb/drivers/usbhid/bind 

I have no idea why no one bothered to make a nice gui for this feature (which also works on other busses), or why it's not standard to popup some message-box on other OSs (e.g. Windows) whenever something is plugged in a port, before even trying to load any drivers.

(edit: added 2nd part where I manually bind)

It seems to be this one here... Auto Track III

http://www.raytheon.com/capabilities/products/autotrac/ https://www.youtube.com/watch?v=QB4Qy6mNYWY

They no longer just try out random combinations or cover the input space exhaustively (which is not feasible anyway).

Nowadays they use instrumentation in the fuzzed/tested code to have guidance in what direction the input should be modified to get more cases the code covered.

Good example: http://lcamtuf.coredump.cx/afl/

Compare to the --at lest now, pretty obscure-- "Neper", which I've never seen used in practice except that I own a very old analog meter with a scale in Np...

https://en.wikipedia.org/wiki/Neper

The Np seems to have be used for amplitudes (rather than power), and value/ref = e^Np. And 0.01 Np ~ 1.01 (+1%) which is probably less useful than it seems at first glance.

There's also a surprising difference in behavior between tm = localtime() and localtime_r(..., &tm).

The former is the "traditional" function which returns a pointer to a statically allocated, global "struct_tm". The latter is the thread-safe version receiving a pointer to a use-supplied "struct tm" as it's second argument.

    :   do {
    :           t = time(NULL);
    :           localtime_r(&t, &tm);
    :           printf("The time is now %02d:%02d:%02d.\n",
    :                  tm.tm_hour, tm.tm_min, tm.tm_sec);
    :           sleep(1);
    :   } while(--N);

    write(1, "The time is now 07:23:33.\n", 26The time is now 07:23:33. ) = 26
    nanosleep({tv_sec=1, tv_nsec=0}, 0x7ffd9e798470) = 0
    write(1, "The time is now 07:23:34.\n", 26The time is now 07:23:34. ) = 26
    nanosleep({tv_sec=1, tv_nsec=0}, 0x7ffd9e798470) = 0
    write(1, "The time is now 07:23:35.\n", 26The time is now 07:23:35. ) = 26
    nanosleep({tv_sec=1, tv_nsec=0}, 0x7ffd9e798470) = 0

    stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
    write(1, "The time is now 07:30:56.\n", 26The time is now 07:30:56.) = 26
    nanosleep({tv_sec=1, tv_nsec=0}, 0x7ffc868c3010) = 0

Note, this is using glibc 2.24 under Arch.

    $ /lib/libc.so.6
    GNU C Library (GNU libc) stable release version 2.24, by Roland McGrath et al.
    (...)
    Compiled by GNU CC version 6.1.1 20160802.

For typical Gamma radiation of about 1MeV photon energy or higher, you need about 1cm thickness of lead to reduce the radiation to about a third (by a factor of 1/ℯ). One order of magnitude of radiation hardness (reduce radiation to 1/10th) needs two centimeters of lead. That's getting heavy pretty fast.

Radiation intensity inside your box depends on the thickness t: I(t) = I₀·exp(-tρμ)

t: thickness, say 1 cm ρ: density of the material, for Lead 11 g/cm³ μ: absorption coeffcient 0.1 cm²/g [see ref 1] I₀: intensity outside of the box

    ...import numpy as np...
    In [5]: np.exp(-0.1 * 11.34)
    Out[5]: 0.32174370422037013

[1] http://www.eichrom.com/PDF/gamma-ray-attenuation-white-paper...

In my day-job, I (help) design electronics that is subjected to (much less) radiation, and we also irradiate our devices to check for long-term effects (and this is done with a comparable doserate in a facility for this purpose).

Damage to your electronics in practice is almost exclusively caused by Photons (convention is to call this γ-Radiation when caused by radioactive decay in the nucleus, X-Rays when created in an accelerator). β-radiation (fast electrons) is easily shielded by thin layers of metal, and α (He nuclei) can't penetrate sheets of paper.

Individual photons can't really deposit much energy at a single location in your semiconductor, so they aren't able to generate enough charge to "flip bits" instantly. Flash still uses a lot of charge/bit, so it's relatively stable, DRAM is constantly refreshed and SRAM would need a jolt of high current to flip, so that does not really happen, either.

What radiation does, however, is to slowly damage the Silicon and change its crystal structure (introducing defects) which increases leakage and moves the analog threshold voltages of circuits around in a funny way. So, what we often see is flash becoming un-programmable on a more global scale (rather than individual stuck bits), and most importantly the analog aspects (voltage references, brownout-protection circuits, voltage regulators) cease to function.

This is all very variable, but we normally observe effects starting at "a few 100 Gy" when testing more complicated modules. We don't research individual components, though.

One especially nasty type or radiation are neutrons, though. When being "moderated" (slowly decelerated by successive interactions with material) they tend to have a high likelihood of merging with some other nucleus (being captured), and the energy resulting from this capture effect can be huge and concentrated on a single spot. This can be enough to flip bits, and this indeed may be an issue near the funny isotope mixture present in Fokushima at various places. Having a strong neutron emitter is very uncommon, though.

Unfortunately these damages are not specific to digital electronics, and especially optical components (parent refers to long fibre cables) tend to be rather sensitive due to their large structures, so "keeping the computers out" may not help much overall.

What's the standard way to use Tor for people who are really diligent with their operational security?

Personally I haven't used Tor except for short casual testing. But if my personal security would depend on the anonymity provided by Tor, I think I'd seriously consider adding an additional layer of protection to avoid information leaking out "to the sides".

and more...

probably refers to the first widely installed (with coaxial cables) 10 MBit Ethernet networks...

Cycle-to-cycle accuracy of an atomic clock (then called a timing and frequency standard) is never dominated by the resonance frequency, and you never extract the timing information from the radio-frequency that interacts with the physics directly.

The reference frequency used externally for timing is the reference oscillator which typically was 5 or 10 MHz, but nowadays tends to be 100 MHz as HF electronics became better.

For an older Caesium clock, a block diagram is explained on this page: http://www.leapsecond.com/museum/hp5062c/theory.htm

{a Rb clock is very similar electronically, only you are not looking at count-rates of Cs atoms flying through your spin filter but you are observing the optical attenuation of a rubidium gas, both vary with radio-frequency waves being injected into the package. Also Cs is a primary standard and Rb is very stable - but adjustable and susceptible to extarnal magnetic fields.}

From the reference frequency, a series of synthesizers / multipliers generate the radio frequency that is relevant to the physics process. And this frequency is then modulated slightly (137 Hz label in Figure 5) so that correlation in the physics process from being too high, or too low in resonance frequency, can be observed (Figure 9, you vary between f2 and f1 137 times per second).

A good GPS steered quartz oscillator will use around 100s of loop time-constant, the time constant for the control loop in a caesium clock will be much higher.