DEV Community: Mike 🐈‍⬛

This Windows script isn't a cry for help

Mike 🐈‍⬛ — Fri, 08 Nov 2024 03:20:36 +0000

0< /* ::

@echo off

set /a min = 15
set /a max = 45

:loop

CScript //nologo //E:JScript "%~F0" "+{F15}"
set /a rand = (%RANDOM% * (%max% - %min% + 1) / 32768) + %min% + 1
ping -n %rand% -w 1 127.0.0.1 > NUL

goto :loop

*/ 0;

WScript.CreateObject("WScript.Shell").SendKeys(WScript.Arguments(0));

What does this do?

Take a moment and see if you can figure out what's happening here.

Go on. I'll wait for 15 to 45 seconds, and then send the Shift + F15 key combination.

Why would you do that?

Because the F15 key exists but most keyboards no longer have it, so pressing Shift + F15 is very unlikely to do anything except act as a key combination being pressed in general, preventing the computer from sleeping in most cases (except some VDI setups).

It works without admin rights and on a vanilla Windows install, although some admins disable JScript.

How the f...

0< /* :: is input redirection from a file for file descriptor 0, which is a special case and refers to standard input (STDIN). For example, if you ran 0< test.txt find "hello", the shell would actually run find "hello" 0<test.txt, which would be the equivalent of running find "hello" then typing in the contents of test.txt into the prompt. So what does this do? 0< /* actually produces an error. But when you put a comment command (either :: or REM) at the end, the command becomes :: 0< /* which does nothing as it's a comment. We use :: instead of REM because REM will print out the line to the terminal while :: will not do that, so aesthetically :: is nicer.

So why the /* when any string can go there? Because that's the start of a javascript/jscript block comment and the jscript interpreter needs to not try to parse the batch scripting between the /* and the */. But then how does the jscript interpreter see this chunk of code? It reads the entire block from 0< /* :: to */ 0; as: 0 < 0; which evaluates to false, but that doesn't matter - it's valid jscript and doesn't have any side effects and the primary hurdle has been accomplished: a way to selectively parse batch script or jscript based on which interpreter is reading the file.

I'm going to skip over turning off echo, setting variables, and label looping, as these are fairly simple concepts, although fun fact - ECMAScript also has labels.

The next important line is CScript //nologo //E:JScript "%~F0" "+{F15}", which sends this .bat file to CScript. CScript starts a script in a command-line environment with several script engine choices (JScript in thise case). WScript is similar but runs a script in a Windows GUI and in this context is not completely related to the last line in the batch file. $~F0 is the full path, filename, and extension of the batch file currently running. +{F15} is Shift and the F15 key for SendKeys. To reiterate, when this batch file is sent, it sees the entire batch script as just 0<0; then runs the last line, which is also valid JScript.

The only interesting things about set /a rand = (%RANDOM% * (%max% - %min% + 1) / 32768) + %min% + 1 is that %RANDOM% is a built-in variable that produces an integer from 0 to 32767 (inclusive), using set /a always rounds down, and the last + 1 is specifically for the following line; when using sleep or timeout, you would not add the extra 1.

The next line, ping -n %rand% -w 1 127.0.0.1 > NUL, is an old way to create a timer that's less processor intensive than sleep and timeout. You basically ping yourself %rand% times with 1 second between each attempt; the +1 from the previous line is because there is no wait before the first ping. > NUL redirects the standard output to NUL, which of course just discards it.

If this script didn't have an infinite loop, you'd want to have a goto :eof before */ 0; to make your batch script skip over the remainder of the file that is not valid script.

And we finally get to the end and the actual JScript: WScript.CreateObject("WScript.Shell").SendKeys(WScript.Arguments(0));. JScript is roughly equivalent to JavaScript 1.5/ECMAScript3 and has a WScript API roughly analogous to VBScript.

Wrap up

