PS3 Apollo save tool (development thread)

Berion said:
Actually RAW files are mc images with ECC (*.ps2, *.VM2) while *.vmc and *.bin are just stripped version of them. ^^ I could compare it to i.e HDD where user can read data from it via standard ATA commands but HDD firmware have access also to ECC/EDC.

But thanks for the update.
Click to expand...

oops, I had no idea. Well, I'll replace ".raw" for ".vmc". It's not such a big deal, just a naming convention. If the user needs, they can rename it back to .bin /vmc.

I will just update the 1.4.2 release package on Github (edit: new .pkg uploaded, now using "vmc" as extension)
 
Last edited:
I have a good story to tell... and a suggestion that i will explain at the epilogue of the wall-of-text to increase the dramatism
There are a couple of details of this story that are common problems, is long to explain and i guess some of you are aware of some of what im going to say, but i never did read a complete explanation of it, so im going to write it for documenting it before i forget

All the assassin's creed games released in a physical bluray (1, 2, brotherhood, revelations, 3, 4, rogue) have something a bit weird and unique, when we make a backup of the real disc (either in JB or ISO format) it seems there is a folder named ASSASSIN_ISO missing, that folder doesnt exists in the real disc, or the backup managers doesnt "extracts" it as a folder
But the fact is the game needs that folder, otherway if you try to boot the game with the backup located in internal dev_hdd0 the game is going to work but the consequences of booting the game that way are weird
-It creates a folder named ASSASSIN_SOMETHING inside dev_hdd0/home/********/savedata/
-It creates another savegame inside dev_hdd0/home/********/savedata/ using the default TITLE_ID of the EBOOT.BIN

The first problem doesnt follows any standard, thats an error that doesnt causes any problem, but is wrong
The second problem is weird because the TITLE_ID of the savegame sometimes is different than the TITLE_ID of the game, it works even having different TITLE_ID but is wrong
I was aware of this problems, but some time ago i made a backup of assassin's creed revelation from the real disc, i had the files in my internal hdd without any modification (i forgot to create the folder ASSASSIN_ISO inside the backuped files), but i forgot about it and i just started playing it... the next days i continued playing and i completed the game, everything was looking normal
Eventually i took a look at the savegame path and i found that i was trapped in this problem (facepalm time, it hurts double when you do something you are not supossed to do and you was aware of not doing it)

----------
The TITLE_ID of my game is BLES01384 (one of the versions released in EUROPE)
Initially i was playing the game without the ASSASSIN_ISO folder, and it was creating the savegames using a folder named BLUS30808AC2AC2_0 (see how it was using the TITLE_ID BLUS30808 that belongs to a diffrent disc released for USA region ?)

The fix starts by creating an empty folder named ASSASSIN_ISO inside the backup (inside USRDIR)
From this point the game is not able to load the old savegame because it belongs to BLUS30808 and my game is BLES01384. This needs to be fixed by rebuilding the savegame
Additionally, you should delete the folder named ASSASSIN_SOMETHING inside dev_hdd0/home/********/savedata/. This folder is breaking the standard, it should not be there, so better delete it

------------------
Ok, that was the intro, this is when things gets more interesting :)
The problem needed to solve now is pretty much a "port" of the savegame in between regions (or better said... from a TITLE_ID to a different TITLE_ID), this is something generic that could be made in lot more games, and as far i know the rules are always the same

Im going to explain how to do it with the PC tool pfdtool.exe (the original release named "strawberry update" by flatz), is the same source code used in apollo and bruteforce savedata so the actions are the same in theory
First we need to create a valid savegame with the "target" TITLE_ID (in this case the backup with the ASSASSIN_ISO folder added manually inside it that creates the gamesaves as BLES01384AC2AC2_0 for EUROPE region), just start a new game, usually the game does an autosave at start, you can quit the game as soon you see the indication that the savegame was created

