I have successfully uploaded the fatca data packets to IDES. I got response from IDES, now I want to decrypt the messages.
Whenever i tried to decypt using our private key it throws "BAD DATA" error.
I have verified my certificate is valid, and we uploaded same certificate to IDES at the time of registration.
I am using c#.net as per IDES guidelines.
What might be the error and any areas which I can cross check?
Maybe a bit late, but I had published a tool for this.
It's the IDES receiver and it's source code is here.
It's written in javascript
I'd recommend to use the official IDES Data Tool, this one has been validated by the IRS and you can download it from https://github.com/IRSgov/IDES-Data-Preparation-Dot-Net.
Install the IDES tool
Open the Decrypt Notification tab
Upload the received Data Packet
Check your Output folder, you should have the Data Packet unzipped, and among others the XML decrypted.
If you have still problems with this process you can also debug this application from the source code.
Related
Seems like every other day XrmToolBox's Plugin Registration tool fails to connect. It's probably the most fickle tool I've ever used professionally (is this really the best tool for the job? yikes)
In years of working with it, I've not yet found a reliable way to get the tool to connect. Everything connects fine in the browser. But XrmToolBox randomly fails.
And I've never found or read online a reliable way to figure it out except restart your computer, throw salt over your shoulder, spin counter-clockwise once in your chair, try again later.
Anyone have a better way?
The server was unable to process the request due to an internal error.
For more information about the error, either turn on
IncludeExceptionDetailInFaults (either from ServiceBehaviorAttribute
or from the configuration behavior) on the server in
order to send the exception information back to the client, or turn on
tracing as per the Microsoft .NET Framework SDK documentation and
inspect the server trace logs.
That was the only error I got from XrmToolBox. But it led me to solving the problem. Followed this article to enable more detailed error log:
https://community.adxstudio.com/products/adxstudio-portals/documentation/developers-guide/knowledge-base/enable-detailed-errors-on-the-organization-service/
Tried again, and saw that indeed there was a meaningful error in the XrmToolBox logs.
TL;DR: Turn on better error logging in the on-premise CRM web.config! Then try again to get a more helpful error.
I'm currently doing a audit of some Safe Exam Browser features as part of my master thesis, and I started looking into the browser request hash that is used to ensure that people use the safe exam browser in the LMS our university has opted for. As an attempt I just created my own SEB config file (on my mac), and I managed to compute the correct browser request hash from the key I got from said config file. If I re-open the same file in the SEB config editor it still presents me with the same hash (so I can get it again later).
However, the SEB config file I got from the LMS system we use, when I open that and copy the config key, I am unable to generate the correct browser request hashes (using the same code). Does this has to do with OSX vs Windows somehow? Or is there some other mechanism that I don't know about?
Originally asked at the Safe Exam Browser forums.
I'm just about to start building MS Exchange ActiveSync client. I found two type of implementations. I don't know which one is the right approach.
http://social.msdn.microsoft.com/Forums/en-US/os_exchangeprotocols/thread/3b1e73fc-b69a-4ed2-a905-d15af6666f22
http://msdn.microsoft.com/en-us/library/hh361570%28EXCHG.140%29.aspx
First option says that the command being sent to my Exchange server (from my iPhone mail app) and the body is not xml encoded. I really didn’t find any other standard documentation regarding ActiveSync without using encoded xml.
Second option says to use WBXML and ActiveSync HTTP to perform the right action. It seams very well documented.
I'm really confused while thinking what should be the right approach to perform actions like SendMail, Reply, Forward, mark Read/Unread etc..
Can you guys guide me to select right basic approach which supports all versions of exchange servers with minimal change (Exchange 2007, 2010 etc.).
Since you mentioned Exchange ActiveSync, I believe you are building a PDA Mail client ? If yes, you can use WBXML approach.
For example, if you are building a Android application in phoneGap, then you can resolve this issue by two approach. Either user KXML java parser to parser, encode and decode wbxml, xml or a javascript approach with this library.
In order to secure Ajax requests, Ran Bar-Zik sugested to "create a small flash file to receive the data, SALT it and encrypt it with MD5. Than sent it to the server. The attacker is able to see the data but it is encrypted." Does anybody who has done this would want to share the code with the world? Thanks :-)
Mr Ran Bar-Zik is mistaken. The security system he has proposed violates CWE-602 and is "(in)security though obscurity".
In short the problem is that the server is providing data to a client side application. The client can do whatever he pleases. He can modify the javascript code or intercept and modify all communications using TamperData or Burp Proxy. A flash application can be decompiled and any secrets stored in memory can be obtained with a debugger like ollydbg. There is no solution to this problem.
I have a windows exe app that used to sends packets to a server in the clear. This app (lets call it the client app) is definitely close sourced, but some clever hacker hex-edited the binary, and made it send packets that are scrambled.
Now, obviously, those packets are scrambled in a way that is decipherable (otherwise the server would not be able to understand it), but what I wanted to do is to write an emulator that emulates this binary app, sending the same packets to the server, and being able to unscramble the response (if it is scrambled).
The hex-ed client required an extra dll in order to run, which the old client did not. I am assuming that somehow the hex-ed client managed to load that dll (lets call it client.dll) and the function of that dll is to implement the scrambling/unscrambling, by hooking into some windows api that rerouted all packets sent from the client.exe process.
If there are anyone who can direct me on how to even get started on working out how this all works, and how I can reverse engineer the scrambing, that would be really appreciated.
I have no idea what kind of information to provide, but if there is any lacking, just reply, and I will post with more details, and if anyone wants the binaries, I m happy to provide it.
binary download for any interested parties:
http://dl.getdropbox.com/u/46623/client.dll
http://dl.getdropbox.com/u/46623/newClient.exe
http://dl.getdropbox.com/u/46623/originalClient.exe
These wont run because the resource files are required - they are about 3 gigs, so too big to upload anywhere. Names have been changed to protect the guilty =) , but that probably doesnt protect the name of the dll...
I'm assuming that the person which coded this hook which adds encryption to the packet I/O for the aforementioned program has either hooked the relevant Windows' socket APIs (WSASend, send, etc) or hooked the internal program functions used to send/receive data.
This being said, I'd suggest you use a hook detection program (e.g. RkUnhooker) to find out what is actually being hooked. Once you know what APIs are hooked you should also know where these hooks are going and from there on in you'll have to manually reverse engineer the hook functions.
As for the subject of learning how to do this, I couldn't direct you to just one tutorial to teach you everything but I highly suggest you look at the Tuts4You site, it has a plethora of tutorials which would meet all of your needs.
If possible, upload a copy of the edited client & the hook DLL, if I have the time I'll code you replica encryption & decryption functions.
You need to hook the functions exported by the additional DLL and look into the functions being called and the parameters being passed to them. This is not going to be easy since you do not have type information (e.g. the function signatures for the DLL exports.)
Look here for some information on API hooking. You will also need a good debugger try Windbg from microsoft.
As far as I can see the only option you have here is black box testing ie give known input to both systems and compare the responses against each other to find the differences and similarities.
+--------------+
Input--------->| Original App |--------->Response1
+--------------+
+------------+
Input--------->| Modded App |--------->Response2
+------------+
Now once you figure out how to use the functions from the additional dll you can use it yourself in the same way the original app does.