EXT4 CRC32C checksum algorithms are badly documented
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty margin-bottom:0;
So I'm making some kind of research on EXT4 checksums.
I found this page and tried to calculate checksum by myself. I've started with Superblock since it is sounds pretty simple: "The entire superblock up to the checksum field".
But it does not work: I can't get the same result as the superblock.
For this task I wrote superblock checksum calculator on Python. You may look at my program on GitHub. I tried a lot of things.
First of all, I tried to read the whole superblock up to checksum (1020 bytes) and put it in CRC32C (algorithm is independent library from pip). Although this was written in wiki, this does not work.
Then I simply reversed the whole superblock. It has not much sense, I think. And I failed again.
After this, I tried more complicated way. I tried to reverse all fields of the superblock separately. It gives another result as you can see:
Raw data: 1F DC 5E 4A
2-byte fields reversed: DC 1F 4A 5E
Full data reverse: 4A 5E DC 1F
And once again, I failed. Here all interpretations of phrase "The entire superblock up to the checksum field" ended.
I tried to add zero-filled checksum field to all algorithms and tried to reverse only little-endian fields (seemed like a good idea actually), without reversing char and u8 fields.
But there is no chance to get the same checksum as the original superblock.
My script makes output like this for superblock:
00c0390000cae600198a0b00c6aca40039a835000000000002000000020000000080000000800000002000001ee68c5c17e68c5c2000ffff53ef01000100000055936d5c000000000000000001000000000000000b000000000100003c000000c60200006b040000d6eb1a5613a44a8a91b66dbfe7cbbca9000000000000000000000000000000002f0061726765740000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000800000000000000f00c3000ca7d5363a49944fd9db16c0f95cfab15010140000c0000000000000055936d5c0af3020004000000000000000000000000800000008070000080000000800000000071000000000000000000000000000000000000000000000000000000000000000010000000000000000000000000200020000100000000000000000000000000000000000000040100000d63df0f00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000fe3731ed
ORIGINAL CHECKSUM (not calculated!): 0xfe3731ed
CALCULATED WHOLE SUPERBLOCK: 0xffffffffL - this always happens, some overflow error maybe.
CALCULATED SUPERBLOCK WITHOUT CHECKSUM: 0x12cec801L
CALCULATED FULLY-REVERSED SUPERBLOCK WITHOUT CHECKSUM: 0x7fe225e5L
CALCULATED FIELDS-REVERSED SUPERBLOCK: 0x8cce5045L
I can't find any documentation, and ext4 source code files are poorly commented (and really complicated), I can't make any sense of them.
python ext4 checksum
edited Mar 17 at 12:50
Rotemya
1114
asked Mar 16 at 19:10
DenisNovacDenisNovac
438
add a comment |
So I'm making some kind of research on EXT4 checksums.
I found this page and tried to calculate checksum by myself. I've started with Superblock since it is sounds pretty simple: "The entire superblock up to the checksum field".
But it does not work: I can't get the same result as the superblock.
For this task I wrote superblock checksum calculator on Python. You may look at my program on GitHub. I tried a lot of things.
First of all, I tried to read the whole superblock up to checksum (1020 bytes) and put it in CRC32C (algorithm is independent library from pip). Although this was written in wiki, this does not work.
Then I simply reversed the whole superblock. It has not much sense, I think. And I failed again.
After this, I tried more complicated way. I tried to reverse all fields of the superblock separately. It gives another result as you can see:
Raw data: 1F DC 5E 4A
2-byte fields reversed: DC 1F 4A 5E
Full data reverse: 4A 5E DC 1F
And once again, I failed. Here all interpretations of phrase "The entire superblock up to the checksum field" ended.
I tried to add zero-filled checksum field to all algorithms and tried to reverse only little-endian fields (seemed like a good idea actually), without reversing char and u8 fields.
But there is no chance to get the same checksum as the original superblock.
My script makes output like this for superblock:
00c0390000cae600198a0b00c6aca40039a835000000000002000000020000000080000000800000002000001ee68c5c17e68c5c2000ffff53ef01000100000055936d5c000000000000000001000000000000000b000000000100003c000000c60200006b040000d6eb1a5613a44a8a91b66dbfe7cbbca9000000000000000000000000000000002f0061726765740000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000800000000000000f00c3000ca7d5363a49944fd9db16c0f95cfab15010140000c0000000000000055936d5c0af3020004000000000000000000000000800000008070000080000000800000000071000000000000000000000000000000000000000000000000000000000000000010000000000000000000000000200020000100000000000000000000000000000000000000040100000d63df0f00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000fe3731ed
ORIGINAL CHECKSUM (not calculated!): 0xfe3731ed
CALCULATED WHOLE SUPERBLOCK: 0xffffffffL - this always happens, some overflow error maybe.
CALCULATED SUPERBLOCK WITHOUT CHECKSUM: 0x12cec801L
CALCULATED FULLY-REVERSED SUPERBLOCK WITHOUT CHECKSUM: 0x7fe225e5L
CALCULATED FIELDS-REVERSED SUPERBLOCK: 0x8cce5045L
I can't find any documentation, and ext4 source code files are poorly commented (and really complicated), I can't make any sense of them.
python ext4 checksum
edited Mar 17 at 12:50
Rotemya
1114
asked Mar 16 at 19:10
DenisNovacDenisNovac
438
1
Note the reason that you always get 0xffffffff when calculating the whole-superblock checksum is not a bug, but rather that the last field in the superblock and in your checksum is always the checksum itself.
– LustreOne
Mar 20 at 1:24
add a comment |
So I'm making some kind of research on EXT4 checksums.
I found this page and tried to calculate checksum by myself. I've started with Superblock since it is sounds pretty simple: "The entire superblock up to the checksum field".
But it does not work: I can't get the same result as the superblock.
For this task I wrote superblock checksum calculator on Python. You may look at my program on GitHub. I tried a lot of things.
First of all, I tried to read the whole superblock up to checksum (1020 bytes) and put it in CRC32C (algorithm is independent library from pip). Although this was written in wiki, this does not work.
Then I simply reversed the whole superblock. It has not much sense, I think. And I failed again.
After this, I tried more complicated way. I tried to reverse all fields of the superblock separately. It gives another result as you can see:
Raw data: 1F DC 5E 4A
2-byte fields reversed: DC 1F 4A 5E
Full data reverse: 4A 5E DC 1F
And once again, I failed. Here all interpretations of phrase "The entire superblock up to the checksum field" ended.
I tried to add zero-filled checksum field to all algorithms and tried to reverse only little-endian fields (seemed like a good idea actually), without reversing char and u8 fields.
But there is no chance to get the same checksum as the original superblock.
My script makes output like this for superblock:
00c0390000cae600198a0b00c6aca40039a835000000000002000000020000000080000000800000002000001ee68c5c17e68c5c2000ffff53ef01000100000055936d5c000000000000000001000000000000000b000000000100003c000000c60200006b040000d6eb1a5613a44a8a91b66dbfe7cbbca9000000000000000000000000000000002f0061726765740000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000800000000000000f00c3000ca7d5363a49944fd9db16c0f95cfab15010140000c0000000000000055936d5c0af3020004000000000000000000000000800000008070000080000000800000000071000000000000000000000000000000000000000000000000000000000000000010000000000000000000000000200020000100000000000000000000000000000000000000040100000d63df0f00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000fe3731ed
ORIGINAL CHECKSUM (not calculated!): 0xfe3731ed
CALCULATED WHOLE SUPERBLOCK: 0xffffffffL - this always happens, some overflow error maybe.
CALCULATED SUPERBLOCK WITHOUT CHECKSUM: 0x12cec801L
CALCULATED FULLY-REVERSED SUPERBLOCK WITHOUT CHECKSUM: 0x7fe225e5L
CALCULATED FIELDS-REVERSED SUPERBLOCK: 0x8cce5045L
I can't find any documentation, and ext4 source code files are poorly commented (and really complicated), I can't make any sense of them.
python ext4 checksum
edited Mar 17 at 12:50
Rotemya
1114
asked Mar 16 at 19:10
DenisNovacDenisNovac
438
So I'm making some kind of research on EXT4 checksums.
I found this page and tried to calculate checksum by myself. I've started with Superblock since it is sounds pretty simple: "The entire superblock up to the checksum field".
But it does not work: I can't get the same result as the superblock.
For this task I wrote superblock checksum calculator on Python. You may look at my program on GitHub. I tried a lot of things.
First of all, I tried to read the whole superblock up to checksum (1020 bytes) and put it in CRC32C (algorithm is independent library from pip). Although this was written in wiki, this does not work.
Then I simply reversed the whole superblock. It has not much sense, I think. And I failed again.
After this, I tried more complicated way. I tried to reverse all fields of the superblock separately. It gives another result as you can see:
Raw data: 1F DC 5E 4A
2-byte fields reversed: DC 1F 4A 5E
Full data reverse: 4A 5E DC 1F
And once again, I failed. Here all interpretations of phrase "The entire superblock up to the checksum field" ended.
I tried to add zero-filled checksum field to all algorithms and tried to reverse only little-endian fields (seemed like a good idea actually), without reversing char and u8 fields.
But there is no chance to get the same checksum as the original superblock.
My script makes output like this for superblock:
00c0390000cae600198a0b00c6aca40039a835000000000002000000020000000080000000800000002000001ee68c5c17e68c5c2000ffff53ef01000100000055936d5c000000000000000001000000000000000b000000000100003c000000c60200006b040000d6eb1a5613a44a8a91b66dbfe7cbbca9000000000000000000000000000000002f0061726765740000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000800000000000000f00c3000ca7d5363a49944fd9db16c0f95cfab15010140000c0000000000000055936d5c0af3020004000000000000000000000000800000008070000080000000800000000071000000000000000000000000000000000000000000000000000000000000000010000000000000000000000000200020000100000000000000000000000000000000000000040100000d63df0f00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000fe3731ed
ORIGINAL CHECKSUM (not calculated!): 0xfe3731ed
CALCULATED WHOLE SUPERBLOCK: 0xffffffffL - this always happens, some overflow error maybe.
CALCULATED SUPERBLOCK WITHOUT CHECKSUM: 0x12cec801L
CALCULATED FULLY-REVERSED SUPERBLOCK WITHOUT CHECKSUM: 0x7fe225e5L
CALCULATED FIELDS-REVERSED SUPERBLOCK: 0x8cce5045L
I can't find any documentation, and ext4 source code files are poorly commented (and really complicated), I can't make any sense of them.
python ext4 checksum
python ext4 checksum
edited Mar 17 at 12:50
Rotemya
1114
asked Mar 16 at 19:10
DenisNovacDenisNovac
438
edited Mar 17 at 12:50
Rotemya
1114
asked Mar 16 at 19:10
DenisNovacDenisNovac
438
edited Mar 17 at 12:50
Rotemya
1114
edited Mar 17 at 12:50
Rotemya
1114
edited Mar 17 at 12:50
Rotemya
1114
1114
asked Mar 16 at 19:10
DenisNovacDenisNovac
438
asked Mar 16 at 19:10
DenisNovacDenisNovac
438
asked Mar 16 at 19:10
DenisNovacDenisNovac
438
438
1
Note the reason that you always get 0xffffffff when calculating the whole-superblock checksum is not a bug, but rather that the last field in the superblock and in your checksum is always the checksum itself.
– LustreOne
Mar 20 at 1:24
add a comment |
1
Note the reason that you always get 0xffffffff when calculating the whole-superblock checksum is not a bug, but rather that the last field in the superblock and in your checksum is always the checksum itself.
– LustreOne
Mar 20 at 1:24
1
1
Note the reason that you always get 0xffffffff when calculating the whole-superblock checksum is not a bug, but rather that the last field in the superblock and in your checksum is always the checksum itself.
– LustreOne
Mar 20 at 1:24
Note the reason that you always get 0xffffffff when calculating the whole-superblock checksum is not a bug, but rather that the last field in the superblock and in your checksum is always the checksum itself.
– LustreOne
Mar 20 at 1:24
add a comment |
1 Answer
1
active
oldest
votes
OK. I've got the answer from Reddit (nightbladeofmalice). This man noticed that checksum of the raw superblock without checksum field (0x12cec801) will give reversed (in big-endian) original checksum if you subtract it from 0xFFFFFFFF:
ORIGINAL SUPERBLOCK:
00c0390000cae600198a0b008f99a400e8a53500000000000200000002000000008000000080000000200000082d8e5c012d8e5c2100ffff53ef01000100000055936d5c000000000000000001000000000000000b000000000100003c000000c60200006b040000d6eb1a5613a44a8a91b66dbfe7cbbca9000000000000000000000000000000002f00617267657400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000040000000000000000000000000000000008000000000000008e013000ca7d5363a49944fd9db16c0f95cfab15010140000c0000000000000055936d5c0af302000400000000000000000000000080000000807000008000000080000000007100000000000000000000000000000000000000000000000000000000000000001000000000000000000000000020002000010000000000000000000000000000000000000004010000df1b5b100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000015de7cf3
ORIGINAL CHECKSUM (not calculated, big endian!): 0xf37cde15
RAW SUPERBLOCK IN CRC32C WITHOUT CHECKSUM FIELDS (1020 bytes): 0xc8321eaL
INVERTED CHECKSUM (0xFFFFFFFF-previous field): 0xf37cde15L
answered Mar 17 at 11:50
DenisNovacDenisNovac
438
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f506714%2fext4-crc32c-checksum-algorithms-are-badly-documented%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
OK. I've got the answer from Reddit (nightbladeofmalice). This man noticed that checksum of the raw superblock without checksum field (0x12cec801) will give reversed (in big-endian) original checksum if you subtract it from 0xFFFFFFFF:
ORIGINAL SUPERBLOCK:
00c0390000cae600198a0b008f99a400e8a53500000000000200000002000000008000000080000000200000082d8e5c012d8e5c2100ffff53ef01000100000055936d5c000000000000000001000000000000000b000000000100003c000000c60200006b040000d6eb1a5613a44a8a91b66dbfe7cbbca9000000000000000000000000000000002f00617267657400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000040000000000000000000000000000000008000000000000008e013000ca7d5363a49944fd9db16c0f95cfab15010140000c0000000000000055936d5c0af302000400000000000000000000000080000000807000008000000080000000007100000000000000000000000000000000000000000000000000000000000000001000000000000000000000000020002000010000000000000000000000000000000000000004010000df1b5b100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000015de7cf3
ORIGINAL CHECKSUM (not calculated, big endian!): 0xf37cde15
RAW SUPERBLOCK IN CRC32C WITHOUT CHECKSUM FIELDS (1020 bytes): 0xc8321eaL
INVERTED CHECKSUM (0xFFFFFFFF-previous field): 0xf37cde15L
answered Mar 17 at 11:50
DenisNovacDenisNovac
438
add a comment |
OK. I've got the answer from Reddit (nightbladeofmalice). This man noticed that checksum of the raw superblock without checksum field (0x12cec801) will give reversed (in big-endian) original checksum if you subtract it from 0xFFFFFFFF:
ORIGINAL SUPERBLOCK:
00c0390000cae600198a0b008f99a400e8a53500000000000200000002000000008000000080000000200000082d8e5c012d8e5c2100ffff53ef01000100000055936d5c000000000000000001000000000000000b000000000100003c000000c60200006b040000d6eb1a5613a44a8a91b66dbfe7cbbca9000000000000000000000000000000002f00617267657400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000040000000000000000000000000000000008000000000000008e013000ca7d5363a49944fd9db16c0f95cfab15010140000c0000000000000055936d5c0af302000400000000000000000000000080000000807000008000000080000000007100000000000000000000000000000000000000000000000000000000000000001000000000000000000000000020002000010000000000000000000000000000000000000004010000df1b5b100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000015de7cf3
ORIGINAL CHECKSUM (not calculated, big endian!): 0xf37cde15
RAW SUPERBLOCK IN CRC32C WITHOUT CHECKSUM FIELDS (1020 bytes): 0xc8321eaL
INVERTED CHECKSUM (0xFFFFFFFF-previous field): 0xf37cde15L
answered Mar 17 at 11:50
DenisNovacDenisNovac
438
add a comment |
OK. I've got the answer from Reddit (nightbladeofmalice). This man noticed that checksum of the raw superblock without checksum field (0x12cec801) will give reversed (in big-endian) original checksum if you subtract it from 0xFFFFFFFF:
ORIGINAL SUPERBLOCK:
00c0390000cae600198a0b008f99a400e8a53500000000000200000002000000008000000080000000200000082d8e5c012d8e5c2100ffff53ef01000100000055936d5c000000000000000001000000000000000b000000000100003c000000c60200006b040000d6eb1a5613a44a8a91b66dbfe7cbbca9000000000000000000000000000000002f00617267657400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000040000000000000000000000000000000008000000000000008e013000ca7d5363a49944fd9db16c0f95cfab15010140000c0000000000000055936d5c0af302000400000000000000000000000080000000807000008000000080000000007100000000000000000000000000000000000000000000000000000000000000001000000000000000000000000020002000010000000000000000000000000000000000000004010000df1b5b100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000015de7cf3
ORIGINAL CHECKSUM (not calculated, big endian!): 0xf37cde15
RAW SUPERBLOCK IN CRC32C WITHOUT CHECKSUM FIELDS (1020 bytes): 0xc8321eaL
INVERTED CHECKSUM (0xFFFFFFFF-previous field): 0xf37cde15L
answered Mar 17 at 11:50
DenisNovacDenisNovac
438
OK. I've got the answer from Reddit (nightbladeofmalice). This man noticed that checksum of the raw superblock without checksum field (0x12cec801) will give reversed (in big-endian) original checksum if you subtract it from 0xFFFFFFFF:
ORIGINAL SUPERBLOCK:
00c0390000cae600198a0b008f99a400e8a53500000000000200000002000000008000000080000000200000082d8e5c012d8e5c2100ffff53ef01000100000055936d5c000000000000000001000000000000000b000000000100003c000000c60200006b040000d6eb1a5613a44a8a91b66dbfe7cbbca9000000000000000000000000000000002f00617267657400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000040000000000000000000000000000000008000000000000008e013000ca7d5363a49944fd9db16c0f95cfab15010140000c0000000000000055936d5c0af302000400000000000000000000000080000000807000008000000080000000007100000000000000000000000000000000000000000000000000000000000000001000000000000000000000000020002000010000000000000000000000000000000000000004010000df1b5b100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000015de7cf3
ORIGINAL CHECKSUM (not calculated, big endian!): 0xf37cde15
RAW SUPERBLOCK IN CRC32C WITHOUT CHECKSUM FIELDS (1020 bytes): 0xc8321eaL
INVERTED CHECKSUM (0xFFFFFFFF-previous field): 0xf37cde15L
answered Mar 17 at 11:50
DenisNovacDenisNovac
438
answered Mar 17 at 11:50
DenisNovacDenisNovac
438
answered Mar 17 at 11:50
DenisNovacDenisNovac
438
answered Mar 17 at 11:50
DenisNovacDenisNovac
438
438
add a comment |
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f506714%2fext4-crc32c-checksum-algorithms-are-badly-documented%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
Note the reason that you always get 0xffffffff when calculating the whole-superblock checksum is not a bug, but rather that the last field in the superblock and in your checksum is always the checksum itself.
– LustreOne
Mar 20 at 1:24