Use a filemanager or FTP, navigate to dev_hdd0/home/********/savedata/ and make a copy of both "source" and "target" savedata folders. Dont delete them in main XMB yet. Copy them to PC, and make another safe copy of them (i use to .zip them)
The files are going to suffer several conversions, and eventually if you commit some mistake they could become malformed or corrupted in main XMB and you will have to delete them and start again, so save the original backups as gold

The main problem to convert them is... some of the files inside the savegame folders are encrypted with keys/hashes that are located in the PARAM.PFD
But the keys located inside the PARAM.PFD of the "source" savegame are different than the "target" savegame, there is an option in pfdtool.exe that allows to do a simple "update" of the PARAM.PFD and there is another option to run a "check" to the updated PARAM.PFD that will report everything as "OK"... but thats not the way to do it because we are merging files from different savegames

The first thing we need to do is to run the command "list" in the target savegame, this is going to show the names of all the protected files. The PARAM.SFO is always protected (in 99% of the games), and additionally it have 2 more files protected AC2_0.SAV and BK_0.SAV (in his encrypted format are different because uses different keys, but after decryption are identical, in the assassin's creed games the second file is a backup of the first file)
Code: 
C:\pfdtool.exe -g BLES01384 -l BLES01384AC2AC2_0
pfdtool 0.2.3 (c) 2012 by flatz

[*] Warning: A disc hash key was not found. A fallback disc hash key will be used.
[*] Version: 3
[*] Type: savegame
[*]
[*] Entries:
[*]   #000:
[*]     File Name: PARAM.SFO
[*]     File Size: 2736
[*]   #001:
[*]     File Name: AC2_0.SAV
[*]     File Size: 307200
[*]   #002:
[*]     File Name: BK_0.SAV
[*]     File Size: 307200
After that we need to run the command "decrypt" in both source and target savegames, by doing this we are removing the encryption layer in the protected files, we need to specify the name of the files in the command, this way:
Code: 
C:\pfdtool.exe -g BLUS30808 -d BLUS30808AC2AC2_0 AC2_0.SAV BK_0.SAV
Code: 
C:\pfdtool.exe -g BLES01384 -d BLES01384AC2AC2_0 AC2_0.SAV BK_0.SAV
The PARAM.PFD files are going to be updated too when running the "decrypt" command, it seems the keys or the hashes inside PARAM.PFD changes at this point

Now is when you can copy the files AC2_0.SAV (this is the real savegame in a single file, without any encryption) and his backup BK_0.SAV from the source savegame (in this case the folder named "BLUS30808AC2AC2_0") to the target savegame folder (named BLES01384AC2AC2_0)

Additionally... this is the time where you can modify the PARAM.SFO, in the way im suggesting to do this "porting" there is not a really need to do it, because it contains the TITLE_ID of the target savegame (remember, you have this savegame visible in your XMB waiting for you to replace his contents, thats because his PARAM.SFO is indexed in the XMB database, so is valid for XMB)
Anyway... you can modify it, sometimes in it appears some texts that tells the game progression or something like that, if you are picky you can "merge" that info from source PARAM.SFO into target PARAM.SFO
In the case of the assasin's creeds when you look at the savegame in XMB appears the total play time, the percentage of game syncing with the animus, etc...
The fact is this is not really needed to be modifyed because the game is going to add all this info the next time the savegame will be updated, anyway, i did it for the sake of it

Ok, so everything is ready... we just need to run the "encrypt" command in the target savegame with the names of the files that are going to be encrypted:
Code: 
C:\pfdtool.exe -g BLES01384 -e BLES01384AC2AC2_0 AC2_0.SAV BK_0.SAV
The PARAM.PFD files are going to be updated too when running the "encrypt" command, it seems the keys or the hashes inside PARAM.PFD changes at this point

After that you can run a "check" command to verify that all encryption, keys and hases are reported as "OK" :encouragement:
Code: 
C:\pfdtool.exe -g BLES01384 -c BLES01384AC2AC2_0
Next thing needed to do is to use FTP or filemanager to copy the files to the PS3 overwriting the target savegame. you should ignore the info about it displayed in XMB, better dont even look at it... just boot the game and allow the game to load it
Usually most/all games saves the game inmediatly after is loaded (to keep a record of some counters that tells how many times the game was booted, his timestanps and things like that)
So you just need to boot the game, load the savegame, and the info inside PARAM.SFO is updated automatically, with it is updated the PARAM.PFD too, and with them the XMB database is updated too, so the next time you look at it in the XMB will look normal. This autoupdate is the confirmation that everything was made correctly


---------------
Im mentioning all this because i thing this "porting" in between different TITLE_ID can be automated, not sure if completly and for all games, but i guess is going to work, the idea is a bit like this
1) The user copies a savegame with TITLE_ID = BCES01670 to USB and opens apollo
2) Apollo displays the savegame in a list and a option to "port" it to other regions
3) When the user clicks in the "port" option, apollo searchs in the games.config file to find how many TITLE_ID exists for that game
4) Apollo realizes the game is "Uncharted 3" and displays a list with all the posible targets (this game have a lot, it was released tenths of times, lol)
5) The user selects one of them
6) Apollo runs the list command in the savegame to identify all the protected files
7) Apollo decrypts all the protected files (and updates the PFD)
8) Apolo replaces the TITLE_ID in the PARAM.SFO by the one selected by the user
9) Apollo modifyes the first 9 characters of the folder name (because are the TITLE_ID too)
10) Apollo encrypts all the protected files (and updates the PFD)