Probably don't do things this way. But maybe you might want to, and now some of it makes sense.

Naming Things

Mike 🐈‍⬛ — Wed, 18 Sep 2019 23:27:09 +0000

So I was implementing a forEach method and asked my co-worker, "is there a name for a for-loop that iterates backwards? Something like:"

for (let i = myObj.length - 1; i >= 0; i--) { ... }

Of course, there wasn't one. So I set out to create one.

Meet rofEach and the rof loop. It's not only the word "for" backwards, it also means "Reverse Order For".

You're welcome, world. 🎤⬇️

Why are IndexedDB operations significantly slower in Chrome vs Firefox?

Mike 🐈‍⬛ — Tue, 27 Aug 2019 23:10:59 +0000

I was writing a simple key/value promise wrapper around IndexedDB, continuing a project I started a couple of years ago but stopped when LocalForage released, since that does pretty much the same thing. But while running some benchmarks by Nolan Lawson, I noticed a problem. Depending on the operation, Chrome is 2x to 7x slower than Firefox when working with IndexedDB. For a trivial insert (objectStore put() operation), it's a bit more than 2x slower. But more than that and it gets significantly worse.

Running the test code I have has Firefox 68 at 170ms and 2800ms for a single .put() transaction and 10k .put() transactions. Running the same code in Chrome 76 is 430ms and 19,400ms. Yes, that's about 700% slower on Chrome when doing a lot of transactions. In Nolan Lawson's database comparison, you can see that with the LocalForage and PouchDB (non-WebSQL) tests.

This kind of matters because things like LocalForage don't combine many operations into a single transaction, meaning multiple database put/set operations will be a lot slower on Chrome than Firefox. But I'm not sure how often you'll be doing tons of inserts.

Included is some code I wrote that you can paste into your browser's dev tools for a simple benchmark. I tried to isolate the test to just inserting 10,000 objects in one transaction vs inserting 10,000 objects in 10,000 transactions, but there are some other small things going on (e.g. casting number to string, a for loop, a function call, an array access, and an array push()).

So... why? Is it actually just that Chrome is much slower with IndexedDB transactions, or is it something else? Is there ever a reason to do thousands of object inserts into a database all at once?

const testRuns = 10000;

runSingleTX(testRuns)
.then(_=>runManyTX(testRuns));

function runSingleTX(runs) {
    return new Promise(async resolve => {

        const database = await init();

        await clear(database);
        const data = generateData(runs);
        const startTime = Date.now(); // benchmark start

        const transaction = database.transaction(['theStore'], 'readwrite');
        const objStore = transaction.objectStore('theStore');

        for (let i = 0; i < runs; i++) {
            objStore.put(data[i], i+'');
        }

        transaction.oncomplete = async _ => {
            const endTime = Date.now();
            console.log(`${runs} objects inserted in a single transaction: ${endTime-startTime} ms`);

            await clear(database);
            resolve();
        };
    });
}

function runManyTX(runs) {
    return new Promise(async resolve => {
        const database = await init();

        await clear(database);
        const data = generateData(runs);
        const startTime = Date.now(); // benchmark start

        const promises = []

        for (let i = 0; i < runs; i++) {
            promises.push(tx(database, i, data));
        }

        // doesn't matter THAT much, since "readwrite" transactions are basically synchronous
        await Promise.all(promises);

        const endTime = Date.now();
        console.log(`${runs} objects inserted one per transaction: ${endTime-startTime} ms`);

        await clear(database);
        resolve();
    });

    // a transaction for a single .put() operation
    function tx(database, i, data) {
        return new Promise(resolve => {
            const transaction = database.transaction(['theStore'], 'readwrite');
            const objStore = transaction.objectStore('theStore');

            objStore.put(data[i], i+'');

            transaction.oncomplete = _ => resolve();
        });  
    }
}

// utility to generate random data outside of benchmarking
function generateData(size) {
    const data = [];
    for (let i = 0; i < size; i++) {
        data.push(Math.random());
    }
    return data;
}

