Here's my build script for mono for non-Windows users to use.
The Ubuntu supplied Mono is too old to run this program.

Please, OPEN UP AND CHECK, AND IF NEEDED, MODIFY THE SCRIPT!
If you don't, I'll make you do it.

It's a shell script, so when downloaded, make it executable, and then run it in a terminal.
(cd to the directory if needed, then run ./build_mono)

This is using latest mono version, so you don't need to modify the MONO variable.

To be fair, I haven't tested it thoroughly, since my server sucks at building things fast.
It should work though, considering that I've took an existing working script and modified it.

Here it is!

My server will take
4000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000

I can't really run this until that is implemented, since I won't be able to do my HW while that is running.
The above range will run on my server for now (withg.us.to under ircuser).

broooom is working on a server atm. The server can give the starting point as well if needed.

I have errors too.... regarding "Access denied":
arthur@arthur-PC:~$ mono Nspire*.exe
1024 bit TI-Nspire boot2 RSA Key:
0xc3b3a7015c04299ff3a25f104e2285c1ec2d55471e6208959d0f6981b2fa2c6d
0x3e316f9364d5eb5c7789e142b75bfaf402e7e02fac0cb09f6419db1f44679f8b
0xbcca142f1d312feb095708ef175a4ef80271321e7240f0d854c90a74fc59209c
0xdf80aa8f85ae3b948a3ce55c69cd050098d5a79aebbc241cc642b106b1af2cb7


Unhandled Exception: System.ComponentModel.Win32Exception: Access denied
  at System.Diagnostics.Process.set_PriorityClass (ProcessPriorityClass value) [0x00000] in <filename unknown>:0
  at (wrapper remoting-invoke-with-check) System.Diagnostics.Process:set_PriorityClass (System.Diagnostics.ProcessPriorityClass)
  at NspireKeyFactorer.Program.Main (System.String[] args) [0x00000] in <filename unknown>:0
arthur@arthur-PC:~$


I think the current plan is to get a good base working, API and all (client and server communications), then we can start porting it to C/C++. I'd definitely like to see wxWidgets come into this (although I hate C++, it does have good stuff in it).

Cross platform is key - the .NET based one won't be discarded - it'll still be used for other devices.
The C/C++ one will be used for mainly PCs and such that can run it.

I'm loving this! (Especially the Folding@Home kind of idea! )
Just before we go too crazy, some things I'd like to suggest:

1) Server submission - should be written in PHP or some web language. It must withstand many submissions (a mini DDoS, practically ), and it has to be stable. The client prgm, after submitting, should pull the latest batch of numbers for backup. The server also reports any mirrors (mirrors are a MUST - you don't want numbers lost!), and the server reports if it's the main server or not. It can also report a main/mirror change if needed. If a factor is found, the main server should email everyone the key immediately, and proceed to pastebin the key as well. My server can act as the mirror, but it may need donations to get it at a good state. It won't be a main server tho – 512 MB of RAM is pretty shabby...

2) Client – I'd like to keep it up and running 24/7, but I don't want to have to stop it every time. An idea is to have it probe CPU usage. If it sees high CPU usage, it'll stop. Once the CPU usage goes down, it'll wait for a buffer 2-3 minutes before resuming work. Work, as usual, should be saved as much as possible. That way, it can act like a service/daemon/background program.

Indication of the client's activity can be achieved with wxWidgets via tray icon. (And if possible, a notification)

Also, as said above, it should submit their number, and pull an update list and such.

That's all! Continue discussing numbers!

EDIT: for CPU usage probing, probe every 10 seconds. Don't probe continuously or every second - then you'll be taking 100% CPU...

Yeah same here. The issue, though, is that most people who want to connect their calc to the Internet just wants to do that/play games online. The problem in this case is that most of your projects posts tends to be unnecessarily long (no offense) and from experience, on large forums people dislike reading walls of text. If they cannot find a 2-3 paragraph summary of a project and screenshots they migth simply ignore the thread altogether. I know myself I used to not reply to E:SoR updates just for that reason. Posts were simply TL;DR. Often I simply said nice to see new progress.

Another issue is that it's very technical and most people here are new to that kind of project, so they might take a while to understand, especially that there are no picture.

In other words it might not be that nobody is interested, it might be just that people simply don't have the time to dechiper every technical detail about the project.

Ahh, I see. I don't take any offense though - my initial thought is that technical stuff would attract some people, especially developers. In the end though, the project really more of less appeals to general users than developers (I'd say 60%/40%).

I'll take note of that when I make a new post about this. (I'll probably let this topic die off, and repost late spring-early summer.)

What DJ said is very true.

I don't know any ASM, and I'm positive Axe wouldn't be up to a project like this, plus I'm not very experienced with electronics and hardware. Otherwise, I would love to help with the technical side of this. Right now, all I can do is offer support and my interest.

To tell you the truth, I kinda hate ASM. (OK, not hate, it's just not really my preferred language.) I would have rather code this in Axe, but it isn't powerful enough yet to do what I need it to do (mainly the USB/IO stuff). To be slightly technical, it's basically port modifying. We'll probably see that in Axe 2.0.

The "hardware" is simply your USB cable (or I/O to USB cable). That's all!

In the future (as mentioned above), this project will probably be released as a community proposal (and therefore become a community project). I can't do this alone - I need everyone's help (including you! ) in order to get this up and working! (And to answer your question, Axe is a part of it, since my plan is to add Axiom support for C2I.)

Thanks for all your support!

Thirded. Ndless is pretty interesting, but it's extremely alpha - you should expect nothing (and only nothing) to work.
SVN repository code is usually very volatile (basically, extremely likely to have broken stuff), and Ndless is no exception. (The only SVN that isn't too bad is TiLP, which sometimes has major fixes not found in the regular releases. However, it's probably volatile right now, since libusb-1.0 support is being added.) Exploit discovery and internal probing is one of the major things that make Ndless what it is, and that takes *quite* a while. Then you got to set up an environment for developers to play in - basically, letting people like apcalc and you make programs for the calc without resorting to extreme hacking. And then you gotta make it stable - crashing every time doesn't sound too good, right?

As you can see, it takes a LOT of work to produce a product. Plus the addition of life, it's not going to be fast. However, the end result is a MUCH stabler end product, and more happy people (and developers)!

Granted, if you are a serious developer that is willing to help (and not just toss it onto your Nspire and expect things to work), you're free - in fact, ENCOURAGED to compile and help out! Otherwise, compiling and installing it may not be a good idea, since as I've said, the code is volatile, and it's going to crash a LOT, not mentioning a possibility of bricking. (I emphasize this a lot - you will need to buy a new Nspire if it does indeed brick, and it's not cheap.)