Long story short... the idea is to use the list of TITLE_ID inside the file games.conf as the menu of a restaurant to allow the user to select all the know TITLE_ID used by all the different disc releases of the same game
Not sure if im missing something but additionally to the encryption and decryption, as far i remember the only 2 things that needs to be modifyed are the TITLE_ID located inside PARAM.SFO (this one is easy to locate, and failproof to modify) and the one used in the folder name (always the first 9 characters, this is a strict rule so we are sure all the official games does it)
 
Last edited:
I don't know if it's the same issue as Sandungas described, but Worms Revolution has a similar issue as the save generated by a BLUS release is named BLES and the other way around. When resigned, the save doesn't works (I haven't tried with Apollo).
 
Apollo using the same keys files format (a simple text file) so You need SFID for this game to resign save whatever it is making by Apollo or BruteforceSaveDataTool.

If game exist in database with key, try add Your GameID (developers often using the same for all regions and digital version).
 
sandungas said:
Long story short... the idea is to use the list of TITLE_ID inside the file games.conf as the menu of a restaurant to allow the user to select all the know TITLE_ID used by all the different disc releases of the same game
Not sure if im missing something but additionally to the encryption and decryption, as far i remember the only 2 things that needs to be modifyed are the TITLE_ID located inside PARAM.SFO (this one is easy to locate, and failproof to modify) and the one used in the folder name (always the first 9 characters, this is a strict rule so we are sure all the official games does it)
Click to expand...

hey @sandungas , I think you missed it, but Apollo already has such region-change feature :D (and it's pretty much exactly as you described)

with the latest Apollo, just open a PS3 save, and browse the "--- SFO Patches ---":
  • You'll find an option called "Change region Title ID"
  • when you click on it, all the title IDs available for that savegame will show up. (those are taken from the games.conf DB)
  • then you select whatever region title you want, and finally you just "Apply changes & resign".

That's all, Apollo will do all the resigning, patching (param.sfo), and rename the folder accordingly.

I guess you missed some changelogs ! :D

I know that Apollo evolved a lot, with a tons of features that should get some nice documentation or explaining videos, but nobody has done anything about it.... then if you go to Youtube, you can find like 1000s videos about how to use pkgi to download "FREE GAMES"... :confused:
 
PwTd said:
I don't know if it's the same issue as Sandungas described, but Worms Revolution has a similar issue as the save generated by a BLUS release is named BLES and the other way around. When resigned, the save doesn't works (I haven't tried with Apollo).
Click to expand...
Im not completly sure why it happens... but i made my theory about it (not sure if is right, but it should not be much far away from what im going to say)

