Hex to Arm Converter Online
- Thread starter NeoGranzon
- Start date
- Views 5,213
- Replies 20
Hex is just a way of displaying binary in something more readable than 00011111001110011101111...
ARM is a type of chip popular in embedded devices for some years now, though there are various flavours as development does happen in it to make new functionality in newer/more powerful chips and even without that then the GBA's own ARM processor has two modes (one called ARM, and another called THUMB) that use unrelated decoding.
That site then looks like what is called a disassembler. It will turn hex code into the text versions (called opcodes) of instructions that the CPU runs according to the pattern you tell it to decode with.
If you find the binary (be it from the ROM or snatched out of the RAM for those consoles that stick code in RAM) you can feed it to a disassembler to generate the text representation of said opcodes (assuming it is not compressed, not encrypted and the right decode mode picked for the areas you care about).
Cheat makers will use them for a variety of purposes as it gets you out of boring and basic RAM manipulation and actually speaking to how the code operates (though most will start knowing a RAM address for something they care about -- know where health is and whatever manipulates it will soon before said manipulation have calculated damage and how to change it, or merely how it works ( https://www.dragonflycave.com/mechanics/gen-i-capturing would likely have been made by such methods), or allowing you to hardcode cheats into the game (two main methods being alter the instructions -- subtract one from lives becomes add or do nothing so easily, hopefully there is only the one and not one method for every way you can die, or you find something that is constantly run like vblanks and add in a quite write to the given area (or check for control pattern and then write, or check for some range and act accordingly if greater than/less than).
ARM is a type of chip popular in embedded devices for some years now, though there are various flavours as development does happen in it to make new functionality in newer/more powerful chips and even without that then the GBA's own ARM processor has two modes (one called ARM, and another called THUMB) that use unrelated decoding.
That site then looks like what is called a disassembler. It will turn hex code into the text versions (called opcodes) of instructions that the CPU runs according to the pattern you tell it to decode with.
If you find the binary (be it from the ROM or snatched out of the RAM for those consoles that stick code in RAM) you can feed it to a disassembler to generate the text representation of said opcodes (assuming it is not compressed, not encrypted and the right decode mode picked for the areas you care about).
Cheat makers will use them for a variety of purposes as it gets you out of boring and basic RAM manipulation and actually speaking to how the code operates (though most will start knowing a RAM address for something they care about -- know where health is and whatever manipulates it will soon before said manipulation have calculated damage and how to change it, or merely how it works ( https://www.dragonflycave.com/mechanics/gen-i-capturing would likely have been made by such methods), or allowing you to hardcode cheats into the game (two main methods being alter the instructions -- subtract one from lives becomes add or do nothing so easily, hopefully there is only the one and not one method for every way you can die, or you find something that is constantly run like vblanks and add in a quite write to the given area (or check for control pattern and then write, or check for some range and act accordingly if greater than/less than).
@FAST6191 thank for reply,but i need an example of where to put the HEX codes and then see them converted to ARM.
ah, that one. first you need to figure out if the code is little or big endianess.
to see what i mean:
for switch: NOP is D503201F
as for where to type in the hex bytes, that would the left side where it says "hex code:"
if you type in D503201F you will get "fnmadd s21, s30, s0, s0" as a translation for arm64
if you type in 1F2003D5 you will get "NOP", so its a matter of first finding out what endianess your codes are.
i dont know how sony is with the endianess, but you would need to find that first.
also, remember this side is for translating, if you want the reverse,
click the "HEX TO ARM" part and write in the asm there.
(again, i dont know how sony writes there codes.)
to see what i mean:
for switch: NOP is D503201F
as for where to type in the hex bytes, that would the left side where it says "hex code:"
if you type in D503201F you will get "fnmadd s21, s30, s0, s0" as a translation for arm64
if you type in 1F2003D5 you will get "NOP", so its a matter of first finding out what endianess your codes are.
i dont know how sony is with the endianess, but you would need to find that first.
also, remember this side is for translating, if you want the reverse,
click the "HEX TO ARM" part and write in the asm there.
(again, i dont know how sony writes there codes.)
So you have a bunch of conventional cheats (usually left as hex. https://web.archive.org/web/20080309104350/http://etk.scener.org/?op=tutorial is for the GBA but the principle works on most systems, though pointer codes are common the later you get in systems so pay extra attention to those. enhacklopedia https://doc.kodewerx.org/ covers cheat formats on older systems, not sure what to link for the vita but whatever emulator or cheat program you use should have a breakdown of the formats for a given newer system) and want them running on the ROM/emulator without the need to do anything? This is usually called hardpatching cheats. https://gbatemp.net/threads/crackers-ds-trainer-maker-tutorial.44410/ is very old and for the DS but the general process is the same whether you are on a commodore 64 or latest 64 bit processor to even think about playing PC game.
Two main options.
Get a debugger (don't know what emulators have here, what external tools there might be for emulators for this system or whether you have to use hardware like the original PSP and some playing on the DS in earlier days). Set break on write (possibly break on read as that might happen earlier) to the area addressed by the basic hex code (or make a cheat that does it). Do something that changes it (fire a bullet, lose a life, use a spell, spend some money... whatever the code deals with really).
The debugger should trigger saying this instruction from this location* did the deed. Now it will probably be a basic write but prior to that (which a basic debugger will include) will have been a bunch of calculations to generate the number to write. Subtract 1 from lives value now becomes add or NOP so very easily and thus jumping in the pit adds a life or does nothing depending upon what you did (again hopefully losing lives is a single routine and not 50 different things corresponding to all the ways you might die, in which case you have 50 different things to handle).
Find the vblank routine (should be obvious and happens say 60 times a second and is a type of interrupt so should be reflected in the CPU flags and such so eh). Find some space in the code (jump to a new location, optimise some code, overwrite some unused data, add it to the end of the list...) and add in a write to the location dictated by the cheat. This is what most classical action replay, gameshark, codebreaker, gold finger, pelican... cheat devices were doing. Might not work in some scenarios if the write happens too late (calculate damage, massive damage so health is zero, oh OK death, at that point your write comes in too late. I used to use such things in N64 Goldeneye as an example as it was a good one -- put in an AR code and then go eat a rocket/explosion, you will die where bullets do nothing and in game invincibility cheats work fine). Does however dodge the 50 different things tickling the same area and all needing their own modification problem.
In either case it is not so hard to add a compare to check for conditions to happen (be it controller state or some more complicated "I want health in this range but never more than this" type deal), or in said working backwards through code figure out a concept you don't like (maybe you disable poison damage in a RPG but leave everything else in the damage calculation, or you half the damage it does by adding in a shift to the calculation at a relevant point). Congratulations you are now an assembly hacker doing real stuff. It gets more and more interesting with more and more subtle but also game changing options you can go in for from here -- fancy moon jump as you understand gravity in the game, understanding structures to in turn edit levels, subtle rebalancing of game mechanics (there is a reason I linked the pokemon stuff earlier, most games have something like this at their heart doing things but that is an example of notable complexity that most reading this would understand at some level), disable checks on money so you can buy the most expensive items in the game (where the write command earlier might do for a hardcoded cheat then it will likely have been preceded by a read to make sure you had enough money to buy it in the first place, same also applies to health codes but now you also don't get any knockback as the enemies never hit you in the first place/do 1 damage, one way of doing equip anything as well but you could also figure out the flags on which classes/characters can equip and edit the game's internal weapon data accordingly as a big boy ROM hacker).
Some will go for more brute force methods, do a static (or grab dynamic from debugger) disassembly, search for anything tickling the location you found for your cheat. Can work and being a text search takes a few seconds to try at best.
*If you are dumping RAM then this location will be part of the binary, as likely will be things surrounding it. If your debugger somehow does not have a disassembler of its own (it should, they are fairly basic to make, and if it is a debugger you will also have the added perks of knowing what mode the CPU is in and what flags are set. Your online link you started this out with being the equivalent of the text box I wrote this site gave me to reply in compared to the formatting options of a professional document layout program). Though the location of binary in RAM is probably obtainable from ROM info tools used by hackers, emulators and more besides as it has to know what file to copy and where to copy it to in memory to in turn run the game, not to mention stuff in RAM is usually uncompressed and unencrypted if that is going to be a thing (though there are downsides in some cases like not all code being there if it is not needed -- why waste space holding the credits animation sequence if that plays once every 100 boots/50 hours? This is called dynamically linked code, DLL in Windows world, overlays in DS games, various WRAM loaded code in GBA games and variations on the theme in most consoles ever. Some games will also remove code from memory in a bid to up security -- try not to include encryption keys after they are no longer needed but games is less likely to see this. Hopefully nobody is going to throw self modifying code into a game at this point in time -- most programmers got together and decided self modifying code is bad news in the 80s and nobody has really done it since). I don't know what is available for the Vita in this regard but it really is a basic concept that many of those above will need and thus make. That said the vita is not that well supported as these things go, is relatively new and relatively complex compared to some things so you might be advised to drop down to a better supported and somewhat simpler device, on the other hand it is doable enough it seems (several examples out in the wild) and if it is the thing that will hold your interest then the project you will do is the thing to learn on.
https://www.romhacking.net/documents/361/ covers how to find graphics in a GBA game with a debugger (albeit a rather old and command line based one), a process generally called tracing. General principles work much the same for anything though. I don't have a good guide to ARM assembly for beginners and don't think there is likely to be one. To that end learn the basics on the PC https://www.plantation-productions.com/Webster/ https://stuff.pypt.lt/ggt80x86a/asm1.htm and then move sideways, ARM themselves and a thousand other places will have the listings of instructions and various breakdowns of how they work in that case (not necessarily the same as the PC but will be close enough for most purposes and if it clicked for you then it is nothing drastic).
@Gamerjin thanks for reply,don't worry i'll give you an example of the PS Vita Vitacheat code right away
Code:
$0200 82B51658>offset 000F423F>hex
This is what I use when I need a quick (dis)assembler:
https://shell-storm.org/online/Online-Assembler-and-Disassembler/
Here's an example disassembling 04 20 A0 E1 --> mov r2, r4
https://shell-storm.org/online/Onli...s_with_raw=True&dis_with_ins=True#disassembly
Use the first text window instead to do the opposite.
--------------------------------------------
There's also this, which I used to use:
https://onlinedisassembler.com/odaweb/
It's prettier but harder to use, I think. Also doesn't do assembly.
https://shell-storm.org/online/Online-Assembler-and-Disassembler/
Here's an example disassembling 04 20 A0 E1 --> mov r2, r4
https://shell-storm.org/online/Onli...s_with_raw=True&dis_with_ins=True#disassembly
Use the first text window instead to do the opposite.
--------------------------------------------
There's also this, which I used to use:
https://onlinedisassembler.com/odaweb/
It's prettier but harder to use, I think. Also doesn't do assembly.
@zoogie thanks for reply,would you be able to give me an example with the code from my previous post?
According to this:
https://github.com/r0ah/vitacheat/wiki/Write
That cheat code you posted means
*(u32*)0x82B51658 = 0x000F423F;
I have my doubts that second number is an instruction(s).
Edit: The decimal of f423f is 999999, so def not an instruction. There's no need to use an assembler/disassembler with this code.
Last edited by zoogie,
@zoogie ,the 2nd number 000F423F is a value,i would like to know how to convert a type of code like this to ARM with the converter in OP.
PSVita is 32-bit ARM LE so it would be 3F 42 0F 00? Endian conversion is just reversing the order of bytes. There's tools online for that as well if you google endian converter.
@zoogie ,so i'm asking for an impossible thing? So,with this converter you are unable to create any code?
I don't think it's impossible, but it would require a more complex setup to begin. to get started, you would need a debugger to attach to the vita, then you would need to know the address to monitor, and even then the debugger would have to be capable of write/read breakpoints.....
once you have an address that does what it is you want, THEN you can begin to experiment.
once you have an address that does what it is you want, THEN you can begin to experiment.
@Gamerjin ,my question then is: with the converter that i posted you can convert a HEX code like this
Code:
$0200 82B51658 000F423F@Gamerjin ,so i can't do anything if i understand correctly with this converter.
Yes it is mostly a useless tool for your immediate purposes but there are asterisks for the lucky and talented.
You know the address the cheat is for. With a disassembly you might be able to find something that writes to it (less likely in this world of pointer codes compared to older systems where memory was more fixed but hey) and work backwards from there (sub becomes add, or simply generating the number using an immediate* value in a mov and then writing that ignoring previous logic).
*I don't think I covered those above or in the previous topics. There are three sources of information in most considerations of assembly. Other registers (add R1, R2 sort of thing), memory locations (ldm being the base instruction in most ARM stuff as unlike X86 then ARM tends not to allow most general instructions to reach out and touch system memory. https://www.codetd.com/en/article/6450767 is perhaps a bit dense but a reasonable overview) and numbers included within the base instruction which are known as immediates in most discussions of assembly.
In a more glib response method then you could turn that address into a write, or a small section of code to do said same (write value to memory is not a common thing in most assembly and I don't think current ARM is an exception, instead you would want to create said value and then write it which means a couple of instructions). The trick would be finding an injection/hooking point which is far far far easier to do that on a live program with a debugger, though not impossible from a static analysis and someone might even have done that before for your game (see master codes in some other systems, though less likely for a vita where cheats are probably more background OS/firmware affairs). Depending upon the reason for the write then you might be able to plough through from the start -- plenty of cheats over the years have had to have a certain value in memory during boot and can be erased once the game is present, however as the basic cheat construction is always write and most times it does not matter for normal play then most cheats are in turn of the form always write, in this scenario you could start at the start of the code, come in after any memory initialisation to write the value you want and thus have your hardcoded cheat without the need to play with a debugger to find a point to hook for your code like most other cheats. Similarly pick a random point in code has sort of worked -- while every frame is most likely to ensure you get what you want then randomly stuffing something somewhere in code (or maybe just code you found running at a given freeze frame) might not work so well for infinite health the infinite gold for ye boring and basic RPG where you can wait for the say 5 seconds or have to navigate into the menu (or some other more obtuse thing) to trigger it is acceptable at some level.
Short version. Just take the plunge and figure out how to get a debugger going on in a vita emulator or hardware. I would suggest something that is more easy to emulate, has more developed debuggers and is more well documented for the first few steps into this world but if the vita is the thing that holds your attention in this then you can certainly get it going on.
@FAST6191 thank you very much,my interest is not only for the PS Vita(i also have the Switch),i wanted to know if it was possible to create ARM codes without having to use a PC and a program like IDA Pro and do it online even from a smartphone,because in addition to having a 17 year old pc i don't have time to work on it.
Possible. Yes.
Something I would suggest to do while learning? No it is a massive handicap. Someone that already knows what goes and has some information to use as a jumping off point (think hacker is at work but has a phone on a break and a bit of time to improve something despite it being akin to trying to write a novel on said phone on a blogging type platform compared to PC with proper word processor or offer some guidance on a forum) could do useful work but as a learning tool it would sap the motivation of almost anybody I have ever met in hacking, including myself and I was bloody minded enough to teach myself (I come from a more classical engineering background if it matters -- minimal programming and whatever electronics I have was largely also self taught) using the DS which at the time was not what it is today.
17 year old machine on the other hand would still be fine for 99% of debugging purposes for anything in the 8-16 bit era or comparable to it (GBA, DS and many other things like that). The 1% being the more demanding aspects some emulators provide you, stuff like https://fceux.com/web/help/CodeDataLogger.html which can slam a system as you are doing a log/analysis on almost every instruction, potentially useful in finding a hooking point (the random point/freeze frame above becomes far more interesting* if it is more directed) but ultimately people were and usually still do it via the other methods outlined in previous posts in this and other threads you were in. Equally hacking does not have to be real time (20% real time is annoying but I have done it for things), though I am not sure Vita or Switch are within that remit right now.
There may well come a time when the tools available online are good either through development (much of this is glorified text analysis which servers can handle happily), the servers themselves being useful as a remote control machine or the servers themselves becoming powerful enough to operate like that themselves (arguably already are but it is more costly). Likewise someone could step up and port things to android (IOS is very unlikely to see this).
Neither of those are today and I very much doubt it will happen in the next 5 years though -- if it has not happened by now and phones and web have been the domain of turbo nerds since before mobile phones took off. At this point I am probably supposed to say you can still find PCs that might do it but equally if you are in Italy I have spoken to people there before about stuff like this and old computers are kept for a lot longer compared to elsewhere (yesterday for a client I scrapped a couple of broken screen i5 laptops, one with DDR4 RAM and m.2 drive, the other with a nice SSD that could both probably work as desktop machines if pressed to using video out and that is nothing unusual around here or the parts of the US I run around in, drop down to late era core2 and as long as replace someone's door stop or foot stool then yeah).
*when analysing say a make player character jump function in a platfomer you would start the logger. Do everything but jump (idle, move, other buttons...) such that the game sees that, has seen the background animations, background music, hidden timers and whatever else, you then jump and the new code it has not seen before it pretty such to have been the jump command. This can be far easier to find interesting code than watching graphics to see what changes there and working backwards, or watching for things looking at the control state and working forwards from there which is what jump (which has implications for moon gravity cheats, invincibility frames/hitboxes, stamina, certain animations, falling control... or simply refill health when jumping) analysis usually entails.
Something I would suggest to do while learning? No it is a massive handicap. Someone that already knows what goes and has some information to use as a jumping off point (think hacker is at work but has a phone on a break and a bit of time to improve something despite it being akin to trying to write a novel on said phone on a blogging type platform compared to PC with proper word processor or offer some guidance on a forum) could do useful work but as a learning tool it would sap the motivation of almost anybody I have ever met in hacking, including myself and I was bloody minded enough to teach myself (I come from a more classical engineering background if it matters -- minimal programming and whatever electronics I have was largely also self taught) using the DS which at the time was not what it is today.
17 year old machine on the other hand would still be fine for 99% of debugging purposes for anything in the 8-16 bit era or comparable to it (GBA, DS and many other things like that). The 1% being the more demanding aspects some emulators provide you, stuff like https://fceux.com/web/help/CodeDataLogger.html which can slam a system as you are doing a log/analysis on almost every instruction, potentially useful in finding a hooking point (the random point/freeze frame above becomes far more interesting* if it is more directed) but ultimately people were and usually still do it via the other methods outlined in previous posts in this and other threads you were in. Equally hacking does not have to be real time (20% real time is annoying but I have done it for things), though I am not sure Vita or Switch are within that remit right now.
There may well come a time when the tools available online are good either through development (much of this is glorified text analysis which servers can handle happily), the servers themselves being useful as a remote control machine or the servers themselves becoming powerful enough to operate like that themselves (arguably already are but it is more costly). Likewise someone could step up and port things to android (IOS is very unlikely to see this).
Neither of those are today and I very much doubt it will happen in the next 5 years though -- if it has not happened by now and phones and web have been the domain of turbo nerds since before mobile phones took off. At this point I am probably supposed to say you can still find PCs that might do it but equally if you are in Italy I have spoken to people there before about stuff like this and old computers are kept for a lot longer compared to elsewhere (yesterday for a client I scrapped a couple of broken screen i5 laptops, one with DDR4 RAM and m.2 drive, the other with a nice SSD that could both probably work as desktop machines if pressed to using video out and that is nothing unusual around here or the parts of the US I run around in, drop down to late era core2 and as long as replace someone's door stop or foot stool then yeah).
*when analysing say a make player character jump function in a platfomer you would start the logger. Do everything but jump (idle, move, other buttons...) such that the game sees that, has seen the background animations, background music, hidden timers and whatever else, you then jump and the new code it has not seen before it pretty such to have been the jump command. This can be far easier to find interesting code than watching graphics to see what changes there and working backwards, or watching for things looking at the control state and working forwards from there which is what jump (which has implications for moon gravity cheats, invincibility frames/hitboxes, stamina, certain animations, falling control... or simply refill health when jumping) analysis usually entails.
@FAST6191 thanks talking to you is wonderful, i realize all my ignorance in this area of hacking to create cheats.
Yes i live in Italy,it isn't that i lack the money to buy a new PC(maybe not a desktop but a laptop),but for such use it seems a waste of money and i'll explain why:in recent years i have always had a Galaxy Note with video output,i just need the dock or an HDMI cable and connect it to my 19 " TV monitor or 32"(11 and 12 years old respectively)and now i do almost everything with my smartphone.
Yes i live in Italy,it isn't that i lack the money to buy a new PC(maybe not a desktop but a laptop),but for such use it seems a waste of money and i'll explain why:in recent years i have always had a Galaxy Note with video output,i just need the dock or an HDMI cable and connect it to my 19 " TV monitor or 32"(11 and 12 years old respectively)and now i do almost everything with my smartphone.
Similar threads
