For some random reasons my blog became quiet recently, but don't worry, it's only temporary. It's time to catch up, and write about this and that.

PHP as a preprocessor not only for HTML
Recently I've seen a discussion developing on a certain Polish forum about mixing different programming languages in application source code - the topic author used (on purpose) a certain simplification (the discussion was about the very basics of programming):

Writing the program source we cannot use instruction from several different languages which are not compatible with each other [...]
Some replies stated 'hey! but you can combine C with assembler, or PHP with HTML' (let's skip the thing that HTML is not a programming language).
After reading the above, a strange idea came to my mind - if you can use PHP with HTML and JS... why not use it with Python, C, assembler, or other languages as well?

Everything circles around a certain PHP feature - the PHP interpreter (in the default running mode) interprets only the code between <?php and ?> tags, thanks to what, we can include PHP in anything, and use it as a powerful preprocessor!

An example of usage looks like this:

// PHP preprocesor test
#include <time.h>
#include <stdlib.h>
#include <stdio.h>

float fast_sin(int deg)
{
 static const float sin_table[] = {
 <?php
   for($i = 0; $i < 359; $i++)
     echo(sin($i) . ", ");
   echo(sin($i));
 ?>
 };

 return sin_table[deg % 360];
}  

int
main(void)
{
 int i;
 srand(time(NULL));
 i = rand();
 printf("Do you know that sin(%i) = %f?\n", i, fast_sin(i));  

 return 0;
}

Compilation and using such a creature looks like this (as one will see, CLI for PHP is required):

$ php my.c | gcc -x c -
$ ./a.out
Do you know that sin(802194582) = 0.994827?
$

A short explanation of gcc options: the -x c option forces gcc to treat input as C language; it is a required parameter if gcc is to read from STDIN (since it cannot check the file extension). The standalone - (dash) tell gcc to read from STDIN, instead of a file.

Is this really useful? In large projects certainly not - using such a hack in large projects is close to being masochistic. Small project on the other hand, especially different kind of hackish-apps, could make use such strange wonders. This might be especially useful for languages which do not have a preprocessor, but one would be useful if it would in fact exist (for example Java).

The opposite of being digitally-paranoid
Everyone that is interested in security is familiar with what people do to make sure they don't forget the password - pieces of paper under the keyboard, sticky notes on the LCD, and in extreme cases there was a story of a guy who has written the PIN to his credit card on the frame of the ATM he used.
And now, a SOHO router manufacturer has entered the marked with a great idea (click to zoom, photo by Samlis Coldwind):



Hah! I'm sure the user will find the default password once he'll try to login! However, it SHOULD force the admin to change the default password at first login. Guess what... Yep.. It didn't. In the above example the shown password had in fact worked...

hosts, malware, and access rights
The other day I wrote, inter alia, about a banker trojan that has worked by adding entries to the C:\Windows\system32\drivers\etc\hosts file (which works like a "local DNS" for the domains it contain).
A certain idea has came to my mind - why don't we revoke the write privileged for that file from all users (well, from admins only, since normal users can't write to it anyway)? A simple command would do that (do not execute it if you don't know what you're doing):

cacls c:\windows\system32\drivers\etc\hosts /g Everyone:R

And thats that. However setting 'Deny Write' for everyone would be even better!

By the way...
On 22nd Nov'24 we're running a webinar called "CVEs of SSH" – it's free, but requires sign up: https://hexarcana.ch/workshops/cves-of-ssh (Dan from HexArcana is the speaker).

Of course, once the malware authors will learn about this trick, they will start to add 'grant write' code to their code, and we're back at the starting point - so it's only a temporary solution, and it will be sufficient as long as no malware writer knows about it (I'm judging that the distance between now and the moment an anti-trick will appear in malware code is inversely proportional to the popularity of my blog - so we still have some time to sleep well ;>)

And thats it for now ;>