I want to know the sample code for sending message to server and get back response to verifone vx520 terminal using ISO 8583.
As noted in a comment on your question, this is not a code sharing site, so such an open-ended question is a bit difficult to answer, but perhaps I can get you started on the right foot.
First of all, let me start by suggesting that if you have control over the terminal code and the server that it will be talking to, I suggest you NOT use ISO8583. Yes, it's an industry standard and yes, it communicates data efficiently, BUT it is much more difficult to use than, say, VISA-1 or XML, or JSON etc. That means you have more opportunities for bugs to creep into your code. It also means that if something goes wrong, it takes a lot more effort to try and figure out what happened and try and fix it. I have used all these protocols and others besides and I'll tell you that ISO8583 is one of my least favorite to work with.
Assuming you do not have a choice and you must use ISO8583 then it's worth noting that ISO8583 is nothing but a specification on how to assemble data packets in order to communicate. There is nothing special about the Vx520 terminal (or any other VeriFone terminal) that would change how you would implement it verses how you might do so on any other C++ platform EXCEPT that VeriFone DOES provide you with a library for working with this spec that you are free to use or ignore as you see fit.
You don't need to use this library at all. You can roll your own and be just fine. You can find more information on the specification itself at Wikipedia, Code Project, and several other places (just ask your favorite search engine). Note that when I did my 8583 project, this library was not available to me. Perhaps I wouldn't have hated this protocol so much if I had had access to it... who knows?
If you are still reading this, then I'll assume that ISO8583 is a requirement (or you are a glutton for punishment) and that you are interested in trying out this engine that VeriFone has provided.
The first thing you will need to do (and hopefully, you have already done it) is to install ACT as part of the development suite (I also suggest you head over to DevNet and get the latest version of ACT before you get started...). Once installed, the library header can be found at %evoact%\include\iso8583.h. Documentation on how to use it can be found at %evoact%\docs. In particular, see chapter 6 of DOC00310_Verix_eVo_ACT_Programmers_Guide.pdf.
Obviously, trying to include a whole chapter's worth of information here would be out of scope, but to give you a high-level idea of how the engine works, allow me to share a couple excerpts:
This engine is designed to be table driven. A single routine is used
for the assembly and disassembly of ISO 8583 packets. The assembly and
disassembly of ISO 8583 packets is driven by the following structures:
Maps One or more collections of 64 bits that drive packet assembly and
indicate what is in a message.
Field table Defines all the fields used
by the application.
Convert table Defines data-conversion routines.
Variant tables Optional tables used to define variant fields.
The process_8583() routine is used for the assembly and disassembly of ISO
8583 packets.
An example of using process_8583() is given elsewhere as follows:
#include "appl8583.h"
int packet_sz;
void assemble_packet ()
{
packet_sz = process_8583 (0, field_table, test_map, buffer, sizeof( buffer));
printf ("\ fOUTPUT SIZE %d", packet_sz);
}
void disassemble_packet ()
{
packet_sz = process_8583 (1, field_table, test_map, buffer, packet_sz);
printf ("\ fINPUT NOT PROCESSED %d", packet_sz);
}
To incorporate this engine into an application, modify the APPL8583.C
and APPL8583.H files so that each has all the application variables
required in the bit map and set up the map properly. Compile
APPL8583.C and link it with your application and the ISO 8583 library.
Use the following procedures to transmit or receive an ISO 8583 packet
using the ISO 8583 Interface Engine:
To transmit an ISO 8583 packet
1 Set data values in the application variables for those to transmit.
2 Call the prot8583_main() routine. This constructs the complete
message and returns the number of bytes in the constructed message.
3 Call write() to transmit the message.
To receive a message
1 Call read() to receive the message.
2 Call the process_8583() routine. This results in all fields being
deposited into the application variables.
3 Use the values in the application variables.
Related
I am using a Keygen application (.exe). There are two input fields in it's GUI:
p1 - at least 1 digit, 10 digits max - ^[0-9]{1,10}$
p2 - 12 chars max - uppercase letters/digits/underscores - ^[A-Z0-9_]{0,12}$
Pressing generate button produce a key x.
x - 20 digits exactly - ^[0-9]{20}$
For each pair (p1,p2), there is only one x (in other words: f(p1,p2) = x is a function)
I am interested in it's encryption algorithm.
Is there any way of reverse engineering the algorithm?
I thought of two ways:
decompiling. I used snowman, but the output is too polluted. The decompiled code probably contains non-relevant parts, such as the GUI.
analyzing of input and output. I wonder if there any option to determine the used encryption algorithm by analyzing a set of f(p1,p2) = x results.
As you mentioned, using snowman or some other decompiling tools is probably the way to go.
I doubt you would be able to determine the algorithm just by looking at the input output combinations, since it is possible to write any kind of arbitrary algorithm, that can behave in any way.
Perhaps you could just ask the author what algorithm they're using ?
Unless it's something really simple, I'd rule out your option 2 of trying to figure it out by looking at input and output pairs.
For decompiling / reverse engineering a static binary, you should first determine whether it's a .NET application or something else. If it's written in .NET you can try this for decompilation:
https://www.jetbrains.com/decompiler/
It's really easy to use, unless the binary has been obfuscated.
If the application is not a .NET application, you can try Ghidra and/or Cutter which both has pretty impressive decompilers built in:
https://ghidra-sre.org/
https://cutter.re/
If static code analysis is not enough, you can add a debugger to it. Ghidra and x64dbg work really well together, and can be synced via a plugin installed in both.
If you're new to this, I can recommend both that you look into basic assembler for the x86 platform so you have a general idea of how the CPU works. Another way to get started is "crackme" style challenges from CTF competitions. Often there great write-ups with the solution, so you have both the question and answer available.
Good luck!
Type in p1 and p2. Scan the process for that byte string. Then put a hardware breakpoint for memory access on it. Generate the key, it will hit that hardware breakpoint. Then you have the address which accesses it and start reversing from there in Ghidra(Don't forget to use BASE + OFFSET) since ghidra's output won't have the same base as the running application. The relevant code HAS to access the inputs. So you know where the algorithm is. Since it either directly accesses it, or somewhere within that call chain is accessed relatively fast. Nobody can know without actually seeing the executable.
I'm trying to decode a h.264 stream using Windows Media Foundation. I'm slowly wading through the API, and one thing I cannot seem to figure out is how to know when the IMFTransform is finished using a IMFTransform provided by ProcessInput. The documentation says "the MFT stores the sample and holds a reference count on the IMFSample pointer." Ignoring the fact that this is absolutely horrendous, how are you supposed to determine when it's actually done, given that you cannot get the reference count of a com_ptr so far as I am aware. You can technically call AddRef and the Release, using what Release returns, but per the documentation the value returned is meant to be used for "testing purposes only". So what is the correct way of determining this?
I want to develop a VGA graphics driver (for Linux(Ubuntu)) with support for the basic primitives such as putpixel, drawline, fillrect and bitblt. I want to do it in protected mode.
I´ve been googling for a week and the following four links are the best I have found:
http://www.brackeen....vga/basics.html
http://www.osdever.n...VGA/vga/vga.htm
http://bos.asmhacker...sing%20bios.htm
Unfortunately, the first one uses a BIOS call so I cannot use it. The second link has lots of information on the VGA registers but no examples showing how to make them work together. The third example is a example to switch in 13h mode but i've tried it and nothing happened. Can you guys give me a hint? Thanks in advance!
--Vincenzo
my code at http://bos.asmhackers.net/docs/vga_without_bios/snippet_5/vga.php
works fine if you are in 32bit mode with full hardware access. Unfortunately I doubt that any Linux variant will let you directly access the VGA ports. I'm not sure how you develop this driver, but if you made sure that you have full access to the VGA ports it should work. In my example code I only switch between mode 0x03 and 0x13, but in the folders above you'll be able to find port values for most other common VGA modes, as well as C code to do the switch if you prefer that.
Christoffer code include files are found BOS operating system source code like text.inc and font8x16.inc
http://bos.asmhackers.net/downloads.php
This is coming many many years later but I think it's still very relevant and if somebody is struggling I hope they can find it useful.
First of all, it is completely possible to configure VGA only using registers without interrupts, as hard as it may be. A useful resource about registers and how to configure them can be found here, but unless you have a ton of time to spare to learn how to properly do all of it, move to the following section.
If you wish to really learn how to do it, I suggest going through with the documentation provided earlier. However, some of it is already done!
Chris Giese did a great job demonstrating exactly how to do this for MS-DOS system, and while you may think that doesn't help you, it really does.
Chris's code can be found here. If you want another useful codes check here as well.
Now, while it only works for MS-DOS it's actually easy to convert to other systems. The code already contains all data needed to configure the registers in many different modes. And that's the part that saves you a ton of time going through documentation.
The code uses functions outportb, inportb, which are MS-DOS functions, to write/read single byte to/from a port. Therefore, you have to redefine these functions to read/write for your own system. Redefinition complexity depends on the system you operate on.
In addition, you will also need to provide means to write to physical memory region between 0xA0000-0xBFFFF which corresponds to standard VGA memory area. Once you have that allocated, you need to also redefine the functions pokeb pokew peekb which will help you output things (text or pixel data) on the screen.
One last note: the code is already defined to work with many different modes including both text and display modes.
I am trying to make an interface with another program so I have to use C++.
It's been years since I have programmed in C++ and I have been at this problem for about a week so I'm slowly starting to see how everything works.
I want to read byte data coming from a serial port device.
I have verified that I can get text through the serial port using the readline command:
For example:
String^ message = _serialPort->Readline();
Is how the data is read in an example from MSDN that I got to work successfully.
However I have tried to modify it several times and I'm having no luck coming up with something that reads the data as bytes. (I already have conversion of byte data to string so I can actually see the bytes such as the number 15 equaling 0f in bytes.)
Modifying the code to
wchar_t message = _serialPort->Readline();
gives me
error c2440: 'initializing' : cannot convert from System::String ^' to 'wchar_t'.
I'm not familiar with Readline. Is it only for strings? I have verified that it does work with strings and if I use a serial device that sends a string the first set of code does work.
Can someone explain what method I could use to read byte data? Thanks.
If you actually want to use C++ rather than C++/CLI, I recommend using boost.asio. It is well established, relatively easy to understand, and has a specific set of functionality just for working with serial ports.
Update
Pure C++ Win32 API versions:
See the following good references
CodeProject article
MSDN
Is there any specific reason you are doing this in C++/CLI code?
I thought you might not even be aware of that (otherwise, tag your questions, please).
String^, Readline etc are CLR functions (i.e. .NET, think: "you could do this more easily in C#). So, again,
If there is a need for this to be in C++, why don't you look at the native Win32 API
Otherwise, why are you bothering with C++
If you really wanted C++/CLI I suggest not mixing native/managed code when handling the serial IO. You can get an UnmanagedMemoryStream to marshal the data in/out of managed land.
$0.02
Would it be possible to take the source code from a SNES emulator (or any other game system emulator for that matter) and a game ROM for the system, and somehow create a single self-contained executable that lets you play that particular ROM without needing either the individual rom or the emulator itself to play? Would it be difficult, assuming you've already got the rom and the emulator source code to work with?
It shouldn't be too difficult if you have the emulator source code. You can use a method that is often used to store images in c source files.
Basically, what you need to do is create a char * variable in a header file, and store the contents of the rom file in that variable. You may want to write a script to automate this for you.
Then, you will need to alter the source code so that instead of reading the rom in from a file, it uses the in memory version of the rom, stored in your variable and included from your header file.
It may require a little bit of work if you need to emulate file pointers and such, or you may be lucky and find that the rom loading function just loads the whole file in at once. In this case it would probably be as simple as replacing the file load function with a function to return your pointer.
However, be careful for licensing issues. If the emulator is licensed under the GPL, you may not be legally allowed to store a proprietary file in the executable, so it would be worth checking that, especially before you release / distribute it (if you plan to do so).
Yes, more than possible, been done many times. Google: static binary translation. Graham Toal has a good howto paper on the subject, should show up early in the hits. There may be some code out there I may have left some code out there.
Completely removing the rom may be a bit more work than you think, but not using an emulator, definitely possible. Actually, both requirements are possible and you may be surprised how many of the handheld console games or set top box games are translated and not emulated. Esp platforms like those from Nintendo where there isnt enough processing power to emulate in real time.
You need a good emulator as a reference and/or write your own emulator as a reference. Then you need to write a disassembler, then you have that disassembler generate C code (please dont try to translate directly to another target, I made that mistake once, C is portable and the compilers will take care of a lot of dead code elimination for you). So an instruction of a make believe instruction set might be:
add r0,r0,#2
And that may translate into:
//add r0,r0,#2
r0=r0+2;
do_zflag(r0);
do_nflag(r0);
It looks like the SNES is related to the 6502 which is what Asteroids used, which is the translation I have been working on off and on for a while now as a hobby. The emulator you are using is probably written and tuned for runtime performance and may be difficult at best to use as a reference and to check in lock step with the translated code. The 6502 is nice because compared to say the z80 there really are not that many instructions. As with any variable word length instruction set the disassembler is your first big hurdle. Do not think linearly, think execution order, think like an emulator, you cannot linearly translate instructions from zero to N or N down to zero. You have to follow all the possible execution paths, marking bytes in the rom as being the first byte of an instruction, and not the first byte of an instruction. Some bytes you can decode as data and if you choose mark those, otherwise assume all other bytes are data or fill. Figuring out what to do with this data to get rid of the rom is the problem with getting rid of the rom. Some code addresses data directly others use register indirect meaning at translation time you have no idea where that data is or how much of it there is. Once you have marked all the starting bytes for instructions then it is a trivial task to walk the rom from zero to N disassembling and or translating.
Good luck, enjoy, it is well worth the experience.