In the EBOOT.BIN appears a list of several posible TITLE_ID's for the game, the reason why the game developers does this is because this same EBOOT.BIN is usually identical for the different copies of the disc game released in different world regions
In other words... they does it this way because is easyer to have all them together and compile the EBOOT.BIN with all them included

When the game uses the savedata functions is supposed to know which TITLE_ID is the correct one... but under some weird scenarios the game doesnt knows it (in the assassin's creed games it happens if you boot the game from internal hdd without the empty folder ASSASSIN_ISO inside USRDIR)
When this happens, it seems the game creates the saves using one of the TITLE_ID's that could be considered as a "fallback" (or the default)
In the assassin's creed games it seems is always BLUS for USA
Maybe is just because in the list of TITLE_ID the BLUS version appears first

----------
I never heard this problem could happen in the worms games thought, i thought it was a unique weirdness of the assassin's creed series
But based in the behaviour of the assassin's creed games i have an idea you should check
Take a look at the folder names inside dev_hdd0/home/********/savedata
All the folder names should start by following the standard strictly (4 characters and 9 digits, ie: ABCD12345)
If you see some weird folder name (ie WORMS_ISO)... delete it, and create an empty folder with that name inside the game backup (inside USRDIR), thats really what fixes the problem in the assassin's creed games, after that the saves are generated correctly
 
bucanero said:
hey @sandungas , I think you missed it, but Apollo already has such region-change feature :D (and it's pretty much exactly as you described)

with the latest Apollo, just open a PS3 save, and browse the "--- SFO Patches ---":
  • You'll find an option called "Change region Title ID"
  • when you click on it, all the title IDs available for that savegame will show up. (those are taken from the games.conf DB)
  • then you select whatever region title you want, and finally you just "Apply changes & resign".

That's all, Apollo will do all the resigning, patching (param.sfo), and rename the folder accordingly.

I guess you missed some changelogs ! :D

I know that Apollo evolved a lot, with a tons of features that should get some nice documentation or explaining videos, but nobody has done anything about it.... then if you go to Youtube, you can find like 1000s videos about how to use pkgi to download "FREE GAMES"... :confused:
Click to expand...
Ops, nice feature, i missed it sorry :oops:

I decided to do it by merging the files from 2 saves from different regions in PC to take a look at them in every step of the conversion process and to see what was doing the tool with all that keys and hashes
After a lot of unsuccessful tests i realized it was not so hard :)
 
sandungas said:
Ops, nice feature, i missed it sorry :oops:

I decided to do it by merging the files from 2 saves from different regions in PC to take a look at them in every step of the conversion process and to see what was doing the tool with all that keys and hashes
After a lot of unsuccessful tests i realized it was not so hard :)
Click to expand...

btw, if you still have the original save files, it would be nice to test it with Apollo, and see if the converted savegame works properly or not
please share your feedback if you try it! :)
 
bucanero said:
I know that Apollo evolved a lot, with a tons of features that should get some nice documentation or explaining videos, but nobody has done anything about it.... then if you go to Youtube, you can find like 1000s videos about how to use pkgi to download "FREE GAMES"... :confused:
Click to expand...

Well, that's good example of Laffer curve. Most peoples interesting only pirate games on "unlocked consoles". And probably we can do nothing about it. Also You have created Apollo in times when PS5 premiere is near, and PS4 pushed out PS3 many years ago. It is retro console now, and retro consoles have only retro users. But Apollo is great no matter how many peoples use it or know about it. :P
 
  • Like
Reactions: Zar
Apollo is a milestone in many ways, as far i know is the first homebrew using a port of the pfd flatz code in PS3, also is the first homebew app able to deal with all that formats related with virtual memory cards
Overall, you achieved all the posible features that could be implemented in the scope of a homebrew app dedicated to game saves :encouragement:

I guess there are some features that could be implemented for PSP formats, but thats a bit unexplored territory
So far you have pwned PS1, PS2, and PS3 save formats completly :p
 
