Make a command line version for Linux

Wikinaut commented 9 years ago

UPDATE 04.11.2015

Coder: binary-file-input -> coder -> coded pdf output (which then can be printed)
Decoder: input scanned image (png/tif/pdf) -> decoder -> binary file output

referenced: https://twitter.com/Wikinaut/status/662021070975852544

@Rupan

I am heavily interested in working with/on that software, especially in porting it to Linux/having it ported to Linux, and to use QR codes and the XZing software https://github.com/zxing/zxing for the code boxes (but letting the old decoder in to keep it compatible and allow decoding of old paperba(c)k backups).

Have you perhaps already ported it but forgot to push upstream?

The program should perhaps go together with Paperkey , see http://www.jabberwocky.com/software/paperkey/ and https://gist.github.com/joostrijneveld/59ab61faa21910c8434c .

For later improvements, I suggest also a pure Javascript [sic] version (yes, there are QR javascript code/decode implementations, see http://www.webqr.com/ (live) and the code https://github.com/LazarSoft/jsqrcode ).

Closed on 02.01.2021

Rupan commented 9 years ago

Short answer: not at the moment. There are several problems, not the least of which is the fact that the user interface definitions are defined in a Borland-specific format that only works on Windows.

Perhaps that could be some sort of command line application which did the same thing ... but I don't have time to work on it at the moment. If anything, this program should be rewritten from scratch using Python and PyQt.

Wikinaut commented 9 years ago

@Rupan

There are several problems, not the least of which is the fact that the user interface definitions are defined in a Borland-specific format that only works on Windows.

Should be changed.

this program should be rewritten from scratch using Python and PyQt.

Unfortunately, I am not familiar with these languages.

Okay, but keep informed that I am interested. If you start a "stub" code, I could improve it, write documentation and so on.

Zorgatone commented 8 years ago

I agree we need a unix port of this :stuck_out_tongue:

Zorgatone commented 8 years ago

I'm curious to see how this will progress

@Rupan

Wikinaut commented 8 years ago

someone must start, removing the Windows-specific stuff and replacing with stubs (for the GUI), so that first a commandline version exists, which does

Coder:

binary-file-input -> coded pdf output (which then can be printed)

Decoder:

scanned image (png/tif/pdf) -> decoder -> binary file output

For scanning, I recommend to use gscan2pdf (I am co-developer of it).

I do not see any need for a GUI.

Zorgatone commented 8 years ago

Neither do I

Wikinaut commented 8 years ago

@Rupan @Zorgatone can you help?

Zorgatone commented 8 years ago

I'm not good with WinApi and TWAIN scan/print :cry:

Wikinaut commented 8 years ago

@Zorgatone the first thing is to get rid of GUI and all direct input / output. Just read from file and write to file.

Rupan commented 8 years ago

At the moment I don't have the time or energy to produce such a port. Also, 0.25 bitcoins isn't enough ... perhaps 2 - 3 bitcoins is a more reasonable number.

Wikinaut commented 8 years ago

@Rupan Yep, you are right, but I wanted to make a first bid.

I looked into the code, and found also assembler code in it, and you compiled parts in extra projects (libs). So, if someone (you?) really can help, I will increase my bounty significantly.

As said: a GUI is not necessary, a mere command line version which compiles on my Linux box, and which can later be extended, will fit.

Rupan commented 8 years ago

The precompiled bits are 3rd party libraries (including the assembly code you mention). Correctly building the Gladman AES and SHA code using the Borland C compiler is somewhat nontrivial, so I did it once and used the static libraries to produce the final Paperbak builds. The interesting bits which perform the data coding are all distributed in source form.

I am a software engineer, so my day job involves writing and maintaining code. Writing additional code after I come home from work is a labor of love, and has to be something I am very interested in since it takes time away from my family.

Wikinaut commented 8 years ago

I am going to increase my bounty if someone shows up showing real interest to port (migrate) to a Linux command line version (gcc complier suite), code which can be later improved by others.

HASDYI commented 8 years ago

@Wikinaut I am interested. How can we get in touch?

HASDYI commented 8 years ago

@Wikinaut Still interested...

HASDYI commented 8 years ago

@Wikinaut Still interested...

Zorgatone commented 8 years ago

Did he die? :stuck_out_tongue_closed_eyes:

HASDYI commented 8 years ago

It seems so :sob:

Wikinaut commented 8 years ago

@HASDYI @Zorgatone I'm back, not dead. Need now to find a way to handle "multiple" solutions (regarding the bounty), so what to do if two of you come up with a working solution ?

@HASDYI what is your previous work, and your experience ? Your github account https://github.com/HASDYI does not show any activity yet.

Zorgatone commented 8 years ago

I'm interested for The final product not the bounty. I don't know how to port this

Wikinaut commented 8 years ago

@Zorgatone ok, I understand. Until we have a working solution, look to what i have started: https://github.com/Rupan/paperbak/wiki .

Zorgatone commented 8 years ago

:+1:

HASDYI commented 8 years ago

@Wikinaut Apologies for the delay, this github account is used to remain anonymous for various personal reasons. I have been a developing software since 2006 and professionally for the past 5 years. I have a special interest in security and electronics. I have a good understanding of Linux and cross platform C++ development (specifically between Windows and Linux (have not done C++ development for OSX)). In terms of quality of the result, you will have to take my word for the fact that you will greatly impressed.

To minimize your risk in terms of the bounty, I'm sure we can come up with an exchange mechanism once the project is complete.

HASDYI commented 8 years ago

@Wikinaut If you would like, please provide me with your public PGP key. We can then arrange a secure channel to communicate.

Wikinaut commented 8 years ago

@HASDYI ok, I understand.

I suggest you first read what I compiled here: https://github.com/Rupan/paperbak/wiki as reference and overview about existing and similar programs, so that we are on about the same level.

The I suggest you clone https://github.com/Rupan/paperbak to your own github repo, where we then can exchange our ideas/bug reports about the code.

When submitting changes please keep in mind, that when you submit your code to Github, the git config settings contain at least a user.name and user.email .

Please keep in mind that my bounty is voluntary, and I do not' want to use the formal "bountysource" way ( https://www.bountysource.com/ ), because they take some percentages as fees. On the other hand, I shall indeed increase the bounty.

Regarding the channel, I have to think about how we can do this.

Zorgatone commented 8 years ago

Also please, try to keep the "crossplatform cli" version of the program compatible with the original :smile:

Wikinaut commented 8 years ago

@Zorgatone Yes. A "must have" is compatibility.

@HASDYI code for controlling a scanner can perhaps be "borrowed" from the http://gscan2pdf.sourceforge.net/ project.

HASDYI commented 8 years ago

@Wikinaut Please send your PGP public key so we can discuss. We can use the issue at https://github.com/HASDYI/paperbak/issues/1 as a platform for now

Wikinaut commented 8 years ago

Am 27.11.2015 um 09:29 schrieb HASDYI:

Please send your PGP public key so we can discuss.

My key is attached, pls. send me your key. Usually I respond immediately, but the last days were very busy. Sorry.

fdobrovolny commented 7 years ago

Hey all, I just came across this amazing project and I want it on linux. So can I dig in or somebody already have done so?

Wikinaut commented 7 years ago

As fas as I know, nobody has started re-coding to Linux yet.

Rupan commented 7 years ago

I don't see what the big deal is regarding native Linux support. The binary application executable is self-contained and runs well under WINE. Why not just use it?

Rupan commented 7 years ago

The graphical UI is designed in a proprietary IDE which costs quite a lot of money to purchase, is infrequently updated, and is not F/OSS friendly. The Paperbak code must be linked with proprietary Borland static libraries in order to render the UI, and cannot therefore be compiled or linked by Visual Studio.

bgklc commented 7 years ago

It would be great if all the functions were available from the command line (as a first step of porting) with no GUI at all.

fdobrovolny commented 7 years ago

Well I want to port it to python so it would be Windows / Mac / Linux compatible. + No third party paid compiler.

Dne st 30. 11. 2016 10:53 uživatel vics notifications@github.com napsal:

It would be great if all the functions were available from the command line (as a first step of porting) with no GUI at all.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Rupan/paperbak/issues/1#issuecomment-263830492, or mute the thread https://github.com/notifications/unsubscribe-auth/ABMR30SclSwA5AMPIGMqqUZNJEzMbtl6ks5rDUebgaJpZM4EcWYj .

Wikinaut commented 7 years ago

@BrnoPCmaniak Well, go on ! I will sponsor this project (on success only, of course). A part of the code is in Assembler! Must be ported, too.

Wikinaut commented 7 years ago

@BrnoPCmaniak before you start, please read further ideas collected here:

https://github.com/Rupan/paperbak/wiki#References_and_further_resources
https://github.com/Rupan/paperbak/wiki#Archiving_PGPGPG_keys_on_paper
https://github.com/Rupan/paperbak/issues/1#issue-76906829 (top post here, section @Rupan)

justinbass commented 6 years ago

I am currently interested in this project, but found it to be way out of date in terms of language choice (c and WinApi), not extensible (requiring an obscure compiler and assembly code), poorly documented (no schema or spec), not callable from command-line, not cross-platform, and with a lot of cruft (scanner/printer unnecessary). While Paperbak is an awesome project, many improvements can be made.

So, I am (also) undertaking the effort to completely rewrite this in a modern fashion (Python, backwards-compatibility kept in mind, well-documented Schema, etc.). Repo here: https://github.com/colorsafe/colorsafe

Currently only encoding from cli is supported, and I haven't verified correctness. It's not ready for initial release just yet, but posting here anyways since I believe I've solved most of the hard problems in making this useful for serious archiving, and the Schema is fairly well fleshed out. Any ideas are most definitely welcome at this point.

fdobrovolny commented 6 years ago

I did some work to port it too https://github.com/BrnoPCmaniak/python-paperbak/ it can encode and decode data into/from blocks, but didn't had time to finish drawing them and reading them from image.

I have to really appreciate @justinbass code it looks much simpler.

Wikinaut commented 6 years ago

@BrnoPCmaniak @justinbass perhaps you can work together? Let me know, when you have something ready for me for testing.

surkeh commented 6 years ago

I've been working on a cross-platform CLI version of this, off and on, with minimal changes to the original. I dropped direct printer, scanner, and GUI support for the same reasons others have. All that remains is to support decryption (we dropped encryption since the encryption used in the original is known to be broken and compression because better alternatives exist) and to make multiple image decryption less finicky. We've tested with a few compilers, as noted in the readme.

https://git.teknik.io/scuti/paperback-cli

justinbass commented 6 years ago

@Wikinaut, I am basically done with the first step of ColorSafe - encoding produces a printable 100dpi PDF, and after scanning it at 3x resolution, the decoded output is fairly accurate for the single file I tested. Technically my code meets the criteria of your original bounty requirements. However, there were few/no stipulations in the bounty, and my code is extremely fragile and not even v0.1 yet (no image rotations, >gigabyte memory usage, not user friendly, code messy, probably won't work for most files). It's in progress, of course.

I'm not sure what your passing criteria was, but I cannot accept a bounty anyways (due to my employer) - I was going to request you donate it to the Free Software Foundation or post the same bounty for a different project (paperback-cli seems to be closest to the original goal, but I could not get it to work on Cygwin in Win7).

What I would be interested in is if @Rupan posted the related projects (in no particular order) in the PaperBak README to give the successor projects a tiny bit of exposure.

Wikinaut commented 6 years ago

@justinbass I will try the code/s soon. Thanks.

Wikinaut commented 6 years ago

@surkeh Thank you for your post here. I will also try your code later. Do you intend to move the code to github?

Wikinaut commented 6 years ago

To all of you: I think, all (new) command line code should be

backwards compatible (i.e. should allow to read and decode papers which were encoded and printed with the orginal version)
compile and run on all Linux systems, not only x86 architecture (i.e. should not use assembler code)
should make use of modern encryption and checksum/hash standards
should allow input and output in standard formats (tif/png/gif/pbm) - bmp(manys flavours, so support of all bmp will be too difficult and perhaps not needed)); pdf - anything else?

surkeh commented 6 years ago

@Wikinaut, had no intention to move it but it is under GPL so feel free to host a mirror on Github. The friend I've been working with asked that I post a list of completed features so I will combine that with a response to your specifications. Our original goal was to rewrite and refactor, as minimally as possible, into a version of paperback that followed the UNIX philosophy. A thorough refactor into maintainable code is our plan for a phase two but feature-complete, crossplatform operation is our current goal.

Backwards compatible

Shall read, decrypt as needed, decompress as needed, and decode scanned images created by Paperback 1.0 and 1.1.

We have all of this except decryption of images decrypted by 1.10. Decrypting images created in 1.0 is painless because the version doesn't have the binary blob. @Rupan, you mentioned you were able to compile Gladman's AES library in Borland C. I've been trying to compile that version in GCC with little luck. Any tips would be appreciated. @justinbass, have you been able to decrypt images created by paperback 1.10? This should work on Linux and Windows but will be limited to x86 until an equivalent to the assembly portion is found or written.

Crossplatform

Shall compile and run on Windows 7+ and Linux.

This is where C is less than ideal but these problems have been solved. Our solution was to use POSIX types and compilers on Windows that have POSIX types available, converting where necessary. Borland has been purged. @justinbass, thanks for giving this a shot on Cygwin. Has been fixed and tested in msys2. This was due to differences in compilers due to unspecified areas of C.

No encryption, no compression

While we do support decryption and decompression for backwards compatibility, we opted for the UNIX way; do one thing and do it well. Highly recommend that gpg is used for safety, maintainability, and composability, as well as for the wealth of options it provides. In a similar vein, programs such as 7z should be used for compression.

Input and output in a standard format

Shall encode BMP images. Shall decode BMP images.

It is straightforward to create and read BMP and BMP-based formats, and scanners can typically create BMPs. For our simplified version, formats that offered additional effects are unnecessary complication that would be better handled through image converters.

justinbass commented 6 years ago

@surkeh Generally looks to be working now, but I haven't tested it extensively. There are tons of minor problems, like the --help not working, and multipage decoding seemed to output nothing:

./paperback-cli.exe --decode -i a_0001.bmp -o in.txt -p 0

I myself would consider this to pass the bounty requirements. It still needs a lot of polish, but it's generally usable as is.

Wikinaut commented 6 years ago

ping to all: I'm not away. I am very busy preparing for the 34c3 congress and so on. Will come back later to your paperbak commandline versions in early 2018!

Wikinaut commented 6 years ago

@surkeh @justinbass please look here: https://github.com/Wikinaut/paperback-cli , yesterday I had the time to try your code, it works. Thank you. There are some issues, but I will help to fix them.

I wanted to send you a first pull-request regarding the https://github.com/Wikinaut/paperback-cli/commit/429f365367e30df6b66c8eec30029341117e5921 , but cannot sign-in to your repo https://git.teknik.io/scuti/paperback-cli , because this service requires an invitation to register.

Wikinaut commented 6 years ago

Update: see https://github.com/Wikinaut/paperbackup/blob/patch-1/README.md for another software list (ColorSafe and Paperbak-cli added there).

Rupan / paperbak