Change of roles of users 1C 8 (file option)
Suppose we need to restore access to the 1C Enterprise file database. As a rule, in such cases, some password manipulations are performed (either brute force or reset). Mena wanted to complicate the task a bit and go the other way - to assign administrator privileges to a regular user.
To begin, I advise you to read about the 1C file format. You can do it here .
So we need a hex editor. I used HIEW. We start the editor and open the 1Cv8.1CD file. Go to offset 0x4000 - this is the root configuration object. The first 32 bytes of the base language code. Then the number of blocks (4 bytes), and actually the addresses of the blocks themselves. We start looking for the V8USERS table. I had it in block 7, that is, with an offset of 0x8E000 (00 00 00 8E 000, read from right to left, add 000 at the end).
We go to this address and see
Going to 0x91000 we see
And already at address 0x92000 there is a description of the table. You can calculate the length of the fields as described in the article that I quoted above, I’ll just say that the record length is 697 (0x2B9) bytes, and the DATA field offset is 678 (0x2A6) bytes.
At the end of the description of the table we see three numbers. The first is the address of the data, the second is the address of the Blob data, the third is the indexes.
143 = 0x8F (data address 0x8F000), 144 = 0x90 (address of the Blob data 0x90000).
We go to the data. There they will send us to 0x193000, then to 0x194000 (by the way, there may be not one block like mine, but several. It depends on the number of users).
Here we are in the data table V8USERS. The first block with a length of 697 bytes is empty, then I had an empty user, then the Admin user.
Let's move another 0x2A6 byte. This is the block number in the blob data.
Next, go to the Blob data (0x90000). From there we go to 0x195000, then to 0x196000.
The zero block of Blob data is empty (the block size is 256 (0xFF) bytes, the first 4 bytes are the address of the next block, if the data does not fit into one block, then 2 bytes is the block size, the rest is the data itself). We need a second block.
Copy this data to a file (in HIEW key F2) and move on to the next block.
Copy the data from it to the same file.
We carry out the same manipulations with the user whose password we know. The resulting files can be opened using this program (thanks to the Decker user for the decryption algorithm ).
We get two of these files.
In principle, you can replace the User user role with the Admin role. In this case, the record size should not change, but I just added the admin role to the user.
Then we save it to a file and use the editor to copy the data to 1Cv8.1cd, into the same blocks from which we took them. Remember that we copy in pieces of 250 (00-F9). If, as in my case, the data size has changed, do not forget to resize the last block. You may have to add another block, then you will need to find a free block and indicate its number.
If everything went smoothly (the first time I didn’t succeed, so that backup, backup and backup again), you can log in with the User account, it is now with full rights.
Using the same technique, you can get the hash of the user's password in order to decrypt or replace it. There he is.
And finally. Please do not consider this article a hacking guide. The Internet is full of information on how to change 2 bytes to gain unauthorized access to data. It is both faster and easier. I showed the principle of working with base tables at a low level, which can come in handy when restoring a damaged database.
To begin, I advise you to read about the 1C file format. You can do it here .
So we need a hex editor. I used HIEW. We start the editor and open the 1Cv8.1CD file. Go to offset 0x4000 - this is the root configuration object. The first 32 bytes of the base language code. Then the number of blocks (4 bytes), and actually the addresses of the blocks themselves. We start looking for the V8USERS table. I had it in block 7, that is, with an offset of 0x8E000 (00 00 00 8E 000, read from right to left, add 000 at the end).
We go to this address and see
Going to 0x91000 we see
And already at address 0x92000 there is a description of the table. You can calculate the length of the fields as described in the article that I quoted above, I’ll just say that the record length is 697 (0x2B9) bytes, and the DATA field offset is 678 (0x2A6) bytes.
Hidden text
(This was the case on all the configurations that I considered, most likely the same in general in each configuration, since the V8USERS service table)
At the end of the description of the table we see three numbers. The first is the address of the data, the second is the address of the Blob data, the third is the indexes.
143 = 0x8F (data address 0x8F000), 144 = 0x90 (address of the Blob data 0x90000).
We go to the data. There they will send us to 0x193000, then to 0x194000 (by the way, there may be not one block like mine, but several. It depends on the number of users).
Here we are in the data table V8USERS. The first block with a length of 697 bytes is empty, then I had an empty user, then the Admin user.
Hidden text
(in HIEW to go to the next user F5, then + 2B9)
Let's move another 0x2A6 byte. This is the block number in the blob data.
Next, go to the Blob data (0x90000). From there we go to 0x195000, then to 0x196000.
The zero block of Blob data is empty (the block size is 256 (0xFF) bytes, the first 4 bytes are the address of the next block, if the data does not fit into one block, then 2 bytes is the block size, the rest is the data itself). We need a second block.
Hidden text
(0x196000 + 0x100 + 0x100)
Copy this data to a file (in HIEW key F2) and move on to the next block.
Copy the data from it to the same file.
Hidden text
(for HIEW do not forget to specify the offset 0xFA).
We carry out the same manipulations with the user whose password we know. The resulting files can be opened using this program (thanks to the Decker user for the decryption algorithm ).
We get two of these files.
In principle, you can replace the User user role with the Admin role. In this case, the record size should not change, but I just added the admin role to the user.
Then we save it to a file and use the editor to copy the data to 1Cv8.1cd, into the same blocks from which we took them. Remember that we copy in pieces of 250 (00-F9). If, as in my case, the data size has changed, do not forget to resize the last block. You may have to add another block, then you will need to find a free block and indicate its number.
If everything went smoothly (the first time I didn’t succeed, so that backup, backup and backup again), you can log in with the User account, it is now with full rights.
Using the same technique, you can get the hash of the user's password in order to decrypt or replace it. There he is.
And finally. Please do not consider this article a hacking guide. The Internet is full of information on how to change 2 bytes to gain unauthorized access to data. It is both faster and easier. I showed the principle of working with base tables at a low level, which can come in handy when restoring a damaged database.