// utility to clear the database of all entries
function clear(database) {
    return new Promise(resolve => {
        const transaction = database.transaction(['theStore'], 'readwrite');
        const objStore = transaction.objectStore('theStore');

        objStore.clear();

        transaction.oncomplete = _ => resolve();
    });
}

// open/create the database
function init() {
    return new Promise((resolve, reject) => {
        let request = indexedDB.open('theDB', 1);

        // create the db the first time
        request.onupgradeneeded = _ => {
            let transaction = request.result.createObjectStore('theStore').transaction;
            transaction.oncomplete = _ => {
                resolve(request.result);
            };
        }
        request.onsuccess = _ => {
            resolve(request.result);
        };
        request.onerror = _ => reject(request.error);
    });
}

5 differences you might not have noticed between desktop and web UIs

Mike 🐈‍⬛ — Thu, 15 Aug 2019 16:53:30 +0000

If you're developing a desktop app in Electron, NW.js, or a similar tool, it's tempting to just create a "website for the desktop" and leave it at that. But there are a few different UI conventions that you may not have noticed between websites and desktop applications!

The cursor does not change to a pointer (finger) from the default (arrow) on buttons

On websites, if you mouse over actionable elements, your cursor generally turns into a pointer. This includes both hyperlinks and buttons that control the UI. Interestingly, by default when using the <button> tag, the cursor acts just as a desktop UI does and stays an arrow. But when using a stylized <a> or <div> tag that looks like a button, or perhaps by intentionally changing the behavior of a <button>, the cursor changes to pointer.

On desktop applications the pointer is used exclusively for hyperlinks and not for the UI actions. For example, your desktop browser's bookmarks and buttons don't change your cursor into the finger pointer, it stays as the default arrow. Chrome's Dev Tools actually has inconsistent behavior for this - the Elements, Console, Sources, Network, etc tabs use a pointer cursor like a browser, but if you're in the Elements tab and select an element, the second set of tabs for Styles, Event Listeners, DOM Breakpoints, Properties, etc follow the desktop convention of leaving your cursor as the default arrow.

You can't highlight/select/copy any text

On websites, mousing over any non-link will generally give you the text-selection (caret) cursor and allow you to select and copy that text.

On desktop applications, you are generally not allowed to select text nor does your cursor change; text that is supposed to be selectable generally resides in a text field.

You can't select nor drag images

On websites, you can select and copy an image, or straight up drag the image around. An easy way to save an image, for example, is to just drag it from a site directly to your desktop.

On desktop applications, images are handled like text; you can't interact with them.

Right clicking is a thing that people do on the desktop

The right-click context menu may need to be handled in a desktop application, either by disabling right-click in most contexts or populating it with sensible actions. For example, Electron by default doesn't do anything when right-clicking, while right-clicking a text field should allow you to cut/copy/paste/undo/select-all.

Be sure to catch random hotkeys that shouldn't work on desktop

Does ctrl+r do something in your app that it shouldn't on a desktop? How about ctrl+-/+? Does ctrl+w kill your program when it shouldn't on the desktop? Refreshing and zooming might be allowable behavior, but it also might not be, depending on your app.

Horizontally and Vertically Centering in CSS

Mike 🐈‍⬛ — Tue, 09 Jul 2019 19:44:59 +0000

If you're anything like me, vertically and horizontally centering an HTML element has been the bane of your existence at some point in your career.

Luckily, this solution works in every browser, even IE 11:

display: flex;
justify-content: center;
align-items: center;

justify-content is for horizontal alignment by default. Removing it or setting justify-content: flex-start; places the child element on the left. Setting justify-content: flex-end; places the child element on the right.

align-items is for vertical alignment by default. Removing it or setting align-items: flex-start; places the child element at the top. Setting align-items: flex-end; places the child element at the bottom.

