Recent content by leecher

i.e. upload it to a 1-click hoster (i.e. depositfiles.com) and send me a private msg with a link to it for instance.

If you send me the dump, I can have a look.

Ah, yes, thanks, there was a comparison error in the commandline argument check resulting in never being able to use x1d, fixed now in current sourcecode (method-'1' > 0 should be method-'1' >= 0 ).

Static compiling is easy, just do: gcc -o hik_repack hik_repack.c -static `pkg-config --static --libs openssl` It's described even in the header comment ;-)

Hm, maybe it is my output buffer that is overrunning. OpensSSL DOCs state: " The amount of data written depends on the block alignment of the encrypted data: as a result the amount of data written may be anything from zero bytes to (inl + cipher_block_size - 1) so out should contain sufficient...

Maybe compiler/glibc problem? Not reproducable when compiling myself. Compile with debug symbols (-g) and check where it overruns. My production system configration: OpenSSL-Version: 0.9.8c-4etch9 GNU libc 2.3.6 But also tested it with: OpenSSL-Version: 1.0.0e-2ubuntu4.7 Ubuntu EGLIBC...

Nonsense.. hik_repack -u digicap.dav fw cd fw lzma -d <firmware.tar.gz >firmware.tar mkdir unp_fw cd unp_fw tar -xvf ../firmware.tar hik_repack -x4d centaurus_bak centaurus.lzma lzma -d <centaurus.lzma >centaurus

Seek, and ye shall find....

hik_repack 0.9 now has a bugfix for wrong iLangAuth (subcrc) calculation, which also affected repacking. And -d parameter dumps more information now.

The return -1 is commented in 0.8, I just wasn't sure which models need subcrc check and which don't. So it then continues to unpack it. So new repacker should work.

Thanks, hik_repack 0.8 now added support for G1 cams. Repacking-support for these RSA-crypted models was now also added, but as mentioned above, it doesn't make any real sense, as RSA signature cannot be calculcated due to unknown RSA public key.

Correct, daemon_fsp_app gets verified via RSA key in kernel (by matching on name /home/process/daemon_fsp_app),so modification of it will get detected,if kernel isn't patched. Grep for string /(/-e/0r/#%s3/$!em/ etc. in kernel to find the routine. This routine also does the decryption of it...

What do you mean by: "injected in a bad way"?

Well, davinci_bak also uses firmware pack format which contains RSA signature and daemon_fsp_app verifies it against this signature. So you need to patch daemon_fsp_app to let firm_data_verify return 0 and the nrepack daemon_fsp_app That should work, but it still involves patching of course.

Hm, directly dumping the files onto the the MTD might work fine. But if you do that, there is no sense in creating digicap.dav file, as you won't need it with your method anyway, if I understand correctly? So repacking digicap.dav itself would still be useless? I just once had a cam where the...