## A bitcoin ransom entrepreneur

March 25, 2021 Uncategorized No comments , ,

I call the bluff. Let’s see the video!

Hello!

Unfortunately, I have some bad news for you.
Several months ago, I got access to the device you are using to browse the internet.
Since that time, I have been monitoring your internet activity.

Being a regular visitor of adult websites, I can confirm that it is you who is responsible for this.
To keep it simple, the websites you visited provided me with access to your data.

I've uploaded a Trojan horse on the driver basis that updates its signature several times per day, to make it impossible for antivirus to detect it. Additionally, it gives me access to your camera and microphone.
Moreover, I have backed-up all the data, including photos, social media, chats and contacts.
Just recently, I came up with an awesome idea to create the video where you cum in one part of the screen, while the video was simultaneously playing on another screen. That was fun!

Rest assured that I can easily send this video to all your contacts with a few clicks, and I assume that you would like to prevent this scenario. )

With that in mind, here is my proposal:
Transfer the amount equivalent to 1350 USD to my Bitcoin wallet, and I will forget about the entire thing. I will also delete all data and videos permanently.

In my opinion, this is a somewhat modest price for my work.
You can figure out how to purchase Bitcoins using search engines like Google or Bing, seeing that it's not very difficult.

My Bitcoin wallet (BTC):
1Lg6nE6zFaMZHiPTFR9nSwuAL6hzeegToC

You have 48 hours to reply and you should also bear the following in mind:

It makes no sense to reply me - the address has been generated automatically
It makes no sense to complain either, since the letter along with my Bitcoin wallet cannot be tracked.
Everything has been orchestrated precisely.

If I ever detect that you mentioned anything about this letter to anyone - the video will be immediately shared, and your contacts will be the first to receive it. Following that, the video will be posted on the web!

P.S. The time will start once you open this letter. (This program has a built-in timer and special pixel ID - [№78853473])
Good luck and take it easy! It was just bad luck, next time please be careful.


## Introducing a fixed capacity directory (Linux).

March 23, 2021 Linux No comments , , , ,

I have a dump directory that is too easily filled up (with cores and dumps) if a programming error makes our system misbehave catastrophically.

Here’s a nice trick to create a small filesystem with fixed capacity so that the owning filesystem (in my case /var) can’t be filled up:

dd if=/dev/zero of=dump.loopback bs=1M count=10
mke2fs ./dump.loopback
mount -o loop dump.loopback ./dump
chmod 777 ./dump


## XPG laptop: how to turn off the annoying ‘lock unlock’ screen indicator.

My macbook harddrive appears to be pooched, so I’m using my personal Windows laptop for work until I can get it fixed.  There’s been an annoying feature of this laptop that I hadn’t figured out, but after trying to use it all day, it was well past time.  In particular, if I hit Caps-Lock, I get the following screen indicator:

close to the top left corner of the screen, which often obscures what I am trying to type!  This indicator is extremely stupid.  I know when I hit caps lock: it’s when I hit caps lock, and don’t need something to tell me that I’ve done it.  If I did not know what state it was in, I can look the keyboard caps lock LED.

I found a couple Q&A’s about similar issues:

I tried the Settings configurations, and disabled the toggle stuff, which did not help.  This suggested that there was vendor (XPG) supplied software that was controlling this annoyance.

To track this down, I ran the sysinternals Process Explorer, and searched for xpg:

Sure enough, after brute force killing all these xpg processes, the annoying Lock-Unlock indicator goes away. After a restart, I found that there’s an xpg application running in the background, and sure enough there’s an option to be annoying:

It turns out that there’s also a pop up indicator that occurs if you press Num-Lock. I also won’t miss the XPG application notifications for Num-Lock either — there is also a keyboard LED for that!

## Hardcover physics class notes.

Amazon’s kindle direct publishing invited me to their hardcover trial program, and I’ve now made hardcover versions available of most of my interesting physics notes compilations:

Instead of making hardover versions of my classical mechanics, antenna theory, and electromagnetic theory notes, I have unpublished the paperback versions. These are low quality notes, and I don’t want more people to waste money on them (some have.) The free PDFs of all those notes are still available.

My geometric algebra book is also available in both paperback and hardcover (black and white). I’ve unpublished the color version, as it has a much higher print cost, and I thought it was too confusing to have all the permutations of black-and-white/color and paperback/hardcover.

