11
It's a big-endian CRC16 (polynomial 0x8005) of the data from the byte following the 0x82 up to and including the byte before the CRC.
For example, for your last RX frame:
82 00 00 00 ff 00 00 00 01 01 4c 4f 0c 6a 83
The CRC16 of {0x00,0x00,0x00,0xff,0x00,0x00,0x00,0x01,0x01,0x4c,0x4f} is 0x0c6a.
To find out this CRC algorithm, I assumed that 0x82 was a '...
10
I'll use "test@test.com" for the sake of example.
Algorithm
Convert the email address to its ASCII bytes. For example, the ASCII bytes for "test@test.com" are 74 65 73 74 40 74 65 73 74 2E 63 6F 6D.
Make a lowercase string out of those hex bytes. Using the running example, this would produce "7465737440746573742e636f6d".
Compute the SHA-1 hash of that ...
7
The key is getting getting a megaton of samples, so that the analysis has something to feed on. It really helps if you can stick the samples in a database table or dictionary that can be queried interactively, e.g. from some sort of script shell. Python should work admirably but I don't have much experience with it, as I've been using Visual FoxPro for ...
7
-1640531527 is hexadecimal '0x9e3779b9'.
This number is used in boost hash function.
The code here in function ub4 hash( k, length, initval) looks similar to yours, at least in the last part.
I think that it is a good point to start googling from.
As far as I can say it is probably intermediate variant(lookup2) of Jenkins Hash
7
This seems to be a checksum, just as you state in your question, not a CRC as mentioned in the header.
Group the values into blocks of 4 bits, add them, ignore overflow (in these examples, ignore overflow means subtract 32):
1000 1000 0000 1000 0100 0101 0001 8+8+0+8+4+5=33 1
1000 1000 0000 1000 0101 0101 0010 8+8+0+8+5+5=34 2
1000 1000 0000 1000 0110 ...
6
Some more low-level details:
What is the purpose of (*(_BYTE *)(content + 7) << 24) isn't a byte only 8 bits, so won't it be 0 every time?
In C, shifts implicitly promote the operand to at least an int/unsigned int, so the _BYTE value gets promoted to an unsigned int. This is probably because most processors support shifts on a single word size and ...
6
The message "crc changed, discarding .udd data" is from OllyDbg itself, not from your target application.
6
The answer turns out to be very simple, once you understand what CRC is.
It's similar to a CRC -- the checksum is the remainder when dividing the input by the polynomial with truncated representation 0x000201.
I wrote a quick Python script to validate checksum:
def crc(data, poly):
# width = 24 bit
# data len = 2048 bit
assert poly<(1<&...
5
The checksum algorithm is simple indeed. It adds all the payload bytes modulo 0xFF and then adds 26.
I wrote a script to test it:
#!/usr/bin/python
import binascii
def checksum(data):
payload = data[3:-1]
checksum = 26
for c in payload:
checksum += c
checksum &= 0xFF
return checksum
with open("input.txt","r") as f:
...
5
As explained there for a similar problem, facing an unknown Frame Check Sequence, the first thing should be to determine if it is an affine function of the frame data, for the sense that has in cryptography. This can be defined by the property:
For any set with an odd number of frames of equal length, the XOR of the Frame Check Sequences for these frames ...
4
Just a small addition to the previous answers.
The following shift construct, asked in 3, is a widely used way to convert a byte stream into a 32-bit integer.
(*(_BYTE *)(content + 7) << 24)
+ (*(_BYTE *)(content + 6) << 16)
+ (*(_BYTE *)(content + 5) << 8)
+ *(_BYTE *)(content + 4)
31 24 23 16 15 8 7 0
...
4
As CTO and founder of Backblaze, I wrote the original source code of the Backblaze client, and Jason Geffner above is correct. That is:
hexencode the email address (all lowercase, email addresses are not case sensitive)
take the sha1 - the result should be a 40 byte human readable all lowercase string
if the sha1 characters have "zero" for the index of the ...
3
I wanted to give this a try because it seemed interesting but I did not succeed.
Still, maybe this will lead you in the right direction for further tests.
I started reading some introduction material on CRCs:
http://www.sunshine2k.de/articles/coding/crc/understanding_crc.html
and this one where someone else was trying to reverse engineer a CRC:
https://...
3
As can be demonstrated by this page:
CRC width: CRC-8
CRC parametrization: Predefined, CRC8_SAE_J1850 (Polynomial: 0x1d, Initial value: 0xff, Final xor: 0xff)
CRC Input Data: Bytes, D1-D7
3
This question seems simpler than you might expect.
Since as OP noted, the code is irrelevant to validation mechanism used in the discussed system, I shall ignore it. It is indeed irrelevant as will be shown below.
as the first byte in each message indeed looks like a preamble, we'll ignore it. Our goal is to recover the function which, when applied to the ...
3
Figured it out. It was not as complicated as I thought. Here is how it goes.
9d1748c2aa11d2044f
9d1748c2aa12b70132
9d1748c2aa139c081f
9d1748c2aa164b01ca
9d1748c2aa173008b7
9d1748c2aa19fa047f
9d1748c2aa1adf0162
9d1748c2aa1d8e0417
9d1748c2aa1e7301fa
The 0x55 and 0x54 at the beginning of the message are the preamble and are not important.
Bytes 1-4 never ...
3
If you have known data and a known CRC, and an unknown value (like the initial CRC value or the final XOR value), you can always loop through all possible values and find those that give you the answer you want. It might not be practical for 32-bit CRCs, but for 8- and 16-bit CRCs it shouldn't take too long to run.
You'll need at least two sets of known ...
3
SOLUTION
I got help from a guy named Peter. He gave me a piece of test code in C. The CRC algorithm looked pretty similar to the ones I already tried. But what was important was that he pointed out that the first sample message most likely had a bit error.
#include <stdio.h>
int crc16(unsigned char *ptr, int count)
{
unsigned int crc;
char i;...
3
Based on the data provided, it appears to be a very simple check with the 5th byte being the sum of the first 3 bytes exclusive-or'd with the 4th byte.
// input bytes
byte b[4];
// check byte
byte c = ( b[0] + b[1] + b[2] ) ^ b[3];
To add how I worked it out -
Firstly, I observed that change of a single bit in the 4th byte flipped the same bit in the check ...
2
(I was trying to add this as a comment, but don't have enough reputation points)
I noticed the consecutive checksums {00,00,10,00,10} repeat 21 times in the first 1100 samples of which 8 times with 19 samples in between while the data remains random/different.
E.g.
This makes me wonder if the checksum is maybe time/clock based? With only 2 bits of ...
2
I edited your example data to include block- and line numbers to make referencing them easier. Unfortunately, this increased the size of the question to more than 32K, so i had to throw away some stuff at the end. Here is the rest of your data:
11 1 A0 82 00 01 02 40 00 E3 04 ////
11 2 A0 82 00 02 02 00 00 E2 08
11 3 A0 82 00 03 02 00 ...
2
Not sure why my last question was deleted.. anyway here is the answer - the bit order of the sum at the end is reversed..
uint8_t rev(uint8_t b) {
b = (b & 0xF0) >> 4 | (b & 0x0F) << 4;
b = (b & 0xCC) >> 2 | (b & 0x33) << 2;
b = (b & 0xAA) >> 1 | (b & 0x55) << 1;
return b;
}
int main() ...
2
You seem to have the same air conditioner like the guy who asked this question. Add up bytes 0-11, xor with 0x55 to get byte 12.
It could help if you stated the brand and model number of your AC unit, that makes it easier for other people who want to do the same thing.
2
You cannot bypass it, you must recalculate all required checksums.
Ubiquiti XW firmware is made from parts below:
UBNT <version-string> CRC32(header part) <4byte padding>
PART u-boot <content> CRC32(u-boot part) <4byte padding>
PART kernel <content> CRC32(kernel part) <4byte padding>
PART rootfs <content><...
2
The CRC is, as suspected, a fairly standard CRC16 with the polynomial 0x8005 (reflected: 0xA001). The only online calculators that I could find for this are:
BobTech's (clear the 'reverse data bytes' and 'reverse CRC' check boxes)
GHS Infotronic's (the link has polynomial and message "123456789" already inserted)
The latter is particularly convenient for ...
2
Your algorithm is probably the following:
width=16 poly=0x1021 init=0xffff refin=true refout=true xorout=0xffff check=0x906e name="X-25"
Operating on the whole packet except the first two bytes and the last two (the CRC).
Playing Buckaroo
If a CRC analysis tool such as CRC RevEng rejects a set of codewords, it is worth starting with the smallest ...
2
There are many ways to go about solving this, but here's how I might approach it based on a common workflow of mine for hacking games (you could say I'm the resident game-hacker around here). Before delving into it, I'll first suggest you opening the game via your debugger of choice, setting a breakpoint on File Management functions of interest, then seeing ...
2
Well thanks to @IgorSkochinsky who suggested in another question of mine to try a disassembler, I found a Docker image that contained a Blackfin toolchain which allowed me to use objdump to disassemble the code:
bfin-elf-objdump -D -b binary -mbfin bootloader.bin > bootloader.disasm
After hastily consulting a manual on Blackfin assembler and poking ...
2
Looks like it's just addition for the checksum, so nice job on that.
The mystery byte is part of the checksum.
The accumulator is 2 bytes.
data = """0000AAAAAA7E00201075000000075FC76F4F0105C8
0000AAAAAA7E00201075000000875FC77BED210712
0000AAAAAA7E00201075000000885FC77BFF010705""".strip().split("\n")
import struct
for ...
2
Partial Answer:
Looking only at the last 2bytes in binary shows some patterns where groups of bits are being flipped between groups of 4 messages ( Not2, Not3), or between groups of 8 (Not4). The unboxed bits influence the value of Not2 in some way.
Only top voted, non community-wiki answers of a minimum length are eligible