Last edited:
I've found that I added a critical bug on the online-db module in the last version... you can't actually download savegames from the DB.

Some days ago I was using Apollo to "enhance" some Guilty Gear saves, and by chance I tried to download something from the Online DB, but it didn't work... so I went to the source I found that I missed to initialize 1 variable for the Online DB listings. :oops:

Anyways, I'll release this fix in a new v1.4.3 version as soon as possible, so the online DB works again.

I'll also include these Guilty Gear Xrd SIGN /REV2 money patches that I've added, just in case someone also wants to unlock the galleries and hundreds of colors/characters quickly :D
 
aldostools said:
Thank you, but BSD is not longer being updated. It's not necessary now that we have Apollo Save Tool :cheerful:
Click to expand...

:D on a side note, in another thread someone was asking about Borderlands, so I checked the patches from BSD in Apollo. I was totally missing the implementation of "Type 6" Game Genie codes. I did a quick basic implementation (Y/Z flags handling is missing) but it worked fine for the Borderlands 1 cheats.

My question is about the Borderlands 1 savegame itself... in BSD, if you open it, is marked as UNPROTECTED, but in the games.conf file I see there's a Secure File-ID for it.... so I'm not sure if I missed something, or how it's unprotected while it has a secure file id.

what I see in the games.conf (based on the latest one you shared):
Code: 
; "Borderlands"
;[BLUS30386-PROFILE/BLUS82012-PROFILE/BLUS82013-PROFILE/NPUB30413-PROFILE/BLES00697-PROFILE/BLES00698-PROFILE/BLES02218-PROFILE/BLES82007-PROFILE/BLKS20145-PROFILE/BLJM60279-PROFILE/BLJS10170-PROFILE/NPHB00399-PROFILE]
;disc_hash_key=
;secure_file_id:*=0A0B01070D06010C09050206090C0A01
;PackZip Settings: -w 15

; "Borderlands"
[BLUS30386/BLUS82012/BLUS82013/NPUB30413/BLES00697/BLES00698/BLES02218/BLES82007/BLKS20145/BLJM60279/BLJS10170/NPHB00399]
;disc_hash_key=
secure_file_id:*=02010508040102010508030A0F070C0D

oh, and I still can't find the proper CRC64 algorithm to match the one in BSD... I used the polys/initial values you shared, and I honestly tried almost every single combination I found, even on online tools and stuff, and I always get a different crc64 result than in BSD. :( I know only a very few savegames use crc64 hash, but I still wonder where's my mistake.

btw, to display a background in PS3 system dialogs, you need to add the flag (psl1ght):
msgType mtype |= MSG_DIALOG_BKG_INVISIBLE;

on the original SDK the flag is:
CELL_MSGDIALOG_TYPE_BG_INVISIBLE
 
bucanero said:
:D on a side note, in another thread someone was asking about Borderlands, so I checked the patches from BSD in Apollo. I was totally missing the implementation of "Type 6" Game Genie codes. I did a quick basic implementation (Y/Z flags handling is missing) but it worked fine for the Borderlands 1 cheats.

My question is about the Borderlands 1 savegame itself... in BSD, if you open it, is marked as UNPROTECTED, but in the games.conf file I see there's a Secure File-ID for it.... so I'm not sure if I missed something, or how it's unprotected while it has a secure file id.

what I see in the games.conf (based on the latest one you shared):
Code: 
; "Borderlands"
;[BLUS30386-PROFILE/BLUS82012-PROFILE/BLUS82013-PROFILE/NPUB30413-PROFILE/BLES00697-PROFILE/BLES00698-PROFILE/BLES02218-PROFILE/BLES82007-PROFILE/BLKS20145-PROFILE/BLJM60279-PROFILE/BLJS10170-PROFILE/NPHB00399-PROFILE]
;disc_hash_key=
;secure_file_id:*=0A0B01070D06010C09050206090C0A01
;PackZip Settings: -w 15