Here's an example.

You can probably stop using padding, absolute left/right and top/bottom positioning, float, line-height, transform, and any other tricks :)

Creating a native executable in Windows with GraalVM

Mike 🐈‍⬛ — Wed, 12 Jun 2019 00:33:00 +0000

GraalVM is pretty awesome for a lot of reasons. But the one that has me most hyped is the ability to create native executables from Java bytecode. This isn't like ExcelsiorJET (R.I.P.), which makes you include a large runtime, nor is it like Launch4J and Oracle's javapackager tool, both of which create a dummy executables that points to your .jar and a packaged JRE.

GraalVM makes real native executables without a packaged runtime.

Unfortunately, GraalVM's native-image, and indeed its entire support for Windows, is in early adopter status. There are some error messages that aren't accurate, some bugs, and some features missing.

But it does work, more-or-less.

Things to know before you get started

There's about a 8.5 MB minimum file size for a bare bones hello world java application. That's kind of a lot, but also a lot less than including the entire JRE.

Some other articles or guides recommend installing Git for Windows and Python 2.7, but I'm like 99% sure that's for building GraalVM before running.

All the Swing and JavaFX applications I've tried haven't been able to build in the Windows version of native-image in 19.0.0.

The Image Generation Options page is a good resource for troubleshooting, you may have to place some of your classes into the --initialize-at-run-time=<comma separated list of class/package names> option.

Steps to run GraalVM 19.0.0's `native-image` in Windows

Uninstall any Visual C++ 2010 Redistributables
Get the Windows version of GraalVM 19.0.0: https://github.com/oracle/graal/releases/tag/vm-19.0.0
Extract it somewhere easy to find
Get the Microsoft Windows SDK for Windows 7 and .NET Framework 4 (ISO): https://www.microsoft.com/en-us/download/details.aspx?id=8442
Mount the image, open F:\Setup\SDKSetup.exe directly
A default install should be perfect
Run the Windows SDK 7.1 Command Prompt by going to Start > Microsoft Windows SDK v7.1 > Windows SDK 7.1 Command Prompt
Run one of these commands based on if you have a .jar or a .class:

\path\to\graalvm-ce-19.0.0\bin\native-image -jar \path\to\helloworld.jar --no-fallback

\path\to\graalvm-ce-19.0.0\bin\native-image \path\to\helloworld.class --no-fallback

The *.exp, *.lib, and *.pdb files seem to be artifacts of the build process, they're not required for distribution.

But that's it, your .exe is made!

Update: As of GraalVM 19.3.0, still no support for Swing nor JavaFX.

For GraalVM 19.3.0 on Windows with the new support for Java 11, you'll need Visual Studio 2017 Community Edition instead of the Microsoft Windows SDK for Windows 7, which you can get here with a free Visual Studio Dev Essentials account. Instead of running the Windows SDK 7.1 Command Prompt, you'll of course run x64 Native Tools Command Prompt for VS 2017 as your command line in Start > Visual Studio 2017.

Gluon is working on providing JavaFX support for 19.3.0 - it already has it for macOS and Linux, and Windows should be coming soon.

Finally, if you do distribute an exe made with native-image on windows, you will need to include vcruntime140.dll with it, which is about 84kb.

Sending data through Mixed Content filters

Mike 🐈‍⬛ — Sat, 08 Jun 2019 16:50:40 +0000

tl;dr / bottom line up front

Using overt steganography (phanerography?), you can retrieve data on a cooperative HTTP server from an HTTPS hosted site while only triggering Mixed Passive/Display Content warnings on the browser.

But why tho?

The most basic use case is including data from a server on the local network in a page hosted on the Internet via HTTPS. Local servers have trouble getting CA-issued HTTPS certificates because HTTPS certificates require a domain name, and local servers generally don't have one. But there still might be a use case for including data from a local server on a site hosted on the Internet, perhaps a configuration page for IoT devices.

