|
Never heard of that coin, can't really help you there =O
|
|
|
|
BTW, how hard is this to port to an alt-coin?
As in mod Armory to run on an alt coin? Depends on much the txn and block rules have been modified. There's also the matter of the client API. Assuming they don't use bitcoind like JSON packets, you need to port that part too. |
|
|
|
|
Windows users: The load error was due to the use of pthread_win32 to support pthreads on Windows (pthreadVC2.dll). The DLL is built on some dependencies found in the .NET Framework SDK. As a result I ported pthreads myself and the error is fixed.
I am now in quite a predicament with WinXP, as it doesn't support condition variables (gg MS). I'll have to hack my way through it, and I still have a lot on my queue, so WinXP users, you'll have to wait some more ='(.
|
|
|
|
Okay. Mr. goatpig, let me know if you have a new XP build for me and others to test. I have a (almost) clean install of XP SP3, and I keep it that way.
Working to resolve the current Windows issue, this should give me a clue as off what's wrong with the WinXP build. |
|
|
|
Windows Builds:
Try the MSVS 2012 redist, that's the only one I can think off that may be missing. This is the same issues as the WinXP builds I've distributed recently and I have to investigate the error on a clean install to find it out.
I installed the MSVS 2012 redist, which added "Microsoft Visual C++ 2012 Redistributable (x86) - 11.0.60610" as an entry to Programs and Features. Unfortunately, I still get the same error. Thanks for the suggestion goatpig. Is there also a .NET Framework that should be installed along side it? I'm now 99% sure this issue stems from a file missing in the package. Give it until Alan gets back and confirms this, he'll build a new installer with the fix. This build shouldn't require those runtimes nor .NET framework binaries that aren't already packed with stock Win7 |
|
|
|
|
Windows Builds:
Try the MSVS 2012 redist, that's the only one I can think off that may be missing. This is the same issues as the WinXP builds I've distributed recently and I have to investigate the error on a clean install to find it out.
|
|
|
|
You don't need to rewrite the BIOS eeprom. You can stick the payload (or its bootloader) in any of the other NVRAM locations and inject it into the running BIOS during boot when the infected device is brought up.
It is obvious that the kind of measure I'm talking about only makes sense if all such locations are enforcing the same security measures. A shielded front door is useless if the window right next to it is wide opened. |
|
|
|
I don't think any software at all would be invulnerable to BIOS-based malware that meets the description of BadBIOS, especially if you assume BIOS-based malware that is specifically aimed at wallets. This is independent of whether BadBIOS exists as described.
As long as writing operations to the BIOS' eeprom are dependant on a hard jumper setting, you're going a long way to thwart root kits. |
|
|
|
WinXP users: second attempt =O Same disclaimer as before: this is my build (goatpig), not ATI's. Use at your own risk. Just getting Armory to start in offline mode is enough to confirm the build is WinXP compatible.https://mega.co.nz/#!xQwT0TRD!FgRbBD6vPAaoZulqHqe5qByy1d4sgRpqjmrShEKCZCU |
|
|
|
WinXP users: better late than never! Note: this is my build (goatpig), not an official ATI (Armory Technologies Inc.) build. I'm offering this build to willing WinXp testers in order to iron out the WinXP building process.This file is a rar archive containing compiled binaries that hopefully will run in WinXP. Succeeding to start Armory in offline mode is enough to confirm the binaries are WinXP compatible. Use it online at your own risk! https://mega.co.nz/#!xQIgyIwT!LixQalxUuStJhNUYao217WVVRY0bjNuxMxUzliuUIAk |
|
|
|
|
is pthreadVC2.dll in the install folder?
|
|
|
|
Lol, I phrased that slightly ambiguously, I realise you were planning on using copper wires, and not loudspeaker and microphone! That could be difficult to get working, and it would bring a whole new concept of (literal) eavesdropping into the mix too. I would assume that all the bandwidth is in the high frequencies, and of course, higher pitched sounds travel further before their "information" dissipates. I don't think we need the added expense of sound proof transaction signing booths in our regular setups quite yet!
The protocol would be different, the data rate reduced, it would be exposed to external sources of noise, allow for possible man in middle attack vectors and an array of issues that I don't need to dwevle into. The point is fundamental anyways: it is possible to get the data moved over the air gap, but such functionality potentially steps out of the current offline transaction signature paradigm currently delivered by Armory. |
|
|
|
If you're dealing with wallets containing large holdings to protect, it's worthwhile considering using a dedicated machine, to be used for broadcasting transactions and for no other reason. Even just a VM for broadcasting only would be a decent measure. After all, you would never fire up either a physical or a virtual machine for any other purpose if that was how you worked, it would at least shut off opportunities to attackers.
Liking the sound of goatpig's progress with analogue air-gap traversal.... I would happily contribute something to a development fund if he were to set up a thread outlining a proposal.
I'm not trying to send data over an air gap. This library I'm developing is to enable sending data over soundcards linked together by double ended audio cables. I don't intent to allow it to function over speakers and mics unless Alan insists upon that feature. Proof of concept is nearly done with a speed of 1 bit per Hz. I think I have a reasonable chance to achieve 2 bits per Hz without the need for massive research and protocol overhaul. |
|
|
|
|
Ok sorry about the folder. I'm in front of a XP machine right now and can't really find the folder. Not my machine though as I'm not home, so I'm not gonna install anything on it. I've given up on the xp toolset and will iron out a msvc9 toolset build as I get back home.
I have personally run msvc9 toolset built code on Win2k. From what I've seen of the Armory source, I think there's a 2/3rd chance it could run on Win2k. I'm 99% positive I can get the current Armory code to run on XP. Just a matter of testing the build first hand.
|
|
|
|
i tried this on XP Pro SP3 32-bit (with nothing else special installed), then installed the xp build from earlier in this thread. still getting the same errors in logfile upon running:
Traceback (most recent call last):
File "ArmoryQt.py", line 21, in <module>
File "psutil\__init__.pyc", line 85, in <module>
File "psutil\_psmswindows.pyc", line 15, in <module>
File "_psutil_mswindows.pyc", line 12, in <module>
File "_psutil_mswindows.pyc", line 10, in __load
ImportError: DLL load failed: The specified procedure could not be found.
did i miss another implied step somewhere in this?
Have you installed the MSVC9 redist from the link I gave? If you did, can you copy msvcp90.dll and put in your Armory installation folder? It's should be in Program Files/Visual Studio 9.0/VC/Redist/X86 I am trying to get this running on XP 32bit as well. I found msvcp90.dll in another place ( I don't have a Program Files/Visual Studio 9.0/ dir. ). I put it in the Armory folder and still get the same error message above as els. Thanks for helping out with this... I think there may be others like him and me who want to use an old XP system for an offline wallet. It needs to be the msvcp90.dll from the package I linked. There are several versions of this DLL distributed by MS and py2exe only links against the one from that package. Regardless, I've concluded this path is too convoluted. I've found a simple way to build the entire project with msvc9/10 toolsets, that still support WinXP. I'll update the msvs projects once I'm back home, push them to my branch and have Alan build and distribute a test version with these. So this'll have to wait till Monday, sorry. |
|
|
|
i tried this on XP Pro SP3 32-bit (with nothing else special installed), then installed the xp build from earlier in this thread. still getting the same errors in logfile upon running:
Traceback (most recent call last):
File "ArmoryQt.py", line 21, in <module>
File "psutil\__init__.pyc", line 85, in <module>
File "psutil\_psmswindows.pyc", line 15, in <module>
File "_psutil_mswindows.pyc", line 12, in <module>
File "_psutil_mswindows.pyc", line 10, in __load
ImportError: DLL load failed: The specified procedure could not be found.
did i miss another implied step somewhere in this?
Have you installed the MSVC9 redist from the link I gave? If you did, can you copy msvcp90.dll and put in your Armory installation folder? It's should be in Program Files/Visual Studio 9.0/VC/Redist/X86 |
|
|
|
|
I've had this problem before. Try to first change your coin password, then send.
|
|
|
|
No offense to Dabs (sorry Dabs!)
None taken. But you have to understand, a lot of corporate environments tend to stick to really really old ancient operating systems and other software. I'm not exactly there, since this is personal usage, but I understand enough to know that I can do almost anything on an older OS like XP while taking up less resources. I do think, a bitcoin wallet should be able to work on something like XP. (well, QT still works on 32 bit XP, so I'm not complaining.) Can you install this: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=9b2da534-3e03-4391-8a4d-074b9f2bc1bf&displaylang=enThen try again to run the last win_xp build Alan gave you. |
|
|
|
|
I don't know if Alan got my email as gmail decided to stop working right when I figured out the trick. I'll update the projects and push it to the repo tomorrow. That one should get Armory working on WinXP.
|
|
|
|
|
Show Posts