; "Borderlands"
[BLUS30386/BLUS82012/BLUS82013/NPUB30413/BLES00697/BLES00698/BLES02218/BLES82007/BLKS20145/BLJM60279/BLJS10170/NPHB00399]
;disc_hash_key=
secure_file_id:*=02010508040102010508030A0F070C0D

oh, and I still can't find the proper CRC64 algorithm to match the one in BSD... I used the polys/initial values you shared, and I honestly tried almost every single combination I found, even on online tools and stuff, and I always get a different crc64 result than in BSD. :( I know only a very few savegames use crc64 hash, but I still wonder where's my mistake.

btw, to display a background in PS3 system dialogs, you need to add the flag (psl1ght):
msgType mtype |= MSG_DIALOG_BKG_INVISIBLE;

on the original SDK the flag is:
CELL_MSGDIALOG_TYPE_BG_INVISIBLE
Click to expand...

If the game is marked as unprotected, then it could be mistake in games.conf

I haven't used BSD in long time, so I don't remember why I set this game like that. Maybe the saves were in updated versions.

Notice that the game uses a secure file id for PROFILE saves and another for the regular saves.

Also the saves in PROFILE use the PackZip compression -w 15. If you don't have this algorithm implemented, you cannot apply cheats or update CRC.

I suggest that try the save from 2 or more regions and compare the results.

BSD is using 2 types of CRC64 algorithms.
CRC64_ECMA182: Poly64 = 0xC96C5795D7870F42
CRC64_ISO: Poly64 = 0xD800000000000000
Private Sub GenerateTable64()
Dim i As Integer, j As Integer
On Local Error Resume Next
Const bit1 As Long = 1&
For i = 0 To 255
var64bit(CRC64) = Hex$(i)
For j = 0 To 7
If (CRC64.LoWord And bit1) Then
RShift1_x64 CRC64
Xor64 CRC64, Poly64
Else
RShift1_x64 CRC64
End If
Next

CRC64_Table(i) = CRC64
Next
End Sub
 
aldostools said:
If the game is marked as unprotected, then it could be mistake in games.conf

BSD is using 2 types of CRC64 algorithms.
CRC64_ECMA182: Poly64 = 0xC96C5795D7870F42
CRC64_ISO: Poly64 = 0xD800000000000000
Private Sub GenerateTable64()
Dim i As Integer, j As Integer
On Local Error Resume Next
Const bit1 As Long = 1&
For i = 0 To 255
var64bit(CRC64) = Hex$(i)
For j = 0 To 7
If (CRC64.LoWord And bit1) Then
RShift1_x64 CRC64
Xor64 CRC64, Poly64
Else
RShift1_x64 CRC64
End If
Next

CRC64_Table(i) = CRC64
Next
End Sub
Click to expand...

thanks a lot for the crc64 code! :) I ran out of time this weekend, but my next task is to make a simple C implementation and compare results. I know this hash is only used in very few games, but since Apollo has evolved enough, I don't want to leave these little missing commands laying around.

btw, even if BSD is not being updated, I still use it every time to validate my work with Apollo. ;) (if I don't get the same results from BSD, then there's a bug in my code :sem blush: )
 
while I was doing some tests about the compress/decompress commands, I realized that I missed one case
BSD actually tries offzip with "wbits=15" (zlib/default), and if not then it tries "wbits=-15" (deflate)

I was only using wbits=15 (default), so I'll try to add the missing case in the next update
 
aldostools said:
BSD is using 2 types of CRC64 algorithms.
CRC64_ECMA182: Poly64 = 0xC96C5795D7870F42
CRC64_ISO: Poly64 = 0xD800000000000000
Private Sub GenerateTable64()
Dim i As Integer, j As Integer
On Local Error Resume Next
Const bit1 As Long = 1&
For i = 0 To 255
var64bit(CRC64) = Hex$(i)
For j = 0 To 7
If (CRC64.LoWord And bit1) Then
RShift1_x64 CRC64
Xor64 CRC64, Poly64
Else
RShift1_x64 CRC64
End If
Next

CRC64_Table(i) = CRC64
Next
End Sub
Click to expand...