If you load non-secure data on an HTTPS page, one of two things could happen. If your content is in an <img>, <audio>, <video>, or some <object> tags, it will be loaded as Mixed Passive/Display Content. This means the site will lose its lock icon and the console will throw warnings about mixed content, but otherwise the site will work. However, if your content is loaded in any other way (<script>, <iframe>, XMLHttpRequest, etc) your unsecure content will fail to load as it'll be considered Mixed Active Content.

Most IoT devices or other network appliances simply forgo HTTPS. Plex has another solution, but it costs $5k-$10k USD per year. This article covers an alternative to those.

Binary data transmission via portable network graphics

Out of images, audio, and video, images are the easiest to programmatically create and have the lowest overhead. And of the more-or-less universally supported image formats, PNGs are ideal in that they have a grayscale mode where one byte is one pixel, they include gzip compression, they have a very low overhead, and they are not lossy.

The overhead is a constant 66 bytes for up to 2 gigabytes of data, which means even without compression (which you could apply to both), it'll be more efficient than base64 for transmitting binary data bigger than about 200 bytes, at the cost of some cpu cycles.

The server (Kotlin/JVM)

Let's start with the server. The server must receive all requests as an HTTP GET request and so all options have to be in a query string or param string. How to do that is outside the scope of this article, but it's super easy.

After it receives a request, it has to transform some data into a PNG, then return that to the requester.

This manually creates a PNG file from a string - it could have been an array of bytes, but I wrote it as a string for this example. The output PNG is a single row with a width equal to the size of the input data and each pixel represents a byte in greyscale. The cover image for this article is "Hello World" run through this, but blown up a bunch so it's visible.

Note: *arrayName is not a pointer, it's the Kotlin spread operator.

fun makePNG(data: String): ByteArray {
    val dataAsByteArray = data.toByteArray(Charsets.UTF_8) // string (utf8) as a byte array

    return (pngSignature() +
            pngIHDR(dataAsByteArray.size,1) +
            pngIDAT(dataAsByteArray) +
            pngIEND())
}

// PNG Signature - https://www.w3.org/TR/PNG/#5PNG-file-signature
fun pngSignature(): ByteArray {
    return byteArrayOf(-119,80,78,71,13,10,26,10)
}

// PNG IHDR chunk - https://www.w3.org/TR/PNG/#11IHDR
fun pngIHDR(width: Int, height: Int): ByteArray {
    val ihdrLength = byteArrayOf(0,0,0,13)
    val ihdrType = byteArrayOf(73,72,68,82)
    val ihdrData = byteArrayOf(
        *intToBA(width), // width
        *intToBA(height), // height
        8, // bitdepth - 8 so each pixel is a byte
        0, // color type - 0 is greyscale
        0,0,0 // compression, filter, and interlace methods - must be 0
    )
    val ihdrCRC = getCRC(ihdrType, ihdrData)

    return (ihdrLength +
            ihdrType +
            ihdrData +
            ihdrCRC)
}

// PNG IDAT chunk - https://www.w3.org/TR/PNG/#11IDAT
fun pngIDAT(data: ByteArray): ByteArray {
    val idatType = byteArrayOf(73,68,65,84)

    val idatData = deflate(byteArrayOf(0, *data)) // filter type 0 (no filter)

    val idatCRC = getCRC(idatType, idatData)

    val idatLength = intToBA(idatData.size) // compressed data length

    return (idatLength +
            idatType +
            idatData +
            idatCRC)
}

// PNG IEND chunk - https://www.w3.org/TR/PNG/#11IEND
fun pngIEND(): ByteArray {
    return byteArrayOf(0,0,0,0,73,69,78,68,-82,66,96,-126)
}

I know that was a lot, but out of all the code above, probably 95% of it is boilerplate to create a basic PNG. The IHDR is interesting, but only because it uses bitdepth 8 and color type 0 to allow exactly 1 byte per pixel. The rest of the chunks aren't anything special unless you're interested in the PNG file format and implementing it in the JVM.