## Debugging a C coding error from an XPLINK assembly listing.

There are at least two$${}^1$$ z/OS C calling conventions, the traditional “LE” OSLINK calling convention, and the newer$${}^2$$ XPLINK convention.  In the LE calling convention, parameters aren’t passed in registers, but in an array pointed to by R1.  Here’s an example of an OSLINK call to strtof():

*  float strtof(const char *nptr, char **endptr);
LA       r0,ep(,r13,408)
LA       r2,buf(,r13,280)
LA       r4,#wtemp_1(,r13,416)
L        r15,=V(STRTOF)(,r3,4)
LA       r1,#MX_TEMP3(,r13,224)
ST       r4,#MX_TEMP3(,r13,224)
ST       r2,#MX_TEMP3(,r13,228)
ST       r0,#MX_TEMP3(,r13,232)
BASR     r14,r15
LD       f0,#wtemp_1(,r13,416)


R1 is pointed to r13 + 224 (a location on the stack). If the original call was:

float f = strtof( mystring, &err );

The compiler has internally translated it into something of the form:

STRTOF( &f, mystring, &err );

where all of {&f, mystring, &err} are stuffed into the memory starting at the 224(R13) location. Afterwards the value has to be loaded from memory into a floating point register (F0) so that it can be used.  Compare this to a Linux strtof() call:

* char * e = 0;
* float x = strtof( "1.0", &e );
400b74:       mov    $0x400ef8,%edi ; first param is address of "1.0" 400b79: movq$0x0,0x8(%rsp)       ; e = 0;
400b82:       lea    0x8(%rsp),%rsi       ; second param is &e
400b87:       callq  400810 <strtof@plt>  ; call the function, returning a value in %xmm0


Here the input parameters are RDI, RSI, and the output is XMM0. Nice and simple. Since XPLINK was designed for C code, we expect it to be more sensible. Let’s see what an XPLINK call looks like. Here’s a call to fmodf:

*      float r = fmodf( 10.0f, 3.0f );
LD       f0,+CONSTANT_AREA(,r9,184)
LD       f2,+CONSTANT_AREA(,r9,192)
L        r6,=A(__fmodf)(,r7,76)
L        r5,=A(__fmodf)(,r7,72)
BASR     r7,r6
NOP      9
LDR      f2,f0
STE      f2,r(,r4,2144)
*
*      printf( "fmodf: %g\n", (double)r );


There are some curious details that would have to be explored to understand the code above (why f0, f2, and not f0,f1?), however, the short story is that all the input and output values in (floating point) registers.

The mystery that led me to looking at this was a malfunctioning call to strtof:

*      float x = strtof( "1.0q", &e );
LA       r2,e(,r4,2144)
L        r6,=A(strtof)(,r7,4)
L        r5,=A(strtof)(,r7,0)
LA       r1,+CONSTANT_AREA(,r9,20)
BASR     r7,r6
NOP      17
LR       r0,r3
CEFR     f2,r0
STE      f2,x(,r4,2148)
*
*      printf( "strtof: v: %g\n", x );


The CEFR instruction converts an integer to a (hfp32) floating point representation, so we appear to have strtof returning it’s value in R3, which is an integer register. That then gets copied into R0, and finally into F2 (and after that into a stack spill location before the printf call.) I scratched my head about this code for quite a while, trying to figure out if the compiler had some mysterious way to make this work that I wasn’t figuring out. Eventually, I clued in. I’m so used to using a C++ compiler that I forgot about the old style implicit int return for an unprototyped function. But I had included <stdlib.h> in this code, so strtof should have been prototyped? However, the Language Runtime reference specifies that on z/OS you need an additional define to have strtof visible:

#define _ISOC99_SOURCE
#include <stdlib.h>


Without the additional define, the call to strtof() is as if it was prototyped as:

int strtof( const char *, char ** );


My expectation is that with such a correction, the call to strtof() should return it’s value in f0, just like fmodf() does. The result should also not be garbage!

Footnotes:

1.  There is also a “metal” compiler and probably a different calling convention to go with that.  I don’t know how metal differs from XPLINK.
2. Newer in the lifetime of the mainframe means circa 2001, which is bleeding edge given the speed that mainframe development moves.