# Tuning Keyboard 4 (369pts)

## Introduction
1. Just a `flag.html`
2. Bunch of useless description
3. Same as last year, some trolls and moving thingy inside the HTML
4. Unlike last year, nothing related with "Keyboard"

## Analysis
Don't you think the aesthetic is so weird? Those changing colors and the pinky background? (oh it's `salmon`, btw do you know salmon isn't pink but `grey` originally?)

(Let me call this "*the moving thing*")

Well, there are only 2 things changing:
1. The position and the rotation of *the moving thing*
a. The position is governed by the `marquee`, no data there, seems random.
b. Angles are discrete integers, could contain data.
2. The color values of each "leaves" of *the moving thing*
a. It uses `HSL` value and lots of random numbers
b. Entropy so high, could contain information

## Solve
How can we commonly represent colors in hex? **RGB!**

Let's try using some online `HSL` to `RGB` converter [like this one](https://www.rapidtables.com/convert/color/hsl-to-rgb.html).
**...And heck, it needs `deg` not `rad` :(**

Let's convert everthing to `deg`:

data='''hsl(4.81261614rad,24.32539791%,36.53413226%);
hsl(3.90699199rad,11.49869364%,34.99557365%);
hsl(0.03878509rad,16.26506004%,32.54902%)
hsl(0.16534689rad,9.7938134%,38.03921569%);
hsl(3.77025878rad,43.64416333%,33.38033344%);
hsl(0.57110573rad,40.23668521%,33.1372549%)
hsl(5.14303676rad,23.77437585%,24.4372566%);
hsl(5.22510196rad,22.22735981%,24.95963139%);
hsl(2.9536028rad,24.8063338%,34.6816857%)
hsl(0.49018897rad,31.99041655%,31.42579079%);
hsl(5.68813836rad,24.64731433%,38.5401126%);
hsl(0.0rad,14.78873099%,27.84313725%)'''

for line in data.split("\n"):
	H = line[line.find("hsl(")+4:line.find("rad")]
	line = line[len(H)+8:]
	S = line[0:line.find("%")]
	line = line[len(S)+2:]
	L = line[0:line.find(");")-1]

	H = float(H)*360/(2*3.141592653584)
	print(H, S, L)

For each value, convert to RGB hex:

'''
hsl(4.81261614rad,24.32539791%,36.53413226%);
hsl(3.90699199rad,11.49869364%,34.99557365%);
hsl(0.03878509rad,16.26506004%,32.54902%)
= 614774 4F5463 614746

hsl(0.16534689rad,9.7938134%,38.03921569%);
hsl(3.77025878rad,43.64416333%,33.38033344%);
hsl(0.57110573rad,40.23668521%,33.1372549%)
= 6A5A58 304E7A 765833


hsl(5.14303676rad,23.77437585%,24.4372566%);
hsl(5.22510196rad,22.22735981%,24.95963139%);
hsl(2.9536028rad,24.8063338%,34.6816857%)
= 4A304D 4D314E 426E66

hsl(0.49018897rad,31.99041655%,31.42579079%);
hsl(5.68813836rad,24.64731433%,38.5401126%);
hsl(0.0rad,14.78873099%,27.84313725%)
= 6A4E37 7A4A66 513D3D

Seems all hex are in ASCII range, eh? Notice the end of the hex `513D3D`, seems resemble to base64's `==` padding, but trying to convert these hex to `ascii` then to `base64` fails.

It turns out that the correct sequence is `1st val of 1st line` + `1st val of 2nd line` + `1st val of 3rd line` + `2nd value of 1st line` and so on, kind of like a vertical zig-zag pattern instead.

So the resulting hex is:

6147746A5A584A304D6A4E374F5463304E7A4D314E7A4A66614746765833426E66513D3D

Result in ASCII:
`aGtjZXJ0MjN7OTc0NzM1NzJfaGFvX3BnfQ==`

And the decode this base64 for flag:
`hkcert23{97473572_hao_pg}`

And now I can stop looking at *the damn thing* anymore.