The convenience functions getCRC(), intToBA(), and deflate() create a CRC using Java's CRC library, convert an integer into a byte array, and DEFLATE data using Java's Deflater library, respectively. They're included in the full server code.

The site (javascript)

The website hosted on HTTPS needs to solve two problems, the first is to send data along with the request to an HTTP server and then get that data.

It sends data via a query string because of course the data communication has to go through an <img> tag. This limits the request data to 1KB according to most browser restrictions.

The second problem is getting the data. The server solves the problem by sending a png that essentially wraps and DEFLATEs the data, but now the browser has to make some sense of it. It does so by drawing the img onto a <canvas> element, then reading each pixel's red value (red, green, and blue are all the same in a greyscale image) and pushing that into an array:

function pngGet(url, fn) {
    const canvas = document.createElement('canvas')
    const ctx = canvas.getContext('2d')
    const img = new Image()
    img.crossOrigin = 'anonymous'
    img.onload = function() {
        canvas.width = img.width
        canvas.height = img.height
        ctx.drawImage(img, 0, 0)

        const utf8 = []
        for (let x = 0; x < img.width; x++) {
            const byte = ctx.getImageData(x, 0, 1, 1).data[0]
            utf8.push(byte)
        }
        fn(stringFromUTF8Array(utf8), img)
    }
    img.src = url
}

This could be improved by cleaning up the <canvas> and <img> elements this creates in the DOM, but in this example it's actually outputting it for the user to see. There are also some optimizations both here and in the server code that could be done (e.g. pre-allocating the utf8 array's length).

The stringFromUTF8Array() function used above was written by Ed Wynne. I didn't modify it at all for this example. Of course if you wanted to transfer binary data, you wouldn't need to translate the byte array into a string.

A huge caveat with this implementation

The provided code only allows the creation of a 2,147,483,647 pixel wide PNG file with a single row, which has a problem... while it's technically allowed by the PNG spec, programs like Photoshop only allow 300,000 x 300,000 pixel images while Chrome and Firefox have a max <canvas> width of 32,767 pixels. So even if more rows than one were implemented, it'd only allow about 1 gigabyte per PNG. It shouldn't be a difficult fix, but this is only a proof of concept so it wasn't implemented in the code.

Regaining confidentiality and data integrity

The major problem with this is that it lacks confidentiality and data integrity. In other words, people sniffing your network traffic via unsecured Wi-Fi or Man-In-The-Middle can theoretically read and/or change the image containing your data. This is a problem with all Mixed Passive/Display Content.

One way to solve this is to roll your own encryption/decryption via something like asmCrypto.js or the Stanford JS Crypto Library. You can then encrypt the response data via the normal Java crypto libraries and decrypt the response after reading the bytes from the <canvas>. You'd have to pass the key in a side channel, with both the HTTPS site/server and HTTP server talking to a HTTPS server to post the key in a database. That HTTPS server+db could also be hosting the HTTPS website.

Closing remarks

In the future browsers may throw more blatant warnings for Mixed Passive/Display Content, or they may start treating such content as Mixed Active Content and just block it outright. Essentially, this is a work-around that may not exist forever. We at GameGlass have decided against implementing it in production for that reason.

This may have applications in sending large amounts of data because it's a bit better than base64, but why not just send the binary directly instead of wrapping it in a .png?

This may also have an application in exfiltrating data from a compromised machine, but I can't think of any situation in which this would be the preferred solution over any of the more established methods, including just sending the binary data.

This could be used for obfuscating a payload I guess, but that'd last about as long as it takes for someone to read this article.

But even if it's not super useful nor that ground breaking, I think it's pretty neat. Thanks to Ron Karroll and the rest of the guys at GameGlass for letting me bounce ideas off their heads!