How can I join two bytes to make an 16-bit int variable in BASCOM-AVR?
PARTIAL ANSWER:
Subquestion 1
If one byte is stored in the variable BYTE1 and the other is stored in the variable BYTE2, you can merge them into WORD1 in many BASICS with WORD1 = BYTE1: WORD1 = (WORD1 SHL 8) OR BYTE2. This makes BYTE1 into the high-order bits of WORD1, and BYTE2 into the low-order bits.
Subquestion 2
If you want to mask (or select) specific bits of a word, use the AND operator, summing up the bit values of the bits of interest - for example, if you want to select the first and third bits (counting the first bit as the LSB of the word) of the variable FLAGS, you would look at the value of FLAGS AND 5 - 5 is binary 0000000000000101, so you are guaranteeing that all bits in the result will be 0 except for the first and third, which will carry whatever value they are showing in FLAGS (this is 'bitwise AND').
Function to shift-left/right binary:
Byte1# = 255
PRINT HEX$(Byte1#)
Byte1# = SHL(Byte1#, 8) ' shift-left 8 bits
PRINT HEX$(Byte1#)
END
' function to shift-left binary bits
FUNCTION SHL (V#, X)
SHL = V# * 2 ^ X
END FUNCTION
' function to shift-right binary bits
FUNCTION SHR (V#, X)
SHR = V# / 2 ^ X
END FUNCTION
You can find this in BASCOM index:
varn = MAKEINT(LSB , MSB)
The equivalent code is:
varn = (256 * MSB) + LSB
Varn: Variable that will be assigned with the converted value.
LSB: Variable or constant with the LS Byte.
MSB: Variable or constant with the MS Byte.
For example:
varn = MAKEINT(&B00100010,&B11101101)
The result is &B1110110100100010.
I've recently found some lua code and what I found inside was some obfuscated string. That made me wonder what sort of obfuscation technique was used there. Does anybody have an idea?
240.06230.0575240.06240.06270.0675250.0625265.06625270.0675250.0625285.07125260.065260.065260.065250.0625265...
https://pastebin.com/raw/7RkxjWQw
If this string is splitted into xxx.yyyy... chunks (exactly three digits before decimal point), then multiply each number by 800/4001 (the results will be integer!), then convert these integer numbers to ASCII, the hidden sequence of 16 floating point numbers would be revealed:
0.0062562944425795
0.036286507766961
0.02127140110477
0.047547837763604
0.041291543321025
0.0025025177770318
0.011261329996643
0.018768883327738
0.017517624439223
0.042542802209541
0.037537766655477
0.016266365550707
0.0087588122196113
0.057557908871731
0.025025177770318
0.026276436658834
Is the puzzle stops here?
Or should we try to decipher it further?
Ok, we could multiply them all by 32767/41 (the results will be integer!)
5
29
17
38
33
2
9
15
14
34
30
13
7
46
20
21
Hmm, the puzzle seems to be really interesting...
Is it the end?
Just googled it.
That's the passwords encrypted, something Roblox-related
So, OP surely doesn't have decoder script :-)
Ok, finally did it.
function decode_password(encoded_password)
local result = ""
local buffer = ""
for x in encoded_password:gsub("%d%d%d%.", "\0%0"):gmatch"%Z+" do
x = math.floor(tonumber(x) / 5.00125 + 0.5)
if x ~= 95 then
buffer = buffer..string.char(x)
elseif buffer ~= "" then
x = math.floor(tonumber(buffer) * 799.195122 + 0.5)
result = result..("qazwsxedcrfjmik,o0 23456-=\\vtgbyhnul.p;;;/[']1789"):sub(x, x)
buffer = ""
end
end
return result
end
Example 1:
local p = '240.06230.0575240.06240.06270.0675250.0625265.06625270.0675250.0625285.07125260.065260.065260.065250.0625265.06625275.06875285.07125265.06625475.11875240.06230.0575240.06255.06375270.0675250.0625280.07270.0675265.06625240.06275.06875275.06875270.0675270.0675285.07125270.0675245.06125475.11875240.06230.0575240.06250.0625245.06125250.0625275.06875245.06125260.065240.06245.06125245.06125240.06260.065275.06875275.06875475.11875240.06230.0575240.06260.065275.06875265.06625260.065275.06875280.07255.06375275.06875275.06875270.0675255.06375270.0675240.06260.065475.11875240.06230.0575240.06260.065245.06125250.0625285.07125245.06125265.06625260.065255.06375255.06375250.0625245.06125240.06250.0625265.06625475.11875240.06230.0575240.06240.06250.0625265.06625240.06250.0625265.06625245.06125275.06875275.06875275.06875275.06875240.06255.06375245.06125280.07475.11875240.06230.0575240.06245.06125245.06125250.0625270.0675245.06125255.06375250.0625285.07125285.07125285.07125270.0675270.0675260.065255.06375475.11875240.06230.0575240.06245.06125280.07275.06875270.0675280.07280.07280.07255.06375255.06375250.0625275.06875275.06875255.06375280.07475.11875240.06230.0575240.06245.06125275.06875265.06625245.06125275.06875270.0675250.0625260.065260.065255.06375285.07125250.0625250.0625255.06375475.11875240.06230.0575240.06260.065250.0625265.06625260.065250.0625280.07240.06250.0625250.0625240.06285.07125265.06625260.065245.06125475.11875240.06230.0575240.06255.06375275.06875265.06625255.06375275.06875275.06875270.0675270.0675270.0675265.06625265.06625260.065275.06875275.06875475.11875240.06230.0575240.06245.06125270.0675250.0625270.0675270.0675255.06375270.0675265.06625265.06625265.06625240.06275.06875240.06275.06875475.11875240.06230.0575240.06240.06280.07275.06875265.06625280.07280.07245.06125250.0625250.0625245.06125285.07125270.0675245.06125245.06125255.06375475.11875240.06230.0575240.06265.06625275.06875265.06625265.06625275.06875285.07125240.06280.07280.07275.06875245.06125275.06875255.06375245.06125475.11875240.06230.0575240.06250.0625265.06625240.06250.0625265.06625245.06125275.06875275.06875275.06875275.06875240.06255.06375245.06125280.07475.11875240.06230.0575240.06250.0625270.0675250.0625275.06875270.0675260.065255.06375270.0675270.0675265.06625280.07280.07255.06375260.065475.11875'
print(decode_password(p)) --> stophackingme123
Example 2:
for _, info in ipairs(loginDatabase) do
print(info.username, decode_password(info.password))
end
I have a question about block cipher using CTR mode. I think i need to find something (value) that when I do 46 XOR value = 43, I get value to be (1011 1101), then i use 0x64(0110 0100) XOR value(1011 1101) but it does not give me 0x72(0111 0010). Did I miss something here? My upstanding is that in order to do this, all i need to do is to find a value that adds counter (in this case is zero) and xor the plain text to get cipher text. Did I miss something here? Thank you in advance.
You know that the 2nd and 3rd block were created by the same key stream (created by concatenating the counter values encrypted by the block cipher).
So for the first byte of the second block you'd have 46 = 43 ^ KK and 51 = P2 ^ KK where KK is the first byte of the key stream. Now KK can be easily calculated, as KK = 46 ^ 43 (KK = 05 if I'm not mistaken). Now P2 = KK ^ 51 or P2 = 05 ^ 51 = 54.
You can simply repeat that for each index into the streams and presto. You don't have to do anything with the counter itself; knowing that the same key and counter were used is enough to generate the same key stream.
Im working on an algorithm to break a modified Vigenere Cipher. The regular Vigenere cipher works in the following way:
Plaintext: ATTACKATDAWN
Key: LEMONLEMONLE
Ciphertext: LXFOPVEFRNHR
Regular Version
CR[i] = (P[i] - 33 + K[i]) mod 94 + 33
Modified Version
CM[i] = (P[i] - 33 + K[i] + CM[i-1] - 33) mod 94 + 33
Notice how the modified version uses previous state/character to generate the new one. My theory to break it is to reverse the modified version back to the regular Vigenere cipher. This way I can apply some frequency analysis and other methods. I need to somehow rearrange that equation such that I have "previousC" on the LHS with C. Since both C and previousC are known values it should be easy to do the reversal (starting with the first character).
My only problem is, how do I rewrite the equation in terms of C and previousC? If someone could point that out that would help a lot.
CR represents the regular Viginere ciphertext, CM the modified Viginere ciphertext
CR[i] = (P[i] + K[i]) mod 26
CM[i] = (P[i] + K[i] + CM[i-1]) mod 26
= (CR[i] + CM[i-1]) mod 26
Now simply solve for the original ciphertext CR
CR[i] = (CM[i] - CM[i-1]) mod 26
Once you have the regular ciphertext, break it as usual.
After reading the base64 wiki ...
I'm trying to figure out how's the formula working :
Given a string with length of n , the base64 length will be
Which is : 4*Math.Ceiling(((double)s.Length/3)))
I already know that base64 length must be %4==0 to allow the decoder know what was the original text length.
The max number of padding for a sequence can be = or ==.
wiki :The number of output bytes per input byte is approximately 4 / 3 (33%
overhead)
Question:
How does the information above settle with the output length ?
Each character is used to represent 6 bits (log2(64) = 6).
Therefore 4 chars are used to represent 4 * 6 = 24 bits = 3 bytes.
So you need 4*(n/3) chars to represent n bytes, and this needs to be rounded up to a multiple of 4.
The number of unused padding chars resulting from the rounding up to a multiple of 4 will obviously be 0, 1, 2 or 3.
4 * n / 3 gives unpadded length.
And round up to the nearest multiple of 4 for padding, and as 4 is a power of 2 can use bitwise logical operations.
((4 * n / 3) + 3) & ~3
For reference, the Base64 encoder's length formula is as follows:
As you said, a Base64 encoder given n bytes of data will produce a string of 4n/3 Base64 characters. Put another way, every 3 bytes of data will result in 4 Base64 characters. EDIT: A comment correctly points out that my previous graphic did not account for padding; the correct formula for padding is 4(Ceiling(n/3)).
The Wikipedia article shows exactly how the ASCII string Man encoded into the Base64 string TWFu in its example. The input string is 3 bytes, or 24 bits, in size, so the formula correctly predicts the output will be 4 bytes (or 32 bits) long: TWFu. The process encodes every 6 bits of data into one of the 64 Base64 characters, so the 24-bit input divided by 6 results in 4 Base64 characters.
You ask in a comment what the size of encoding 123456 would be. Keeping in mind that every every character of that string is 1 byte, or 8 bits, in size (assuming ASCII/UTF8 encoding), we are encoding 6 bytes, or 48 bits, of data. According to the equation, we expect the output length to be (6 bytes / 3 bytes) * 4 characters = 8 characters.
Putting 123456 into a Base64 encoder creates MTIzNDU2, which is 8 characters long, just as we expected.
Integers
Generally we don't want to use doubles because we don't want to use the floating point ops, rounding errors etc. They are just not necessary.
For this it is a good idea to remember how to perform the ceiling division: ceil(x / y) in doubles can be written as (x + y - 1) / y (while avoiding negative numbers, but beware of overflow).
Readable
If you go for readability you can of course also program it like this (example in Java, for C you could use macro's, of course):
public static int ceilDiv(int x, int y) {
return (x + y - 1) / y;
}
public static int paddedBase64(int n) {
int blocks = ceilDiv(n, 3);
return blocks * 4;
}
public static int unpaddedBase64(int n) {
int bits = 8 * n;
return ceilDiv(bits, 6);
}
// test only
public static void main(String[] args) {
for (int n = 0; n < 21; n++) {
System.out.println("Base 64 padded: " + paddedBase64(n));
System.out.println("Base 64 unpadded: " + unpaddedBase64(n));
}
}
Inlined
Padded
We know that we need 4 characters blocks at the time for each 3 bytes (or less). So then the formula becomes (for x = n and y = 3):
blocks = (bytes + 3 - 1) / 3
chars = blocks * 4
or combined:
chars = ((bytes + 3 - 1) / 3) * 4
your compiler will optimize out the 3 - 1, so just leave it like this to maintain readability.
Unpadded
Less common is the unpadded variant, for this we remember that each we need a character for each 6 bits, rounded up:
bits = bytes * 8
chars = (bits + 6 - 1) / 6
or combined:
chars = (bytes * 8 + 6 - 1) / 6
we can however still divide by two (if we want to):
chars = (bytes * 4 + 3 - 1) / 3
Unreadable
In case you don't trust your compiler to do the final optimizations for you (or if you want to confuse your colleagues):
Padded
((n + 2) / 3) << 2
Unpadded
((n << 2) | 2) / 3
So there we are, two logical ways of calculation, and we don't need any branches, bit-ops or modulo ops - unless we really want to.
Notes:
Obviously you may need to add 1 to the calculations to include a null termination byte.
For Mime you may need to take care of possible line termination characters and such (look for other answers for that).
(In an attempt to give a succinct yet complete derivation.)
Every input byte has 8 bits, so for n input bytes we get:
n × 8 input bits
Every 6 bits is an output byte, so:
ceil(n × 8 / 6) = ceil(n × 4 / 3) output bytes
This is without padding.
With padding, we round that up to multiple-of-four output bytes:
ceil(ceil(n × 4 / 3) / 4) × 4 = ceil(n × 4 / 3 / 4) × 4 = ceil(n / 3) × 4 output bytes
See Nested Divisions (Wikipedia) for the first equivalence.
Using integer arithmetics, ceil(n / m) can be calculated as (n + m – 1) div m,
hence we get:
(n * 4 + 2) div 3 without padding
(n + 2) div 3 * 4 with padding
For illustration:
n with padding (n + 2) div 3 * 4 without padding (n * 4 + 2) div 3
------------------------------------------------------------------------------
0 0 0
1 AA== 4 AA 2
2 AAA= 4 AAA 3
3 AAAA 4 AAAA 4
4 AAAAAA== 8 AAAAAA 6
5 AAAAAAA= 8 AAAAAAA 7
6 AAAAAAAA 8 AAAAAAAA 8
7 AAAAAAAAAA== 12 AAAAAAAAAA 10
8 AAAAAAAAAAA= 12 AAAAAAAAAAA 11
9 AAAAAAAAAAAA 12 AAAAAAAAAAAA 12
10 AAAAAAAAAAAAAA== 16 AAAAAAAAAAAAAA 14
11 AAAAAAAAAAAAAAA= 16 AAAAAAAAAAAAAAA 15
12 AAAAAAAAAAAAAAAA 16 AAAAAAAAAAAAAAAA 16
Finally, in the case of MIME Base64 encoding, two additional bytes (CR LF) are needed per every 76 output bytes, rounded up or down depending on whether a terminating newline is required.
Here is a function to calculate the original size of an encoded Base 64 file as a String in KB:
private Double calcBase64SizeInKBytes(String base64String) {
Double result = -1.0;
if(StringUtils.isNotEmpty(base64String)) {
Integer padding = 0;
if(base64String.endsWith("==")) {
padding = 2;
}
else {
if (base64String.endsWith("=")) padding = 1;
}
result = (Math.ceil(base64String.length() / 4) * 3 ) - padding;
}
return result / 1000;
}
I think the given answers miss the point of the original question, which is how much space needs to be allocated to fit the base64 encoding for a given binary string of length n bytes.
The answer is (floor(n / 3) + 1) * 4 + 1
This includes padding and a terminating null character. You may not need the floor call if you are doing integer arithmetic.
Including padding, a base64 string requires four bytes for every three-byte chunk of the original string, including any partial chunks. One or two bytes extra at the end of the string will still get converted to four bytes in the base64 string when padding is added. Unless you have a very specific use, it is best to add the padding, usually an equals character. I added an extra byte for a null character in C, because ASCII strings without this are a little dangerous and you'd need to carry the string length separately.
For all people who speak C, take a look at these two macros:
// calculate the size of 'output' buffer required for a 'input' buffer of length x during Base64 encoding operation
#define B64ENCODE_OUT_SAFESIZE(x) ((((x) + 3 - 1)/3) * 4 + 1)
// calculate the size of 'output' buffer required for a 'input' buffer of length x during Base64 decoding operation
#define B64DECODE_OUT_SAFESIZE(x) (((x)*3)/4)
Taken from here.
While everyone else is debating algebraic formulas, I'd rather just use BASE64 itself to tell me:
$ echo "Including padding, a base64 string requires four bytes for every three-byte chunk of the original string, including any partial chunks. One or two bytes extra at the end of the string will still get converted to four bytes in the base64 string when padding is added. Unless you have a very specific use, it is best to add the padding, usually an equals character. I added an extra byte for a null character in C, because ASCII strings without this are a little dangerous and you'd need to carry the string length separately."| wc -c
525
$ echo "Including padding, a base64 string requires four bytes for every three-byte chunk of the original string, including any partial chunks. One or two bytes extra at the end of the string will still get converted to four bytes in the base64 string when padding is added. Unless you have a very specific use, it is best to add the padding, usually an equals character. I added an extra byte for a null character in C, because ASCII strings without this are a little dangerous and you'd need to carry the string length separately." | base64 | wc -c
710
So it seems the formula of 3 bytes being represented by 4 base64 characters seems correct.
I don't see the simplified formula in other responses. The logic is covered but I wanted a most basic form for my embedded use:
Unpadded = ((4 * n) + 2) / 3
Padded = 4 * ((n + 2) / 3)
NOTE: When calculating the unpadded count we round up the integer division i.e. add Divisor-1 which is +2 in this case
Seems to me that the right formula should be:
n64 = 4 * (n / 3) + (n % 3 != 0 ? 4 : 0)
I believe that this one is an exact answer if n%3 not zero, no ?
(n + 3-n%3)
4 * ---------
3
Mathematica version :
SizeB64[n_] := If[Mod[n, 3] == 0, 4 n/3, 4 (n + 3 - Mod[n, 3])/3]
Have fun
GI
Simple implementantion in javascript
function sizeOfBase64String(base64String) {
if (!base64String) return 0;
const padding = (base64String.match(/(=*)$/) || [])[1].length;
return 4 * Math.ceil((base64String.length / 3)) - padding;
}
If there is someone interested in achieve the #Pedro Silva solution in JS, I just ported this same solution for it:
const getBase64Size = (base64) => {
let padding = base64.length
? getBase64Padding(base64)
: 0
return ((Math.ceil(base64.length / 4) * 3 ) - padding) / 1000
}
const getBase64Padding = (base64) => {
return endsWith(base64, '==')
? 2
: 1
}
const endsWith = (str, end) => {
let charsFromEnd = end.length
let extractedEnd = str.slice(-charsFromEnd)
return extractedEnd === end
}
In windows - I wanted to estimate size of mime64 sized buffer, but all precise calculation formula's did not work for me - finally I've ended up with approximate formula like this:
Mine64 string allocation size (approximate)
= (((4 * ((binary buffer size) + 1)) / 3) + 1)
So last +1 - it's used for ascii-zero - last character needs to allocated to store zero ending - but why "binary buffer size" is + 1 - I suspect that there is some mime64 termination character ? Or may be this is some alignment issue.