hello @aldostools

I implemented a basic crc64 algo following the code you shared, but I still get different results. Here's the C code.
I believe my table code is following your VB example closely, so maybe I'm missing some initial value or xor in the crc64 calc?


Code: 
#include <stdio.h>
#include <inttypes.h>


#define CRC64_ECMA182_POLY      0xC96C5795D7870F42

uint64_t crc64_table[256] = {0};

void generate_table()
{
    for(int i=0; i<256; i++)
    {
        uint64_t crc = i;

        for(int j=0; j<8; j++)
        {
            if(crc & 1)
            {
                crc >>= 1;
                crc ^= CRC64_ECMA182_POLY;
            }
            else
            {
                crc >>= 1;
            }
        }
 
        crc64_table[i] = crc;
    }
}


uint64_t crc64(const unsigned char *s, uint64_t len) {
    uint64_t j;
    uint64_t crc = 0; // initial value

    for (j = 0; j < len; j++) {
        uint8_t byte = s[j];
        crc = crc64_table[(uint8_t)crc ^ byte] ^ (crc >> 8);
    }
    return crc;
}


int main(int ac, char* *av)
{
    generate_table();
 
    uint64_t result;

    printf("taking CRC64 of '\\x80' (returns 0xC96C5795D7870F42)\n");
    result = crc64((uint8_t*)"\x80", 1);
    printf("result0: %016llX\n", result);

    printf("taking CRC64 of '123456789' (returns 2B9C7EE4E2780C8A)\n");
    result = crc64((uint8_t*)"123456789", 9);
    printf("result0: %016llX\n", result);

    printf("taking CRC64 of '\\xDE\\xAD\\xBE\\xEF' (returns FC232C18806871AF)\n");
    result = crc64((uint8_t*)"\xDE\xAD\xBE\xEF", 4);
    printf("result: %016llX\n", result);

    printf("taking CRC64 of '99eb96dd94c88e975b585d2f28785e36' (returns DB7AC38F63413C4E)\n");
    result = crc64((uint8_t*)"\x99\xEB\x96\xDD\x94\xC8\x8E\x97\x5B\x58\x5D\x2F\x28\x78\x5E\x36", 16);
    printf("result: %016llX\n", result);

    printf("taking CRC64 of '\\DE\\xAD' (returns 44277F18417C45A5)\n");
    result = crc64((uint8_t*)"\xDE\xAD", 2);
    printf("result: %016llX\n", result);

}

could you check it out when you have a chance? thanks!

for reference, when I use BSD, I use crc64_ecma to calculate "123456789" and I get 0x19AA344B407A0CF5

Code: 
:SYSTEM.DAT

[Write 123456789]
write at 0x000000:0x313233343536373839

[Test CRC64 (Required)]
set range:0x0,0x8
set [hash]:CRC64_ecma
msgbox [hash]
 
Last edited:
bucanero said:
hello @aldostools

I implemented a basic crc64 algo following the code you shared, but I still get different results. Here's the C code.
I believe my table code is following your VB example closely, so maybe I'm missing some initial value or xor in the crc64 calc?
Click to expand...

well I solved the mystery... at least on my C code, I need to set the initial crc64 value to 0xC96C5795D7870F42

so, the code goes:

Code: 
uint64_t crc64(const unsigned char *s, uint64_t len) {
    uint64_t j;
    uint64_t crc = 0xC96C5795D7870F42; // initial value

    for (j = 0; j < len; j++) {
        uint8_t byte = s[j];
        crc = crc64_table[(uint8_t)crc ^ byte] ^ (crc >> 8);
    }
    return crc;
}

from the ECMA-182 references online, the initial value should be 0x0, but maybe this is a customized crc64? I have no idea, but at least now I have an implementation that matches BSD crc64 100% :D

btw, the same applies for the crc64_iso on BSD, I need to use poly = 0xD800000000000000, and then crc initial value = 0xD800000000000000.
 
You must log in or register to reply here.

Similar threads

Back
Top